How DNS Lookup Works: Full Resolution Path

When a program needs to reach another machine by name, it does not go straight to a server that knows the answer. It starts a chain of queries that crosses several machines, each with a specific role and each with its own cache. Understanding that chain explains most DNS behavior, including why a change you made an hour ago is still not visible.

The Stub Resolver

The first step happens on the machine itself. The program calls a function in the operating system, usually getaddrinfo() on Unix-like systems or GetAddrInfoW() on Windows. That function is part of a stub resolver—a small client that knows only one thing: the address of a recursive resolver, typically provided by DHCP or configured manually. The stub resolver does not know how to find the answer on its own. It sends a single query to that recursive resolver and waits for a complete answer.

If the answer is already in the local cache (the stub resolver keeps one), it returns immediately. Otherwise, it forwards the query to the recursive resolver.

The Recursive Resolver

The recursive resolver, often run by an ISP or a public DNS provider, accepts the query and does the actual work of finding the answer. It is called recursive because it repeats the process of querying other servers until it gets a definitive answer. This process is not a single query but a series of them, each step narrowing down the location of the authoritative answer.

The recursive resolver also maintains a cache. If it has a recent answer for the queried name, it returns it immediately. If not, it begins the iterative process.

Iterative Queries: Walking the Tree

The recursive resolver does not ask a single server for the final answer. Instead, it follows the DNS hierarchy, starting at the root and moving down. Each step is an iterative query—a query to a server that responds with a referral to another server, not the final answer.

1. Root servers: The recursive resolver has a list of 13 root server addresses (these are logical names, each backed by multiple physical servers). It sends a query for the domain name to one of them. The root server does not know the answer, but it knows which servers are authoritative for the top-level domain (TLD). For example, for www.example.com, it returns a referral to the .com TLD servers.
2. TLD servers: The resolver then queries one of the .com servers. That server also does not know the answer, but it knows which servers are authoritative for example.com. It returns a referral to those servers.
3. Authoritative servers: Finally, the resolver queries one of the authoritative servers for example.com. These servers hold the actual DNS records, such as the A or AAAA record for www.example.com. They return the final answer.

The recursive resolver caches the final answer and sends it back to the stub resolver, which also caches it and returns it to the program.

Caching and TTL

Every DNS record has a Time to Live (TTL) value, specified in seconds. This value tells any resolver how long it may keep the record in its cache before it must consider it stale and re-query. TTLs are set by the domain owner and can range from seconds to days.

Caching happens at every level:

• The stub resolver caches the final answer.
• The recursive resolver caches the final answer and also caches the referrals it received (the addresses of TLD and authoritative servers). Those referrals have their own TTLs.
• Even the root server addresses are cached, though they are rarely stale.

When a resolver has a cached record that has not expired, it returns it without querying upstream. This is why a change to a DNS record does not take effect immediately: every resolver that has cached the old record will continue to serve it until the TTL expires.

Why Changes Are Not Visible Immediately

Suppose you change the IP address of www.example.com in your DNS management console. The change is immediate on the authoritative server. But if a recursive resolver queried that server an hour ago and got a response with a TTL of 86400 (24 hours), it will keep using the old IP for up to 24 hours. Even if you query that resolver directly, it will return the cached old answer.

This is not a failure; it is the intended behavior of DNS. To minimize propagation delay, lower the TTL before making a change, so that caches expire sooner. But even with a low TTL, some resolvers may ignore TTLs or have minimums, and the old record can persist.

Recursive vs. Iterative DNS

These terms describe two different roles in the resolution process:

• Recursive resolution: A resolver that accepts a query from a client and performs the full process of finding the answer, following referrals until it gets a final answer. The client only makes one query.
• Iterative resolution: A query where a server responds with a referral to another server, rather than the final answer. The querier then queries the referred server. This is what the recursive resolver does with each step.

In practice, a recursive resolver performs iterative queries. The distinction is between the client’s perspective (recursive) and the server’s response (iterative).

Comparison of Resolver Types

What People Get Wrong

A common misconception is that DNS is a single server that has all the answers. In reality, it is a distributed database with a hierarchical structure. Another mistake is thinking that a change to a DNS record is immediately visible everywhere. Because of caching, it is not. This is not a bug; it is a feature that reduces load on authoritative servers.

People also confuse the roles of recursive and authoritative servers. A recursive resolver does not own the records; it merely fetches them. An authoritative server does not perform recursion; it only answers for its own zone. Understanding this distinction helps diagnose why a query might return a stale answer or why a misconfigured authoritative server can cause outages.

How to See the Process

To observe the resolution path, use dig (on Unix-like systems) or nslookup (on Windows). The +trace option in dig shows each step from root to authoritative:

dig +trace example.com

This command queries the root servers, then the TLD servers, then the authoritative servers, and prints each response. The output shows the referrals and the final answer, making the process visible.

On Windows, nslookup can show the authoritative server for a domain:

nslookup -type=soa example.com

This displays the Start of Authority record, which includes the primary authoritative server and the TTL.

To check the cache on a recursive resolver, you can query it for a record and then query again immediately; the second response will be from cache (often indicated by a lower response time). However, there is no standard command to see cache contents directly.

Practical Implications

• TTL planning: Set TTLs based on how quickly you need changes to propagate. For critical changes, lower the TTL days in advance.
• Troubleshooting: If a change is not visible, check the TTL of the old record and wait. You can also query the authoritative server directly to confirm the change is live.
• Performance: Caching reduces latency and load. A well-configured recursive resolver can serve most queries from cache.

Understanding the full path of a DNS lookup allows you to predict behavior in scenarios not covered here. For example, if a recursive resolver is down, a client cannot resolve names unless it has a cached answer. If an authoritative server is down, queries will fail unless the recursive resolver has a cached answer. If a TTL is very low, more queries will reach the authoritative server, increasing load but reducing propagation delay.