What this lookup shows

The tool asks two independent public recursive resolvers — Cloudflare's 1.1.1.1 service and Google Public DNS — the same question at the same moment, using their DNS-over-HTTPS JSON interfaces. Each panel shows the response code, the flags the resolver set, every record in the answer with its remaining TTL, and, for negative answers, the SOA record that decides how long "no such name" may be cached.

Comparing two resolvers is the quickest way to separate a problem in your zone from a problem with caching. If both return the same new answer, the authoritative data is published and the resolvers have picked it up. If they disagree, one of them is probably still serving an older cached copy — which is normal for up to the old TTL after a change.

How to read the result

You seeWhat it means
NOERROR with recordsThe name exists and has data of the type you asked for.
NOERROR with no answer"NODATA": the name exists, but not with this record type. Try another type, or check whether the name is a CNAME.
NXDOMAINThe name does not exist in the zone. Resolvers cache this negative answer for the SOA-derived TTL shown under Authority.
SERVFAILThe resolver could not get a usable answer: unreachable or broken authoritative servers, or a DNSSEC validation failure. Re-run with "Disable validation" to test the DNSSEC theory.
AD flagThe resolver validated the answer with DNSSEC. It only appears for signed zones. The tool asks for DNSSEC data (the DO bit) on every query, because Cloudflare's JSON interface does not report AD reliably for signed zones without it.
TTLSeconds the resolver may keep serving this copy. It counts down from the value configured in the zone, so two resolvers rarely show the same number.

Why the two resolvers can disagree

  • Different cache ages. Each resolver fetched the record at a different time, so one may still hold the value you replaced. Waiting out the old TTL fixes this; editing the record again does not.
  • Location-aware answers. CDNs and large platforms often return different addresses depending on where the query comes from. Different IPs from Cloudflare and Google are expected for such names and are not an error.
  • Negative caching. If someone looked the name up before you created it, a resolver may keep returning NXDOMAIN until the negative TTL runs out.
  • DNSSEC. Both services validate DNSSEC. A broken signature or a stale DS record at the registrar produces SERVFAIL on validating resolvers while non-validating ones still answer.

What this tool cannot see

Public resolvers show the internet's view of a name. They cannot show records that exist only on an internal or split-horizon DNS server, the cache inside your operating system or browser, or what a specific ISP resolver currently holds. To see the source of truth, query the zone's authoritative name server directly with recursion disabled: 

dig example.com NS +short
dig @ns1.example-dns.net www.example.com A +norec

An answer with the aa (authoritative answer) flag comes straight from the zone, with no cache in between. If the authoritative answer is right and a resolver is wrong, you are waiting on a cache. If the authoritative answer is wrong, no amount of waiting will help.

Privacy

The page is static. When you press Look up, your browser sends the name to cloudflare-dns.com and dns.google; their own privacy policies apply to those queries. Nothing is sent to and.guide, and the query only appears in the page address so you can share or bookmark a lookup.