DNS
Domain Name System · Application layer
Nobody types IP addresses. DNS is the distributed database that maps names to addresses, organised as a hierarchy so no single machine has to hold all of it. Almost every connection starts with a DNS lookup, which is why DNS failures look like everything being broken.
Understand these first
- Why does this protocol exist?
- People use names and packets need addresses. A global list on every machine stopped working in the 1980s, so lookup had to become a distributed, cacheable protocol.
- Which problem does it solve?
- Turn a name into an address, using a hierarchy where no single server knows everything and no single server has to.
- Who participates?
- A stub resolver on your machine, a recursive resolver acting on its behalf, and the authoritative servers: root, TLD, and the domain's own. The recursive resolver does nearly all the work.
- Which layer uses it?
- Application layer. Usually over UDP port 53; over TCP when a response is too large or a zone transfer is needed.
- What does it depend on?
- UDP (and TCP for large answers), which means IP, which means ARP. The resolver's own address usually comes from DHCP.
- What depends on it?
- Effectively every user-facing protocol. Nothing reaches a website by name without it, which is why DNS failure looks like total internet failure.
- What state does each participant maintain?
- Caches, keyed by name and record type, each with a TTL set by the authoritative server. A pending query holds a transaction ID until the answer arrives. Authoritative servers hold their zone; recursive resolvers hold whatever they have learned recently.
- Which fields matter?
- transaction id — Matches a response to its query. UDP has no connection, so this is the only thing tying them together.
- flags (QR, RD, RA, RCODE) — Query or response, recursion desired, recursion available, and the result code — NXDOMAIN, SERVFAIL, REFUSED are all here.
- question section — The name and record type asked about. Echoed in the response, which is how you confirm the answer is to the right question.
- answer TTL — How long this may be cached. It explains why a change takes time to take effect everywhere.
- What does normal behaviour look like?
- One query from the stub to the recursive resolver, several queries from the resolver down the hierarchy (root, then TLD, then authoritative), then one answer back, then silence — the next lookup is served from cache.
- What does failure look like?
- NXDOMAIN when the name genuinely does not exist. Timeout and retry when the resolver is unreachable. SERVFAIL when the resolver tried and could not complete. The three have completely different causes and the application reports all of them as 'cannot reach site'.
- How can I prove the diagnosis from packets?
- Look at the response code and at who answered. A timeout with no response at all is a reachability problem, not a naming one; NXDOMAIN is an authoritative statement that the name does not exist; SERVFAIL means the resolver itself failed.
- How does it interact with the rest of the stack?
- DNS runs before almost everything else and its failure is the first thing to rule out. It depends on the resolver address DHCP supplied, and the address it returns is what TCP then connects to — which is why a stale cached record produces a connection failure that has nothing to do with TCP.
Guided course — 4 lessons
Read in order. Every lesson pauses the capture on the packets it is talking about, and every one reads at three levels — so the time below is an estimate from the number of steps, not a measurement of anybody.
- 1DNS-01How a Name Becomes an AddressNobody holds the whole directory — and that is the design≈10 min · 8 steps · 4 questions · guidedNot started
- 2DNS-02Troubleshooting: 'It Must Be DNS'Telling a DNS failure from something DNS is merely downstream of≈10 min · 6 steps · 3 questions · guided · diagnosis lab · after dns-how-a-name-is-resolvedNot started
- 3DNS-03Record Types and the Four SectionsA is not the only question, and the answer section is not the only answer≈15 min · 8 steps · 3 questions · guided · after dns-how-a-name-is-resolvedNot started
- 4DNS-04When the Answer Does Not FitTruncation, TCP, and telling three kinds of failure apart≈10 min · 7 steps · 3 questions · guided · diagnosis lab · after dns-how-a-name-is-resolved, dns-records-and-sectionsNot started
Troubleshooting labs — 2
A symptom, a capture, and no answer given. Each one is a lesson from the course above, listed again here because the diagnosis is worth coming back for.
Packet explorer — 9 scenarios, no coaching
PC1 asks its resolver for www.example.test. The resolver knows nothing, so it walks the hierarchy: root, then .test, then example.test. Six packets to answer one question — and the next one will take two.
Cached: the same question, answered instantlyTwo identical lookups, four seconds apart. The first walks the whole hierarchy; the second is answered from cache in one round trip. This is why the second page of a site loads faster than the first.
A CNAME chainshop.example.test is an alias. The answer carries two records: the alias pointing at cdn.example.test, and that name's address. One question, a two-step answer.
NXDOMAIN — no such nameA definitive 'this does not exist', which is very different from a timeout. The resolver caches the negative answer too, so a typo in a config file cannot generate the same doomed lookup forever.
SERVFAIL — the resolver could not find outNot 'the name does not exist' but 'I could not answer'. The distinction matters: NXDOMAIN means stop, SERVFAIL means try a different resolver.
Looking up a mail serverMX records answer a different question from A records: not 'where is this host' but 'who accepts mail for this domain'. The preference number ranks the candidates.
Truncated: too big for one datagramUDP preserves datagram boundaries, so an oversized answer cannot simply be split. The server returns an empty response with the truncation flag set, which means: ask again over TCP.
Query lost, client retriesThe first query never arrives. Nothing reports it — UDP has no mechanism to. The client's own timer fires a second later and it asks again. Every bit of that recovery is the application's work.
Troubleshooting: the resolver address is wrongPC1 is configured with a resolver that nothing owns. It ARPs, gets no answer, and every lookup times out. Notice there is no DNS packet in the capture at all — the failure is below DNS entirely.
Reference material
The terms this module introduces, and the specifications behind them. Both lists come from the lessons themselves rather than from a list kept beside them.
That you can read a response code as an answer, and say what a name resolution does and does not reveal.
Where DNS sits in a real request
These captures run DNS as one stage of a longer chain, and hand its result to whatever comes next.
You plug in a laptop and type a name. Four protocols run before a single byte of the page is requested, and each one exists because the one before it could not do this job. Watch what each stage hands to the next.
Opening a secure websiteThe same four stages, plus one: before any request is sent, the server has to prove it is the server. Note what a capture can still read after encryption starts — and what it cannot.
A routed enterprise application, end to endThe office journeys stop at the gateway. This one starts before it: two routing protocols fill one routing table, then ARP and DNS do their usual jobs, then an application opens a connection across the result. Nothing in the application's packets refers to a routing protocol — and that is what the routing protocols are for.
Diagnosis: one site fails, everything else is fineOther sites load normally. This one fails instantly — not slowly, instantly. That timing is a clue in itself.
Diagnosis: the site is reachable but refusesThe name resolves and the server is clearly alive — it answers immediately. It just will not accept the connection.
Diagnosis: the browser warns before showing anythingThe connection opens fine, bytes flow both ways, and then the client hangs up on purpose. Something in what the server sent was unacceptable.
Diagnosis: the page loads, and it is an error pageEvery layer beneath does its job perfectly. This is the case where the network is genuinely not at fault — and being able to prove that is the skill.