DNS Propagation Checker

Introduction

DNS propagation is the period when recursive resolvers no longer agree about a record. Some resolvers may still serve a cached old answer, some may already have the new answer, and some may fail or apply DNSSEC, EDNS Client Subnet, or provider-specific policy differently.

A propagation check is most useful when it measures the exact record a user or service depends on. An A-record cutover says nothing about an MX or TXT change, and a leading answer is not automatically the intended answer. The safest cutover read compares public resolver answers against the value you planned to publish.

The main percentage is an agreement score across the selected resolver set. With an expected answer, it measures how many selected resolvers match the target. Without one, it measures how many resolvers share the largest normalized answer group. Failed resolvers stay in the denominator so the score does not hide weak evidence.

Use the result as public recursive evidence, not as proof of every client cache. For critical changes, compare the intended value, inspect TTLs on holdouts, and confirm the authoritative side when the resolver view remains split.

How to Use This Tool:

Run the first pass with the hostname and record type you changed, then widen the evidence only when the basic snapshot raises a question.

1. Enter the Domain as a hostname or URL. The check normalizes URLs to their host before querying resolvers.
2. Choose the exact Record type: A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, or CAA. Match the record type to the change you are validating.
3. Add an Expected answer for cutovers, rollbacks, or incident checks where one value is supposed to be visible. Leave it blank when you only need to see the current leading answer.
4. Pick a Comparison rule. Use exact text for full answer strings, contains text for one value inside a larger RRset, and regular expression only when a careful pattern is truly needed.
5. Use the default Resolvers first. Select all only when you need a wider public resolver survey and can tolerate more failures or slower responses.
6. Enable DNSSEC DO bit, DNSSEC CD bit, or EDNS client subnet when validation state, resolver policy, or location-aware answers are part of the question.
7. Read Propagation Brief before the charts. It gives the verdict, next check, operational facts, and observed answer groups; then use Resolver Matrix, Answer Distribution, and Resolver Latency for deeper review.

Interpreting Results:

When an expected answer is provided, the percentage answers a practical deployment question: how many selected resolvers returned the value you expected under the selected comparison rule. That is the strongest mode for cutover checks because it prevents an incidental majority from looking correct.

When the expected answer is blank, the percentage measures the largest answer cluster. A high score then means the public recursive sample mostly agrees, but you still need to decide whether the lead answer is the value you intended.

TTL is the main timing clue for holdouts. A resolver showing the old answer with a large remaining TTL may simply be waiting out cache. A resolver showing the old answer with a very small TTL, repeated failures, or a different AD state may point to a deeper issue such as stale upstream data, DNSSEC validation, or resolver-specific steering.

• Expected or Lead rows are the good cluster for the selected mode.
• Different or Other rows are holdouts or alternate answers that deserve TTL and answer inspection.
• Fail rows did not return a usable answer and still count against the score.
• AD is a DNSSEC validation signal from the resolver response, not a guarantee that every downstream client validated the same way.

Technical Details:

Recursive resolvers answer from cache until a record's time to live expires or until the resolver refreshes its cached state. That means propagation is not a single global event. It is a set of resolver-specific observations shaped by cache age, resolver policy, DNSSEC validation, transport failures, and sometimes client-subnet steering.

Answer comparison starts by cleaning returned RDATA into stable text. Hostname-style values have trailing dots removed, TXT values have wrapping quotes stripped, duplicate values are removed, and multi-value answers are sorted before comparison. That normalization makes repeated checks easier to compare without hiding meaningful answer changes.

Formula Core:

The score uses every selected resolver in the denominator, including resolvers that failed to return a usable answer.

Here s is the total selected resolver count. With an expected answer, m is the number of resolvers that match the target. Without an expected answer, m is the size of the largest normalized answer cluster.

Rule Core:

Retries repeat failed resolver requests after the first attempt and keep the fastest successful answer for a resolver. A wider resolver list improves coverage, but it can also introduce more network noise, browser reachability limits, and provider-specific behavior.

Privacy and Accuracy Notes:

DNS queries leave the page and are sent to the selected public resolvers. The queried hostname, record type, DNSSEC options, EDNS Client Subnet value, and timing settings can be visible to those providers, and some selected resolver paths may pass through simplified.tools before reaching the provider because browsers cannot read every resolver response directly. Avoid testing private names when that disclosure is not acceptable.

Worked Examples:

A planned A-record cutover to 203.0.113.20 should use Record type A and put 203.0.113.20 in Expected answer. If four of five resolvers match and one shows the old address with a TTL of 25 minutes, the result is mostly propagated but still has a visible cache holdout.

A TXT record such as an SPF update often has a long answer string. In that case, Contains text can check for one required token, while the resolver matrix still shows the full returned answer so you can spot missing or duplicated parts.

If every selected resolver fails, do not interpret the score as propagation delay. Check the hostname, record type, timeout, resolver set, and DNSSEC options. A wrong type or unreachable resolver path can create a no-signal result before any cache comparison is meaningful.

FAQ:

Glossary:

RRset

The set of DNS records with the same owner name, class, and type.

TTL

Time to live, the cache lifetime a resolver reports for a returned answer.

AD

Authenticated Data, a resolver response signal related to DNSSEC validation.

EDNS Client Subnet

An optional subnet hint that may affect location-aware DNS answers.

Recursive resolver

A resolver that answers from cache or by following DNS delegation on behalf of clients.

References:

• RFC 8484: DNS Queries over HTTPS, IETF, October 2018.
• RFC 7871: Client Subnet in DNS Queries, IETF, May 2016.
• RFC 4035: Protocol Modifications for the DNS Security Extensions, IETF, March 2005.
• RFC 2308: Negative Caching of DNS Queries, IETF, March 1998.