DNS check
DNS Checker
Check a domain’s A, AAAA, CNAME, MX, NS and TXT records against four independent public resolvers at once, and see exactly where their answers differ.
What This Tool Does
This tool asks four separate public DNS resolvers — Google on 8.8.8.8, Cloudflare on 1.1.1.1, Quad9 on 9.9.9.9 and OpenDNS on 208.67.222.222 — what a domain currently publishes, and shows you each answer separately.
The separation is the whole point. Most DNS lookup tools query one resolver and present the result as the answer. But there is no single answer: every resolver holds its own cached copy, expiring on its own schedule. When you have just changed a record, the interesting question is not what the record is, it is which resolvers have caught up and which have not. That question only has an answer if you ask several resolvers and refuse to merge what they say.
Six record types are queried in parallel and appear as they arrive. Every result includes the response code, the remaining TTL on each resolver’s copy, and a transcript of the raw exchange.
How to Read Your Results
A records
The IPv4 address a browser connects to. A domain serving a website normally has at least one; several is normal for load balancing and CDNs. If there are none, the domain will not load in a browser — the connection fails before any web server is involved, which is why a “site down” problem is so often actually a DNS problem.
AAAA records
The IPv6 equivalent. These are optional and their absence is not a fault — plenty of working sites publish none. If you have deliberately enabled IPv6 and no AAAA record appears, that is the finding.
CNAME records
An alias pointing this name at another name. A CNAME cannot coexist with other records at the same name, and by specification it cannot exist at the zone apex — at example.com itself rather than www.example.com. Many DNS providers offer a workaround under a name like ALIAS, ANAME or CNAME flattening; those appear here as ordinary A records, because that is what the provider actually returns.
MX records
The mail servers that accept email for the domain, each with a preference number. Lower preference wins, so 10 mail.example.com is tried before 20 backup.example.com. A single entry reading 0 . is a null MX: the domain is stating that it accepts no mail at all.
NS records
The authoritative nameservers for the domain — the servers that hold the real records everything else here is a cached copy of. These should match what your registrar shows. If they do not, you are editing DNS in one place while the internet reads it from another, which is one of the most common and most confusing misconfigurations there is.
TXT records
Free-form text, used in practice for SPF, DKIM, DMARC and domain verification. Records longer than 255 characters are split into chunks on the wire and rejoined here, so a long DKIM key displays as one value rather than several fragments.
One rule catches people out: a domain may publish only one SPF record. Two records starting v=spf1 is a misconfiguration that causes receiving servers to fail the check outright, and it happens easily when two services are each told to “add” their SPF entry.
TTL
Seconds remaining before that resolver discards its cached copy and asks again. This is the number that tells you how long propagation still has to run — not a guess, the actual countdown. TTLs differ between resolvers because each cached the record at a different moment, which is normal and is why they are excluded when comparing answers.
Response codes
NOERROR means the query succeeded. Note that it can succeed with an empty answer, which means the domain exists but publishes nothing of that type. NXDOMAIN means the name does not exist at all. SERVFAIL means the resolver tried and failed, usually because the authoritative nameservers are unreachable or DNSSEC validation failed.
When resolvers disagree
Two very different situations produce the same display, and telling them apart matters. If you changed a record recently, disagreement means propagation is in progress and the TTLs tell you how much longer. If you did not change anything and the domain sits behind a CDN or uses geographic routing, disagreement is permanent and correct — those systems answer differently by design.
Common Problems and Fixes
Some resolvers still return the old IP address
Expected after any record change. Check the TTL column for the resolvers still showing the old value: that is how many seconds remain. Nothing can flush a third-party resolver’s cache on demand, so the fix is to wait it out. For next time, lower the record’s TTL to 300 seconds a day before the migration, then raise it again afterwards.
Every resolver returns NXDOMAIN
The name does not exist in DNS. Check for a typo first, then check that the domain has not expired, then check that nameservers are actually set at the registrar. A registered domain with no nameservers assigned returns NXDOMAIN exactly like an unregistered one.
Some resolvers return SERVFAIL and others answer
A split like this points at DNSSEC. Validating resolvers reject an answer whose signatures do not verify, while non-validating ones serve it happily. It usually follows a nameserver change where the DS record at the registrar was left pointing at the old provider’s keys. Fixing the DS record, or removing it if you are not using DNSSEC, resolves it.
NS records exist but there are no A records
The domain is registered and delegated correctly, but nothing tells browsers where the site lives, so it will not load. Add an A record pointing at your server’s IP address at whichever provider runs the nameservers shown in the NS row — which is not necessarily your registrar.
The NS records do not match your registrar
You are almost certainly editing DNS in the wrong control panel. The NS row here is authoritative about where the internet actually looks. Either move your records to that provider, or change the nameservers at the registrar to the one you have been editing — and expect the change to take as long as the parent zone’s TTL.
Mail is being rejected and there are two SPF records
Two TXT records beginning v=spf1 is a permanent error, not a warning. Merge them into a single record combining every include: mechanism, and keep the total number of DNS lookups the record triggers at ten or fewer.
What This Tool Cannot Tell You
- It does not query your authoritative nameservers. Everything here is a public resolver’s cached view, which is what visitors get. A change made seconds ago may not appear yet.
- It cannot tell you why two resolvers disagree. It reports the disagreement accurately; whether the cause is propagation or intentional geographic routing depends on facts about the domain that DNS does not expose.
- It sees four vantage points, not the whole internet. A corporate or ISP resolver you cannot reach from here may hold something different again.
- It does not validate DNSSEC itself. It reports whether a resolver flagged an answer as authenticated, and a SERVFAIL split is a strong signal, but a dedicated DNSSEC analyser will tell you more.
- It queries six record types, not all of them. SOA, CAA, SRV and PTR are not included.
Frequently Asked Questions
What is a DNS checker?
A DNS checker asks public resolvers what records a domain currently publishes, and shows you their answers. This one queries four independent resolvers separately rather than merging them, because the disagreements between them are usually what you are trying to find.
How long does DNS propagation actually take?
It is governed by the TTL on the old record, not by a fixed waiting period. A resolver that cached the previous value will keep serving it until that TTL expires, so a record with a 3600-second TTL can take up to an hour to change everywhere, and one with a 86400-second TTL can take a day.
The TTL column in the transcript shows how many seconds each resolver has left on its cached copy. That is the real answer to "how much longer", and it is why lowering the TTL a day before a planned migration makes the switch much faster.
Why do resolvers show different IP addresses for the same domain?
There are two common reasons and they need different responses. The first is propagation: you changed a record recently and some resolvers still hold the old value. That resolves itself when the TTL expires.
The second is that the domain uses geographic or load-balanced DNS on purpose. Large sites and CDNs answer differently depending on where the query came from, so different resolvers will permanently return different addresses. That is not a fault, and waiting will not change it.
Does this check the authoritative nameservers directly?
No. It queries four public recursive resolvers, which is deliberately what your visitors' own resolvers do. That means you see what real users see, including stale cached answers.
The trade-off is that a very recent change may not appear here until the resolvers refresh. To read the record straight from the source, query one of the nameservers in the NS row directly with dig.
What does NXDOMAIN mean?
It means the name does not exist in DNS at all — not that a particular record type is missing. A domain that exists but has no MX records returns NOERROR with an empty answer instead.
NXDOMAIN usually means the domain is unregistered, has expired, or has no delegation from its parent zone. It does not by itself mean the domain is available to buy, because a registered domain with no nameservers set will also return NXDOMAIN.
What does SERVFAIL mean?
The resolver tried to answer and could not. The usual causes are authoritative nameservers that are down or unreachable, a delegation pointing at nameservers that do not host the zone, or a DNSSEC signature that fails validation.
DNSSEC failures are worth ruling out first, because they often produce SERVFAIL on validating resolvers such as Google and Quad9 while non-validating ones still answer normally. A split like that in your results is a strong hint.
Why does the MX row sometimes show "0 ."?
That is a null MX record, defined in RFC 7505. A preference of 0 pointing at the root zone is an explicit statement that the domain accepts no email at all, which is a deliberate and correct configuration for a domain that only serves a website.
It is different from having no MX records, which is ambiguous and causes some senders to fall back to delivering mail to the A record instead.
Are these results cached?
Yes, for five minutes, and the transcript always states the age of what you are looking at. Five minutes is short enough to be useful while you are actively changing records, and long enough to keep repeated checks from hammering public resolvers that are provided free to everyone.