DNS Propagation: What TTL Can and Cannot Tell You

You change a website's IP address and your laptop opens the new site, but a colleague still sees the old one. This is often described as propagation. DNS is not copying one update to every visitor at once: resolvers may still hold earlier answers until their cache lifetime expires.

Understand which timer is running

TTL tells a resolver how long an answer may be cached. Lowering a TTL immediately before a move does not erase copies already stored with the old, longer value. Plan the lower TTL ahead of the change and allow the previous lifetime to pass.

Not every delay is the same record. Nameserver delegation, A and AAAA answers, and a cached answer saying that a name does not exist can have separate caching behavior. A low A-record TTL therefore does not promise instant recovery from every DNS mistake.

Compare answers before waiting blindly

First check the authoritative server: does it return the intended value? Then compare a separate recursive resolver and the affected user's result. If the authoritative answer is wrong, more waiting will not fix the configuration. If only a cached answer differs, repeated edits can make the situation harder to understand.

• Check the exact hostname, including www where relevant.
• Compare both A and AAAA records.
• Confirm the registrar delegates to the expected nameservers.
• Record query time and remaining TTL when collecting evidence.

Separate DNS from website caching

The browser, CDN and application may display old content even when DNS points to the new server. Look at response headers and the actual content served by each destination. A working DNS answer also says nothing about whether the new server recognizes your domain or has a valid certificate.

For an OrienHost web hosting migration, keep a small change log with the previous value, new value and switch time. These details make a useful support request and help you decide whether to wait, correct a record or investigate the application instead.