Cloudflare Saved ~100 TB of RAM Optimizing 1.1.1.1’s DNS Cache in Rust (2026)

Cloudflare 1.1.1.1 DNS cache memory optimization — cover image

Cloudflare just published one of the more concrete systems write-ups of 2026: by reshaping how DNS cache entries are laid out in Rust, the company freed roughly 100 terabytes of RAM across the fleet that powers 1.1.1.1 — without adding servers, and without trading memory for slower lookups.

In an August 27, 2026 engineering post by Sebastiaan Neuteboom, Cloudflare walked through five successive layout changes on Big Pineapple, the shared DNS resolution platform behind 1.1.1.1, Gateway DNS, DNS Firewall, AS112, and related services. Coverage from TechSpot, GIGAZINE, and developer aggregators echoed the same headline numbers: smaller entries, faster inserts, faster lookups.

Key Facts at a Glance

Here is the compressed scorecard from Cloudflare’s post and follow-on coverage — platform scale, per-entry savings, speed gains, and the production rollout window.

Item	Detail
Platform	Big Pineapple — 1.1.1.1 and other Cloudflare DNS services
Scale	250B+ live DNS cache entries fleet-wide
Per-entry footprint	953 → 420 bytes (−56%)
Per-entry allocations	1.1 KB → 461 bytes (−58%)
Fleet RAM freed	~100 TB (~130 Gen 13 servers’ worth)
Insert throughput	+43% (625k → 893k entries/s in benchmarks)
Lookup latency	−19% (828 ns → 670 ns)
Production p99 memory	9.3 → 5.3 GB (−43%) per instance
Rollout	May 18 – July 6, 2026

Why a Few Bytes Matter at DNS Scale

Big Pineapple keeps a massive in-memory cache. On cold start the cache is empty; as queries arrive it fills until it hits a per-location entry budget, then older or less popular items are evicted.

At 250 billion-plus concurrent entries, wasting a single byte per entry costs more than 250 GB of RAM across the fleet. EDNS Client Subnet (ECS) makes the problem sharper in some data centers: different client networks can require different answers for the same query name, so more variants — and more memory — sit in cache.

The engineering lesson is blunt: once a structure is write-once and read millions of times per second, idiomatic Rust defaults like growable Vec / String stop being “free.”

Five Rust Layout Changes

Cloudflare did not rewrite the resolver. It tightened how a cache entry is represented — five steps, measured as they shipped.

1. Drop unused capacity

Cache entries never grow after insert. Replacing Vec / String with Box<[T]> / Box<str> removes the capacity word and over-allocated heap slack — about 64 bytes of struct overhead per entry across eight fields, plus heap waste. Cloudflare estimates 15+ TB from this change alone.

2. Fewer lists, fewer pointers

Answer, authority, and additional sections moved into one list with u16 section offsets instead of three separate boxed slices — ~28 bytes saved per entry, plus padding wins from packing flags.

3. Optional owner names

Most records’ owner matches the query name. Store Option and reconstruct the common case from the cache key; only CNAME-style divergences keep a heap-allocated name.

4. Box large enum variants

RecordData was sized for rare, large types (e.g. NAPTR ~136 bytes inline). Boxing large variants shrinks the enum so common A/AAAA payloads stop paying a ~144-byte tax.

5. Wire-format record bytes

Biggest win: store length-prefixed raw DNS wire bytes in one contiguous Box<[u8]>. Most A/AAAA/TXT/DNSSEC answers can be memcpy’d into responses; locality improves and boxing overhead largely disappears.

Benchmark and Production Results

Cloudflare measured both synthetic fills (traffic mix ~56% A, 25% AAAA, 19% TXT stand-ins) and real resident memory during rollout.

Metric	Before	After	Change
Per-entry net footprint	953 bytes	420 bytes	−56%
Per-entry allocations	1.1 KB	461 bytes	−58%
Cache insert throughput	625,000 /s	893,000 /s	+43%
Cache lookup latency	828 ns	670 ns	−19%
Instance memory (p99)	9.3 GB	5.3 GB	−43%
Instance memory (p90)	6.5 GB	3.8 GB	−42%
Fleet working-set RAM	—	−~100 TB	≈ 130 Gen 13 servers

Production savings are a bit lower than pure per-entry math because process RSS includes buffers and non-cache state — which is why Cloudflare published both views.

What Happens to the Freed Memory?

Cloudflare is not banking idle RAM for its own sake. The plan is to reinvest the headroom into more cache capacity at the same memory budget — higher hit rates, fewer upstream queries. Further cache-structure work is still on the table.

That framing matters for anyone running memory-resident hot paths: the goal of a layout audit is often capacity and latency together, not a smaller bill alone.

Why This Story Travels Beyond DNS

Write-once collections

If data never grows after create, fixed slices beat growable vectors — capacity fields and over-allocation add up at billions of objects.

Rare large variants

Enum/union sizing taxes every instance. Box the rare giants so the common small cases stay dense.

Serialize for the hot path

If you mostly re-emit bytes unchanged, a wire/serialized buffer can beat a richly parsed AST for both memory and CPU.

The same instincts apply to embedding caches, feature stores, session state, and other in-process indexes — not only recursive DNS.

FAQ

If you only need the short answers — what changed, whether speed suffered, how long the rollout ran, and what “100 TB” actually means — start here.

Question	Answer
What did Cloudflare optimize?	In-memory layout of DNS cache entries on Big Pineapple (1.1.1.1 and related DNS products).
Did lookups get slower to save RAM?	No — inserts rose 43% and lookups fell 19% in Cloudflare’s benchmarks.
How long did production rollout take?	May 18 to July 6, 2026, in stepped releases.
Is “100 TB” per-server or fleet-wide?	Fleet-wide aggregate working-set reduction after rollout settled.

Sources

Stay in the loop

Keep up to date with the latest news and updates