Cloudflare trims 100 TB of memory from 1.1.1.1 by redesigning its DNS cache internals

In a technical post published on August 27, 2026, Cloudflare engineer Sebastiaan Neuteboom described how the company freed roughly 100 terabytes of memory by reworking the way its 1.1.1.1 public DNS resolver stores cached responses. The change was invisible to users, but it is a clear example of how tiny inefficiencies in code can balloon into enormous costs when multiplied across a global network.

To understand the achievement, it helps to know what a DNS resolver does. The Domain Name System, or DNS, is the internet's phonebook: when you type a website name, a resolver such as 1.1.1.1 looks up the matching numeric address and sends it back to your device. Because this happens for billions of queries every day, resolvers keep a DNS cache, a temporary memory store of recent answers, so they do not have to repeat the full lookup each time. That cache is one of the most memory-hungry parts of the service, and how it is arranged in RAM directly affects speed, cost, and reliability.

Cloudflare's 1.1.1.1 resolver is written in Rust, a programming language known for safety and performance. Every cached item is represented by a pair of structures: a key that identifies the lookup, and a value called CacheEntry that stores the response itself. The CacheEntry shown in the post contains a timestamp, an inception time, a Time-to-Live (TTL) value, a hit counter, and three lists of DNS records for the answer, authority, and additional sections, plus fields for error data. Each of those lists is a Vec, Rust's standard growable array. A Vec stores three things: a pointer to the data, the current length of the list, and the capacity, which is the total space already allocated. The capacity is often larger than the length because the array grows in chunks, and that extra space, plus the pointer and length fields themselves, adds overhead to every single entry.

The team realised that several field types carried more overhead than necessary once an entry was stored. For example, timestamps and other metadata can be held in smaller, more compact forms when they no longer need the flexibility of the original types. By switching to leaner representations and restructuring the lists, they reduced the per-entry memory cost substantially. This applied to both the cache key and the cache value, and the savings came without sacrificing the information needed to serve responses correctly.

To measure each optimization, Cloudflare built a benchmark that fills the cache with randomly generated entries matching the traffic mix seen in production: 56% A records, the classic records that map names to IPv4 addresses; 25% AAAA records, which map names to IPv6 addresses; and 19% TXT records, which hold arbitrary text and stand in for all other variable-length response types in the test. Each entry contains between one and four records, and the TXT records are randomized between 64 and 224 bytes, close to the average response size for that category. The benchmark tracks memory usage through a custom allocator that wraps Rust's system allocator and records the number and size of every allocation per cache entry. At the same time, it measures insert throughput and lookup latency across the full cache flow, ensuring that the memory savings did not come at the cost of slower queries.

The result was a reduction of about 100 terabytes across production instances. The team also verified the improvement by watching resident memory, the actual RAM in use, during a gradual rollout. A smaller per-entry footprint means that the same physical memory can hold more cached answers, which improves response times for users and can delay the need to add more servers. Even a few saved bytes per entry become enormous when multiplied by billions of cached names and thousands of machines.

For readers who rely on a private, encrypted DNS service such as AEU DNS, this is the kind of engineering that helps keep lookups fast, reliable, and compatible with a strict no-logs approach, because a well-designed cache stores only what it needs and nothing more. The optimization also shows that the most effective performance work often happens out of sight, in the low-level code that users never see but feel every time a page loads quickly.