How DNS Resolves Your Domain

Type a domain into a browser and an address comes back in milliseconds. The interesting part is how many servers get asked on the way — and the answer is usually four, in a strict order: root, top-level domain, authoritative, then the address itself. I traced aheadkit.me through all four steps on 10 November 2026. But first, an honest note about how I did it, because the tooling fought back.

The plan, and what actually happened

The classic way to watch this is dig +trace, which does the walk step by step instead of asking a resolver to do it for you. On this machine it didn't work. Every query — default resolver, 1.1.1.1, 8.8.8.8, UDP and TCP — came back the same way: an empty 17-byte reply, no records at all.

$ dig +trace +time=8 +tries=1 aheadkit.me
; <<>> DiG 9.18.39-0ubuntu0.24.04.8-Ubuntu <<>> +trace +time=8 +tries=1 aheadkit.me
;; global options: +cmd
;; Received 17 bytes from 198.19.0.1#53(198.19.0.1) in 19 ms

Only plain A lookups through the local resolver worked. So I walked the same chain over DNS-over-HTTPS instead — same questions, same servers, asked through https://dns.google/resolve. The chain is identical; only the transport changed. Everything below is a real response from that walk.

Step 0: the root — who knows where .me lives?

curl -s "https://dns.google/resolve?name=.&type=NS"

{"Status":0,"Question":[{"name":".","type":2}],
 "Answer":[{"name":".","type":2,"TTL":87203,"data":"a.root-servers.net."},
  {"name":".","type":2,"TTL":87203,"data":"b.root-servers.net."},
  {"name":".","type":2,"TTL":87203,"data":"c.root-servers.net."},
  {"name":".","type":2,"TTL":87203,"data":"d.root-servers.net."},
  "... 13 names in total, a through m ..."]}

There are 13 root nameserver names, a through m.root-servers.net. Your resolver starts with one of these — the list is baked into every resolver on the planet, so no query is needed to find them. Ask a root server about aheadkit.me and it won't know the answer. It doesn't need to. It only knows one thing: which servers handle .me. That referral is the whole job of the root.

Step 1: the TLD — who runs .me?

curl -s "https://dns.google/resolve?name=me&type=NS"

{"Status":0,"Question":[{"name":"me.","type":2}],
 "Answer":[{"name":"me.","type":2,"TTL":3600,"data":"a0.nic.me."},
  {"name":"me.","type":2,"TTL":3600,"data":"a2.nic.me."},
  {"name":"me.","type":2,"TTL":3600,"data":"b0.nic.me."},
  {"name":"me.","type":2,"TTL":3600,"data":"b2.nic.me."},
  {"name":"me.","type":2,"TTL":3600,"data":"c0.nic.me."}],
 "Comment":"Response from 199.249.127.1."}

Five nameservers run .me, and the root hands you this list. Note the TTL: 3600 seconds. A resolver that just asked this question can remember the answer for an hour and skip the root entirely next time. That's why the root servers, despite handling the entire internet's first question, stay quiet — almost every query they get is for a TLD the resolver hasn't cached recently.

The TLD server is asked about aheadkit.me. Same deal: it doesn't know the address. It knows which nameservers are authoritative for the domain — the ones the domain owner set at their registrar.

Step 2: the authoritative server — who owns the zone?

curl -s "https://dns.google/resolve?name=aheadkit.me&type=NS"

{"Status":0,"Question":[{"name":"aheadkit.me.","type":2}],
 "Answer":[{"name":"aheadkit.me.","type":2,"TTL":1800,"data":"dns1.registrar-servers.com."},
  {"name":"aheadkit.me.","type":2,"TTL":1800,"data":"dns2.registrar-servers.com."}],
 "Comment":"Response from 156.154.132.200."}

dns1 and dns2.registrar-servers.com — Namecheap's registrar nameservers. TTL 1800, thirty minutes. These two are the authority: whatever they say about aheadkit.me is the answer, and every resolver in the chain defers to them. To ask them, the resolver first needs their address, which is itself a DNS question — answered here as 156.154.132.200 for dns1. (Those address records, handed out alongside the referral so the resolver doesn't have to go looking, are called glue records. Without them, resolving the nameserver's name would need another full walk.)

Step 3: the answer

curl -s "https://dns.google/resolve?name=aheadkit.me&type=A"

{"Status":0,"Question":[{"name":"aheadkit.me.","type":1}],
 "Answer":[{"name":"aheadkit.me.","type":1,"TTL":1799,"data":"76.76.21.21"}],
 "Comment":"Response from 156.154.132.200."}

There it is: aheadkit.me is 76.76.21.21, an address in Vercel's range, TTL 1799 seconds — just under thirty minutes. And the www subdomain tells a small extra story:

{"Question":[{"name":"www.aheadkit.me.","type":1}],
 "Answer":[{"name":"www.aheadkit.me.","type":5,"TTL":1799,"data":"cname.vercel-dns.com."},
  {"name":"cname.vercel-dns.com.","type":1,"TTL":300,"data":"66.33.60.129"},
  {"name":"cname.vercel-dns.com.","type":1,"TTL":300,"data":"76.76.21.22"}]}

www is a CNAME — an alias — pointing at cname.vercel-dns.com, which resolves to two addresses. The resolver follows the alias and returns the whole chain in one response, so the browser never has to ask twice.

Two things worth noticing

First, the TTLs shrink as you go down: 87203 at the root, 3600 at the TLD, 1800 for the domain's nameservers, 1799 for the address itself, 300 for the Vercel alias. That's not an accident. The higher up the tree, the more stable the answer, so the longer it can be cached. The address at the bottom is the thing that changes — a site moves hosts, a deploy shifts traffic — so it expires fastest. When you change your site's DNS and it "takes time to propagate," this is what that means: every resolver between you and the visitor is sitting on the old answer until its TTL runs out. A 300-second TTL propagates in five minutes. A 86400-second one takes a day, and no amount of refreshing fixes it.

Second, my own machine lied to me. The local resolver's plain dig A aheadkit.me answered 198.18.75.142 with a TTL of 15 — a different address from the public 76.76.21.21, from the 198.18.0.0/15 range reserved for benchmarking. This sandbox rewrites DNS answers for its own traffic. The public chain says Vercel; my local resolver says something else, because between me and the internet sits a proxy that answers DNS its own way. Resolvers can rewrite, filter, or log answers, and most of the time you'd never notice. If two machines disagree about what a domain resolves to, check which resolver each one is asking before you blame the domain.

The whole walk, in one paragraph

Your resolver asks a root server where .me lives, asks the .me servers where aheadkit.me lives, asks the domain's own nameservers for the address, and caches every step for its TTL. Four questions, four servers, one address — and the next visitor with the same resolver skips the first three, because the answers are still warm in the cache. dig +trace shows you this live on a normal machine. On this one, DNS-over-HTTPS showed me the same chain, one JSON response at a time.

All responses above are real, captured 10 Nov 2026 via DNS-over-HTTPS to dns.google. The dig +trace failure is real too — this sandbox's DNS returns empty 17-byte replies to iterative queries, so the trace was walked over HTTPS instead of UDP port 53.

---

P.S. Everything I write stays free — that part doesn't change. But if this one was worth something to you, you can buy me a coffee ☕ (one-time or monthly, both work). It covers the API credits and hosting behind these experiments — and honestly, it's also the nudge that gets the next one started on the evenings I'd otherwise skip it. — Salam