Build the idea first, then use the next activity to check it.
Records, resolvers and the order of lookups
What a resolver actually consults and in what order, which record types you will meet, and why a name can resolve on one host and fail on the next.
What you will be able to do
- Name the common record types and what each one answers
- Trace a lookup through cache, hosts file and configured resolver
- Explain why two hosts can disagree about the same name
Before this: You need "DNS - names instead of addresses" for the basic idea, and the DHCP lesson, since the resolver a host uses usually arrives in its lease.
Why it matters: "It works from my machine" is nearly always a DNS answer that differs between two hosts - a cached record, a hosts-file entry, or a different resolver handed out by a different scope. Knowing the lookup order turns that from a mystery into three things to check.
A resolver does not go straight to a DNS server. It works through a short list of places, in order, and stops at the first answer. Almost every confusing DNS fault is really a disagreement about which of those places answered.
The record types worth knowing
| Type | Answers | Typical use |
|---|---|---|
| A | Name to IPv4 address | The everyday lookup |
| AAAA | Name to IPv6 address | The same, over IPv6 |
| CNAME | Name to another name | An alias that follows a move |
| MX | Domain to mail host | Where to deliver mail |
| PTR | Address back to a name | Reverse lookups, logging |
| NS | Zone to its servers | Delegation between zones |
The order a lookup takes
- The application's own cache, if it keeps one.
- The operating system's resolver cache - a previous answer that has not yet expired.
- The hosts file, which is local, static, and beats the network.
- The configured resolver, usually the one handed out in the DHCP lease.
Two of those four are per-host state. That is the whole reason one machine resolves a name and its neighbour does not: the cache still holds an old answer, or someone put a line in the hosts file two years ago and forgot.
Two hosts, one name, two answers
The stock system moves to a new address on schedule and the A record is updated. A host that has never looked the name up gets the new address immediately. 's machine looked it up an hour before the cutover, under a one-day TTL, so it keeps using the old address for the rest of the day - and he reports the stock system as down while everyone around him is working normally.
TTL is a promise about staleness
Every record carries a time to live: how long a resolver may keep the answer before asking again. A long TTL reduces query load and makes changes slow to take effect. A short one does the opposite. Before a planned change, lowering the TTL in advance is what makes the cutover quick when it happens.
Key takeaways
- A resolver stops at the first answer from cache, hosts file, then the configured server.
- Two of those are per-host state, which is why hosts disagree.
- A CNAME answers with a name, not an address, and that indirection is what makes cutovers cheap.
- TTL decides how long a stale answer survives; lower it before a planned change, not during one.
Ready to keep going?
Create a free account to save your progress and take the knowledge check.