Skip to content
Lesson 12 of 13

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

ComponentComes from
Header parsingThe DNS Header
Name encoding and decodingEncoded Names & Compression
Query constructionQuestion Section
Pointer dereferencingName Compression Decoder
Resource record encodingResource Records
MX / SRV / SOA RDATAMX, SRV, and SOA Records
Zone lookup, NODATA vs NXDOMAINZone Files & Authoritative Lookups
Alias followingCNAME Chasing
The root-to-authoritative walkRecursive Resolution
TTL expiryTTL-Based Caching
Truncation and the TCP retryEDNS, 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.

Up nextNegative Caching (RFC 2308)Caching & Production

Discussion

Ask a question, share an insight, or help someone who’s stuck.

Sign in to post a comment or reply.

Loading…