Skip to content

Free tool

What a domain publishes: all 8 answers, in one go

You type a name, the eight questions go out together, and the zone comes back stacked: the base, the delegation, then everything hanging below it. An empty box is not an outage — we tell you which ones are normal and which ones are not.

No sign-up, no email required. You can paste a full address — we'll pull the domain out of it.

The mechanism

DNS has four ways of saying nothing

Most tools display all four the same way: an empty box. Yet three of those four answers are perfectly healthy, and only one means something is broken. Click to see what comes back, and what to do with it.

status: NXDOMAIN
ANSWER: 0
Valid answer

This name exists nowhere in the zone — not for that type, not for any other. It is a valid DNS answer, and it is categorical: this is not “not yet”, it is “not at all”.

What to do: Check the spelling, then check that the record really was created in the zone served by the current name servers. A record left at the old host is invisible from the new one.

A table that renders the same empty box for those four answers costs you the day: you hunt an outage where there is none, and you walk past a real one. The one above tells them apart.

Lines trimmed down to what decides: the answer status and the number of records returned. Example domain: RFC 2606.

What nobody displays

What a zone leaves unsaid matters just as much.

A missing CAA lets every certificate authority in. A missing MX lets mail drift off into nothing. A missing SOA simply says you are not at the top of a zone.

  • SOAmissing = you are not at the top of a zone
  • CAAmissing = every authority can sign
  • MXa dot = no mail, and that is on purpose

Reading the result

What each line means

Six situations, and for each one the only thing that matters: is it serious.

Values under a type
The zone publishes that type. Mail servers are sorted by priority, name servers alphabetically: that order is ours, not the zone's, and it carries no meaning.
A type, and no value
The name exists, it publishes no record of that type. In DNS terms, NOERROR with no answer at all — a valid answer, not an outage. A sub-name such as www normally has no SOA, no NS and no MX.
A type, and a code instead
That is something else: the servers did not answer, or answered that they did not know. SERVFAIL is the most common, and it usually comes from an expired DNSSEC signature.
A lone dot in the mail servers
A null MX: priority 0, empty destination. The domain states that it receives no mail (RFC 7505). Deliberate, and cleaner than a missing MX.
A zone deed, and no delegation
An SOA with no name servers: the zone exists, but nobody is declared to serve it any more. It will vanish from the internet when the registry cache expires.
An alias, and a whole zone behind it
When a CNAME shows up, everything displayed under it belongs to its target: the resolver changed names along the way. Run the lookup on the target to read the real zone.

Common mistakes

Five ways to misread a lookup

All five end with the same sentence — “my DNS is broken” — when in four cases out of five it is not.

  1. No address at all, and yet the site loads

    What causes it: The name you queried is not the one serving the site. Plenty of zones put the address on www only and leave the bare domain empty.

    What fixes it: Look up both, the bare domain and the www. Whichever is empty must redirect to the other, or half your visitors fall into nothing.

  2. The MX shows a dot, and the record looks broken

    What causes it: It is a null MX: priority 0, empty destination (RFC 7505). Most tools render a blank line and let you assume something was forgotten.

    What fixes it: Nothing to fix if that domain is not meant to receive mail. If it is, replace that entry with the one from your mail provider.

  3. You query www and conclude the domain has no name servers

    What causes it: The SOA, the NS records and the CAA records live only at the top of a zone. On a sub-name they are missing by design, not by accident.

    What fixes it: Ask the question again on the bare domain. That is where — and only where — the delegation can be read.

  4. The SPF record appears cut into two pieces

    What causes it: A DNS text string cannot exceed 255 characters. Beyond that, the zone publishes it in several pieces, which have to be glued back together.

    What fixes it: This tool already glues them: what you read is the whole value. If your host shows two lines, do not count them as two records.

  5. The record you created an hour ago still does not show up

    What causes it: A “this type does not exist” is cached too, for the duration written in the last field of the SOA. Until it runs out, the resolver repeats its old absence without asking again.

    What fixes it: Read that duration in the zone deed above, and wait it out. To see what the domain's own servers publish without going through a cache, use the DNS propagation tool.

Worth keeping around

The 8 types, and what their absence means

The right-hand column is the one you will not find anywhere else: a missing record says something, and not the same thing depending on the type.

TypeThe question it answersWhat its absence means
AWhich IPv4 address should reach this name?No browser can reach it over IPv4.
AAAAAnd over IPv6?The name is reachable over IPv4 only. Very common, with no consequence to date.
CNAMEIs this name somebody else's other name?The name is served in its own right, not by forwarding.
MXWho receives this domain's mail?The domain receives none — without saying so. A null MX does say so.
NSWhich servers are authoritative for this zone?Normal on a sub-name. On a domain, it is an outage.
SOAWhere does the zone start, and who runs it?This name is not the top of a zone.
TXTWhat does this domain state in free text?No SPF, no DMARC, no proof of ownership: mail leaves with no guarantee.
CAAWhich authorities can issue it a certificate?All of them. That is the default setting (RFC 8659).

The eight questions go out to two public resolvers, 1.1.1.1 and 8.8.8.8: if the first does not answer, the second takes over. Neither is your host's resolver, which can filter or answer from a local cache. To query the domain's own servers, use the DNS propagation tool.

Frequently asked questions

What people ask us about DNS lookups

How is this different from the DNS propagation tool?

This one tells you what a public resolver answers today, for the eight types at once. Propagation compares eight resolvers with each other and with the domain's own servers, for a single type: it is the tool for migration days, not for the question “what does this domain publish”.

Why can I not pick the type from a menu?

Because the real question is almost never “what does the MX say” but “what does this zone publish”. Picking a type first assumes you know what you are looking for — which is precisely what you do not know when you arrive here. All eight at once show you.

Does an empty record mean my domain is broken?

No. DNS tells “this name does not exist” (NXDOMAIN) apart from “this name exists but publishes no such type” (NODATA). The second answer is the most common of all, and it is a perfectly valid one.

What does the single dot in the mail servers mean?

It is a null MX: priority 0, empty destination. The domain states that it receives no mail (RFC 7505). A server reading it refuses immediately, instead of holding the message in a queue for 5 days.

Can I look up a subdomain?

Yes, and it is often the right thing to do. Just know that the SOA, the NS records and the CAA records are found only at the top of a zone: on a www, or on any service name, they will be empty, and that is not a flaw.

Are the values shown mine, or a cache's?

A public cache's, at the second you ask. As long as the time to live written on the record has not expired, a resolver serves its own copy without asking again. To read the domain's own servers directly, use the DNS propagation tool.

The zone deed

The seven SOA fields, and the two that cost you a morning

Every tool shows them in a heap, on one line. They are seven distinct settings, and two of them explain half the questions we get asked.

ns1.example.com. hostmaster.example.com. 2026091601 7200 3600 1209600 300
  1. MNAMEThe primary name server

    The one holding the original of the zone; the others only serve copies of it. This is the one to query when you want to see a change before it spreads.

  2. RNAMEThe administrator address

    An email address written the DNS way: the first dot stands for the at sign. So “hostmaster.example.com” reads as “hostmaster@example.com”.

  3. SERIALThe serial number

    It goes up with every change. If a secondary server shows a lower number than the primary, it has not received your change yet — and that is where to look, not in the caches.

  4. REFRESHThe refresh interval

    How long a secondary server waits before asking the primary whether anything is new. With no notification in place, this is the worst-case delay before a copy catches up.

  5. RETRYThe retry after a failure

    If the primary did not answer, the secondary waits this long before trying again. Always shorter than the previous one.

  6. EXPIREGiving the zone up

    After this long without reaching the primary, a secondary stops answering for the zone rather than serve a stale copy. It is the last line of defense against a domain that lies.

  7. MINIMUMThe negative time to live

    The only field that concerns you directly: it says how long a “this name publishes no such type” stays true in caches around the world. It is the one you curse when a record created ten minutes ago is still unfindable.

The seven fields and their order come from RFC 1035 § 3.3.13. The negative time to live is the smaller of the MINIMUM field and the time to live of the SOA itself, as redefined by RFC 2308 § 5.

Why all eight at once

The five floors of a zone do not fall together

This is the whole reason for asking the eight types at the same time. Two of these floors are the frame: without them, nothing hanging below is served at all. The other three empty out one by one, without the rest moving an inch.

  1. The base

    SOA

    Frame

    Without itThe name is not the top of a zone. That is not necessarily an outage — it may just be a sub-name — but none of the conclusions below holds if you forget it.

    What holdsEverything, if the name really is a sub-name: its address, its declarations and its mail are read normally in the zone above.

  2. The delegation

    NS

    Frame

    Without itNobody is declared to serve the zone any more. While the registry cache holds, everything keeps working; once it expires, the domain vanishes from the internet entirely.

    What holdsNothing, in the end. It is the only floor whose absence takes all the others with it.

  3. The address

    A · AAAA · CNAME

    Without itNo browser finds anywhere to go. The site is unreachable, and its certificate cannot even be renewed automatically any more.

    What holdsThe mail. A domain with no website receives its messages perfectly well — that is in fact how a great many brand domains are set up.

  4. The mail

    MX

    Without itMessages fall back onto the site's address: with no MX, a sending server treats the A record as an implicit MX (RFC 5321 § 5.1). They land on the web server, which does nothing with them.

    What holdsThe site, entirely. A mail outage is never visible from a browser, and that is why it drags on for weeks.

  5. The declarations

    TXT · CAA

    Without itNothing breaks straight away, and that is the trap. With no SPF and no DMARC, mail leaves with no guarantee and ends up in the junk folder; with no CAA, any authority can issue a certificate for this domain.

    What holdsThe site and the mail, for now. This is the floor whose absence is only noticed at the moment it gets expensive.

The fallback of mail onto the A record is described by RFC 5321 § 5.1; unrestricted issuance in the absence of CAA, by RFC 8659.

The vocabulary

Eight words you read everywhere and never see defined

These are the terms that turn up in the result above, in your host's replies, and in the discussion threads you will end up searching through.

Zone
The set of names administered by one and the same group of servers. A domain is a zone; a subdomain can be another one, handed to somebody else.
Apex
The top of a zone — the bare domain, without www. It is the only place where the SOA and the NS records live.
RRset
Every record of the same type on the same name. The four addresses of a website form a single RRset, and are replaced together.
NODATA
The name exists, it publishes no record of that type. A valid answer, the most common of all, and the one wrongly taken for an outage.
NXDOMAIN
The name does not exist at all. Different from the previous one, and far more final.
SERVFAIL
The servers could not answer. The only genuine outage among the four silences, and often an expired DNSSEC signature.
Null MX
An MX of priority 0 pointing at a dot: the domain states that it receives no mail (RFC 7505).
Glue
The address of a name server published by the registry above, when that server carries a name from the very zone it serves. Without it, the search would go round in circles.
A zone is not read line by line. It is read from the base downwards.
That is the reason for the order the result is displayed in, and for the absence of a dropdown: the question is not “what does the MX say”, it is “what does this zone publish”.