DNS Validator

A zone can be internally inconsistent in ways nobody notices until a particular resolver, mail server or certificate authority refuses to play along. What follows is the background: the rules a zone is supposed to follow. The next section covers what this tool queries, a subset of them.

CNAME, and why the apex is special

A CNAME cannot coexist with any other data at the same name (RFC 1034 §3.6.2; RFC 1912 §2.4), and the zone apex must carry SOA and NS records — so the apex can never be a CNAME. That single constraint is why a provider who hands you a hostname rather than an address cannot simply be pointed at from your root domain, and why CNAME flattening and ALIAS records exist; our DNS flattener follows such a chain to the addresses it ends at. Just as often missed: NS and MX targets must not be aliases either (RFC 2181 §10.3).

Nameservers, delegation and SOA

A zone should have at least two nameservers (RFC 1912 §2.8), and RFC 2182 argues for placing them so one failure cannot take out both. A lame delegation is an NS record naming a server that is not authoritative for the zone (RFC 1912 §2.8): the name is advertised, the server does not back it up, and a resolver that picks it may wait for a timeout. The parent registry’s NS set should match the child zone’s own, and where a nameserver’s hostname lives inside the zone it serves, the parent must publish address glue or resolution becomes circular (RFC 1034 §4.2.1).

The SOA record (RFC 1035 §3.3.13; RFC 1912 §2.2) carries MNAME, RNAME, SERIAL, REFRESH, RETRY, EXPIRE and MINIMUM, with the serial conventionally written YYYYMMDDnn. MINIMUM no longer means what its name suggests: since RFC 2308 §4 it is the negative-caching TTL. Treat RFC 1912’s numeric ranges — refresh 20 minutes to 12 hours, expire two to four weeks — as the 1996 guidance they are.

Mail: MX, SPF, DKIM and DMARC

A lower MX preference value is tried first (RFC 5321 §5.1), so the smallest number is the primary, and MX RDATA is a hostname and never an IP literal (RFC 1035 §3.3.9). A domain that accepts no mail says so with a null MX, a single 0 . record (RFC 7505). SPF, DKIM and DMARC all live in TXT records. SPF (RFC 7208) is published as TXT — the dedicated RR type 99 is obsolete (§3.1) — exactly one record may exist per name (§3.2, §4.5), and a check may make at most ten DNS-querying mechanisms or modifiers (§4.6.4). A single TXT string tops out at 255 octets (RFC 1035 §3.3.14), so longer values arrive split into several strings that are concatenated before evaluation (RFC 7208 §3.3). DKIM (RFC 6376) puts a public key under a selector so keys can rotate; DMARC is a TXT record on a _dmarc label, specified by RFC 9989, which replaced the informational RFC 7489 most older material still cites, with reporting formats in RFC 9990 and RFC 9991.

Outside mail, CAA (RFC 8659, obsoleting RFC 6844) restricts which certificate authorities may issue for a domain: the lookup climbs towards the root and stops at the first non-empty CAA record set (§3), so with none on that path any CA may issue.

Seven checks run in parallel against the domain you enter, and the report has one card per check. Nothing else is queried: there is no SOA field audit, no CAA lookup and no DMARC or DKIM query on a _dmarc or selector name, so a clean report here is not a statement about any of those. The checks that query once per record stop after the first twenty of a kind — far more than the seven nameservers RFC 1912 §2.8 recommends as a maximum — and say on the card when a zone had more, so no report describes part of a zone as though it were all of it.

• Glue Records — takes the zone’s NS records, keeps the ones whose hostname sits at or below the domain itself, and asks a parent-zone server for the delegation, looking for matching A or AAAA records in the additional section. Only those in-zone nameservers are judged: glue is only necessary where the nameserver’s name is below the cut (RFC 1034 §4.2.1), and a referral must carry it for them or set the truncation bit (RFC 9471 §3.1). A nameserver in someone else’s zone — ns1.example-dns.net serving yourdomain.com — needs no glue, so nothing is reported about it either way. What is reported: an in-zone nameserver absent from the referral whose name does not resolve at all is a failure, because the lookup really is circular; one that does resolve by another route is a warning, because resolution works today but the parent is not publishing what it should. Three outcomes leave the card on a warning without any glue being missing: the name publishes no NS records, the domain has no parent to ask, or no parent answered. The first of those is usually not a fault at all — a name inside a zone, such as mail.example.com, has no nameservers of its own because the zone’s are published at its apex. Where the enclosing zone can be determined the card names it and suggests running the validator on that instead. A truncated referral is treated the same way — the truncation bit is exactly how a parent says the glue did not fit, so nothing can be concluded from it.
• Lame Delegation — resolves each NS hostname and queries its addresses directly, with recursion off, for the zone’s SOA, trying up to two IPv4 and two IPv6 addresses per nameserver. A server that answers without authority, or with an SOA for some other name, is a lame delegation (RFC 1912 §2.8) and is an error; so is one answering REFUSED or SERVFAIL for the zone, which the card names by the code it sent. A server that never answers is a warning saying it did not answer, because silence is not evidence of a misconfiguration; a nameserver reachable only over IPv6, where this checker has no IPv6 route, says that instead. An NS hostname that resolves to no address is left to the NS Configuration check rather than counted twice.
• NS Configuration — warns when the zone publishes only one NS record, and reports any NS hostname that was looked up and has no address records at all. A hostname whose lookup did not complete is reported as that instead, as a warning, because it says nothing about the zone.
• MX Configuration — checks each MX record’s preference value is within 0 to 65535, flags a target written as a real IP address literal, flags a target that is neither a hostname nor an address as exactly that, flags a target that turns out to be a CNAME, and reports targets that do not resolve — a null MX, whose target is the single dot naming no host at all (RFC 7505 §3), is excluded. Several records sharing one preference value is not reported: that is the protocol’s own load sharing, where a sender must randomise between equally preferred destinations to spread the load across multiple mail exchangers (RFC 5321 §5.1).
• TXT Records — looks only at the TXT records on the domain itself. A record’s character-strings are concatenated without separators before anything is matched (RFC 7208 §3.3), so a value split across strings is judged as the one value it is. A record counts as an SPF record when its value begins with a version section of exactly v=spf1, terminated by a space or by the end of the record and matched case-insensitively (RFC 7208 §4.5); a value that merely mentions “spf” somewhere else does not qualify. It reports more than one such record, an SPF record whose total passes the 512 octets RFC 7208 §3.4 asks it to stay within, a single character-string over the 255-octet limit of RFC 1035 §3.3.14 (which a correctly split record never hits), an SPF record with neither an all mechanism nor a redirect modifier, and any TXT record over 2048 octets. It says nothing about DKIM: a key record lives at a selector under _domainkey, a name this check never queries.
• Oversized Responses — queries the domain for an A record with a 4096-byte EDNS buffer. It warns when the answer passes 512 bytes, and separately reports a failure when the truncation bit is set; a single answer can do both at once.
• UDP Fragmentation — repeats that A query at EDNS buffer sizes of 512, 1232 and 4096 bytes, reporting truncation at any of them and warning when the largest answer passes the 1500-byte threshold it compares against.

Two consequences of the input handling are worth stating plainly. A leading www. is stripped, so www.example.com is validated as example.com — these checks are about the zone, and the zone is what a www host lives in. And the TXT check reads only the TXT records on that name, so a _dmarc or DKIM selector name is never visited on its own, even though such names are valid input elsewhere on the site.

Each check lands on one of three statuses. Pass means nothing was found to report. Warning means something is worth a look but is not itself broken — a single nameserver, an SPF record with no default mechanism, an answer over 512 bytes. Fail means an error-severity issue: a lame server, an MX record pointing at a CNAME, a truncated response. One card can carry both at once — an answer over 512 bytes that was also truncated raises the warning and the failure together. The Overall Status at the top is the worst case across the seven: any failure makes it a failure, otherwise any warning makes it a warning.

A failure is not always your zone

Several of these checks depend on reaching third-party servers from this one. A check that could not complete reports that it could not complete, and that is a different fact from a misconfiguration: a parent nameserver that refused the probe, a nameserver that stayed silent, or an NS hostname whose own resolution failed in the moment all surface as warnings that say so, never as a red failure against your zone. Only something this tool actually observed — a server answering without authority, a target that resolves to nothing — makes a card fail. Read the detail text under each card rather than the status alone, and re-run before acting on a single reading.

Configuration is not the same as what resolvers are serving

This report describes the zone as it answers now. If you have just changed the records being reported on, caches elsewhere are still holding the previous answer for the rest of their TTL, so the internet at large and this page can legitimately disagree for a while. Our propagation checker shows what public resolvers are actually returning, which is the other half of the picture. If the zone is signed, note that nothing here inspects signatures; that is what the DNSSEC validator is for.

• A nameserver is reported lame. Either it is genuinely not configured for the zone, or the NS record is left over from a provider you have stopped using. Configure the server to be authoritative or remove it from the NS set at both the registrar and the zone; a resolver that picks a lame server may wait for a timeout before trying another. A card saying a nameserver did not answer is a different statement: it was asked and stayed silent, which may be a firewall between it and this checker rather than anything wrong with your zone.
• Glue is reported missing. This only arises when a nameserver’s hostname is inside the zone it serves, and it is fixed at the registrar rather than in the zone file, usually under “host records” or “private nameservers”. A pass means a parent’s referral was read and carried an address for every in-zone nameserver — except where the card says the glue could not be verified, which means no referral was read at all.
• An MX record is flagged. A target that is a CNAME or a bare address is invalid under RFC 2181 §10.3 and RFC 1035 §3.3.9 even where mail currently still gets through; point MX records at a hostname with its own A or AAAA records.

Responses are large or truncated

Oversized and truncated answers usually mean the apex is carrying more than it needs to: long TXT records, many MX or NS records, or signature data. The mechanics are old and well specified. A message carried by UDP is restricted to 512 bytes, not counting the IP or UDP headers; longer messages are truncated and the TC bit is set in the header (RFC 1035 §4.2.1). EDNS(0) lets a requestor advertise a larger UDP payload size, carried in the OPT record’s CLASS field (RFC 6891 §6.2.3, STD 75, obsoleting RFC 2671). A client that receives a response with TC set takes that flag as an indication that it should retry over TCP instead (RFC 7766 §4), and all general-purpose DNS implementations must support both UDP and TCP transport — authoritative servers must support TCP, so response size is not limited to what fits in one UDP packet (RFC 7766 §5, which updates RFC 1035 and RFC 1123).

So truncation is normal protocol behaviour rather than an error in itself. It becomes a failure where TCP to the server does not work. The buffer sizes this tool probes with — 512, 1232 and 4096 bytes — and the 1500-byte figure it compares the largest answer against are this tool’s own choices for surfacing that, not standardised values. Trimming what the apex answers with is still worth doing where you can.