Part 6 · 2 chapters · ~12 min

DNS

The name hierarchy and delegation, stub and recursive resolvers, authoritative servers and zones, record types (A, AAAA, CNAME, MX, TXT, NS, SRV, CAA), TTLs and caching, negative caching, DNS in Kubernetes, GeoDNS and failover, DNSSEC, encrypted DNS (DoH, DoT), and common attacks and outages.

Resolution and caching

code

dig api.bank.example +trace         # follow the delegation from the root
dig api.bank.example A +short       # the answer
dig bank.example MX TXT CAA         # mail, verification records, which CAs may issue certificates
dig @1.1.1.1 api.bank.example +stats   # query a specific resolver and see timing

RESOLVING api.bank.example

stub resolver, recursive resolver, and the delegation chain

swipe the figure sideways, or tap expand for full screen

1/4

the stub

Your app asks the OS resolver (a stub), which asks a configured recursive resolver: your ISP's, a cloud VPC resolver, or a public one (1.1.1.1, 8.8.8.8).

stub → recursive resolver/etc/resolv.conf, VPC resolvers

Records, TTLs and failure modes

record	use
A / AAAA	name → IPv4 / IPv6
CNAME	alias to another name (not allowed at the zone apex; providers offer ALIAS/flattening)
MX, TXT	mail routing; SPF, DKIM, DMARC and domain verification
NS, SOA	delegation and zone metadata
SRV	service discovery with ports (used by some protocols and Kubernetes)
CAA	which certificate authorities may issue for the domain

Failure modes: a long TTL slowing a failover; negative caching of an NXDOMAIN after a record was briefly missing; Kubernetes ndots:5 causing several lookups per external name (use fully qualified names with a trailing dot, or tune ndots); resolver overload; and attacks such as cache poisoning (mitigated by randomised source ports and DNSSEC) and DDoS on authoritative servers. DoH and DoT encrypt queries between the client and resolver.