What is DNS Resolution

The hierarchy, first principles

DNS is a globally distributed, eventually-consistent, read-heavy key-value store. The key is a Fully Qualified Domain Name (FQDN); the value is one or more resource records (A, AAAA, CNAME, MX, TXT, …). The store is sharded by a tree structure: the root zone, then top-level domains (TLDs), then second-level domains, then subdomains — each level delegated to different operators.

The five players in every resolution

1. Stub resolver — a tiny library inside your OS (glibc, Windows DNS Client). It has no knowledge of the hierarchy; it just forwards queries to a configured recursive resolver.
2. Recursive resolver (a.k.a. full-service resolver) — the heavy lifter. Your ISP, Google (8.8.8.8), Cloudflare (1.1.1.1), or your VPC's resolver. It does the multi-step walk on your behalf and caches results.
3. Root nameservers — 13 logical servers (A–M.root-servers.net), anycast-distributed across 1,700+ physical nodes. They don't know your answer; they know which nameservers are authoritative for each TLD.
4. TLD nameservers — operated by registries (Verisign for .com, PIR for .org). They know which nameservers are authoritative for each registered second-level domain.
5. Authoritative nameserver — the source of truth for a zone. This is where your A records, CNAMEs, and MX entries live. Route 53, Cloudflare DNS, or your own BIND server.

The resolution walk, step by step

Assume cold cache throughout:

1. Your browser calls getaddrinfo("api.example.com"). The OS stub resolver checks /etc/hosts — no match.
2. Stub resolver sends a recursive query to the configured recursive resolver (say, 1.1.1.1).
3. Recursive resolver checks its cache — cold. It starts the iterative walk.
4. Recursive resolver queries a root nameserver: "Who handles .com?" Root responds with NS records pointing to Verisign's TLD nameservers. (i.e. the registry's Name Server)
5. Recursive resolver queries a .com TLD nameserver: "Who handles example.com?" TLD responds with NS records for example.com's authoritative nameserver.
6. Recursive resolver queries that authoritative nameserver: "What is the A record for api.example.com?" Authoritative server responds with 93.184.216.34 (this is just an example, and may not be accurate) and a TTL (say, 300 seconds).
7. Recursive resolver caches the answer for 300 seconds, then returns it to your stub resolver.
8. OS caches it (often separately, with its own TTL enforcement), then returns it to your application.

Total round trips: typically 3 UDP exchanges (root → TLD → authoritative), each ~10–100 ms depending on geography. On a warm cache, step 2 returns in <5 ms.

Resource records you must know

• A / AAAA — maps hostname → IPv4 / IPv6.
• CNAME — canonical name alias; chains to another name. A CNAME at a zone apex is forbidden by RFC 1034 (use ALIAS/ANAME or CNAME flattening as workarounds).
• NS — delegates a zone to a nameserver. The glue that makes the whole hierarchy work.
• SOA — Start of Authority; defines the zone's primary nameserver, admin email, serial number, and negative-cache TTL.
• MX, TXT, SRV — mail routing, verification tokens, service discovery.

TTL mechanics and why they matter operationally

TTL (Time To Live) is set by the zone owner on each record. It is a hint to caching resolvers — RFC 1035 says resolvers must respect it, but many clients (browsers, JVMs, some CDNs) apply their own minimums or maximums. When you're planning a migration:

• Lower TTLs to 60–300 seconds before the cutover, not during.
• After cutover, raise them back to hours or days to reduce resolver load.
• Understand that some resolvers ignore TTL floors — a record with TTL 0 may still be cached for 30–60 seconds in practice.

Negative caching

NXDOMAIN (name does not exist) responses are also cached — for the duration specified in the SOA's MINIMUM field (RFC 2308). If you fix a typo in a hostname and DNS propagated the NXDOMAIN, some resolvers will stubbornly return NXDOMAIN until that TTL expires. This bites engineers who fix records and immediately test.

DNSSEC in brief

DNSSEC adds a chain of cryptographic signatures from root → TLD → authoritative zone. It prevents cache poisoning (Kaminsky attack) by letting resolvers verify that answers weren't tampered with in transit. It does not encrypt queries — DNS over HTTPS (DoH) and DNS over TLS (DoT) handle that separately.

Practical tools

# Full iterative walk from root — mirrors what a cold recursive resolver does
dig +trace api.example.com

# Query a specific resolver directly
dig @8.8.8.8 api.example.com A

# Check what your OS stub resolver sees (may differ from dig)
nslookup api.example.com

# Inspect SOA negative TTL
dig SOA example.com