DNS Lookup Tool

Query any record type against Google, Cloudflare, or Quad9 over DNS-over-HTTPS. Same answers dig would give you, without the terminal — and without your local resolver in the way.

Try an example: cloudflare.com (A) · google.com (MX) · github.com (TXT)

Not sure what a record type does? → DNS Record Types Reference

How this DNS lookup tool works

This is dig in a browser tab. Pick a record type, pick a public resolver (Google, Cloudflare, or Quad9), and the query goes out over DNS-over-HTTPS (RFC 8484). What you see is what that resolver currently has cached for your domain. Choose "All resolvers" and the tool fires the same query at all three in parallel and flags any disagreement.

Supported types cover the everyday set (A, AAAA, MX, TXT, CNAME, NS, SOA, SRV, CAA, PTR) plus the DNSSEC trio most web lookup tools skip: DS, DNSKEY, and RRSIG. Each answer is shown with its TTL so you can see how long the resolver will keep serving it before re-asking the authoritative nameservers.

Why does "All resolvers" sometimes disagree?

Usually it's caching. You changed a record, Cloudflare's edge has already re-fetched it, Google's hasn't, and the TTL on the old answer is still ticking down somewhere. The other common cause is geo-routing at the authoritative nameserver — different answers handed to different resolver POPs, usually for CDN steering. Split-horizon DNS does much the same thing on purpose, where the operator returns one set of records to one resolver and another set to everyone else.

Our take: a single divergent answer right after a change is cache lag nine times out of ten. Wait the TTL out before assuming a real problem. If the disagreement persists past the published TTL, it's a configuration issue, not a propagation one.

NXDOMAIN versus NOERROR with no answer

These two look identical in the UI (zero records), but they mean different things on the wire. NXDOMAIN means the name itself doesn't exist — no record of any type at that label. NOERROR with an empty answer means the name exists but there's no record of the type you asked for. So example.com returning zero AAAA records is normal: the name exists, it just has no IPv6.

The distinction matters because negative answers are cached too, using the SOA minimum field. If you publish a new record and resolvers around the world are still saying "no", it isn't broken DNS — it's a negative cache entry that hasn't expired yet.

PTR lookups: why the input changes shape

Reverse DNS doesn't use the IP address directly. It queries a synthetic name under in-addr.arpa with the octets reversed: 

93.184.216.34  →  34.216.184.93.in-addr.arpa

Pick PTR in this tool and you can paste either the raw IPv4 or the full reversed name — we'll do the flip for you. PTR records live in the IP owner's zone (usually your hosting provider or ISP), not your own, so you can't set them from your domain's DNS panel. For sending mail servers this matters: receivers check that the PTR matches a forward A or AAAA record (forward-confirmed reverse DNS) before they trust the connection.

Why not just use dig?

Use dig when you're on the box and want to see exactly what your local recursive resolver thinks. That's a different question from "what does the rest of the internet see?", which is what this tool answers. A corporate resolver with a split-horizon zone, a Pi-hole rewriting an answer, or a stale ISP cache will all show up in dig and not here.

What to do: run both. If dig says one thing and this tool says another, the resolver between you and the internet is the variable. Most "DNS isn't working" tickets are really "my resolver is lying to me" tickets.

Where to go next

For a wider sweep across resolvers in different regions, the DNS propagation checker hits a global panel at once — better than this tool while you're waiting on a TTL to expire after a change. The TXT record checker pulls every TXT at the apex plus well-known labels like _dmarc and _mta-sts in one pass. The CNAME checker probes common sub-hosts and follows each alias to its terminal A or AAAA. For what each record type actually does, see the DNS record types reference.

Frequently Asked Questions

DNS lookups, resolver disagreement, and the gotchas that bite.

All of them, from their own point of view. Each public resolver runs its own cache, and they re-fetch at different moments. If you published a change inside the last hour, the resolver still serving the old answer is just waiting for its cached copy to expire. Note the TTL on the divergent answer and wait that long.

Persistent disagreement past the TTL means something else. Geo-routing at the authoritative nameserver hands different answers to different resolver POPs — common with CDNs. Split-horizon DNS does the same thing on purpose. In both cases the records aren't "wrong", they're targeted, and the fix is at the authoritative side, not the resolver.

Not necessarily. There are two empty-answer cases and the UI shows them the same way. NXDOMAIN means the name itself doesn't exist. NOERROR with no answer means the name exists but has no record of the type you asked for. Querying AAAA on a domain that only publishes IPv4 returns NOERROR with no answer — the domain is fine, it just doesn't run on IPv6.

Empty answers are cached as well, using the SOA minimum field for negative TTL. So if you just added a record and resolvers keep saying "no", the resolver is honouring its negative cache. Wait it out, then re-query.

PTR is reverse DNS — it answers "what hostname is this IP?" rather than "what IP does this hostname have?". The query is made against a synthetic name under in-addr.arpa with the octets reversed:

93.184.216.34  →  34.216.184.93.in-addr.arpa

Paste a raw IPv4 with PTR selected and the tool does the flip. PTR records live in the IP owner's zone, not yours, so they're set by your hosting provider or ISP. For mail it matters: receivers check that the PTR resolves forward to the same IP (FCrDNS) before they trust the connection. The MX Inspector runs that check for every MX host on a domain.

Because dig asks whichever resolver your machine is configured to use, and this tool asks Google, Cloudflare, or Quad9 directly over HTTPS. The resolver in the middle is the variable. A corporate DNS server with a split-horizon zone, a Pi-hole rewriting answers, an ISP cache that hasn't refreshed, or a VPN with its own resolver will all show up in dig and not here.

Run both. If they match, the answer is real. If they don't, the resolver between your laptop and the internet is editing reality on the way through, and that's worth knowing.