When a browser opens a website, it first has to find out where the site lives. People use names; computers need numeric addresses. The Domain Name System, DNS, is the global directory that converts one into the other, and almost every connection on the internet starts with a DNS lookup.
What a lookup involves
DNS is not a single database. It is a hierarchy of servers run by many organizations, and a lookup walks down it.
Your device asks a recursive resolver, usually run by your internet provider or a public DNS service. If the resolver has no answer in its memory, it asks a root server, which does not know the address but knows which servers handle each top-level domain, such as “.com.” Those servers in turn point to the authoritative name servers for the specific domain, and those hold the actual answer. The resolver passes it back to your device and remembers it for next time.
The design dates to the 1980s. RFC 1034, the foundational specification, describes applications reaching the system through resolver programs that query name servers, and it builds caching into the design.
Who runs the root
The top of the hierarchy is often described as thirteen servers, which is slightly misleading. The root server system has 13 identities, labeled A through M, operated by 12 independent organizations. Each identity is served from many sites using a technique called anycast, so that a query goes to a nearby copy. The root server operators’ own website listed 2,049 operational instances worldwide when checked in October 2026.
Caching and the time to live
To avoid repeating the whole walk for every request, resolvers and devices remember answers for a period set by the domain owner, called the time to live, or TTL. RFC 1034 defines it as the maximum time a record may be cached. Short TTLs let changes spread quickly. Long ones cut traffic and speed things up, but make updates slow to reach everyone, which is why moving a website to a new server involves planning around TTLs.
When DNS fails: a documented case
DNS faults can look like total outages even when servers are healthy, because nothing can find them. A detailed example is public. Amazon Web Services published a post-event summary of a disruption in its US East region that began late on 19 October 2025 and ended on the afternoon of 20 October.
According to AWS, a latent race condition in the automation that manages DNS for its DynamoDB database service left the regional endpoint with an empty DNS record. One component applied an older plan after a newer one, and a clean-up process then deleted the older plan, removing every IP address for the endpoint. The system could not repair itself, and operators had to intervene by hand. AWS says all DNS information was restored at 2:25 a.m. Pacific time on 20 October and that cached records expired by 2:40 a.m., completing DynamoDB’s recovery.
The damage did not end there. Other AWS services that depend on DynamoDB, including its virtual-server and load-balancing systems, suffered knock-on failures, and some took many more hours to recover. AWS said it had disabled the DNS automation worldwide until it could fix the race condition. The incident is a good illustration of the problem we examine in our article on cloud outages: a fault in one shared service spreads to everything built on top of it.
Why DNS problems spread
Several features of the system amplify trouble. Many sites share a handful of DNS providers, so one failure reaches many customers at once. Applications depend on far more domains than their own, for images, payments and analytics, so a page can break because of a name you did not know it used. Caching works both ways: it can keep things running briefly during a failure and then reveal the outage when entries expire, and it can also keep a bad answer alive. Human error contributes, too, since a wrong record pushed to many servers at once is a classic trigger.
Security and privacy layers
DNS was designed in a more trusting era, and protections have been added around it. DNSSEC, described in RFC 4033, adds origin authentication and data integrity to DNS answers, letting a validating resolver check that an answer is genuine and unaltered, though it provides no confidentiality. Encrypting the path between a device and its resolver is a separate job, handled by DNS over HTTPS (RFC 8484) and DNS over TLS (RFC 7858). They address different problems and are designed to be used together.
What to do when names stop resolving
A working connection does not guarantee working DNS. Restarting the router, trying a different network such as a phone’s mobile connection and switching to another resolver in the network settings are all quick ways to tell a local problem from a wider one. For organizations, the standard resilience measures are using more than one DNS provider, keeping TTLs sensible and testing changes before widespread rollout. Some of the most widely used DNS software is itself open source, one of the shared foundations discussed in our guide to open source software.
