Networking
DNS Resolution
Hierarchical name-to-IP lookup, cached at every level
DNS (Domain Name System) is the internet's phone book — it translates human-readable names like example.com into IP addresses computers actually route to. The lookup walks a hierarchy from root servers to TLD servers to authoritative name servers, with caches at every step. A typical lookup hits the local cache in microseconds; an uncached query takes 50-200 ms.
- Default port53 (UDP for queries, TCP for large responses or zone transfers)
- Modern alternativesDNS-over-HTTPS (DoH), DNS-over-TLS (DoT) — port 443 / 853
- Hierarchy levelsRoot → TLD → authoritative → recursive resolvers
- Common record typesA, AAAA, CNAME, MX, TXT, NS, SOA, PTR
- Default TTL300-86400 seconds (5 min to 24 h)
- Anycast deploymentAll 13 root servers use anycast (hundreds of physical instances)
Interactive visualization
Press play, or step through manually. The visualization is yours to drive — try it before reading on.
Watch the 60-second explainer
A condensed visual walkthrough — narrated, captioned, under a minute.
How a DNS lookup actually flows
You type example.com in your browser. Here's what happens (assuming nothing is cached anywhere):
- Browser → OS resolver. The browser asks the operating system. OS checks its cache; on miss, asks the configured DNS resolver (typically your ISP, or 1.1.1.1, or 8.8.8.8).
- OS → recursive resolver. Sends "what's the IP for example.com?" over UDP to port 53.
- Recursive resolver → root. Resolver checks its cache. On miss, queries one of the 13 root server clusters: "where's the .com TLD?"
- Root → TLD. Root replies with the .com TLD name servers (Verisign).
- Recursive resolver → .com TLD. "Where's example.com's authoritative server?"
- TLD → authoritative. .com replies with the name servers for example.com (in ICANN's registry).
- Recursive resolver → authoritative. "What's example.com's A record?"
- Authoritative → recursive resolver. Returns the IP (e.g., 93.184.216.34) and a TTL.
- Recursive resolver → OS. Returns the IP, caches it for the TTL.
- OS → Browser. Returns the IP, caches it briefly.
- Browser opens TCP connection to 93.184.216.34.
Total: 4-5 round trips for an uncached lookup. With caching at every layer, most lookups complete in 0-1 round trips. Your local resolver caches the .com TLD info for hours; example.com's A record stays cached until the TTL expires.
Common DNS record types
| Type | Purpose | Example |
|---|---|---|
| A | IPv4 address | example.com → 93.184.216.34 |
| AAAA | IPv6 address | example.com → 2606:2800:220:1:248:1893:25c8:1946 |
| CNAME | Alias to another name | www.example.com → example.com |
| MX | Mail server | example.com MX 10 mail.example.com |
| TXT | Free-form text (SPF, DKIM, domain verification) | "v=spf1 include:_spf.google.com ~all" |
| NS | Authoritative name server | example.com NS ns1.example.com |
| SOA | Start of Authority — zone metadata | (serial, refresh, retry, expire, minimum) |
| PTR | Reverse lookup (IP → name) | 34.216.184.93.in-addr.arpa → example.com |
| CAA | Which CAs may issue certificates for this domain | example.com CAA 0 issue "letsencrypt.org" |
| SRV | Service location (port + host) | _sip._tcp.example.com → 10 5 5060 sip.example.com |
Caching and TTL strategy
Every DNS record has a TTL — the maximum time a cache may hold it before re-asking the authoritative server. Picking the right TTL is a trade-off:
| TTL | Best for | Cache hit rate | Update propagation |
|---|---|---|---|
| 30-60 sec | Failover, frequent IP changes, A/B testing | Low | ~1 minute |
| 5 min | Active development, recent migrations | Moderate | ~5 min |
| 1 hour | Default for most DNS providers | Good | ~1 hour |
| 24 hours | Stable production records | Excellent | ~24 hours |
| 1 week | Rarely-changing infrastructure (NS records) | Highest | ~1 week |
Best practice — drop TTL to ~5 min before a planned migration, wait for old caches to expire, do the change, raise TTL back to ~1 hour after stability. The lower TTL costs you nothing during steady-state because the migration happened.
DNS security — poisoning, DoH, DNSSEC
Plain DNS over UDP has two security problems:
- Eavesdropping. Anyone on the network path (your ISP, a coffee-shop attacker, a state actor) can see every domain you query. Reveals every site you visit, even before TLS protects the actual content.
- Tampering. An attacker can race the legitimate response with a forged one — DNS queries are unauthenticated, the first matching response wins. Cache poisoning attacks (Kaminsky 2008) inject fake records into resolver caches, redirecting users to malicious sites for the cache TTL.
Two solutions:
- DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). Encrypt the query in transit. DoH wraps DNS in HTTPS to port 443 — looks like normal web traffic, hard to block. DoT uses port 853 with TLS but is identifiable. Both prevent eavesdropping and tampering between client and resolver. Doesn't fix authoritative-server-to-resolver tampering.
- DNSSEC. Cryptographically signs DNS records so resolvers can verify authenticity end-to-end. Eliminates cache poisoning even with plain UDP DNS. Adoption is uneven — most TLDs and registrars support it, but many domains don't enable it.
Inspecting DNS with dig and nslookup
# Standard A record lookup
dig example.com
# Specify record type
dig example.com MX
dig example.com AAAA
# Trace the resolution path step by step
dig +trace example.com
# Query a specific server
dig @1.1.1.1 example.com
# Reverse lookup
dig -x 93.184.216.34
# Get just the answer, no metadata
dig +short example.com
# Check DNSSEC
dig example.com +dnssecWhy root servers can be hit from anywhere
The 13 root servers (named A through M) aren't single machines — each is an anycast cluster of hundreds of identical servers spread globally. When you query "the A root server," BGP routing delivers your query to the closest physical instance.
This is why a query from Tokyo and a query from London both reach "the root" in 5-10 ms each, even though only 13 logical servers exist. The whole DNS hierarchy uses anycast at the root and TLD level for latency and DDoS resilience — taking down one physical instance just shifts load to the others.
Common DNS issues
- "DNS propagation taking forever." Almost always cache-related. The new value is set; old caches are still serving old values until TTL expires. The fix isn't to wait longer — the fix is to set a low TTL before the change. Once changed, you wait at most the old TTL.
- CNAME at the apex domain. CNAMEs can't coexist with other records, and the apex always has SOA + NS. So you can't have
example.com CNAME load-balancer.aws.com. Use ALIAS (Route53) or ANAME (other providers) — provider-specific records that resolve to the underlying IP at query time. - Stale glue records. When your domain's NS records point at name servers that are themselves subdomains (
example.com NS ns1.example.com), the parent zone (.com) has to provide "glue" — the IP of ns1.example.com so resolvers can find it. Forgetting to update glue when changing IPs creates orphan zones — your name servers move but resolvers can't find them. - Mismatched IPv4 / IPv6 records. A record points to one IP; AAAA points to a different (or non-existent) IP. Clients with IPv6 may get a different (broken) answer than clients with IPv4 only. Either set both consistently or drop one.
- Forgetting to set SPF / DKIM / DMARC for email. Without proper TXT records, your email goes to spam. SPF in TXT, DKIM in TXT (one per signing key), DMARC in TXT at
_dmarc.example.com. Use a tool to verify (mxtoolbox, dmarcian). - Browser DNS caching independent of OS. Chrome and Firefox cache DNS separately from the OS resolver. Browser cache is ~60 seconds; flushing the OS cache won't clear it. Restart the browser or use
chrome://net-internals/#dnsto clear it explicitly.
Frequently asked questions
Why is DNS hierarchical?
Scalability and delegation. The root knows only TLDs. The .com TLD knows only .com domains' name servers. Each domain's authoritative server knows only its own subdomains. No single server has to know everything. The hierarchy lets each level be operated by a different organization (ICANN runs root, Verisign runs .com, you run example.com).
What's the difference between recursive and iterative resolution?
A recursive resolver does the full lookup on the client's behalf — asks root, then TLD, then authoritative, returns the final answer. An iterative resolver returns "I don't know, but try server X" and the client must follow up. End-user devices use recursive resolvers (configured via DHCP or manually like 8.8.8.8). The recursive resolver itself uses iterative queries against the hierarchy.
What's the difference between A and AAAA records?
A records hold IPv4 addresses (32-bit, like 93.184.216.34). AAAA records hold IPv6 addresses (128-bit, like 2606:2800:220:1:248:1893:25c8:1946). Modern domains have both — clients prefer IPv6 when their network supports it, fall back to IPv4 otherwise. The double-A in AAAA is because IPv6 is 4× the bits of IPv4.
What's a CNAME and when do you use it?
A CNAME (Canonical Name) is an alias from one name to another. www.example.com CNAME example.com means "look up example.com instead." Use them for service aliases (api.example.com → load-balancer.aws.com) and to avoid duplicating records. Restriction — a CNAME can't coexist with other records (A, MX, TXT) at the same name. So you can't CNAME the apex domain (example.com itself); use ALIAS or ANAME records (provider-specific) instead.
How does DNS caching work?
Every layer caches. Browser cache (~60s), OS resolver cache (per OS), recursive resolver cache (your ISP's or 8.8.8.8), TLD servers cache, occasionally authoritative servers themselves. Each record has a TTL; cache layers serve from cache until TTL expires. Lower TTLs = faster propagation of changes; higher TTLs = better cache hit rates and less load on authoritative servers. Typical TTLs are 300s (5 min) to 86400s (24 h).
What's DNS-over-HTTPS?
DNS queries encrypted inside HTTPS, sent to port 443. Solves two problems with traditional DNS — (1) ISPs can see and log every domain you visit (privacy), (2) attackers on your network can intercept and tamper with DNS responses (security). DoH disguises DNS traffic as ordinary HTTPS, defeating both. Cloudflare (1.1.1.1), Google (8.8.8.8), and Quad9 all support DoH; modern browsers like Firefox use it by default in some regions.
What's DNSSEC and why isn't it used everywhere?
DNS Security Extensions — adds cryptographic signatures to DNS records so resolvers can verify authenticity (the answer really came from the authoritative server). Solves DNS poisoning. Adoption is patchy because deploying it correctly is hard — key management, larger response sizes, more configuration steps. Most large registrars now offer DNSSEC, but the bottom of the hierarchy (resolver validation) remains uneven. Critical for protocols like SSHFP and DANE that bootstrap trust off DNS.