DNS is Simple. DNS is Hard

Summary

DNS is Simple. DNS is Hard. How a "simple" lookup system turns into a distributed systems problem Posted on March 30, 2026 by Adam Wespiser DNS looks like a simple mapping: DNS :: Domain Name → IP Address That’s the mental model most of us carry around: wespiser.com → 104.21.13.171 It feels like configuration. A lookup. Some project metadata you change, and then it’s changed. But that’s not what actually happens. When your application makes a DNS request, it doesn’t go straight to the authoritative server. It goes to a recursive resolver that is run by your ISP, your company, or a public provider like 8.8.8.8. That resolver: Queries root servers Follows referrals to TLD servers Queries the authoritative name server Caches the result Returns the answer And then every other resolver in the world does the same thing: on its own timeline, with its own cache, with no coordination. There is no global view of DNS state. There is no control plane. There is no way to ask, “what does the system believe right now?” When you change DNS, you are not updating configuration. You are initiating a convergence process across a distributed system you don’t control, can’t observe, and can’t roll back. At small scale, DNS feels like a lookup. At internet scale, it behaves like a distributed system. That gap is where things break. Internet building block For a taste of how critical DNS is, on October 21, 2016, Dyn, a DNS provider critical for many of the most popular web platforms, went down for hours. The attack was basic by modern standards: have your botnet send DNS requests that are more expensive to resolve than they are to generate. Millions of unique subdomains forced resolvers to bypass caches, triggering a flood of upstream lookups that overwhelmed Dyn’s infrastructure. The result? Reddit, Twitter, PayPal, and others were unavailable for hours. The real failure wasn’t Dyn went down. The failure was everyone depended on Dyn. DNS is one of the few systems where you ship a change, ...