DNS
DNS lookup
Query any DNS record type from two resolvers at once, so a change still spreading is easy to spot.
Free, no accountLive check
Result
Fill in the form and press Look up DNS records. The verdict and the detail appear here.
What this is
This dns lookup asks two public resolvers the same question at once rather than one, because a single resolver only ever shows one side of a change: the moment a record is edited, some resolvers still hold the old answer in cache while others already have the new one, and a tool that reads just one of them cannot tell the two states apart.
A DNS record is a line in a zone file that a name’s nameservers publish and a resolver caches for a while - the "time to live", or TTL. Querying two resolvers rather than one is the only way to see a record from two independent vantage points at the same moment, which is what makes an in-progress change, rather than a finished one, visible.
Some record types carry a rule the others do not. A CNAME record is special: RFC 1035 defines it as an alias for another name, and RFC 1912 §2.4 forbids it from sharing a name with any other record, which includes the NS and SOA records a zone’s own apex always needs - so a CNAME at the apex is not a style choice, it is a configuration a correctly built zone cannot have.
How to read the result
The table lists every distinct value either resolver returned, with a tick under each resolver that reported it. A row ticked under both resolvers is a settled answer; a row ticked under only one is either a change still spreading or a short TTL letting one resolver’s cache lag behind the other’s.
A verdict of danger means something is actually broken - a name that does not exist, or a CNAME sitting where the zone apex cannot allow one. A warning means the two resolvers disagree right now, which often resolves itself within the record’s TTL without anyone doing anything.
Common mistakes
What goes wrong most often, and how to tell.
- Reading one resolver as the whole truthA single resolver only shows its own cached state. Right after a change, different resolvers legitimately disagree for as long as the old TTL, and checking just one can make a finished change look stuck, or a still-spreading one look finished.
- Putting a CNAME at the zone apexRFC 1912 §2.4 forbids a name with a CNAME from carrying any other record, and the apex always needs an NS and an SOA record, so a CNAME cannot legally sit there. Most DNS hosts refuse to save it; the ones that do not produce a zone that behaves unpredictably depending on which record a resolver happens to ask for first.
- Assuming a changed record is live everywhere at onceA record only updates everywhere once its old TTL has fully elapsed at every resolver that cached it. Checking immediately after a change and seeing the old value is not a sign the change failed.
- Not checking the record type that actually mattersA domain can have a perfectly good A record and a completely broken MX or TXT record at the same time; each type is published and cached independently, so checking the wrong one gives false confidence about the one that is actually causing a problem.
Questions
What people ask about this tool.
- Each resolver caches a record for as long as its TTL says, independently of the other. Right after a change, one resolver can still be serving the old cached value while the other has already fetched the new one; the disagreement clears itself once the old TTL runs out everywhere.
- No. RFC 1912 §2.4 forbids a CNAME from sharing a name with any other record, and the root of a zone always needs its own NS and SOA records, so a CNAME there is a configuration a correctly built zone cannot have, not a style choice.
- A resolver that answers "no such name" is saying the domain itself is not registered or not yet delegated to any nameserver, which is different from the record type simply being empty. An empty record type still means the domain exists.
- At most as long as the old record’s TTL, counted from the moment each resolver last cached it rather than from the moment the change was made. A one-hour TTL can mean up to an hour of some resolvers still serving the old value.
Use it from the API
The same check, as one request.