DNS Checker

Look up a domain’s DNS records from two independent public resolvers at once — Google and Cloudflare — so you can see not just what the records say, but whether both resolvers agree. That second part is what tells you a change has actually taken effect.

Queried live over DNS-over-HTTPS. Deselect record types you do not need to make the lookup faster.

—

Key takeaway: when the two resolvers return different A records, that is usually not a problem. Large sites use geographic DNS to send you to a nearby server, so Google and Cloudflare are answered from different places and get different addresses on purpose. The differences that matter are in NS, MX, TXT and SOA records — those should be identical everywhere.

What each record type does

Type	Purpose
`A`	The IPv4 address a name points to. The one that decides which server your browser connects to.
`AAAA`	The same thing for IPv6. Missing AAAA records are normal but mean IPv6-only clients cannot reach you directly.
`CNAME`	An alias pointing one name at another. Common for `www` and for hosted services.
`MX`	Where email for the domain should be delivered. The number is a priority — lower is tried first.
`NS`	The nameservers authoritative for the domain. Changing these is what moves DNS hosting.
`TXT`	Free-form text, in practice SPF, DKIM and DMARC policies plus ownership verification strings.
`SOA`	Administrative details for the zone, including a serial number that changes when the zone is edited.
`CAA`	Which certificate authorities are allowed to issue certificates for the domain. Absent on most domains.

Reading the two-resolver comparison

Every lookup here runs twice, against Google’s resolver and Cloudflare’s. Comparing the answers is more useful than a single lookup, because a difference tells you something a single answer cannot — but only if you know which differences mean something.

Differences that are normal

A and AAAA records for large sites. Content delivery networks answer with whichever server is closest to whoever asked. Google’s resolver and Cloudflare’s sit in different places, so they get different addresses. Checking a handful of well-known domains, most return different A records to the two resolvers, every time, forever. It is the system working as designed, not a fault.

TTL countdowns. Each resolver caches independently, so the remaining time-to-live differs. That is why this page shows TTL per resolver rather than pretending there is one value.

Differences that mean something

One resolver has records and the other has none. That is a change still working its way out, or a zone in an inconsistent state.

NS, SOA, MX or TXT differ. These are not geographically varied. If two resolvers disagree about your nameservers or your mail servers, a change is mid-flight — or two sets of nameservers are serving conflicting data, which is worth fixing urgently because mail may be going to the wrong place.

What “propagation” actually means

Nothing is pushed anywhere. When you change a record, your authoritative nameservers update instantly; everyone else keeps serving the previous answer until the copy they cached expires. That expiry is the TTL, and it is a value you control.

So the familiar advice to “wait 24 to 48 hours” is not a law of nature — it is a guess at the longest TTL anyone might have cached. If your records use a TTL of 300 seconds, changes are visible in five minutes. The professional move before a migration is to lower the TTL a day in advance, make the change, then put the TTL back up once everything is settled.

Two exceptions take longer whatever you do. Nameserver changes at the registrar involve the TLD’s own servers and their TTLs, often a day or two. And some ISP resolvers ignore short TTLs and cache for longer than they should, which is one reason using your ISP’s resolver is rarely the best choice. If you need to see a change immediately on your own machine, flush your local DNS cache — that clears your computer’s copy, not the internet’s.

Reading TXT records

TXT is where most of the interesting configuration lives, and this tool labels the common ones as it finds them:

SPF — starts v=spf1 and lists the servers allowed to send mail for the domain. Exactly one SPF record should exist; two is a misconfiguration that causes failures. DMARC — lives at _dmarc.yourdomain and tells receivers what to do when a message fails authentication. DKIM — publishes the public key used to sign outgoing mail, under a selector name. Verification strings — the google-site-verification and similar records proving you control the domain.

If you are investigating a suspicious email rather than configuring your own domain, these records are the other half of the picture the email header analyzer shows you.

Your DNS lookups are visible unless you encrypt them

This page queries DNS over HTTPS, so these lookups are encrypted. Your everyday browsing usually is not: by default your device asks your ISP’s resolver in plain text, which hands them a list of every domain you visit even on HTTPS sites. Encrypted DNS fixes the eavesdropping; a VPN moves the lookups off your ISP entirely.

PureVPN Set up encrypted DNS free

Affiliate link. We do not rank by commission — compare providers yourself.

What this checker cannot tell you

What your authoritative nameservers currently hold. Both resolvers may be serving cached copies. For the definitive answer, query the authoritative server directly: dig @ns1.example.com example.com, or dig +trace example.com to follow the chain from the root.

What your own device sees. Your computer, router and ISP each keep their own cache. A record can be live here and stale on your machine — that gap is normal and clears on its own.

Whether the records are correct. It reports what is published. A perfectly valid MX record pointing at the wrong server looks exactly like a right one.

Anything about the server behind the address. An A record tells you where the name points, not whether anything is listening — the ping test and port scanner answer that.

Frequently asked questions

Why do Google and Cloudflare show different IP addresses?

Almost always geographic routing. The site publishes different answers depending on where the question came from, so each resolver gets the address nearest to it. Both are correct. If the NS or MX records differ as well, then something really is inconsistent.

My change is not showing. What do I do?

Check the TTL on the old record — that is how long caches keep it. Confirm you edited the zone on the nameservers the NS records actually point at, which is the usual mistake after moving hosting. Then check here rather than in your browser, since your own machine caches too.

What is DNSSEC, and should the badge worry me?

DNSSEC signs DNS answers so a resolver can verify they were not tampered with in transit. The badge shows whether the answer was authenticated. Most domains are still unsigned, so “not signed” is common and not a fault — it simply means this protection is not in use.

Is there a difference between no records and no domain?

A large one, and this tool separates them. A domain that does not exist returns NXDOMAIN, which means the name is not registered or its zone is gone entirely. A domain that exists with no MX records is a working domain that just does not receive mail.

Why does my TXT record look split up?

DNS strings are limited to 255 characters, so long records — DKIM keys especially — are published as several chunks that get joined back together. This page shows them joined, which is what the reading software sees.