DNS Resolution, Step by Step

Introduction¶

DNS feels like magic until the first time a record change "doesn't take" or a site resolves for you but not for a colleague. Both are ordinary once you know how resolution actually works and can trace it.

Concepts¶

There are two kinds of DNS server:

• Recursive resolver — the one your machine talks to (1.1.1.1, 8.8.8.8, your ISP's, your router). It does the legwork and caches the answer.
• Authoritative server — holds the real records for a zone. example.com's authoritative servers are the only source of truth for example.com.

A cold lookup for www.example.com A:

1. Resolver asks a root server (.). Root replies: "I don't know, but ask the .com servers — here they are."
2. Resolver asks a .com TLD server. It replies: "ask example.com's nameservers — ns1.example.com at this glue IP."
3. Resolver asks ns1.example.com. It replies with the actual A record.
4. Resolver caches every answer for its TTL and returns the A record to you.

Steps 1–2 are almost always already cached (the root and .com referrals change rarely), so a "cold" lookup in practice is usually just step 3.

Hands-on¶

Trace the full recursion¶

dig +trace www.example.com A

This makes dig do the resolver's job itself, printing each referral. You see . → .com → authoritative → answer. If it stops at the .com level, the domain's delegation (NS records at the registrar) is broken.

Query a specific server¶

# Ask the authoritative server directly — bypasses all caching
dig @ns1.example.com www.example.com A +norecurse

# Ask a public resolver
dig @1.1.1.1 www.example.com A

# What's the TTL and is it counting down (i.e. a cached answer)?
dig www.example.com A | grep -A1 "ANSWER SECTION"

See the delegation¶

dig example.com NS +short          # authoritative nameservers
dig com NS +short                  # the .com TLD servers

Reverse the flow (PTR)¶

dig -x 93.184.216.34 +short

Verification and troubleshooting¶

• "It works for me but not for them" — TTL. You (or your resolver) cached the old record; theirs cached the new one, or vice versa. Wait out the TTL, or check both against the authoritative server directly with dig @nsX. Lower the TTL before a planned change, not after.
• NXDOMAIN — the name genuinely doesn't exist at the authoritative server, or the delegation is broken so the resolver can't find the authoritative server. dig +trace shows which.
• SERVFAIL — the resolver tried and failed. Common causes: all authoritative servers unreachable, a broken DNSSEC chain (dig +cd disables validation — if that fixes it, it's DNSSEC), or a resolver bug. Check with the DNSSEC checker.
• Right IP from one resolver, wrong from another — a stale cache on one resolver, or a GeoDNS / split-horizon setup returning different answers by location. Compare dig @1.1.1.1 vs dig @8.8.8.8 vs the authoritative.
• Propagation "stuck" — there's no global push; every resolver just caches until its copy's TTL expires. Check spread with the propagation checker.
• CNAME at the apex breaks things — you can't have a CNAME on the bare domain alongside other records (SOA, NS, MX). Use ALIAS/ANAME (provider feature) or an A record.

Related tools and reading¶

• On-site: DNS Lookup, DNS Propagation Checker, DNSSEC Checker, WHOIS, RDNS.
• Related posts: What happens when you type a URL, DHCP DORA explained.