DNS Propagation: Why Your Domain Still Points Elsewhere

Quick answer
There is no propagation between DNS servers; the authoritative server returns the new record as soon as you save it.
The delay comes from caching: recursive resolvers, operating systems, and browsers keep the old answer until its TTL expires.
Lower the TTL well before a planned change, wait for the old TTL to pass, then change the record.
Check the authoritative server directly to separate a bad record from a stale cache.
Negative answers are cached too, so a hostname that did not exist can remain invisible for a period after you create it.

Does DNS actually propagate?

The word is misleading. When you change a record, the authoritative nameserver for the zone has the new value immediately. Other servers do not receive it by push; they ask again when their cached copy expires. What looks like slow propagation is a set of independent caches each counting down its own TTL.

That is why two people can see different answers at the same time and both be correct. One resolver has a cached answer from before the change, another has queried since. The record is not spreading; the caches are expiring on different schedules.

How long does a change take to be visible?

As long as the previous TTL, plus whatever caching the client adds. If the old record had a one-hour TTL, a resolver that cached it just before the change may serve the old value for up to an hour. Some networks and applications cache longer than the TTL or ignore it entirely.

Plan changes by lowering the TTL to a short value a day or two in advance, waiting at least the old TTL so the short value is what resolvers hold, then making the change. After the change is verified, raise the TTL again. This is the only reliable way to make a cutover quick.

# Ask the authoritative server, bypassing caches.
dig +short example.com A @ns1.example.net

# Follow the delegation chain from the root.
dig +trace example.com A

# See the TTL the resolver is currently serving.
dig example.com A | grep -A1 'ANSWER SECTION'

# Compare public resolvers.
dig @1.1.1.1 example.com A +short
dig @8.8.8.8 example.com A +short

Why is the change invisible even after the TTL?

Check the authoritative answer first. A typo in the record, a missing trailing dot, a record created in the wrong zone, or a proxy status that hides the origin will produce the wrong answer no matter how long you wait. If the authoritative server is correct, the problem is a cache or the client.

Then consider negative caching. If the hostname did not exist before, resolvers may have cached the non-existence for the period in the zone’s SOA record. Creating the record does not clear those caches. Also check local caches: the operating system resolver, the browser, and any VPN or container DNS layer.

What should you do during a cutover?

Verify from multiple vantage points: the authoritative server, a public resolver, and a network you do not control. Keep the old endpoint running until the new one is confirmed, because some clients will keep using the cached old address after you believe the change is complete. For a web cutover, that means both hosts serving the site for a period.

Watch the old host’s traffic decline rather than assuming it stopped at the TTL. If the old host still receives meaningful traffic hours later, something is caching longer than expected, and shutting it down will break those users. DNS changes are safe when the old and new answers both work during the overlap.

Where this bites vibecoders
A generated deployment guide says to wait 24 to 48 hours for DNS propagation, which turns a five-minute change into a day of waiting and hides real errors. The correct approach is to inspect the authoritative record and the TTL, and to plan the cutover so both endpoints work during the overlap.

Where AI coding assistants get this wrong

Waiting 48 hours instead of checking the authoritative record and TTL.
Changing the record before lowering the old TTL.
Forgetting the trailing dot in a fully qualified name.
Creating a record in the wrong zone or at the wrong provider.
Shutting down the old host at the first sign of the new answer.
Ignoring negative caching after a hostname did not exist.

Checklist

Lower the TTL at least one old-TTL period before the change.
Verify the record on the authoritative nameserver.
Check the TTL of the answer you receive.
Compare at least two public resolvers.
Keep both endpoints live during the overlap.
Watch old-host traffic before decommissioning it.

FAQ

How long does DNS propagation take?

There is no fixed period. It takes as long as the longest cache holding the old answer, which is normally the old TTL but can be longer if a resolver or client ignores it. Lowering the TTL in advance is what makes the actual change fast.

Why do I still see the old site after changing DNS?

Either the authoritative record is still wrong, or a resolver is serving a cached answer. Check the record directly against the nameserver, then check the TTL. If the authoritative answer is correct and the TTL has passed, clear your local resolver and browser caches before concluding the change failed.

Does a lower TTL make my site faster?

No. TTL controls how long resolvers cache the answer, not how fast the site responds. A very low TTL increases DNS query volume and can slightly increase lookup latency, because clients must resolve more often. Use a low TTL around changes and raise it afterwards.

What is negative caching?

When a name does not exist, resolvers cache that negative answer for a period defined by the zone’s SOA record. Creating the record later does not immediately clear those caches, so a new hostname can remain unreachable for a while even though the record is correct.