DNS Propagation Checker

A validated propagation check for the A record of example.com.

How it works

• Validate and normalize the target exactly as a DNS lookup does.
• Query each resolver configured by the deployment (the client cannot choose a resolver).
• Compare the answer sets and name any resolver that disagrees.

• Resolvers cache answers, so a freshly changed record can legitimately appear on some resolvers before others.

Methodology

1. Validate the hostname and record type with the same guard as the DNS lookup.
2. Ask each configured resolver for the record and normalize the answers.
3. Declare propagation only when every resolver returns the same record set; name the divergent resolvers otherwise.

Time model

• Time source: UTC.
• Timezone: Each resolver is queried at request time; the result reflects their caches at that instant.
• Locale: Record values are ASCII tokens; no locale-specific formatting is applied.
• Daylight saving: The query instant is absolute; daylight-saving transitions do not affect it.
• Reference date: There is no reference-date input; the verdict reflects resolver state when the request is served.

Usage

1. Enter a public hostname.
2. Choose the record type to compare.
3. Run the check and read each resolver's answer and the consistency verdict.

Examples

These are examples, not current values: they use fixed inputs, while the interactive tool computes live results in your browser.

A record propagation

{
  "target": "example.com",
  "type": "A"
}

NS record propagation

{
  "target": "example.com",
  "type": "NS"
}

Limitations

Server processing and data flow

This check runs on the Gampangin API. The hostname and record type are sent to our server, which queries each resolver configured by the deployment and returns per-resolver answers plus a verdict.

Only the validated hostname and record type leave the browser; no query is stored or logged, the response is no-store, and an unconfigured deployment fails closed rather than guessing.