Introduction

People blame propagation for a lot of DNS problems that are not actually propagation. Real propagation delay does happen, but if the authoritative answer is wrong, missing, or split across providers, waiting will not help. The first job is proving whether the delay is real or whether the live DNS is simply broken.

Symptoms

  • Some users see the new site while others still reach the old one
  • DNS tools return different answers depending on the resolver
  • A record change appears correct in the dashboard but not everywhere else
  • The issue began after updating an A, AAAA, CNAME, or nameserver record
  • Support teams keep hearing to wait longer without clear evidence

Common Causes

  • TTL values were high before the change, so cached answers persist longer than expected
  • The authoritative zone still contains old or conflicting records
  • Nameserver delegation changed but the new zone is incomplete
  • Local resolvers or enterprise DNS appliances hold stale cache entries
  • CDN, load balancer, or app configuration changed out of sync with DNS updates

Step-by-Step Fix

  1. Query the authoritative nameservers directly to see the source-of-truth answer for the record you changed.
  2. Compare that answer with public resolvers and local resolvers to determine whether you are dealing with cache lag or a wrong authoritative value.
  3. Check the TTL on the old and new records so you know how long stale cache could realistically persist.
  4. Verify there are no duplicate records, split DNS providers, or wrong nameserver delegations still serving older answers.
  5. Flush local and organizational resolver caches where you control them, but do not mistake that for fixing authoritative DNS.
  6. Confirm the application, CDN, or origin behind the new IP is actually ready so DNS is not being blamed for an upstream outage.
  7. If the authoritative record is wrong, correct it immediately instead of waiting for nonexistent propagation to finish.
  8. Re-test over time from several public resolvers and geographic locations until the expected answer is stable.
  9. Before future changes, lower TTLs in advance and keep a record of the intended cutover values.