How DNS resolves a name, end to end
Four servers, one answer, and a cache in front of all of them. What really happens when a name resolves — and why the change you just saved may not be visible yet.
How DNS resolves a name, end to end
DNS is a distributed database with a cache bolted onto every layer of it. Hold those two facts at once and most "DNS is broken" tickets stop being mysterious. This page walks one lookup from a browser to the server that actually holds the answer, then covers the part that catches everybody out: caching, which is what people mean when they say propagation.
The four servers involved
- Recursive resolver — asks on your behalf and remembers the answer. Usually
your ISP's, or a public one you chose.
- Root servers — do not know your name. They know who runs your TLD.
- TLD servers — know your extension. They do not hold your records either;
they point at whoever does.
- Authoritative nameserver — the only server in the chain that actually has
your zone. Here, that is our anycast DNS.
Only the last one is yours. Everything above it is a referral, and a referral is exactly as stale as the cache that returned it.
One lookup, in order
- The resolver checks its own cache. A hit ends the story there.
- On a miss it asks a root server, which replies with the TLD's servers.
- It asks the TLD, which replies with your zone's nameservers.
- It asks one of those, which returns the real answer.
- The answer is cached for its TTL and handed back to the client.
That whole path is one round of questions for a cold cache, and nothing at all for a warm one. dig will show you the answer it got, and the TTL attached to it:
$ dig www.example.com A +noall +answer
www.example.com. 300 IN A 93.184.216.34The 300 is the TTL in seconds: how long a resolver is entitled to keep that answer. It is the number that governs the next section.
The records you will actually set
| Record | What it answers | Where it goes wrong |
|---|---|---|
| A | Which IPv4 address is this name? | Two A records are load balancing, not a bug — but a stale one keeps sending visitors to a host you retired. |
| AAAA | The same, for IPv6 | Added without checking the host actually listens on IPv6. |
| CNAME | This name is another name | Cannot sit alongside any other record at the same name, and it is not valid at the zone apex. Providers that "flatten" it are doing something non-standard on your behalf. |
| MX | Where does mail for this domain go? | No MX at all is not an error: mail falls back to the address in the A record, quietly, and you never notice until something bounces. |
| TXT | Arbitrary text | Where SPF, DKIM and DMARC live, plus every verification token you will ever paste. Long values have to be split into strings. |
| NS | Who is authoritative for this zone? | Changed at the registry but not inside the zone, or the other way round. A parent and a zone that disagree is the classic half-working domain. |
| SOA | Zone bookkeeping | Its negative-caching field decides how long "that name does not exist" is remembered — usually longer than people expect. |
| CAA | Which certificate authorities may issue for this name? | Absent means any authority may issue. Present and wrong means your certificate renewal fails. |
Mail records are the ones worth reading twice, because Email Hosting publishes SPF, MX and DMARC for you and a hand-edited duplicate of any of them will conflict with the one the platform maintains.
Why your change has not shown up yet
Nothing propagates. That word describes a push, and DNS is a pull: every resolver fetches when it needs to and remembers for the TTL it was given. So a change appears at different times in different places, and the delays stack:
- the resolver's cache, populated before you pressed save;
- your operating system and your browser, which both cache too;
- negative caching, if the name did not exist when somebody asked;
- resolvers that clamp very short or very long TTLs to limits of their own.
The practical rule follows directly: lower the TTL before a planned move, wait out the old TTL, cut over, then raise it again. Doing it in that order is the difference between a migration and an outage.
And be pessimistic about the calendar. Allow up to 24–48 hours before concluding that something is broken. We do not promise updates that appear everywhere at once, because the caches that decide are not ours.
What anycast DNS does and does not change
Anycast means the same nameserver addresses are announced from many locations, so a query is answered by a nearby node and there is no single machine whose failure takes your name offline. It improves whether an answer is reachable at all.
It does not shorten a TTL, does not reach into somebody else's cache and correct it, and does not make a record you just edited appear faster in a resolver that already stored the old one.
Debugging it, in the order that works
- Ask the authority directly. Query our nameserver for the name. If the
answer is wrong there, the zone is wrong — stop.
- Ask a cold resolver. If the authority is right and a public resolver is
stale, you are looking at a cache, not a fault.
- Check the delegation. The NS records at the registry and the NS records
inside the zone must agree. This is the failure behind "I changed nameservers and nothing happened".
- Check the TTL that was in place before your change, not the one that is
there now.
- Only then suspect the platform.
Where this meets the rest of the platform
Domain Registration creates the zone. Static Hosting and App Hosting publish the records their custom domains need. Email Hosting publishes mail authentication. See also: static hosting — a deploy changes content, not records, so publishing is never a DNS event.
One honest boundary: we can only answer for names delegated to us. If your nameservers point somewhere else, the dashboard will show you a perfectly correct zone that nobody on the internet is asking.