DNS is the system that turns example.com into an IP address that a browser can connect to. It is the first thing that happens on every visit to every website, and when it is wrong nothing else matters. Here is exactly what happens, in the order it happens, and what that means when you change hosts.
The one-sentence version
Your computer asks a resolver for the address; the resolver asks the root servers, then the TLD servers, then your domain's authoritative servers; it remembers the answer for a while (the TTL) and hands it back.
Step by step
- Browser cache. The browser checks whether it looked this name up recently.
- Operating system. Then the OS checks its own cache and the hosts file.
- Resolver. Neither knows, so the OS asks the resolver it is configured to use — your ISP's, or a public one like
1.1.1.1or8.8.8.8. Resolvers also cache aggressively. - Root servers. The resolver has no answer either, so it starts at the top: one of the 13 root server clusters. The root does not know
example.com, but it knows who handles.com. - TLD servers. The
.comservers do not know the IP, but they know which nameservers are authoritative forexample.com— that is what your registrar sends them when you set nameservers. - Authoritative nameservers. Finally, the servers that actually hold your zone answer:
example.com A 203.0.113.10, "and you may cache this for 3600 seconds". - Back down the chain. The resolver caches the answer and returns it; the OS caches it; the browser connects to
203.0.113.10.
The whole round trip usually takes 20–100 ms the first time and 0 ms afterwards, because of the caching at every level.
Watch it happen
dig +trace performs the lookup the way a resolver does and prints each step:
dig +trace example.com AYou will see the root servers answer with the .com servers, .com answer with the authoritative nameservers, and the authoritative servers answer with the IP. To ask one specific resolver and see what it currently has cached:
dig example.com A @1.1.1.1
dig example.com A @8.8.8.8If those two disagree just after a change, that is caching, not a fault.
TTL and "propagation"
The TTL (time to live) is how long a resolver may keep an answer. With a TTL of 86400, a resolver that looked up your domain an hour before you changed the IP will keep sending visitors to the old server for another 23 hours. Nothing is being "propagated" anywhere — resolvers are simply waiting for their cached copy to expire.
That is why every migration guide says to lower the TTL to 300 the day before you switch: after that, no resolver holds the old answer for more than five minutes. See our zero-downtime migration guide.
Two caveats: some ISP resolvers ignore low TTLs and cache for hours regardless, and the nameserver change at the registrar (the NS delegation at the TLD) has its own TTL, typically 48 hours. Change records at your existing DNS provider when you can; change nameservers only when you must.
Where your records live
Your domain's zone — the list of A, MX, TXT records — lives on whichever nameservers your registrar points at. That could be:
- the registrar's own nameservers,
- your hosting provider's (Plesk serves DNS for every domain you add),
- a dedicated DNS service such as Cloudflare.
It does not matter where the site is hosted; the zone can be anywhere. What matters is that the nameservers set at the registrar are the ones you are editing. A record edited on the wrong provider changes nothing, which is the single most common DNS support ticket.
Find out which nameservers are live for a domain:
dig example.com NS +shortThe records you will meet
| Record | Points to | Used for |
|---|---|---|
| A | an IPv4 address | the website |
| AAAA | an IPv6 address | the website, over IPv6 |
| CNAME | another name | www → the bare domain |
| MX | a mail server name | where email is delivered |
| TXT | text | SPF, DKIM, DMARC, site verification |
| NS | nameserver names | delegation |
We go through each in DNS record types explained.
When DNS "doesn't work"
Almost always one of four things: the record was edited at a provider that is not authoritative; the TTL has not expired yet; a typo (exmaple.com, a trailing dot missing on a CNAME target); or the domain has expired and the registrar replaced the nameservers with a parking page. dig +trace shows which of the four within a minute.
Every VPSPioneer plan includes DNS hosting in Plesk with records pre-filled for the site and mail, and our free migration includes the DNS switch — we lower the TTL, move the records and watch them go live.