DNS Propagation Checker
This checker compares DNS answers across multiple resolvers so you can track real propagation progress instead of guessing from one local resolver view.
What this tool checks
- Resolver-by-resolver response spread for selected record type.
- Agreement and disagreement patterns that indicate cache transition state.
- Structured evidence for rollout windows and incident communications.
How to read the output
- Result Summary indicates convergence level across tested resolvers.
- Overview helps you estimate whether users are likely to see mixed behavior.
- Technical Details reveals exact resolver divergence to support rollout decisions.
- Raw Output can be attached to change tickets and postmortems.
Common failure patterns
- New value appears in some regions but old value persists elsewhere.
- Resolver-specific policy or stale cache creates prolonged inconsistency.
- Incorrect TTL strategy causes longer migration windows than planned.
- Record-type mismatch makes propagation appear broken when query is wrong.
Remediation workflow
- Confirm you are checking the intended record type and host label.
- Track TTL and expected cache expiry before escalating propagation concerns.
- Re-run from interval checkpoints instead of continuously refreshing one resolver.
- Validate post-propagation service behavior with HTTP/TLS or mail tests.
Next steps
FAQ
How long should DNS propagation take?
It depends on TTL, resolver refresh behavior, and provider caching policy.
Is propagation complete when most resolvers match?
For production changes, wait for full convergence or acceptable risk threshold defined by your team.
Can CDN behavior hide propagation issues?
Yes. Edge caching and geo routing can mask underlying resolver divergence.
Should I lower TTL before planned migrations?
Usually yes, with enough lead time to let previous high TTL values expire first.
What confirms migration success after convergence?
End-to-end application checks over the new DNS target.