DNS
Date: 2026-08-17
The system translating hostnames into IP addresses. It’s a hierarchy of caches, which is why it’s fast, and why a change you made an hour ago is still not visible to everyone.
DNS — the Domain Name System — resolves a hostname like shop.example.com to an IP address, using a distributed hierarchy of servers and caches.
Resolution, step by step
shop.example.com — where is it?
1 browser cache seen it recently?
2 OS cache seen it recently?
3 RECURSIVE RESOLVER your ISP, or
1.1.1.1 / 8.8.8.8
↓ if not cached, it asks:
4 ROOT servers "who handles .com?"
5 TLD servers "who handles
example.com?"
6 AUTHORITATIVE server "shop is 203.0.113.5"
↓
7 answer cached at every level on the
way back, for the TTL
Steps 4–6 happen rarely. Almost every lookup is answered from a cache at step 1, 2 or 3 — which is what makes DNS fast, and what makes changes slow to propagate.
The records you’ll actually meet
A hostname → IPv4 address
AAAA hostname → IPv6 address
CNAME hostname → ANOTHER hostname
MX where email for this domain goes
TXT arbitrary text — verification,
SPF, DKIM, DMARC
NS which servers are authoritative
CAA which authorities may issue
certificates for this domain
CNAME’s restriction is the one that bites: a CNAME cannot coexist with other records at the same name, which means the root domain (example.com) cannot be a CNAME. This is why pointing an apex domain at a platform like Shopify or Vercel needs an A record, or a provider-specific extension — ALIAS, ANAME or CNAME flattening — that resolves it server-side.
TTL, and why changes are slow
Time to live is how long a resolver may cache an answer.
TTL 3600 cached for an hour
TTL 300 cached for five minutes
TTL 86400 cached for a day
Change a record and every cache holding the old answer keeps serving it until its TTL expires. Some resolvers ignore short TTLs and impose their own minimum, so the real window is “at least the TTL, possibly longer”.
The standard migration procedure:
1 drop the TTL to 300, days ahead
2 wait for the OLD TTL to fully expire
3 make the change
4 both old and new must work during
the overlap
5 once traffic has moved, raise the TTL
Step 4 is the one that gets skipped, and it’s why a migration cuts off a fraction of users — Site Migrations and SEO.
Performance
Resolution is the first thing on the critical path and costs a round trip when uncached — How the Web Works.
dns-prefetch resolve early, cheap hint
preconnect resolve + connect + TLS
Use preconnect for domains you know you’ll need — a payment iframe, a font host, an analytics endpoint. Each distinct hostname on a page is its own resolution, which is a real argument for fewer third parties rather than faster ones — Third-Party Scripts.
Where it goes wrong
- The TTL trap above. Changing a record with a 24-hour TTL and expecting it to take effect today
- Propagation is a misnomer. Nothing is pushed; caches simply expire. “Waiting for propagation” is waiting for TTLs
- Dangling records. A subdomain still pointing at a decommissioned service is a subdomain takeover risk if someone else can claim that service’s name — a real and commonly-exploited hole — Common Vulnerabilities
- Email records are DNS. SPF, DKIM and DMARC are TXT records, so an email deliverability problem is often a DNS problem
- Registrar versus DNS host. Where a domain is bought and where its records are served are separate, and confusing them wastes hours
Checking it
dig shop.example.com
dig +trace shop.example.com full path
dig @1.1.1.1 example.com specific
resolver
dig example.com TXT a record type
Query a specific resolver when debugging. Your machine’s cached answer and a public resolver’s can differ, and the difference is usually the answer.