DNS resolution, referrals and cache

One question, several exchanges

An application usually asks a local stub resolver. The stub sends the question to a configured recursive resolver. If the resolver has fresh cached data, it can answer without repeating the full hierarchy. Otherwise it follows referrals toward the authoritative zone.

1. 01Client
2. 02Recursive resolver
3. 03Root
4. 04TLD
5. 05Authoritative server
6. 06Typed answer + TTL

Read the path carefully

1. The client asks for a specific name and record type.
2. The recursive resolver checks eligible cached data.
3. If needed, a root server refers it toward the relevant top-level domain.
4. The TLD server refers it toward the zone's authoritative servers.
5. An authoritative server returns the requested data or a DNS result explaining that it is unavailable.
6. The resolver returns the result and may cache eligible records for their remaining TTL.

The arrows are DNS messages, not a claim that the client application talks directly to every server. The recursive resolver performs those upstream exchanges on the client's behalf.

Cache changes what you observe

A second lookup can be faster because the resolver already has fresh data. It can also return an older-but-still-valid value until TTL expiry. Clearing a workstation's client cache does not clear the recursive resolver's cache and does not edit authoritative data.

Observe, then change one variable

In DNS Command Lab, run nslookup example.test, then inspect the cache. Change the requested type to AAAA, and finally clear only the virtual client cache. Explain which layer changed each time.

Next stepRun the DNS query lab

Type a real command form against a deterministic documentation-only fixture.