DNS Resolution Process

DNS resolution is the process of converting a domain name into its IP address. Two things make it fast enough to be invisible: the way queries are asked, and the caching that stops most of them from travelling far.

Two Ways to Ask

A DNS query comes in two styles, and the difference is about who is responsible for finding the answer.

Recursive query

The resolver asks the server for the complete answer.

If the server has it, it replies. If it does not, the server takes on the job of contacting other DNS servers until it finds the answer, and only then replies. The work happens out of sight.

Recursive queries put more responsibility on the server.

Iterative query

The resolver asks the server for the best answer it has right now.

If the server does not have the complete answer, it replies with a referral: the address of another server that might know more. The resolver then sends a fresh iterative query to that server, and repeats until it gets a complete answer.

Iterative queries put more responsibility on the resolver.

Both styles appear in a single lookup. Your device sends one recursive query to its resolver, and that resolver then works through the hierarchy iteratively on your behalf.

Caching

Resolvers and servers cache the results of previous queries.

When a resolver receives a query, it checks its cache first. If the answer is there, it replies immediately without contacting any other server. That saves time and cuts network traffic, and it is why most lookups never reach a root server.

TTL

A cached answer cannot be kept forever, or the internet would never be able to move anything.

Every DNS record carries a Time To Live (TTL) value, which specifies how long the record should be stored in the cache. TTL is measured in seconds. Once it expires, the cached information is removed, so outdated answers do not keep being served.

That makes TTL a direct control on how quickly a change spreads. Suppose a team is about to move a service to a new IP address. If the TTL is long, resolvers all over the internet will keep handing out the old address until their copies expire. Lowering the TTL in advance means cached copies of the old address expire sooner, so resolvers pick up the new one quickly after the change.

The trade is the obvious one. A short TTL means faster propagation and more lookups. A long TTL means fewer lookups and slower propagation.

Negative Caching

Caching an answer is useful. Caching the absence of an answer turns out to be useful too.

Negative caching is caching the fact that a domain or record does not exist.

When a resolver is asked for a name that is not there, it walks the hierarchy, receives the authoritative answer that the name does not exist, and stores that non-existence as a negative response. The next time the same name is asked for, the resolver answers from the cache instead of walking the hierarchy again to fail in the same way.

This matters more than it sounds. Typos, stale links and misconfigured clients generate a steady stream of requests for names that will never resolve. Without negative caching, every one of them would travel the full hierarchy. With it, they stop at the first resolver.

💡 A useful thing to know in an interview: DNS propagation delay is not a mysterious internet property, it is just TTL. If you are asked how to make a failover fast, "lower the TTL on that record ahead of time" is a concrete answer, and noting that it costs extra lookups shows you know what you are trading away.

Key takeaway: A recursive query asks the server for the full answer and makes the server do the chasing. An iterative query returns a referral and leaves the chasing to the resolver. Caching keeps most lookups from travelling at all, TTL decides how long each cached record survives and therefore how fast a change spreads, and negative caching remembers that a name does not exist so failed lookups are not repeated.

The next lesson, DNS Load Balancing and High Availability, covers what DNS can do beyond answering a question correctly.