How Cloudflare Saved 100TB of Memory by Optimizing 1.1.1.1 DNS Caching: An Engineering Deep Dive

The Memory Challenge Behind DNS Caching

Cloudflare's public DNS resolver 1.1.1.1 is one of the largest and fastest DNS services in the world, handling trillions of queries every day. Launched on April 1, 2018, it is a public-facing recursive DNS resolution service. A recursive DNS resolver acts like the internet's "phone book intermediary" — when a user types a domain name into their browser, the recursive resolver queries authoritative name servers starting from the root, working its way down the hierarchy until it finds the IP address corresponding to the target domain. Compared to similar services like Google's 8.8.8.8 and Quad9's 9.9.9.9, 1.1.1.1 stands out for its privacy protections and query speed. Cloudflare pledges not to use DNS query data for advertising purposes and regularly publishes third-party audit reports.

At such massive traffic volumes, even the tiniest inefficiency gets amplified enormously. Recently, Cloudflare's engineering team shared a remarkable achievement: by optimizing the caching mechanism of 1.1.1.1, they successfully saved a staggering 100TB (100 terabytes) of memory.

Behind this number lies a core principle of hyperscale systems engineering: details are costs. When your service runs across hundreds of data centers worldwide on thousands of servers, saving a few dozen megabytes of memory per machine adds up to an astonishing cumulative effect.

Why DNS Caching Is So Memory-Hungry

Caching Is the Heart of DNS Resolution Performance

The core value proposition of a DNS resolution service is speed. To deliver domain resolution results to users as quickly as possible, DNS resolvers cache queried records in memory. This way, when the same domain is queried again, there's no need to initiate a new recursive query to authoritative servers — the result can be returned directly from memory.

However, caching comes at the cost of memory consumption. The internet contains an enormous number of domains, and each domain can have multiple record types. DNS record types are different resource record formats defined in the DNS protocol, each carrying different information: A records map domain names to IPv4 addresses (e.g., 93.184.216.34), while AAAA records map to IPv6 addresses (e.g., 2606:2800:220:1:248:1893:25c8:1946). MX records specify the mail servers responsible for handling email for a domain, along with their priorities. TXT records store arbitrary text information, commonly used for email verification mechanisms like SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). CNAME records serve as an aliasing mechanism, pointing one domain name to another. There are also NS records, SOA records, SRV records, and more. A busy domain might have over a dozen different record types simultaneously, each requiring independent storage in the cache.

All of this information — plus metadata like TTL (Time to Live) — resides in memory. TTL is a critical field in DNS records, set by the authoritative DNS server, representing the number of seconds a record is allowed to survive in a recursive resolver's cache. When the TTL countdown reaches zero, the cache entry expires, and the resolver must re-query the authoritative server for the latest record. TTL settings embody a classic engineering trade-off: a longer TTL (e.g., 86400 seconds, or one day) reduces recursive query volume and improves response speed, but increases DNS change propagation delay; a shorter TTL (e.g., 60 seconds) enables rapid IP switching, benefiting failover and load balancing, but increases query traffic and cache maintenance overhead. For caching systems, TTL also means each entry requires additional storage for expiration timestamps, along with continuous expiration checking and cleanup operations. For a service like 1.1.1.1 handling global traffic, the number of cache entries is extraordinarily large.

The Hidden Memory Overhead of Data Structures

In actual cache implementations, beyond the space occupied by domain names and records themselves, there's a significant amount of "hidden overhead":

• Data structure metadata: Pointers, hash table slots, alignment padding, and more. Hash tables are the most commonly used core data structure in DNS caching systems, using hash functions to map combinations of domain names and record types to fixed-size array indices, achieving O(1) average lookup time complexity. However, hash tables themselves carry significant memory overhead: to control collision rates, they typically maintain a 50%-75% load factor, meaning at least 25%-50% of slots are empty yet still consuming memory. Collision handling mechanisms (open addressing or chaining) also require additional pointers and node allocations. On 64-bit systems, each pointer alone takes up 8 bytes. Furthermore, when hash tables resize, they typically need to double capacity and rehash all entries, briefly consuming double the memory.
• Redundantly stored information: Different records for the same domain may contain duplicate data.
• Waste from memory alignment: For access efficiency, compilers perform memory alignment on data structures, causing byte-level waste. Memory alignment is a fundamental concept in computer architecture — modern CPUs don't read memory byte by byte but in fixed-size "words" (typically 4 or 8 bytes). When data's starting address is an exact multiple of its size, the CPU can complete the read in a single memory access; otherwise, it may need two accesses followed by stitching, significantly degrading performance. To ensure alignment, compilers insert padding bytes between struct fields. For example, on a 64-bit system, a struct containing a 1-byte char and an 8-byte long might have 7 padding bytes inserted after the char, making the struct occupy 16 bytes instead of 9 — a waste rate of 44%.

It's precisely these seemingly insignificant overheads that, at hyperscale, aggregate into massive memory consumption.

Core Strategies Behind Cloudflare's DNS Cache Optimization

Streamlining Memory Layout at the Data Structure Level

The Cloudflare team focused their optimization efforts on streamlining the memory layout of cache entries. In hyperscale systems, the most effective memory optimization often isn't about deleting data, but about making data storage more compact and efficient.

Typical optimization techniques include:

1. Redesigning the data structure of cache entries: By reordering fields and eliminating padding gaps caused by memory alignment, each cache entry occupies fewer bytes. Specifically, placing larger fields first and grouping smaller fields together can significantly reduce the padding bytes inserted by the compiler. This technique seems simple, but in a system with billions of cache entries, saving a few padding bytes per entry yields remarkably significant results.
2. Eliminating redundant storage: Identifying and merging duplicated information to prevent the same data from being stored multiple times.
3. More compact encoding schemes: Using more space-efficient encoding or compression methods for domain names, records, and other information.

The Multiplier Effect of Scale

The beauty of these optimizations lies in their multiplier effect. Suppose optimization saves an average of a few dozen bytes per cache entry — seemingly trivial. But when the system contains billions of cache entries, and those entries are independently cached across hundreds of data centers worldwide, that tiny per-entry saving gets amplified into TB-level aggregate gains.

It's worth highlighting how Cloudflare's Anycast network architecture amplifies this scale effect. Anycast is a network addressing and routing method that allows multiple geographically distributed nodes to share the same IP address (such as 1.1.1.1). When a user initiates a DNS query, the BGP routing protocol directs the request to the nearest node in terms of network topology. This architecture inherently provides high availability and low latency, but it also introduces a unique caching challenge — the DNS cache at each data center is maintained independently. Records for the same popular domain are cached separately in data centers across 330+ cities worldwide, creating massive redundancy. This is fundamentally different from a centralized caching architecture: in a centralized setup, a cache record needs to be stored only once, whereas under Anycast architecture, popular domain records may be cached hundreds of times over. This design trade-off is made to ensure deterministic query latency — cross-data-center cache lookups would introduce additional network latency, violating the core requirement of "fast response" in DNS resolution.

This also explains how the savings reached 100TB — it's not a single massive breakthrough at one point, but the cumulative manifestation of fine-grained optimization across hyperscale infrastructure.

Deeper Insights from the 100TB Memory Optimization

In Hyperscale Engineering, Details Determine Costs

For typical application developers, saving a few dozen bytes of memory is essentially meaningless. But for companies operating global infrastructure, such optimizations translate directly into real cost savings. The 100TB memory savings carries significant economic implications in the context of hyperscale infrastructure costs. Based on current market prices for server-grade DDR5 ECC memory at roughly $5-8 per GB, 100TB (approximately 102,400 GB) represents hardware procurement costs of about $500,000 to $800,000. But the actual savings go far beyond hardware alone — memory is one of the most power-dense components in a server. Typical power consumption of DDR5 memory is about 0.3-0.5 watts per GB, meaning 100TB of memory draws a sustained 30-50 kilowatts. Factoring in comprehensive data center power costs (including cooling and power distribution losses with a PUE factor of roughly 1.2-1.4), this translates to approximately 260,000-440,000 kilowatt-hours of electricity consumption per year. Additionally, reducing memory usage means the same servers can hold more cache entries or handle other workloads, improving per-machine utilization and deferring hardware expansion timelines. During periods of supply chain constraints, the value of such "soft scaling" is especially pronounced.

This reminds us that evaluating the value of systems engineering must be done within the context of its operational scale. The same one-line code optimization can be negligible in a small-scale system yet worth millions in a hyperscale system.

The Art of Balancing DNS Performance and Resource Consumption

DNS cache optimization is fundamentally about finding the optimal balance between response speed and resource consumption. Cloudflare's practice demonstrates that through clever engineering design, it's entirely possible to dramatically reduce memory usage without sacrificing cache hit rates or response speed. This ability to achieve seemingly contradictory goals simultaneously is the core competitive advantage of elite infrastructure teams.

Lessons for Distributed Systems Development Teams

As cloud services, edge computing, and large-scale distributed systems become increasingly prevalent, more and more engineering teams will face similar scaling challenges. Cloudflare's experience provides a valuable case study:

• Pay attention to the memory layout of underlying data structures — this is an area that many developers working with high-level languages tend to overlook. In languages with garbage collection like Java and Go, issues such as object headers, pointer compression, and memory allocator fragmentation can also cause significant memory overhead, and are worth deep understanding by systems-level developers.
• Build comprehensive measurement systems — only by precisely measuring the composition of memory consumption can you optimize with purpose. This includes using memory profiling tools (such as Valgrind's Massif or jemalloc's statistics features) for fine-grained memory analysis, distinguishing the proportions of useful data, metadata, fragmentation, and padding.
• Leverage scale-effect thinking — evaluate the true value of small local improvements within the context of global scale. A struct modification that saves 8 bytes, at a scale of 1 billion entries × 300 data centers, translates to 2.4TB of memory savings.

Conclusion

Cloudflare's achievement of saving 100TB of memory by optimizing 1.1.1.1's DNS caching is a textbook example of hyperscale systems engineering. It didn't rely on any disruptive technology, but rather achieved remarkable resource savings through meticulous refinement of data structures and memory layouts, amplified by the enormous scale of operations.

Perhaps the most valuable takeaway from this story is: in hyperscale systems, an engineer's relentless pursuit of detail ultimately translates into tangible business value and a superior user experience. For every technical team involved in infrastructure development, this is a lesson well worth reflecting on.