Skip to content
Tech News
← Back to articles

Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache

read original more articles
Why This Matters

Cloudflare's recent DNS cache optimizations for 1.1.1.1 significantly reduce memory usage by over 100 terabytes, enabling more efficient infrastructure and faster DNS responses. These improvements highlight the importance of continual performance tuning in large-scale internet services, benefiting both the industry and end-users with faster, more reliable DNS resolution.

Key Takeaways

Big Pineapple , the platform behind 1.1.1.1 , Gateway DNS , DNS Firewall , AS112 , and several other Cloudflare DNS services, stores over 250 billion DNS cache entries at any given time. At that scale, wasting a single byte per entry costs more than 250 gigabytes of memory across our fleet.

Five successive changes to how cache entries are stored in memory cut the per-entry footprint by over 50%. Across our fleet, these changes freed up roughly 100 terabytes of memory, equivalent to the amount of RAM in 130 of our Gen 13 servers . The cache also got faster. Insert throughput rose 43% and lookup latency dropped 19%, as fewer allocations and better memory locality meant we did not trade speed for space.

What we cache

On cold start, Big Pineapple starts out with an empty cache. As DNS queries arrive, the cache fills until it hits its maximum entry count, at which point we evict older or less popular items to make room.

The exact 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 we cache multiple versions of the same query. This increases both the number of entries and the memory each one consumes, making the optimizations in this post especially impactful for ECS-heavy locations.

Each item in the cache is a key-value pair. The key identifies what was queried:

pub struct CacheKey { qname : Name , qtype : Rtype , authenticated : bool , tag : Vec < u8 >, }

The value stores the DNS response itself: the answer, authority, and additional record sections, along with metadata like the creation time, a hit counter, and the Time-to-Live (TTL).

pub struct CacheEntry { timestamp : UnixTimeStamp , pub inception : Instant , pub ttl : Ttl , pub hits : u32 , pub answers : Vec < Record >, pub authority : Vec < Record >, pub additional : Vec < Record >, pub errors : Vec < ExtendedError >, ... }

Both structs have room for improvement. Several fields use types that carry overhead we don't need once the entry is stored.

... continue reading