DNS: How Domain Name Resolution Works

Why DNS exists

Machines route traffic using IP addresses. A server sits at a number like 192.0.2.1. Human memory is not built for remembering hundreds of those numbers, so a translation layer was needed between names that people use and addresses that routers forward to.

The original solution was a single text file called hosts.txt, maintained at Stanford Research Institute and distributed to every machine on the network. When the internet was small this worked. By the early 1980s the network had grown enough that a centrally maintained file was no longer viable. DNS replaced it in 1983 with a distributed hierarchical system. The same design has scaled to handle billions of records without any central bottleneck.

The hierarchy

DNS is not a single database. It is a tree of delegated authority. No single server knows every record. Each level of the tree knows which servers to ask next.

At the top sit the root servers. There are thirteen root server authorities, labelled A through M, each operated independently and distributed globally through anycast. A root server does not hold records for individual domains. It holds the locations of the nameservers responsible for each top-level domain.

Below the root are the TLD nameservers. These handle top-level domains: .com, .net, .org, .io and every country code. They hold delegation records pointing to the authoritative nameservers for individual domains. Below those sit the authoritative nameservers themselves, which hold the actual zone records.

How resolution works

When your browser needs to reach docs.example.com, the resolution process moves through several stages. Each stage can short-circuit if the answer is already cached.

The recursive resolver does the actual walking of the tree. The client makes one request. The resolver makes several, caches everything it learns along the way, then returns the final answer. Most queries never reach the root servers because the resolver already has the TLD nameserver addresses cached from a previous lookup.

This type of resolution is called recursive. The resolver takes responsibility for the full chain of lookups on behalf of the client. The alternative, iterative resolution, has the client perform each step itself. In practice, clients delegate to recursive resolvers rather than doing iterative lookups directly.

Record types

A zone file is a collection of records. Each record type serves a specific purpose. Configuring the wrong type in the right place does nothing useful.

TTL and caching

Every DNS record carries a TTL value measured in seconds. It tells resolvers how long they are allowed to cache the answer before they need to ask again.

The practical effect of TTL is that DNS changes do not take effect everywhere at once. Once a resolver has cached a record it will keep serving the old answer until the cached value expires. This is what people mean when they say DNS changes take time to propagate. Nothing is being pushed outward from a central location. Old cached values are expiring at different rates across thousands of resolvers around the world.

If you are about to change an IP address, dropping the TTL to 300 several hours beforehand shortens the window during which old and new answers coexist. Once the change is made, resolvers that query after the TTL expires will pick up the new record. Resolvers that cached the old answer shortly before the TTL drop will hold it for at most five minutes.

Querying DNS with dig

dig is the standard tool for inspecting DNS directly. It sends a query to a nameserver of your choice and shows the full response including TTL values, the answering server and query timing.

The number between the name and IN A in the answer section is the remaining TTL in seconds. Here it shows 3512, meaning this cached answer expires in just under an hour. The server line shows which resolver actually answered the query.

The @ flag sends the query to a specific resolver. Useful for checking whether a particular server has picked up a recent change while other resolvers still hold the old cached value.

The +trace flag makes dig walk the full resolution chain from the root servers. It shows exactly which servers were contacted at each stage and what they returned. Useful for diagnosing delegation issues where the zone is configured correctly but the parent TLD is still pointing at old nameservers.

Common failure points

DNS failures tend to surface far from where the problem actually lives. Placing the failure somewhere in the resolution chain is usually faster than guessing at the application layer.