DNS Propagation

DNS propagation is the gap between saving a DNS change and everyone on the internet seeing it. Nothing is being pushed around the world during that gap: old answers are simply sitting in caches until they expire, and knowing that lets you plan a change so the gap is minutes rather than a day.

What actually changes when you update DNS

Every domain has authoritative name servers: the servers that hold its records and have the final say on them. When you edit a record in your DNS provider's dashboard, say pointing shop.example.com at a new server's IP address, you are editing the records on those servers. The update there is quick, usually seconds, occasionally a few minutes while the provider copies it to all of its own servers.

So the source of truth is updated almost at once. The delay comes from everyone who asked before you made the change.

Caching is the whole story

Very few lookups ever reach an authoritative server. When your browser needs an address, it asks a resolver: a DNS server run by your ISP, your office network, or a public service such as Google Public DNS or Cloudflare's 1.1.1.1. The resolver does the work of finding the answer, then keeps a copy so the next person who asks gets it instantly.

That copy is the point of DNS caching. It keeps lookups fast and stops the authoritative servers being asked the same question millions of times a minute. The price is that a cached copy doesn't know the record has changed. Until it expires, the resolver keeps handing out the old address with complete confidence.

Resolvers aren't the only layer. Your operating system keeps a small DNS cache, most browsers keep their own, and some home routers do too. Each layer holds its answer for a while, so a change has to wait for every copy between a user and the name server to run out.

TTL: how long an answer lives

Every DNS record carries a TTL, short for 'time to live': a number of seconds that tells anyone caching the answer how long they may keep it. A record with a TTL of 3600 may be cached for an hour. When the hour is up, the next lookup has to go back to the authoritative servers and fetch the record again, which picks up any change.

You set the TTL yourself, per record, in the same dashboard where you set the address. It is a trade-off:

• A long TTL (hours, or a day) means fewer lookups, slightly faster responses for visitors, and resilience if your name servers have a brief outage. It also means a change can take that long to reach everyone.
• A short TTL (a few minutes) means changes spread quickly, at the cost of more lookups reaching your name servers.

For a record that rarely changes, an hour or more is sensible. For one you are about to change, or one you might need to switch quickly in an emergency, a few minutes is better.

The TTL is the upper bound for a well-behaved cache, not a promise. A resolver can drop an answer early, and a small number of resolvers and devices keep answers longer than they were told to. Plan for the TTL, and expect a small tail of stragglers.

Why different people see different answers

Each resolver caches on its own clock. A resolver that happened to look up the name ten minutes before your change still has the old answer for the rest of its TTL. A resolver that had never looked it up, or whose copy just expired, goes to the name server and gets the new answer straight away.

That is why propagation looks so inconsistent. Two people in the same city, on different networks, can load different servers for the same name at the same moment. Your phone on mobile data might see the new site while your laptop on home broadband still sees the old one. Nothing is broken: each resolver is correctly serving what it was allowed to cache.

Here is that split, with two resolvers asking about the same name:

A worked example: moving a site to a new server

Say shop.example.com has an A record pointing at 203.0.113.10, with a TTL of 86400 (one day). You are moving the shop to a new server at 203.0.113.20.

If you simply change the address, some resolvers cached the old answer moments before and will keep it for up to a day. For that whole day, some customers reach the old server. If you have already switched it off, they see an error.

A calmer plan takes a little patience:

1. Two days before, lower the TTL from 86400 to 300 (five minutes). The old one-day TTL still applies to copies already cached, so you need to wait at least that long for them to expire. After that, every cached copy lives for five minutes at most.
2. On the day, change the address to 203.0.113.20. Within about five minutes, almost every resolver has the new answer.
3. Keep the old server running for a while, ideally serving the same site or a page that sends people onward, to catch the stragglers that ignore TTLs.
4. Once the new server has settled, raise the TTL back to an hour or more.

The idea is that the TTL in force at the moment of the change sets how long propagation takes. Lowering it in advance is the one lever you have, and it only works if you pull it early enough.

Checking propagation yourself

dig is the standard command-line tool for asking DNS servers questions. It ships with macOS and most Linux distributions. Ask a specific public resolver what it currently has:

dig shop.example.com A @8.8.8.8

The answer section shows the address and the TTL:

;; ANSWER SECTION:
shop.example.com.  247  IN  A  203.0.113.10

When the answer comes from a cache, that TTL is the time left on the resolver's copy, counting down. Here the resolver will keep serving the old address for about four more minutes. Run it again against another resolver, such as @1.1.1.1, and you may well get a different answer.

To see the truth rather than a cached copy, ask one of your domain's authoritative name servers directly. Find them first, then query one:

dig example.com NS +short
dig shop.example.com A @ns1.your-dns-host.net

If the authoritative server shows the new address, your change is saved correctly and the rest is just caches running out. If it shows the old one, the change never landed, and waiting will not help.

Nameserver changes take longer

Changing a record is one thing. Moving a whole domain to a different DNS provider means changing its name servers, which you do at your domain registrar. Those NS records live one level up, in the zone for .com or .co.uk, and their TTL is set by whoever runs that zone, not by you. They are often long, a day or two, and you cannot lower them in advance.

This is where the familiar advice that DNS changes can take up to 48 hours comes from. For an ordinary record change with a short TTL, it's usually far quicker. To move providers safely, copy every record to the new provider first, so both give the same answers, and only then switch the name servers.

Common mistakes

• Lowering the TTL at the same time as the change. Resolvers already holding the old answer cached it under the old, long TTL, and they keep it that long regardless.
• Switching off the old server as soon as DNS is updated. Visitors still on cached answers land on nothing.
• Testing only from your own machine. Your browser, operating system and resolver each have their own cache, so one result tells you little. Ask the authoritative server, then a couple of public resolvers.
• Looking the name up before the record exists. A 'this name does not exist' answer is cached too, for a time set in your zone's settings, so a brand new subdomain can seem missing after you create it.
• Leaving a very short TTL on for good. It works, but every visitor's lookup goes further, and a name server outage hurts sooner.

Key takeaways

• DNS propagation is caches expiring, not a change being sent around the world.
• The authoritative name servers have your change almost at once; resolvers, operating systems and browsers catch up as their copies run out.
• The TTL decides how long a copy may live, so lower it well before a planned change.
• During propagation, different people seeing different addresses is normal.
• Check the authoritative server with dig first, and keep the old server running until the stragglers have moved on.