How 1.1.1.1 Cut DNS Cache Memory by 56%

Cloudflare says it has cut the memory footprint of the DNS cache behind 1.1.1.1 by 56%, turning a collection of small Rust data-structure changes into roughly 100 terabytes of freed memory across its network. The interesting part is not the headline number alone: the same work also increased cache insert throughput by 43% and reduced lookup latency by 19%.

The 1.1.1.1 DNS cache had a surprisingly large memory bill

Cloudflare's DNS platform, internally called Big Pineapple, holds more than 250 billion cached DNS entries at any given time. DNS, or Domain Name System, is the part of the internet that translates names such as a website's domain into information computers need to connect to it. Keeping those answers in memory avoids repeatedly asking upstream DNS servers for information that has already been resolved.

At that scale, tiny inefficiencies become expensive. Cloudflare calculated that wasting just one byte on every cached entry would consume more than 250 gigabytes of memory across its fleet. The company therefore looked below the DNS protocol itself, focusing instead on how each cached answer was represented inside its Rust software.

Cloudflare started by removing memory reserved for growth

The first optimization targeted Rust's Vec and String types. These containers are designed for data that can grow, so they keep information about both their current length and their available capacity. A DNS response stored in the cache does not need that flexibility because the response is not modified after it has been created.

Cloudflare replaced those growable structures with fixed-size representations using Box<[T]> and Box<str>. That removed capacity information and avoided reserving unused space for future growth. The change saved 64 bytes per cache entry in the relevant structures, which the company estimates amounted to more than 15 terabytes with more than 250 billion entries.

DNS records did not need to store the same information repeatedly

The next gains came from looking at how DNS responses are divided into sections. Instead of keeping separate lists for answer, authority, and additional records, Cloudflare combined the data into one list and used small offsets to identify where each section began.

That sounds like a minor implementation detail, but pointers and lengths also occupy memory. Cloudflare says the change saved 28 bytes per entry by replacing two pairs of larger pointer-and-length fields with compact offsets. The broader lesson is that data structures designed for general-purpose software can become surprisingly costly when they are repeated hundreds of billions of times.

The cache also stopped storing domain names it could already infer

Cloudflare found another repeated piece of data inside individual DNS records: the domain name, known as the record owner. In most cached responses, that name is identical to the domain being queried, so storing it again is unnecessary because the cache key already contains the queried name.

The optimized cache therefore omits the owner when it matches the query and reconstructs it when the response is returned. When a record points somewhere else, such as when a CNAME record redirects a name to another domain, the full owner name is still retained. This keeps the optimization focused on the common case rather than assuming every DNS response has the same structure.

Rust's enum layout created another source of wasted space

Cloudflare also changed how different DNS record types were represented. Rust enums reserve enough space for their largest possible variant, which can leave considerable unused room when most records are much smaller.

The company initially moved larger variants onto the heap, but that introduced another problem: additional allocations. It eventually moved toward a more compact contiguous representation that stores records together instead of giving every large variant its own allocation. The result reduces structural overhead and improves memory locality, although the data has to be processed sequentially rather than accessed through arbitrary indexes.

The production results were smaller than the laboratory benchmark

Cloudflare's benchmark reduced the cache's per-entry footprint from 953 bytes to 420 bytes, a 56% reduction. Allocated memory per entry fell from 1.1 kilobytes to 461 bytes. Those figures came from a controlled benchmark designed to resemble production traffic, rather than from a completely identical copy of the company's live workload.

Production measurements tell a slightly different story because a running DNS process contains more than its cache. At the 99th percentile, Cloudflare says resident memory fell from 9.3 GB to 5.3 GB per instance, a 43% reduction. Across the fleet, the settled working-set reduction was roughly 100 terabytes.

The memory savings also made the DNS cache faster

The optimization was not simply a trade of memory for slower processing. Cloudflare reports that cache insert throughput increased from 625,000 entries per second to 893,000, while lookup latency fell from 828 nanoseconds to 670 nanoseconds.

The likely reason is closely tied to how computers access memory. Fewer allocations mean less allocator work, while smaller and more compact structures make it easier for the processor's caches to keep useful data close at hand. Cloudflare's measurements therefore suggest that reducing the amount of memory used by a hot data path can improve performance at the same time, although those results belong specifically to its DNS workload and implementation.

What the 1.1.1.1 DNS cache optimization means for the wider web

Users will not suddenly see a new 1.1.1.1 feature because of these changes. DNS resolution should continue to look the same from the outside. The difference is underneath: Cloudflare can hold its existing cache using substantially less memory and says it plans to reinvest some of the freed capacity into increasing cache size without increasing overall memory use.

A larger effective cache can keep more DNS answers available locally, potentially reducing the number of upstream queries required to resolve names. That matters because 1.1.1.1 is not a small application serving a handful of machines; it is infrastructure where a few dozen bytes saved from one object can become terabytes when multiplied across the fleet. The work is a useful reminder that major internet performance gains do not always come from a new protocol or a faster server. Sometimes they come from looking closely at the data structures sitting underneath a service that handles enormous amounts of traffic.