On August 27, 2026, Cloudflare published an unusual optimization at the scale of its 1.1.1.1 resolver: five changes to its cache-entry representation freed about 100 terabytes of memory and reduced internal lookup latency by 19%.
The result matters because cache is the fast path through a resolver. While an answer remains valid, the service does not need to repeat the full journey to authoritative servers. It finds the data locally, adjusts the required fields, and sends it to the user.
The 19% figure needs careful interpretation. The measurement fell from 828 to 670 nanoseconds inside the cache process. Cloudflare is not claiming that every phone-to-1.1.1.1 query became 19% faster on every network.
The scale of the 1.1.1.1 cache
Cloudflare’s Big Pineapple resolution platform supports 1.1.1.1, Gateway DNS, DNS Firewall, AS112, and other services. The company says it holds more than 250 billion cache entries at any moment.
At that scale, wasting one byte per entry costs more than 250 GB across the fleet. Cloudflare optimized the Rust structures that store the query key, response records, TTL, creation time, counters, and extended errors.
Its development benchmark approximated the production traffic mix:
- 56%
Arecords; - 25%
AAAArecords; - 19%
TXTrecords standing in for variable-length types; - one to four records per entry.
The team also measured resident memory on production instances during a rollout that began May 18 and completed July 6, 2026.
What changed in the numbers
| Metric | Before | After | Change |
|---|---|---|---|
| Net footprint per entry | 953 bytes | 420 bytes | -56% |
| Allocations per entry | 1.1 KB | 461 bytes | -58% |
| Cache insert throughput | 625,000/s | 893,000/s | +43% |
| Cache lookup latency | 828 ns | 670 ns | -19% |
Production process memory fell by less than 56% because it includes code and data outside the cache. Even so, p99 memory per instance dropped from 9.3 GB to 5.3 GB. The aggregate working-set reduction was about 100 TB—equal, Cloudflare says, to the RAM in 130 of its Generation 13 servers.
How less memory also made the cache faster
Saving memory can sometimes add processing. Here, several changes reduced both.
A general-purpose structure may reserve enough inline space for its largest record variant even when holding a small A or AAAA. Alternative designs create many separate heap allocations. Both patterns waste bytes and scatter data, forcing the CPU to follow pointers into different memory regions.
The final design stores DNS record data in a compact, contiguous wire-format buffer. Common types can be copied almost directly into the response. Only records containing names—such as CNAME, NS, MX, and SOA—still need parsing for DNS name compression.
Fewer allocations and better memory locality explain why insertion throughput rose and lookup time fell even as RAM usage declined.
Does this make the user’s Internet faster?
It can help, but not by a direct 19%. A query observed on a phone normally takes milliseconds, not nanoseconds. End-to-end time includes:
- Wi-Fi or mobile access to the router;
- the ISP route to an anycast point of presence;
- resolver processing;
- on a cache miss, root, TLD, and authoritative lookups;
- DNSSEC validation and possible retries.
Saving 158 nanoseconds is small next to a 10 or 30 millisecond network trip. The more interesting effect may come next: Cloudflare plans to reinvest freed memory in greater cache capacity. More entries can improve hit rates and avoid upstream trips, which cost far more time.
The benefit will not be uniform. Short TTLs, rare names, and EDNS Client Subnet variants reduce reuse. Popular domains with suitable TTLs are more likely to benefit.
How to look for a difference in a benchmark
Do not compare one query made before the announcement with one made afterward. Routing, congestion, and cache state create larger variations than this internal optimization.
Use a repeatable method:
- run multiple rounds on the same device and connection;
- compare Cloudflare, Google, Quad9, and the ISP resolver in the same time window;
- separate warm, repeated queries from randomized names that create cache misses;
- record median, P95, jitter, and success rate;
- repeat at different times and confirm the resolver endpoint actually reached.
A consistent P95 or stability improvement matters more than a tiny average difference. See how to compare Cloudflare and Google DNS and how to find the fastest DNS for a structured test.
What the news actually demonstrates
The optimization does not make 1.1.1.1 the universal benchmark winner. The fastest resolver still depends on ISP, location, anycast route, time, and query type.
It demonstrates that memory efficiency and speed are connected in a global resolver. Compacting hundreds of billions of objects leaves room for a larger cache, reduces allocator pressure, and saves CPU work. The per-query effect reaching a user may be subtle, but it multiplies across the service and can improve capacity and consistency.
