Step 1 of 5 · Reading · ~3 min
Read
Caching & Production
Putting It All Together
A complete DNS server or resolver is the pieces you have already written, wired into one loop:
incoming UDP/TCP packet on :53
-> parse DNS header
-> parse question
-> if RD=1 and we are a recursive resolver:
check cache (positive AND negative)
if miss: do iterative resolution
cache the answer
return to client
else (we are authoritative):
look up zone
handle CNAME chasing
return answer, NODATA, or NXDOMAIN
-> serialize response
-> send back
What each earlier lesson contributed
| Component | Comes from |
|---|---|
| Header parsing | The DNS Header |
| Name encoding and decoding | Encoded Names & Compression |
| Query construction | Question Section |
| Pointer dereferencing | Name Compression Decoder |
| Resource record encoding | Resource Records |
| MX / SRV / SOA RDATA | MX, SRV, and SOA Records |
| Zone lookup, NODATA vs NXDOMAIN | Zone Files & Authoritative Lookups |
| Alias following | CNAME Chasing |
| The root-to-authoritative walk | Recursive Resolution |
| TTL expiry | TTL-Based Caching |
| Truncation and the TCP retry | EDNS, DNSSEC, & DoH |
Operating this at scale
Three mechanisms you meet the moment a resolver or an authoritative server carries real traffic. None of them changes a byte of the wire format you have been writing.
Anycast. One address is advertised into BGP from many sites at once, and ordinary routing delivers each client to whichever site is nearest. 1.1.1.1 and the root servers work this way: a single address, hundreds of machines. It is not multicast - each query still travels to one destination - and it is not a failover pair, because every site is live. A site that dies simply stops advertising the route.
Geo-aware answers. A CDN wants a client in Osaka to receive a different A record than a client in Lisbon, so the authoritative server picks its answer from where the query appears to come from. The awkward part is that it sees the recursive resolver's address, not the client's. EDNS Client Subnet (RFC 7871) exists for exactly this: the resolver passes along a truncated prefix of the real client address as a hint.
Zone transfers. Secondary authoritative servers replicate a zone from the primary instead of being edited separately. AXFR (RFC 1035) pulls the entire zone. IXFR (RFC 1995) pulls only what has changed since the serial number the secondary already holds - a zone that costs megabytes over AXFR is usually a handful of records over IXFR. The secondary knows to ask because the SOA refresh timer fired, or because the primary sent it a NOTIFY (RFC 1996).
Still ahead of you
- DNSSEC validation - verifying RRSIG signatures and walking NSEC/NSEC3 records to prove that a name really does not exist.
- Dynamic updates (RFC 2136) - changing a zone programmatically rather than by editing a file.
- Health-checked answers - returning only the backends that are currently up.
What you have built is the shape of the real thing. BIND, Unbound, dnsmasq, CoreDNS, systemd-resolved, Route 53 and Cloudflare DNS all parse the same 12-byte header, dereference the same 14-bit pointers, and obey the same TTLs.
Discussion
Ask a question, share an insight, or help someone who’s stuck.
Sign in to post a comment or reply.
Loading…