DNS propagation checker

Nothing is pushed anywhere. A change at your provider is immediate at your provider and invisible everywhere else.

Every other resolver keeps serving its cached answer until the lifetime attached to the old record expires, then asks again and receives the new one.

So the time a change takes to be universally visible is governed by the lifetime the old record carried, not by the new one — which is why lowering it after making a change accomplishes nothing.

Lowering it a day or two before the change is what shortens the window, and it is the single most useful preparation for a migration.

Some resolvers also hold answers longer than the lifetime asks, which is why a window usually outlasts the arithmetic.

The answer each queried resolver returns for the names examined, and whether they agree.

Where they disagree, which answer is the new one — because a mix of old and new is a change in progress, and a mix of two answers that are both wrong is something else.

Whether the nameservers listed at the registry match the nameservers the zone itself publishes, which is a mismatch that does not resolve on its own.

Conflicting record types on the same name, which is a configuration error rather than a timing one.

Alias and service records, and whether their targets resolve — a target that does not is a failure with no propagation explanation.

An alias record at a name coexists badly with other record types at that same name, because the alias is meant to redirect every lookup for it.

At the domain apex this is the classic failure: an alias pointing the website at a hosting platform, alongside the mail exchanger records the domain needs.

Depending on the resolver and the provider, the mail records are ignored — so the website works perfectly and the mail stops, with no change to anything about the mail configuration.

It is the most confusing DNS failure there is, because the symptom is in a service nobody touched. The check reports the conflict directly rather than leaving it to be inferred.

Providers frequently offer a flattening mechanism at the apex that avoids it, and that is the right fix rather than removing records that are needed.

Some resolvers on the new answer and some on the old, shortly after a change: normal. Wait out the old lifetime.

All resolvers on the old answer long after the change: the change did not take effect at the authoritative source, or it was made in a zone that is not the one being served.

Resolvers disagreeing with each other and none serving the new answer: usually a nameserver mismatch, where part of the world is asking a different set of servers than you edited.

Registry nameservers not matching the zone's own: this does not resolve with time, and it is worth fixing before anything else is diagnosed.

`dns.propagation` queries several independent resolvers and reports consistency across them. `dns.conflicts` reports record types that conflict at the same name.

`dns.nameserver_consistency` compares the nameservers listed at the registry with the ones the zone publishes.

`dns.cname` reports alias records and `dns.srv` reports service records, including whether their targets resolve. `dns.ptr` reports reverse names.

`dns.ttl` reports the lifetimes, which is what governs how long any disagreement lasts.

A sample of resolvers is queried, not every resolver in the world. Agreement across the sample is strong evidence and not proof.

A result describes one moment. During a change the same check a few minutes later legitimately returns something different.

Corporate and ISP resolvers with their own caching policies are not represented in the sample, and those are frequently the slowest to update.

Nothing is queried from inside your network, so a resolver you operate yourself is outside the picture.