What this tool actually queries
Each record type is a separate question. When you choose All types, this tool fires nine independent queries in parallel and reports the outcome of each one on its own: the records returned, or the specific reason none were. That per-type honesty matters, because the three ways a query can come back empty mean completely different things and have completely different fixes.
| Result | What the resolver said | What it means |
|---|---|---|
| Records listed | NOERROR with an answer section | The name exists and publishes this record type. |
| No records of this type | NOERROR with an empty answer (NODATA) | The name exists. It just has nothing of this type. Other types may still work. |
| Domain not found | NXDOMAIN | The name does not exist anywhere in DNS. No record type will ever answer. |
| Lookup failed | SERVFAIL | The resolver could not get an answer — broken delegation, unreachable nameservers, or a DNSSEC validation failure. |
| Query timed out | no response at all | The authoritative servers did not reply in time. A network or server problem, not a record problem. |
How to read each record type
- A — IPv4 addresses. Multiple A records are normal: that is round-robin, or a CDN handing out the nearest edge. See the A record lookup for detail.
- AAAA — IPv6 addresses. Absent on IPv4-only hosts, which is not an error. Check with the AAAA lookup.
- CNAME — an alias pointing at another name. A CNAME may never coexist with other data at the same name, which is why the apex of a zone can never be a CNAME. See CNAME lookup.
- MX — mail routing, lowest preference number wins. Use the MX lookup for a mail-specific view.
- NS — the nameservers authoritative for the zone. See NS lookup.
- TXT — free-form text: SPF, verification tokens, and more. See TXT lookup.
- SOA — the zone apex record carrying the serial number and timers. See SOA lookup.
- CAA — which certificate authorities may issue for the domain. See CAA lookup.
- SRV — service location records at
_service._protonames. See SRV lookup.
Read the full explanation of dns lookup results ↓Show less ↑
One subtlety worth internalising: a lookup for www.example.com and one for example.com are different questions about different names. Records do not inherit down the tree. If example.com has an MX record and www.example.com does not, that is correct and expected — mail is addressed to the domain, not to the web host.
Where the answers come from
This tool queries through a recursive resolver, which means you are seeing a cached view, not necessarily what the authoritative servers hold at this instant. Every record carries a TTL; until it expires, resolvers keep serving the old value. That is the entire mechanism behind "DNS propagation" — nothing propagates, caches simply expire at different times.
If you have just changed a record and this tool still shows the old value, the change is almost certainly live at the authoritative servers and merely cached here. Confirm with the DNS propagation checker across all 85 resolvers, or compare four major public resolvers side by side with DNS Compare.
Common failures and how to fix them
- Everything returns NXDOMAIN. The domain is unregistered, expired, or its delegation is missing. Check the registration with WHOIS and the delegation with an NS lookup. Editing zone records will not help.
- Every type returns SERVFAIL. Either the nameservers are unreachable, or the zone is signed and failing DNSSEC validation. Run the DNSSEC checker — a stale DS record after a key rollover produces exactly this and is invisible to non-validating resolvers.
- A works but AAAA does not, and some users cannot reach you. A broken or stale AAAA record is worse than none: IPv6-capable clients try it first and hang. Either fix the address or remove the record.
- The record you added does not show up. Check for a trailing-dot mistake. In most control panels,
example.comin a value field is expanded toexample.com.example.com. Also confirm you edited the zone on the nameservers the domain is actually delegated to — moving hosts without updating NS records at the registrar is the single most common cause. - TXT records look truncated. A single TXT string cannot exceed 255 bytes; longer values are split into multiple chunks that must be concatenated. This tool joins them for you, so what you see is the effective value.
- The value is right but the site is still down. DNS is only the first hop. Confirm the host is listening with the port checker and the certificate is valid with the SSL checker.
The same lookup from the command line
Everything here maps directly onto dig. The +noall +answer pair strips the output down to just the answer section, which is what you almost always want:
# One record type
dig +noall +answer example.com A
example.com. 300 IN A 172.66.147.243
example.com. 300 IN A 104.20.23.154
# Ask a specific resolver rather than your local one
dig @1.1.1.1 +noall +answer example.com A
# Bypass every cache and ask the authoritative server directly
dig +noall +answer @ns0.wikimedia.org wikipedia.org SOA
# Follow the delegation from the root down, one step at a time
dig +trace example.com AThe status line tells you which of the empty cases you hit. Run dig example.com MX without +noall and look at status: NOERROR versus status: NXDOMAIN versus status: SERVFAIL in the header — that single word is the difference between "no record", "no domain", and "broken zone".
nslookup -type=MX example.com is the closest equivalent, but it hides the response code. If you have WSL or Git Bash, use dig — the extra detail is worth it.