DNS Resolution Process

A team moves its website to a new server at 10:00 in the morning. They update the DNS record, test the site, and everything works.

But for the rest of the day, some customers still reach the old server. Other customers see the new one. Nothing is broken. DNS is doing exactly what it was designed to do.

To understand why, we need to look at how a DNS lookup actually runs. This lesson explains the two ways a DNS server can be asked a question. It also covers the caches that make most lookups fast, and the rules that decide how long an answer is kept.

What DNS Resolution Is

DNS resolution is the process of converting a domain name into its IP address. The previous lesson showed who takes part: the stub resolver on your device, a recursive resolver, and the root, TLD, and authoritative servers.

Two things make resolution fast enough that users rarely notice it.

• How queries are asked. Different servers do different amounts of the work.
• Caching. Most answers are stored, so most lookups finish without asking many servers.

Two Ways to Ask: Recursive and Iterative Queries

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

Recursive Query

In a recursive query, the client asks the server for the complete answer.

If the server has the answer, 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 client just waits.

Recursive queries put more responsibility on the server.

Iterative Query

In an 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, which tells the resolver about another server that knows more. The resolver then sends a new query to that server. It repeats this until it gets the complete answer.

Iterative queries put more responsibility on the resolver.

Authoritative servers usually answer iteratively. When asked about a subdomain they do not manage, they reply with a referral to the name server that does.

Both Styles in One Lookup

A single lookup uses both styles, as shown below.

1. Your device's stub resolver sends one recursive query to its recursive resolver, like 1.1.1.1: "Give me the full answer for www.example.com."
2. The recursive resolver sends an iterative query to a root server. The root server replies with a referral to the .com TLD servers.
3. The resolver sends an iterative query to a .com TLD server. The TLD server replies with a referral to the authoritative servers for example.com.
4. The resolver sends an iterative query to an authoritative server, which replies with the IP address.
5. The recursive resolver returns the full answer to your device.

Caching

DNS caching means storing the results of earlier queries, so the same question can be answered again without asking other servers.

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

Caches exist at several layers, from nearest to farthest.

1. The browser keeps its own short-lived cache of recent lookups.
2. The operating system keeps a cache, used by the stub resolver.
3. The home router often acts as a caching-only resolver for every device in the home.
4. The recursive resolver keeps a large cache shared by all of its users. A popular resolver has almost every common domain name cached already.

The lookup stops at the first layer that has a fresh answer.

Here is the difference in numbers. An answer from a cache usually takes a few milliseconds or less. A full lookup with no cached data needs several round trips to the root, the TLD, and the authoritative servers. That can take from tens to hundreds of milliseconds.

TTL: How Long an Answer Is Kept

A cached answer cannot be kept forever. If it were, a website could never move to a new IP address.

Every DNS record has a Time To Live (TTL) value, which specifies how long the record should be stored in a cache. TTL is measured in seconds. When the TTL runs out, the cached copy is removed, so outdated answers are not served forever.

For example, a record with a TTL of 3600 may be cached for one hour. A record with a TTL of 300 may be cached for five minutes.

Why Some Customers Saw the Old Server

This explains what happened at the start of the lesson. The team's record had a TTL of 86400, which is one day. Resolvers that looked up the site just before 10:00 cached the old IP address for up to 24 hours. Until those copies expired, their users kept reaching the old server.

People often call this delay DNS propagation. But the new record does not travel anywhere. The delay comes only from old cached copies whose TTL has not expired yet.

Changing an IP Address Safely

TTL is a direct control on how quickly a change reaches users. Teams use it like this when they move a service to a new IP address.

1. Lower the TTL in advance. For example, change it from 86400 to 300. Do this at least one old TTL (here, one day) before the move, so every cached copy with the long TTL has expired.
2. Change the IP address in the record. Cached copies of the old address now expire within five minutes, so resolvers pick up the new address quickly.
3. Keep the old server running for a while, for any users who still have the old address.
4. Raise the TTL again once the move is complete, to reduce the number of lookups.