Cloudflare cuts 1.1.1.1 DNS cache memory by 100 TB

Cloudflare’s 1.1.1.1 DNS resolver and related services rely on a platform called Big Pineapple to cache over 250 billion DNS entries globally. At that scale, small inefficiencies in memory usage compound quickly. A series of five optimizations to the cache’s Rust implementation reduced the per-entry memory footprint by more than half, freeing roughly 100 terabytes of RAM across Cloudflare’s fleet without sacrificing performance—in fact, both speed and efficiency improved as a result.

How the optimizations worked

The cache stores DNS responses as structured data, with each entry containing the query details and the response records. Early versions used standard Rust types like Vec<T> and String, which include capacity fields and heap allocations that are unnecessary once the data is written to the cache. By replacing these with fixed-size alternatives like Box<[T]> and Box<str>, Cloudflare eliminated 64 bytes of overhead per entry. This change alone saved over 15 terabytes of memory across the fleet.

Further savings came from consolidating the three record sections (answer, authority, and additional) into a single list with offsets. Instead of storing three separate lists—each requiring an 8-byte pointer and length—Cloudflare used 2-byte offsets, reducing the per-entry cost by 28 bytes. Additional tweaks, such as packing boolean fields into bitflags and removing redundant owner names from DNS records, shrank the structs further by eliminating padding.

The largest records, like NAPTR, previously forced all enum variants to allocate space for the largest possible size, wasting memory for common record types like A and AAAA. Boxing the larger variants moved them to the heap, reducing the inline size of the enum from 144 bytes to 24 bytes for most records. While this introduced some allocator overhead, the tradeoff was justified by the rarity of large record types in production traffic.

The final optimization stored record data in raw wire format, encoded as a single byte buffer. This eliminated per-variant enum overhead and improved CPU cache locality by packing data contiguously. Records that don’t require name compression (like A, AAAA, and DNSSEC) can now be copied directly into responses, reducing serialization work during lookups.

Impact on performance and capacity

The rollout began on May 18, 2026, and completed across all services by July 6, 2026. Production measurements showed steady-state memory usage dropped by 42-43% across percentiles. At the 99th percentile, resident memory per instance fell from 9.3 GB to 5.3 GB. Aggregate fleet memory savings totaled approximately 100 terabytes, equivalent to the RAM in 130 of Cloudflare’s Gen 13 servers.

Performance metrics improved alongside memory efficiency. Cache insert throughput increased by 43%, from 625,000 to 893,000 entries per second. Lookup latency decreased by 19%, from 828 nanoseconds to 670 nanoseconds. The optimizations also reduced per-entry allocations from 1.1 KB to 461 bytes, a 58% reduction.

Cloudflare plans to reinvest the freed memory into expanding cache capacity, which should improve hit rates and reduce upstream queries. The company is also exploring additional optimizations, such as further refinements to the cache’s data structures.

Why this matters for DNS operators

The optimizations demonstrate how low-level changes to data structures can yield significant resource savings at scale. For operators running large DNS resolvers, the techniques—such as replacing Vec<T> with Box<[T]>, boxing enum variants, and storing data in wire format—are broadly applicable. The improvements in memory locality and reduced allocations also highlight the importance of benchmarking performance tradeoffs, as some changes (like boxing) introduced overhead that was later mitigated by alternative approaches.