← All guides

DNS

Why DNS answers differ after a change

Use record types, TTLs, and resolver comparisons to investigate a website or email DNS change.

Ask the question your service depends on

DNS is a collection of records, not a single domain-to-IP mapping. A and AAAA records supply IPv4 and IPv6 addresses. MX records direct incoming email. TXT records often contain verification or mail-policy data. NS identifies authoritative nameservers, and CAA controls which certificate authorities may issue certificates.

An empty answer for one type does not mean the domain is missing. For example, a domain may have A records but no AAAA record. NXDOMAIN means the queried name does not exist; SERVFAIL means the resolver could not complete the query and can indicate upstream or DNSSEC problems.

Worked example: a website move at 14:00

Imagine the old A record had a TTL of 3600 seconds. A resolver cached it at 13:50, and you changed the authoritative record at 14:00. That resolver can normally continue returning the old answer until around 14:50. A second resolver with an empty cache may see the new address immediately.

Lowering the TTL at 14:00 does not shorten the lifetime of answers already cached with the old TTL. Plan a lower TTL ahead of a migration. Keep the old service available through the previous cache window when possible. Negative answers can be cached too, so adding a previously nonexistent hostname may not appear instantly.

Compare answers with a purpose

The DNS tool compares selected public recursive resolvers from our server. It is useful evidence, but it is not a map of every resolver worldwide. Use a single record type to compare resolvers, or the ten-type overview to inspect one resolver’s records together.

Save a snapshot before changing a record, then query the same name, type, resolver, and mode again. The difference view shows common, added, and removed records. TTL-only changes are reported separately from record changes. Snapshots stay in page memory; export JSON or CSV if you need to keep the evidence after leaving. A shared configuration link prefills a query without including the answers or running it automatically.

  • Query the exact name and record type your application uses, including subdomains such as www.
  • Compare the actual record values. Answer order and remaining TTL differences are not, by themselves, conflicting DNS data.
  • Check your DNS provider’s authoritative configuration. A correct public answer cannot repair a typo at the source.
  • Compare your device’s normal resolver with a public resolver. Corporate or VPN DNS can intentionally provide different internal answers.
  • If public answers are correct but the browser still reaches the old service, investigate browser caches, a service worker, a hosts-file entry, or an application proxy.
# Query two public resolvers from your own machine
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

# Query the resolver configured on your device
nslookup example.com

Know when different answers are expected

CDNs and location-aware DNS can intentionally return different valid address sets. A proxied Cloudflare hostname normally returns Cloudflare addresses, not the origin server’s address. Neither case automatically indicates a broken deployment.

The resolver’s DNSSEC authenticated-data flag is one signal about that response. An absent flag alone is not a finding that a domain is insecure or misconfigured. The lookup does not audit an entire DNSSEC chain or send a test email.

Further reading & sources

← Browse all guidesCheck your connection →