Cloudflare says it clawed back 100TB of memory from 1.1.1.1's DNS cache

Cloudflare has revealed it trimmed roughly 100 terabytes of memory usage out of the caching system behind 1.1.1.1, its free public DNS resolver. It’s a genuinely large number, and Cloudflare has put out an engineering write-up tagging the work under DNS, Rust, performance and optimisation. The catch: this is an internal infrastructure saving for Cloudflare, not a speed boost you’ll personally notice.

What Cloudflare actually did

The company runs 1.1.1.1 as one of the world’s most-used DNS resolvers, sitting between billions of devices and the wider internet, translating domain names into addresses. Keeping answers cached in memory rather than re-fetching them constantly is what makes DNS fast at that scale - but cache entries add up, and at Cloudflare’s size, inefficient storage of them becomes an expensive problem measured in whole data centres’ worth of RAM. The blog post frames this as a case of restructuring how that cache is held in memory, freeing up around 100TB in aggregate across their fleet. Cloudflare hasn’t published the granular before-and-after benchmarks or exact data structure changes in the material available for review here, so the precise mechanics of the fix are Cloudflare’s to verify - the headline figure comes from the company itself, not an independent audit.

So who is actually affected

Nobody browsing the web through 1.1.1.1 needs to do anything, and there’s no indication this changes reliability, privacy or response times for end users in any noticeable way. This is squarely an operational cost story: less memory needed per server means Cloudflare can run its resolver infrastructure more cheaply and, presumably, keep scaling it without buying as much hardware. If you use 1.1.1.1 as your DNS provider, or your ISP or router quietly routes through it, this is invisible plumbing work rather than a feature update.

The bit worth flagging: why wasn’t this done sooner

The Hacker News thread discussing the post (644+ points, nearly 200 comments) spends less time marvelling at the 100TB figure and more time debating why an optimisation this “trivial” - as some commenters put it - wasn’t baked in from day one. One popular take is that shipping a working product, proving the business model and only then optimising is the sensible order of operations, since premature optimisation for problems you don’t yet have is often wasted effort. Others push back, noting that changing a live, hot-path caching data structure in production is far harder than changing code that isn’t handling real traffic, and pointing out that Cloudflare’s own rollout graph shows the change took more than four months to fully deploy - hardly a trivial afternoon’s work, whatever the eventual code diff looked like.

The takeaway

Treat this as a solid, plausible engineering achievement rather than a headline that changes anything for ordinary internet users. Cloudflare gets to run 1.1.1.1 more cheaply, which is good for the resolver’s long-term sustainability, but there’s no independent verification of the 100TB figure beyond Cloudflare’s own account, and no evidence of any change in performance or privacy that you’d actually feel. If you’re a systems engineer, the real story is in the rollout timeline, not the round number.