Check the propagation of DNS and IP changes for domains

When you change a record, the new value must first appear on all the zone's authoritative DNS servers. Resolvers that had already looked up the old value may keep it in cache until the TTL it had before the change expires.

A change of DNS servers also involves the delegation published by the parent zone and the caches of the NS records. If the domain uses DNSSEC, you also need to check that the DS record published by the parent zone matches the new configuration.

That is why there is no fixed time frame for every change. The result depends on the type of change, the previous TTLs, when each resolver last looked it up and possible negative caching of responses such as NXDOMAIN.

Check the change in this order:

1. If you changed the DNS servers, check the NS delegation and, where applicable, DS.
2. Query the exact record on each authoritative server and confirm that they all return the expected value.
3. Check the A and AAAA records separately; an old IPv6 record can send some connections to the old destination.
4. Only then compare public resolvers and the resolver of the affected connection.

For the first step you can use IPeek's DNS check, a free external tool. It compares the NS servers published by the parent zone with those announced by the domain's servers, shows whether there is a DS record and checks that each authoritative server responds with the same SOA serial number. It doesn't show the value of other records on each server, and it keeps the result for 10 minutes.

If the new value doesn't appear on the authoritative servers, waiting for a cache to expire won't fix the configuration. See the advanced record diagnosis before going any further.

Our DNS propagation tool reads the value on the authoritative servers and compares it with what twenty public resolvers from different operators return, along with the time left on each one's copy. It doesn't check every Internet connection, nor does it necessarily reflect the result each user will get.

Enter the exact domain or subdomain and select the record type. Check the value returned by each server, not just the icon:

• A result with the expected value only confirms that resolver's response at that moment.
• An old value may come from its cache.
• An empty or different response may be due to NXDOMAIN, no record of that type, a timeout, SERVFAIL or a DNSSEC failure.
• A green tick on every server tested doesn't guarantee 100% propagation for every user.

Note down the name queried, the record type, the expected value, the response obtained and the date and time. If the change is part of a migration, keep the old provider until you have checked DNS, website, HTTPS, email and any pending data from the destination.

If only one browser or connection fails

The browser may use secure DNS with a different resolver from the one configured on the system. Note down both before comparing results. Clearing cookies doesn't update the authoritative DNS or a public resolver's cache.

Lowering the TTL after changing the IP doesn't shorten the time left on an old response that is already cached. In a planned migration, lower the TTL in advance and let the old value expire before the change. Keep both destinations available during the transition to avoid losing transactions.