DNS: finding the server

DNS is the first step of every request and the cause of many 'site is down' and slow-first-load problems.

Before connecting, the client must turn a hostname into an IP address. That's the Domain Name System.

A lookup for www.example.com:

The OS checks its cache, then asks a recursive resolver, usually run by your ISP or a public service such as 1.1.1.1 or 8.8.8.8.
On a cache miss, the resolver asks a root server, which points to the .com TLD servers, which point to example.com's authoritative name servers, which return the answer.
Every answer carries a TTL (time to live, in seconds), how long resolvers and clients may cache it.

Common record types:

A and AAAA: IPv4 and IPv6 addresses.
CNAME: an alias to another name, e.g. www to myapp.cdn-provider.net. Not allowed on the bare apex domain (example.com); providers offer ALIAS/ANAME flattening instead.
MX for mail, TXT for verification and email security (SPF, DKIM), NS for delegation.
HTTPS/SVCB: newer records that advertise HTTP/3 support and other connection hints.

TTLs explain "propagation delays": after a change, old answers live on until cached copies expire. Lower the TTL a day before planned migrations.

Plain DNS is unencrypted UDP on port 53; DNS over HTTPS (DoH) and DNS over TLS hide lookups from the network. Browsers also prefetch DNS, and <link rel="dns-prefetch"> or preconnect lets a page ask for it early.

Example

# sample output; real addresses vary
$ dig +short www.github.com
github.com.
140.82.121.3

$ dig shop.example.com A +noall +answer
shop.example.com.    300    IN    A    203.0.113.10
#                    ^ TTL in seconds

$ dig gmail.com MX +short
5 gmail-smtp-in.l.google.com.

$ dig +trace www.wikipedia.org      # follow root -> .org -> wikipedia's servers

# Which resolver answered and how long it took
$ dig @1.1.1.1 example.com | grep -E "SERVER|Query time"

Remember

DNS turns names into IPs via resolver, root, TLD and authoritative servers
A/AAAA = addresses, CNAME = alias, MX = mail, TXT = text
TTL controls caching and therefore how fast changes spread
Lower TTLs before planned changes

Watch out for

Changing DNS for a migration with a 24-hour TTL and expecting traffic to move immediately.

Check yourself

You change an A record whose TTL was 86400. Some users still reach the old server hours later. Why?

Official docs: developer.mozilla.org/en-US/docs/Glossary/DNS

Example

Remember

Watch out for

Check yourself

Builds on

Unlocks