DNS

A device asks its resolver, which finds the answer by following referrals from the root down to the authoritative server for the name, and caches it for its TTL. Classic DNS is one unencrypted UDP packet each way with no proof: DNSSEC and encrypted DNS came later.

How DNS works, step by step

Names form a tree read from the right: www.example.lab. is www inside example, inside lab, inside the root, the final dot. Each part of the tree, a zone, is served by its owner's authoritative name servers. A parent zone does not know its children's names; it only knows which servers to ask, and delegates to them with NS records.

When a program on a laptop needs the address of www.example.lab:

1. The stub asks the resolver. The laptop's resolver library reads /etc/resolv.conf and sends one UDP packet to port 53 of the server named there. The DNS header holds a 16-bit id, the RD flag (recursion desired: "do the whole job for me") and the question: name, type A, class IN.
2. The resolver checks its cache. If it holds an unexpired answer, it replies at once.
3. Otherwise it walks the tree. It asks a root server, from the list it ships with (the root hints). The root does not know the name and answers with a referral: no answer, an NS record in the authority section (lab. NS ns.lab.) and the address of that server in the additional section, the glue.
4. It asks ns.lab, which refers it one level down to ns.example.lab.
5. ns.example.lab answers with the address and the AA flag set: an authoritative answer.
6. The resolver answers the laptop with RA set (recursion available), and caches every answer and referral for its TTL in seconds.

The resolver does the walking and the servers only point the way: that is iterative resolution. A forwarder, like the DNS server in a home router, skips the walk and hands every question to one upstream resolver.

What it looks like on a Linux machine

In the DNS tree lab the name servers run BIND and the resolver runs unbound. dig shows the flags and the TTL:

$ dig www.example.lab
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41721
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
www.example.lab.	60	IN	A	10.0.2.13

;; SERVER: 10.0.1.11#53(10.0.1.11) (UDP)

No aa: the resolver is passing on what it found. You can play resolver yourself. +norecurse clears RD and @ picks the server:

$ dig +norecurse @10.0.2.10 www.example.lab
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; AUTHORITY SECTION:
lab.			60	IN	NS	ns.lab.

;; ADDITIONAL SECTION:
ns.lab.			60	IN	A	10.0.2.11

Ask ns.example.lab the same way and the flags read qr aa. dig +trace does the whole walk, one level at a time. Ask the resolver twice and the second answer comes from its cache, its TTL counting down, while a capture on the resolver's outside shows no query at all.

What goes wrong, and how you see it

NXDOMAIN. The name does not exist. The answer comes from the server responsible for where it would be, with the zone's SOA record, whose last field says how long "does not exist" may be cached (negative caching, RFC 2308).

SERVFAIL. The resolver tried and failed: an authoritative server is unreachable, a delegation is broken, or DNSSEC validation failed. The DNSSEC lab shows the last one.

No answer at all. dig prints ;; connection timed out; no servers could be reached. The resolver in resolv.conf is down, or a firewall drops port 53. Programs report it as a failed lookup: curl exits with code 6, Could not resolve host.

An old answer. A record changed, but resolvers keep the cached one until its TTL runs out. That is what "DNS propagation" means. Lower the TTL a day before a move.

A false answer. Classic DNS has no proof of origin: whoever answers first with the right id and port wins. The DNS spoofing lab sends a laptop to the wrong server this way, and shows what TLS does about it.

Questions people ask

Does DNS use UDP or TCP? Both, on port 53. Queries go over UDP; an answer too big for the UDP size the client offered comes back truncated (the TC flag) and the client retries over TCP. Zone transfers always use TCP.

What is the difference between a resolver and an authoritative server? A resolver looks names up for clients and caches them. An authoritative server holds a zone and answers only for it. Keeping the jobs on separate servers is good practice.

What are A, AAAA and CNAME records? A maps a name to an IPv4 address, AAAA to an IPv6 address, CNAME makes a name an alias of another name, which the resolver then follows.

See it on real machines