DNS

Before a browser can open a TCP connection to api.example.com, it needs an IP address. DNS is the directory service that maps names to addresses — and the reason a tiny misconfiguration can make a whole application vanish from the internet.

Analogy

DNS is like calling directory assistance to find a friend's new apartment. You don't know the street address, only the name. The local operator (your stub resolver) doesn't have it, so they call their regional office (the recursive resolver). That office calls the national switchboard (root nameservers), which says "try the state operator for Ohio", which points them at the county operator, which finally points them at the building manager who actually holds the address. Once they've looked it up, the regional office tapes the answer to their wall for a set number of days (the TTL), so the next fifty people asking get the answer instantly. "DNS propagation" is just waiting for each regional office's tape to fall off — if a tape said "good for 24 hours", nobody's pulling it down early, no matter how urgently you updated your address.

The resolution path

No single server knows all names. The work is divided hierarchically and cached aggressively.

browser
  │ "what is api.example.com?"
  ▼
stub resolver (your OS)
  │ checks local cache — miss
  ▼
recursive resolver (your ISP or 8.8.8.8)
  │ checks its cache — miss
  │ "who manages .com?" → asks a root nameserver
  ▼
root nameserver
  │ "I don't know, ask .com TLD servers"
  ▼
recursive resolver
  │ "who manages example.com?" → asks .com TLD server
  ▼
.com TLD nameserver
  │ "I don't know, ask ns1.example.com"
  ▼
recursive resolver
  │ "what is api.example.com?" → asks ns1.example.com
  ▼
authoritative nameserver (ns1.example.com)
  │ "api.example.com → 1.2.3.4, TTL 300"
  ▼
recursive resolver → caches for 300 seconds → returns to stub
stub → caches locally → browser opens TCP to 1.2.3.4

The recursive resolver does the heavy lifting. Your stub resolver (in the OS) delegates everything to it. The recursive resolver climbs the hierarchy once, then caches the answer so subsequent queries are instant.

Record types

Type	Stands for	What it contains	Example use
A	Address	IPv4 address	api.example.com → 1.2.3.4
AAAA	IPv6 Address	IPv6 address	api.example.com → 2001:db8::1
CNAME	Canonical Name	Alias to another name	www.example.com → example.com
MX	Mail Exchange	Hostname to send email to (+ priority)	example.com → mail.example.com
TXT	Text	Arbitrary text	SPF, DKIM, domain verification
NS	Nameserver	Authoritative nameserver for a zone	Delegation
SOA	Start of Authority	Zone metadata + admin contact	Required in every zone

A CNAME cannot coexist with other record types at the same name — this is the "CNAME at apex" problem. If example.com is a CNAME, it cannot also have an MX or NS record. CDN providers work around this with proprietary "ALIAS" or "ANAME" records at the apex.

TTL and caching

Every DNS record carries a TTL (time to live) in seconds. Resolvers must not serve the cached answer after the TTL expires.

Short TTLs (60–300 seconds) allow fast failover. Long TTLs (86400 seconds = 1 day) reduce resolver load. Before a planned migration, lower the TTL days in advance so the old value drains from caches quickly.

Negative caching: A "this name does not exist" (NXDOMAIN) response is also cached, for the SOA's minimum value. Misconfigure a zone, and the "not found" answer can stick around for hours.

Propagation

"DNS propagation" is often misunderstood. There is no push — DNS changes spread only as caches expire. If the TTL was 86400 before your change, some resolvers will serve the old answer for up to 24 hours after you updated the record. That is why you lower the TTL days before the change, wait for caches to drain, make the change, then raise the TTL again afterward.

dig in practice

dig is the command-line DNS client. Reading its output is a core skill:

$ dig api.example.com A

;; QUESTION SECTION:
;api.example.com.      IN  A

;; ANSWER SECTION:
api.example.com.  300  IN  A  1.2.3.4

;; AUTHORITY SECTION:
example.com.  3600  IN  NS  ns1.example.com.

;; Query time: 12 msec
;; SERVER: 8.8.8.8#53

The 300 is the TTL remaining. The SERVER line tells you which resolver answered. Add +trace to force a full walk from the root — useful when you suspect delegation is broken.

DNS over HTTPS and DNS over TLS

Traditional DNS sends queries in plaintext over UDP port 53. Anyone on the path can see what names you resolve. DNS over HTTPS (DoH, port 443) and DNS over TLS (DoT, port 853) encrypt the query. Both are widely deployed in browsers and operating systems.