Cloudflare saved 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

Cloudflare's engineers have cut the memory used by its DNS cache by more than half through five successive storage-level optimizations. The work, published on the company's blog on August 27, targets Big Pineapple, the platform that runs the 1.1.1.1 public resolver as well as Gateway DNS, DNS Firewall and AS112.

A cache of 250 billion entries

Big Pineapple holds over 250 billion DNS cache entries at any given moment. Because every entry exists across hundreds of data centers at once, a single wasted byte per entry costs more than 250 gigabytes of memory fleet-wide. Each item is a key-value pair: the key identifies what was queried (name, record type, authentication flag, tag), while the value stores the response itself — the answer, authority and additional sections, plus metadata such as creation time, a hit counter and the TTL.

Cache size varies by data center. When EDNS Client Subnet (ECS) is in use, authoritative servers return different answers depending on the client's network, so Cloudflare caches multiple versions of the same query.

Five changes to the storage layout

The team benchmarked each change with randomly generated entries that match production traffic: 56% A records, 25% AAAA and 19% TXT, with one to four records per entry.

Replacing Vec and String fields with Box<[T]> and Box<str> removes the capacity field and the heap space reserved for growth — 8 bytes per field, 64 bytes per entry, and more than 15 terabytes fleet-wide. Storing the answer, authority and additional sections in one list with 2-byte offsets instead of three separate lists saves another 28 bytes per entry. Most records repeat the queried domain as their owner, so that field is now dropped and the name is restored from the cache key at read time.

Two further changes addressed Rust enum sizing. Record data kept as an enum was always as large as its biggest variant — NAPTR at 144 bytes — while an A record needs only 4 bytes, so most records wasted over 120 bytes. Boxing the large variants fixed that but added allocator rounding and scattered heap allocations. The final step stores record data as raw wire-format bytes in a single buffer with 2-byte length prefixes, which restores locality and lets most records be copied directly into outgoing responses.

Results in production

In benchmarks the per-entry footprint fell from 953 bytes to 420 bytes (-56%), and per-entry allocations from 1.1 KB to 461 bytes (-58%). Insert throughput rose from 625,000 to 893,000 entries per second (+43%), while lookup latency dropped from 828 to 670 nanoseconds (-19%).

The rollout ran from May 18 to July 6, 2026, with memory falling in steps as each release landed. At p99, resident memory per instance dropped from 9.3 GB to 5.3 GB (-43%); at p90 it fell from 6.5 GB to 3.8 GB (-42%). Aggregate working-set memory across the fleet is roughly 100 terabytes lower — about as much RAM as 130 of Cloudflare's Gen 13 servers. The company plans to reinvest the freed memory into larger caches, which should improve hit rates and reduce upstream query volume.