Cloudflare Cuts 100 TB of Memory from 1.1.1.1 DNS Cache

Cloudflare changed how its Big Pineapple DNS cache represents data in memory. The cache still stores DNS results, but its internal layout uses less space for each result. This matters because a large cache contains enormous numbers of entries. Small per-entry savings can become massive across a global fleet.

The redesign was implemented in Rust. Its key idea was to reduce the memory footprint of each cache entry by 56%. That freed roughly 100 TB of working-set memory across Cloudflare’s fleet. The same change also made cache operations faster, rather than trading speed for compactness.

This was more than a cosmetic code update. Cloudflare could use the recovered memory to increase cache capacity without adding more memory. The redesign also raised cache insertion throughput by 43% and reduced lookup latency by 19%.

A DNS cache is temporary storage for DNS answers. DNS translates names such as example.com into IP addresses that computers can contact. When a resolver receives an answer, it can keep that result for the answer’s allowed lifetime, called its time to live. Later requests may use the stored answer instead of starting over.

Cloudflare’s 1.1.1.1 service is a public DNS resolver. When users ask it for a domain’s address, the resolver checks its cache first. If the answer is present and still valid, 1.1.1.1 can return it immediately. If not, it queries other DNS servers, saves the response, and returns the address.

Caching reduces work and network traffic. It also improves response time for popular domains. The article focuses on making Cloudflare’s large Big Pineapple cache more compact and faster, supporting more cached results with existing resources.

The redesign saved roughly 100 TB of working-set memory across Cloudflare’s fleet. Working-set memory is the memory actively needed by running systems and their current data. This is an unusually large saving because it came from changing the representation of individual cache entries, not simply deleting cached DNS results.

The per-entry memory footprint shrank by 56%. For example, if an entry previously used 100 units of memory, the redesigned version would use about 44 units, assuming the percentage applies directly. Repeated across a very large cache, that difference adds up quickly. Big Pineapple holds many DNS results, so the fleet-wide effect is substantial.

The recovered memory gave Cloudflare additional room for cache data. The company could increase cache capacity without adding memory. That can help retain more useful answers and reduce misses, while preserving the same infrastructure investment.

The redesign improved two important cache operations. Cache insertion throughput rose by 43%, meaning the system could add DNS results at a substantially higher rate. Lookup latency dropped by 19%, meaning the time needed to find an existing result became shorter. Together, these changes improve both cache updating and cache serving.

A simple example shows the difference. When an upstream DNS server sends a fresh answer, Big Pineapple can insert that result more efficiently. When another user requests the same domain, the cache can locate the stored answer with less delay. The article attributes these gains to the Rust-based changes and redesigned representation.

These results matter because DNS systems handle many repeated, time-sensitive requests. Faster insertions help the cache keep up with incoming answers. Lower lookup latency helps 1.1.1.1 respond promptly. Cloudflare also gained memory capacity, so the redesign improved speed and scale together.

A cache has a fixed amount of memory available for stored results. If every entry uses less space, that same memory can hold more entries. More capacity means the cache can retain more domain answers before older results must be removed. This can increase the chance that a future request finds a usable answer locally.

Suppose a cache has room for 100 entries, and each entry becomes roughly half as large. The system could approach twice the entry capacity, depending on other data and implementation limits. Cloudflare reported a 56% reduction in per-entry footprint, not a promise of exactly 56% more entries. Other overheads still affect the final capacity.

For Cloudflare, the redesign freed roughly 100 TB of working-set memory. That space allowed Big Pineapple’s capacity to grow without additional memory. In practical terms, Cloudflare could support more cached DNS data using existing infrastructure, while also gaining faster insertion and lookup performance.

Memory footprint means the amount of memory used by a cache or one cache entry. A smaller footprint lets a fixed memory pool store more data. In Big Pineapple, reducing this footprint by 56% produced large fleet-wide savings. It also created room for a larger cache without extra memory.

Insertion throughput measures how many cache entries the system can add during a period, such as a second. Higher throughput means the cache can absorb new DNS answers more efficiently. Cloudflare reported a 43% increase. This matters when many answers arrive or existing records need refreshing.

Lookup latency is the delay between asking the cache for a result and receiving its stored answer. Lower latency makes cached DNS responses faster. Cloudflare reduced lookup latency by 19%. In operation, a strong cache aims for compact entries, high insertion throughput, and low lookup latency at the same time.

When a user enters a website name, the device first asks its configured DNS resolver for an IP address. The request may pass through a local or network cache. Cloudflare’s 1.1.1.1 can then check its own cache for a valid answer. If it finds one, it returns the IP address without asking upstream servers.

If the answer is missing or expired, the resolver performs a recursive lookup. It can ask a root DNS server where to find the relevant top-level domain server, such as .com. It then asks that server for the domain’s authoritative name server and queries the authoritative server for the domain’s address. The resolver stores the answer according to its time to live.

Finally, 1.1.1.1 returns the IP address to the user’s device. The device uses that address to connect to the website. Caching makes later requests faster by avoiding much of this process.