You change a DNS record, reload the site, and nothing happens. A colleague in another office sees the new version. Your phone on mobile data sees it too, but your laptop does not. The usual explanation is that the change is “propagating”, as if it were spreading outward from server to server.
It isn't. Nothing is pushed anywhere. The change is live at the source almost at once. What you are waiting for is old copies to expire, and how long that takes is a number you set yourself, usually without thinking about it.
Two kinds of DNS server
Authoritative nameservers hold the real records for a domain. These are the servers run by your DNS provider, the ones named in the domain's NS records. When you edit a record in a control panel, this is where the edit lands.
Recursive resolvers are what your devices actually talk to. Your internet provider runs one, and so do the large public DNS services. A resolver holds no records of its own. When asked for a name, it finds the authoritative servers, asks them, hands you the answer, and keeps a copy so it doesn't have to ask again for a while.
That copy is the whole story. Every resolver in the world that has recently looked up your name is holding its own copy with its own countdown. Each one will come back for a fresh answer when its countdown ends, and not before.
TTL is the countdown
Every record carries a TTL (time to live), in seconds. It is the second column here:
www.example.com. 3600 IN A 192.0.2.10
This tells resolvers they may reuse the answer for up to an hour. If you change the address to 192.0.2.20, a resolver that fetched the old record one minute ago will keep serving it for another 59 minutes. A resolver that had never looked the name up gets the new address immediately. That is why two people can see different things at the same moment, and why the wait is at most one TTL per resolver, not a mysterious 24 to 48 hours.
The trade-off is simple. A long TTL means fewer lookups and a little more resilience if your DNS provider has an outage. A short TTL means changes take effect quickly. Neither is right all the time, which is why the plan below changes it on purpose.
Other places an old answer hides
- Your own machine. Operating systems and browsers keep their own short-lived DNS caches on top of the resolver's. A browser with an open connection to the old server will also keep using it. Closing the browser, or testing in a different one, removes that variable.
- Resolvers that bend the rules. Some resolvers enforce their own minimum or maximum on how long they keep an answer. You cannot control this. It is the reason to leave a margin beyond the TTL before you switch anything off.
- Large resolvers are many machines. A big public resolver is a fleet of servers with separate caches. Ask it twice during a change and you can get the old answer, then the new one, then the old one again.
Negative caching: the trap with new records
Resolvers also cache the fact that a name does not exist. If you look up shop.example.com before you have created it, the resolver remembers “no such name” for a period taken from the zone's SOA record. Create the record a minute later and that resolver still says it isn't there.
The practical rule: create the record first, then test it. If you have already been caught, check through a different resolver or wait out the negative TTL. The DNS record types guide shows where that value sits in the SOA record.
Why nameserver changes are slower
Moving a domain to a different DNS provider is a different kind of change. The list of nameservers for your domain is held by the parent zone, which for a .com domain is the .com registry. You change it through your registrar, and the registry publishes it with a TTL that the registry chooses. That TTL is typically much longer than the ones on ordinary records, often a day or more, and you cannot lower it.
So for a day or two, some resolvers will still send their questions to the old provider. The safe way through is to make that not matter:
- Copy every record to the new provider before you touch the nameservers. Check mail records and TXT records in particular, since those are the ones people forget.
- Change the nameservers at the registrar.
- Keep the old provider's zone in place and unchanged for several days. While both providers give the same answers, it makes no difference which one a resolver asks.
If the domain uses DNSSEC, a nameserver move needs extra steps to keep the signatures valid. Read both providers' instructions before you start.
A low-risk plan for changing a record
This is the routine for moving a site or service to a new address with no window where visitors get an error.
- Note the current TTL. Look the record up and find the value configured at your DNS provider. Call it the old TTL.
- Lower it well ahead of time. Set the TTL to something short, such as 300 seconds, and leave the address alone. Then wait at least one full old TTL. Until that time has passed, some resolvers still hold a copy with the long countdown. Lowering the TTL five minutes before the switch achieves nothing.
- Get the new server ready. It should be fully working before any traffic arrives, including its TLS certificate. Test it directly by address or with a hosts-file entry.
- Switch the record. Change the address. Within a few minutes nearly all resolvers will have picked it up.
- Keep the old server running. For the length of the short TTL plus a generous margin, both servers will receive traffic. If the old one is still answering correctly, nobody notices the overlap. For mail, keep the old mailboxes accepting messages for a few days.
- Verify from outside. Check what several resolvers return, not just your own machine.
- Raise the TTL again. Once you are sure you won't need to roll back, put the TTL back to its normal value.
The short TTL also gives you a fast way back. If the new server misbehaves, pointing the record at the old address takes effect just as quickly.
How to check where a change stands
The DNS propagation checker asks three independent public DNS resolvers for the same record, straight from your browser, and shows their answers side by side. You pick the record type: A, AAAA, MX, TXT, NS or CNAME. If all three return the same set of values it says they agree. If they differ, a change is probably still working its way through caches.
Read the result for what it is. Three large resolvers agreeing is good evidence, but it is not proof that every resolver at every internet provider has let go of the old answer. That is what the margin in step five is for.
The checker shows values, not timers. To see a countdown, use the DNS lookup tool. Its TTL column is the time left on one resolver's cached copy, so looking twice a few seconds apart shows it ticking down. When it reaches zero, that resolver fetches the record again and you will see your new value with a fresh TTL.
If a record still looks wrong long after the TTL has passed, stop waiting and look for a real fault. The usual ones are an edit made at a provider that is no longer authoritative for the domain, a second record of the same type that was never removed, or a typo in the name.