How to Check DNS Propagation and Fix Stale Records

A DNS change can look correct in one location and wrong in another. That does not always mean the update is still propagating. The real cause may be resolver caching, an incorrect authoritative nameserver, a long TTL, DNSSEC trouble, or a record changed in the wrong DNS zone.

This guide shows a repeatable way to find the failing layer instead of waiting blindly.

Start with the authoritative answer

Authoritative nameservers are the source of truth for a domain. First identify the nameservers delegated by the parent zone, then ask one of those servers directly for the record you changed.

1. Look up the domain's NS records.
2. Choose one authoritative nameserver.
3. Query it for the A, AAAA, CNAME, MX, or TXT record you changed.
4. Compare the returned value and TTL with your intended configuration.

If the authoritative answer is wrong, waiting will not help. Correct the record at the active DNS provider or fix the parent-zone nameserver delegation.

Compare recursive resolvers

Public recursive resolvers cache DNS answers for the record's TTL. Compare responses from more than one resolver. Duck Cloud's [DNS Lookup](/tools/dns-lookup) provides a quick browser-based check without installing command-line tools.

If authoritative servers show the new value but one recursive resolver shows the old value, note the old answer's remaining TTL. The cache should refresh when that timer reaches zero.

Check the full CNAME chain

A hostname may point to a CNAME that points to another hostname. Every link has its own TTL and can fail independently. Follow the chain to the final A or AAAA record.

Common problems include:

• a CNAME target with no address record;
• a CNAME at the zone apex where the provider does not support flattening;
• old records left at a previous DNS provider;
• proxy services returning their own anycast addresses;
• IPv6 clients reaching an outdated AAAA record while IPv4 works.

Verify delegation and DNSSEC

If different authoritative servers return different answers, the zone may not be synchronized. If the parent zone delegates to nameservers you no longer control, update the registrar configuration.

DNSSEC adds another failure mode. A stale DS record at the registrar can make validating resolvers reject an otherwise correct zone. Look for SERVFAIL responses and compare results with DNSSEC validation enabled and disabled. Coordinate DS and signing changes so the chain of trust remains valid.

Use TTLs deliberately

Before a planned migration, lower the TTL at least one old-TTL period in advance. If the current TTL is 86,400 seconds, lower it a full day before switching the address. After the change is stable, raise the TTL again to reduce query load.

Very low TTLs do not guarantee immediate updates. Some networks impose minimum cache times, and browser or operating-system caches may persist separately.

A practical checklist

• Confirm the domain's delegated nameservers.
• Query each authoritative nameserver directly.
• Verify A and AAAA records independently.
• Follow every CNAME target.
• Compare at least two recursive resolvers.
• Inspect TTL values and wait only when a valid old cache explains the result.
• Check DNSSEC when responses return SERVFAIL.
• Confirm the application and TLS certificate at the new destination.

DNS troubleshooting becomes faster when you separate authoritative configuration from recursive caching. Start with the source of truth, follow the chain, and use TTLs as evidence rather than treating propagation as a mystery.