Cloudflare says five changes to the in-memory layout of its DNS cache reduced the memory needed for each entry by 56%, freeing roughly 100 terabytes across its infrastructure. The company also reported a 43% increase in insertion throughput and a 19% decrease in lookup latency after deploying the changes.
The work targeted Big Pineapple, the platform that supports Cloudflare services including the 1.1.1.1 public resolver, Gateway DNS, DNS Firewall and AS112. It holds more than 250 billion cached DNS entries at a time, according to Cloudflare. At that scale, one unnecessary byte per entry translates into more than 250 gigabytes of fleet-wide memory use. The total saving was equivalent to the RAM installed in 130 of the company's Generation 13 servers.
Each cached item includes a key describing the query and a value containing the DNS response and metadata such as creation time, hit count and time-to-live. Cloudflare's engineers focused on fixed data that did not need the flexibility of general-purpose Rust container types.
One change replaced growable vectors and strings with boxed slices and boxed strings once responses entered the cache. A Rust vector stores a pointer, length and capacity, while a boxed slice does not need capacity because it cannot grow. Eight such fields appeared in every cache entry. Removing their capacity values saved 64 bytes per entry, while avoiding excess reserved space on the heap. Cloudflare attributed more than 15TB of the overall reduction to this step.
The team also combined the answer, authority and additional sections of a DNS reply into one list, recording two-byte offsets for section boundaries. That eliminated two separate pointer-and-length pairs and saved 28 bytes per entry. Several Boolean values were packed into bit flags, which also reduced padding inserted by Rust to align structures in memory.
Another optimisation addressed record-owner names. Many records have the same owner as the domain in the query, so storing that name again creates duplication. The revised cache omits identical owners and reconstructs them from the already available cache key during response generation. A full name remains stored when it differs, as can happen with records reached through a CNAME.
Cloudflare measured the changes with a custom allocator and synthetic entries approximating its production traffic: 56% A records, 25% AAAA records and 19% TXT records, with one to four records in each entry. TXT payload sizes ranged from 64 to 224 bytes. Engineers tracked both allocation sizes and cache performance, then monitored resident memory on production instances during rollout.
The company cautioned that the benchmark inputs approximate rather than exactly reproduce live traffic. Actual process memory varies with cache occupancy, allocation state, traffic mix and memory used elsewhere. Even with those limits, the production measurements illustrate how small representation choices can generate infrastructure-scale savings when repeated hundreds of billions of times.
