How Cloudflare Cut 100 TB From the 1.1.1.1 DNS Cache and What It Means for Hosting
A breakdown of the Rust-level changes that freed 100 TB of memory across Cloudflare's 1.1.1.1 DNS cache and what website owners can learn from the approach.
Cloudflare's public resolver at 1.1.1.1 serves a large share of the internet's DNS traffic, and behind it sits an internal platform called Big Pineapple. That platform holds more than 250 billion DNS cache entries at any given time, so every byte saved per entry adds up across the global fleet. In a detailed engineering write-up, Cloudflare explained how five successive Rust-level changes to how cache entries are stored freed roughly 100 terabytes of memory while also making the cache faster. For site owners and developers who depend on fast, reliable DNS, the lessons extend well beyond Cloudflare's own infrastructure.
Key Takeaways
- Big Pineapple, the platform behind 1.1.1.1, stores more than 250 billion DNS cache entries at any moment.
- Five Rust-focused memory changes cut the per-entry footprint by over 50 percent and freed about 100 TB of RAM fleet-wide.
- Insert throughput rose 43 percent and lookup latency dropped 19 percent during the rollout, so memory savings did not cost performance.
- Replacing growable Vec and String types with Box slices, merging section lists, packing bitflags, and deduplicating owner names drove most of the savings.
- EDNS Client Subnet (ECS) responses multiply cache entries, which makes per-entry memory discipline especially valuable for global resolvers.
Why a Public DNS Resolver Cache Matters to Website Owners
When a visitor types your domain into a browser, the resolver they use often determines how quickly the first byte of your site reaches their screen. Cloudflare's 1.1.1.1 service and its sibling products, including Cloudflare internal DNS generally available for teams, rely on a shared caching layer called Big Pineapple. The same layer also serves Gateway DNS, DNS Firewall, AS112, and several other Cloudflare DNS services.
A larger, smarter cache means fewer recursive lookups, lower latency, and less load on authoritative nameservers. Conversely, a wasteful cache forces operators to scale hardware just to hold redundant bytes. Cloudflare estimated that the 100 TB freed during this work equals the RAM inside 130 of its Gen 13 servers. That is real infrastructure that can be redirected to capacity, redundancy, or new features rather than storing empty vector slots.
How the Cache Is Structured
Each cache entry is a key-value pair. The key records what was queried (the question name, type, and class, plus the EDNS Client Subnet when ECS is active). The value stores the DNS response itself, broken into answer, authority, and additional sections, along with metadata such as creation time, hit count, and Time-to-Live.
Two characteristics make this structure expensive at scale:
- ECS produces many distinct entries for the same logical record, because authoritative servers return different answers for different client networks.
- The response is immutable once cached, so any growable buffer used during construction is pure overhead afterward.
Those two facts shape every optimization Cloudflare applied.
The Five Memory Wins at a Glance
| Optimization | What Changed | Why It Helped |
|---|---|---|
| Drop Vec and String capacity fields | Replaced 8 growable fields with Box<[t]> and Box | Removed 8 bytes per field, 64 bytes per entry, and unused heap reservations |
| Merge section lists | Stored answer, authority, and additional sections in one list with u16 offsets | Eliminated two list headers and cut 28 bytes per entry |
| Pack boolean fields | Combined several booleans into a single bitflag | Reduced struct padding beyond the bytes the booleans themselves used |
| Drop redundant owner names | Inferred the owner from the queried domain when it matched | Avoided storing the same domain string inside every record |
| Compact key storage | Tightened the key struct for ECS-heavy entries | Reduced per-entry footprint where ECS multiplies entry counts |
The combined effect dropped the per-entry footprint by more than 50 percent. Across 250 billion entries, that translated into about 15 TB of savings from the Vec-to-Box change alone, with the remaining optimizations layering on top.
Reading the Rust Lessons as a Site Owner or Developer
You do not need to run a resolver to benefit from this work. The principles map directly onto application caches, in-memory stores, and even database row design.
Choose fixed-size containers for immutable data
Rust's Vec and String carry a capacity field plus reserved heap space for future growth. If the value never changes after creation, that capacity is wasted. Box<[T]> and Box<str> drop the capacity and signal intent. In other languages, the equivalent lesson is to allocate the final size up front and reuse a single buffer instead of repeatedly appending.
Pack flags and booleans together
A boolean field is rarely just one bit on disk or in memory. Alignment rules insert padding between fields, and several adjacent booleans can balloon a struct by more than the bytes they actually use. Bitfields, enum discriminants, or a single packed byte keep the layout dense. This same idea applies to database schemas, where a row of small columns can quietly consume far more space than its useful data requires.
Deduplicate strings on the hot path
DNS owner names are a special case of a general problem. Many cache entries, log records, or analytics events repeat the same identifier (a domain, a user ID, a tenant name). Storing the full string inside each record wastes memory and slows comparisons. Pointers, interning tables, or shared dictionary entries recover that space and often improve locality.
Mind ECS, locale, and personalization effects
Cloudflare flagged that ECS-heavy locations multiply entry counts because the same question produces multiple cached answers based on the client's network. Any caching layer that personalizes by region, device class, or A/B variant should expect a similar fan-out. Monitor entry counts in addition to hit rates, since a "perfect" cache can quietly consume memory proportional to the number of variants rather than the number of unique records.
Putting the Same Ideas to Work in Smaller Stacks
Even a modest WordPress site or API service can borrow these patterns. Cache backends such as Redis benefit from compact value encodings and shared string interning. Application-level caches in Node.js, PHP, or Go often serialize objects with verbose field names; switching to a tighter schema or a binary format such as MessagePack or Protocol Buffers reclaims memory and reduces network bytes.
If you host through SiteCountry and front your site with Cloudflare, the cache improvements inside Big Pineapple reach your visitors automatically. You can pair that with a solid how to add a website to Cloudflare setup so DNS, security rules, and caching work together. Picking the right domain to point at the resolver also matters, and a quick pass through Search and Buy Domains helps you lock in a clean name before tuning performance.
Frequently Asked Questions
What is Big Pineapple inside Cloudflare's DNS stack?
Big Pineapple is the internal Rust-based platform that powers 1.1.1.1, Gateway DNS, DNS Firewall, AS112, and several other Cloudflare DNS services. It stores the shared cache that resolvers and gateways rely on for fast responses.
How much memory did the 1.1.1.1 cache optimization actually save?
Across the global fleet, the five changes freed roughly 100 terabytes of memory, equivalent to the RAM inside about 130 Gen 13 Cloudflare servers. Per-entry footprint dropped by more than 50 percent.
Did the DNS cache get faster after the memory changes?
Yes. Cloudflare reported 43 percent higher insert throughput and 19 percent lower lookup latency during the rollout. Fewer allocations and better memory locality improved speed while shrinking the footprint.
Why does EDNS Client Subnet (ECS) make caching more expensive?
ECS lets authoritative servers return answers tailored to the client's network, so the same logical query can produce many distinct cached responses. That multiplies entry counts and amplifies any per-entry waste, which is why ECS-heavy locations benefit most from these optimizations.
Do these changes affect site owners who use 1.1.1.1?
Indirectly, yes. A leaner, faster cache lowers latency for everyone using the resolver and reduces the load on authoritative nameservers. Site owners do not need to change any configuration to benefit, but pairing 1.1.1.1 with a well-tuned Cloudflare setup and a lean application cache keeps end-to-end performance consistent.
Conclusion and Action Checklist
The 1.1.1.1 cache story is a reminder that memory efficiency and performance usually rise together when you remove wasted allocations. Website owners and developers can apply the same mindset without rewriting a resolver.
- Audit your application caches for growable buffers that hold immutable data and switch to fixed-size containers where possible.
- Pack boolean and flag fields together so alignment padding does not inflate struct or row size.
- Deduplicate repeated strings such as domain names, tenant IDs, or user identifiers using interning or pointer-based references.
- Watch entry counts in personalized caches (ECS, locale, A/B variants) so memory scales with unique records, not variants.
- Keep your DNS layer healthy by registering a clean domain, pointing it at a fast resolver, and reviewing Cloudflare settings periodically.
