DNS propagation: why resolvers disagree and how long changes take

Why DNS resolvers disagree, how TTL decides when a change reaches everyone, and what NXDOMAIN, SERVFAIL, and a dangling CNAME mean.

When you change a DNS record, your DNS provider’s name servers give the new answer straight away. But resolvers, the services that look up names for browsers and mail servers, keep the answer they saved last time until its TTL runs out. Until then, some visitors get the old record and some the new one. That delay is what people call propagation.

SignalDNS asks several public resolvers, and the domain’s own name servers, the same questions, so you can see whether they agree.

What SignalDNS checks

We ask Cloudflare (1.1.1.1) and Google (8.8.8.8) for the name’s A, AAAA, CNAME, MX, TXT, NS, SOA, and CAA records. In the DNS lookup you can add Quad9, OpenDNS, and more record types. Each answer comes from one resolver, with no fallback.

We also ask the zone’s own name servers directly. Their answer is the current one; a resolver’s is a saved copy, and the TTL we show beside it is the time that copy has left.

DNS resolvers disagree

The resolvers returned different records for a type other than addresses, such as MX, TXT, or CNAME. Visitors get different answers depending on their resolver, so this needs attention, though it can be normal briefly after a change.

The usual causes:

How to fix it: check the name servers’ own answers in the report. If they all give the new record, wait for the time shown. If they disagree, make the change at every DNS provider that serves the zone.

Resolvers return different addresses

Different A, AAAA, or HTTPS records from each resolver are normal for a site behind a CDN or load balancer, which answers each resolver with servers near it or rotates through a pool. We mark this OK as long as every resolver returned an address.

It needs attention when one resolver returns no address while another does, since location doesn’t explain that. To check for one fixed address, use an expected value.

A resolver still has older records

A resolver returned records that differ from what the domain’s name servers give now. It saved its copy before the change and keeps it until the TTL runs out. The report says how long its copy can last, such as “saved for up to 1 hour”. That’s normal right after a change.

We don’t compare addresses this way, since they can vary on purpose. Nor SOA, which changes with every edit, or DS and NS, which can come from the registry’s side.

How to fix it: wait for the time shown, then check again. Google Public DNS and Cloudflare’s 1.1.1.1 let you clear a name from their caches, linked below. If a resolver still differs after that, check that every name server gives the new answer.

Resolvers don’t all return the value you expect

In the DNS lookup, you can enter the value you expect, such as a new IP address or a verification code. Addresses are compared as addresses, and types such as TXT match when a record contains the value. The answer is one of these:

  • “Yes.” Every resolver returns it.
  • “Only Cloudflare does.” Some resolvers have it, and the others still return the old value. This needs attention. The answer says how long their copies have left.
  • “Not yet. Its name servers do.” No resolver returns it yet, but the name servers do. The change is made; resolvers pick it up when their copies run out.
  • “No. None of them do.” No resolver returns it, and when we could ask the name servers, they don’t either. This is a problem.

How to fix “None of them do”: check the record at your DNS provider, that it saved, and that it’s on the name you checked, such as www.example.com rather than example.com. If the domain moved DNS providers, edit the zone at the provider its name servers point to now.

How long a DNS change takes (TTL)

Every DNS record has a TTL, or time to live, in seconds. It tells resolvers how long they may keep the record: 3600 is up to an hour. A low TTL makes changes reach visitors sooner; a high one means fewer lookups.

The TTL that decides how long a change takes is the old record’s, because that’s the copy resolvers saved. To make a planned change quickly:

  1. Find the record’s TTL. The name servers’ answer in the report shows the TTL set in the zone.
  2. Lower it, to 300 seconds for example, at least that long before the change. If it’s 86400, a day, lower it a day ahead.
  3. Make the change. Resolvers pick it up within the shorter TTL.

Two kinds of answer take longer. Name servers set at your registrar are published by the registry with its own TTL; Amazon’s Route 53 guide says registrars typically use 24 to 48 hours. And resolvers save “doesn’t exist” answers too, for the shorter of the zone’s SOA TTL and the SOA’s minimum field (RFC 2308).

The name doesn’t exist (NXDOMAIN)

Every resolver answered NXDOMAIN for every query: as far as DNS is concerned, the name doesn’t exist. Browsers show an error such as DNS_PROBE_FINISHED_NXDOMAIN. This is a problem.

Common causes are a typo, a record added at a DNS provider the domain doesn’t use, or a domain that isn’t registered, has expired, or is on hold.

How to fix it: check the spelling and the domain’s registration. Then check that the record exists at the DNS provider the name servers point to. If you just added it, resolvers may still have the “doesn’t exist” answer saved; see How long a DNS change takes.

No resolver could answer (SERVFAIL)

Every resolver returned SERVFAIL for every query: none could get a usable answer. Visitors’ resolvers are likely to fail the same way. This is a problem.

It usually has one of two causes:

  • The name servers aren’t working. They time out, refuse, or don’t hold the zone. See Name servers.
  • DNSSEC doesn’t validate. The zone’s keys or signatures don’t match the registry’s DS record. When Cloudflare names the failure, the answer says “No. Its DNSSEC is broken.” instead. See DNSSEC.

How to fix it: fix any name server the report says isn’t answering. If they all answer, check DNSSEC. After a move between DNS providers, check the DS record at your registrar first.

Some DNS answers are missing

Some queries failed or timed out, so we couldn’t compare every record type. It counts as couldn’t check, not as a failure. Try again.

If every resolver returned SERVFAIL for just one type, the name servers are probably mishandling it. RFC 8659 notes that some fail on types they don’t recognise, such as CAA.

How to fix it: ask your DNS provider to return an empty answer for that type, not an error, as RFC 1034 expects.

The name has no address

The resolvers agree, but none returned an A, AAAA, or CNAME record, so browsers can’t find a server. The answer is “Yes, but there’s no web address.” and needs attention. That’s expected for a name used only for email.

How to fix it: add an A record (IPv4) or AAAA record (IPv6) pointing at your web host, or a CNAME to the name your host gives you. A bare domain such as example.com can’t have a CNAME; use your provider’s alternative, such as Cloudflare’s CNAME flattening or Route 53’s alias records.

The alias leads nowhere (dangling CNAME)

The name is an alias (CNAME) of another name that has no address. The answer is “Yes, but its alias leads nowhere.” and needs attention.

This often follows a service being shut down: app.example.com still points at example-app.azurewebsites.net after the app was deleted. On some cloud services, anyone can then create a resource with that name and serve their own pages on your subdomain, with a valid certificate. This is called a subdomain takeover.

How to fix it: if you no longer use the service, delete the CNAME. If you do, point it at the name the service gives you now. In future, remove the DNS record before you delete the resource.

Your provider’s guides

What we can’t tell from outside

We see what a few public resolvers return, from one anycast location each, at one moment. Your visitors may use their internet provider’s resolver, with its own saved copy. Agreement here isn’t a worldwide propagation score, and we can’t see the TTL a record had before a change.

Sources

Last reviewed .