A DNS change can be present on an authoritative nameserver while a device still receives the old answer. The usual reason is caching: recursive resolvers and devices can reuse an earlier answer for the time allowed by its TTL. Resolvers may also have cached records identifying the previous authoritative nameservers. There is no single worldwide switch that updates every cache at once.

Not every apparent delay comes from an old positive answer. An edit to the wrong authoritative zone, a cached response saying a name does not exist, or an application using a separate DNS service can produce a similar result. Comparing the published record with the answer received through the affected resolver helps distinguish these cases.

First Confirm the Authoritative Change

DNS records are published in an authoritative zone. When an operator edits an A or AAAA address record, an MX mail-routing record, or another DNS value, the change must reach the nameservers actually authoritative for that zone. A control panel showing the new value is useful, but it does not by itself prove that the designated authoritative nameservers now serve it. Check the exact name and record type directly against those servers.

If the servers should all publish the same replacement record but return different versions, check publication and synchronization. Some DNS services distribute updates across multiple authoritative nodes, and secondary servers can obtain changes through zone transfers. A delay in that process occurs before a recursive resolver can fetch the replacement from the affected server. It is separate from the remaining TTL of a copy already stored in a recursive cache.

Also verify that the edit was made in the zone reached through public delegation. A DNS provider can host a valid copy of a zone while the parent zone still directs resolvers to another provider. A subdomain can have its own delegation to a child zone managed elsewhere. An ordinary record added below that delegation in the parent zone does not replace the child's authoritative record.

Then Account for Cached Positive Answers

TTL specifies how long a DNS answer may normally be reused from cache. Suppose a resolver stores an address with a TTL of 3,600 seconds, and the operator changes that address 15 minutes later. That resolver can still have 45 minutes remaining for the old answer, while another resolver with no cached copy may obtain the new address immediately.

Lowering a TTL at the moment of an edit does not shorten the remaining lifetime of copies cached under the earlier TTL. A resolver that fetched the old record before the reduction may keep it for the rest of the original cache lifetime. For a planned change, publish the lower TTL early enough for records cached with the earlier value to expire before replacing the data.

Cache lifetimes begin at different times because resolvers do not all fetch a record at once. Devices and browsers may also hold DNS data or reuse an existing connection without performing another lookup. A public DNS checker shows the answers available through its test locations and resolvers, which may differ from the resolver used by the affected device. Those samples cannot establish a worldwide completion time.

Why New Records Can Still Appear Missing

A resolver may keep returning a cached negative answer after a new record has been published. For example, a query for new.example.com before that name exists can produce an NXDOMAIN response. If the name exists but has no record of the requested type, the response can instead indicate no data for that type. Either response can remain in a resolver's cache after the missing data is added.

An authoritative negative response normally includes an SOA record containing information about the zone. The negative TTL is derived from the smaller of that SOA record's TTL and its MINIMUM field. This is a different control from the positive TTL on a newly added address record. Lowering only the new record's TTL will not erase a negative answer already cached elsewhere.

An NXDOMAIN answer containing a CNAME alias can refer to a missing final target rather than the name originally queried. Save the question name and type, response code, answer section, and SOA data when investigating a missing record. These details distinguish a nonexistent name, an absent record type, and an alias leading to a missing destination.

Delegation Records Have Separate Cache Lifetimes

A parent zone publishes NS records identifying the child's authoritative nameservers. Recursive resolvers can cache that delegation and, where applicable, nameserver address data. One resolver may still use the previous nameserver list while another uses the replacement. If the old and new providers serve different records during that interval, devices using those resolvers can receive different answers even when each provider has published its own intended data correctly.

A delegation change is not the same as replacing an address record inside a zone that keeps the same nameservers. Compare the parent-side NS records with the data served by the old and new authoritative servers. A resolver still using cached delegation can query the previous server even after the parent has changed. The lifetime of that delegation data is independent of the TTL on an address record in the child zone.

Compare Authoritative, Resolver and Application Results

  1. Record the complete domain name, record type, previous value, expected replacement, and the resolver that returned the unexpected answer.
  2. Query the authoritative nameservers for that exact name and type, and check whether they serve the expected data.
  3. If the nameservers changed, inspect the parent delegation and compare the answers from the old and new authorities.
  4. Query the affected recursive resolver and note the response, remaining TTL, and any SOA information accompanying a negative answer.
  5. Compare the application's result with the direct DNS result, accounting for its DNS configuration, cache, and existing connections.

Record the time of each observation so that later checks can be compared with the earlier cache lifetime. If the authoritative answer is still wrong, repair the published data rather than waiting for recursive caches to expire. If the authority serves the intended data but a resolver still has a valid older copy, its remaining cache lifetime helps explain the difference. A fixed claim that every DNS change takes 24 to 48 hours cannot describe all of these cases.