What the DNS module tests on your zone: name-server resilience, address records, CAA, SOA hygiene, open zone transfers and routing security – with scoring and concrete fixes.
Check your domain →
Last updated: September 2026 · 20 checks documented
Number of authoritative name servers #
Multiple name servers provide resilience for DNS resolution. If the only NS goes down, the entire domain (web + mail) is offline. RFC 2182 §5 is explicit: “The DNS specification and domain name registration rules require at least two servers for every zone” — and it advises more, because a zone with two listed servers is running on one as soon as either is unavailable.
Ratingpass with ≥ 2 name servers; warn with exactly one (single point of failure); fail with none, or when a delegated name server has neither an A nor an AAAA record of its own and both lookups came back conclusively — a resolver that looks that name up cannot reach it (an address that exists only as glue in the parent zone is the exception). This check deliberately avoids the phrase “lame delegation”: RFC 9499 §7 records that the term has drifted from its original meaning, is no longer specific or clear, “should be considered historic and avoided in favor of terms that are specific and clear” — and it lists both a non-resolvable name server and a server that answers without the authoritative-answer flag among the uses it has drifted to. Whether the reachable servers answer authoritatively is measured separately, under the direct queries to the zone’s name servers. Weight 2.
How to fix itRun at least two name servers – preferably separated by network/location (RFC 2182).
Name servers with an IPv6 address (AAAA) #
An IPv6-only resolver can reach a zone only if its name servers have AAAA addresses. This check reads the AAAA records of the delegated name servers — it opens no connection, so it shows publication, not reachability: an address that is published but not answering on port 53 still passes here. No RFC requires AAAA on authoritative name servers, and this is not scored as a violation; the converse is what is standardised, in RFC 3901 (BCP 91) §4: “every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server”, so that an IPv6-only delegation does not fragment the name space.
Ratingpass if at least one name server publishes an AAAA record; warn when at least one AAAA lookup came back conclusively and no name server has one; skipped (“not measurable”, no deduction) when not a single AAAA lookup for the name servers was conclusive — a failed lookup of ours is not a missing record. The value line reads as “with AAAA / measured”: the denominator is the set of name servers whose AAAA answer was conclusive, not the number of name servers. Weight 1.
How to fix itConnect at least one name server over IPv6 as well.
Name server addresses (routability & reverse DNS) #
Two address-level hygiene checks for the authoritative name servers (Zonemaster ADDRESS01 and ADDRESS02, as of 2026-08 — explicitly not ADDRESS03, which compares the PTR hostname against the name server’s own name; this check does not require that). First, every name-server IP must be globally routable – a private/reserved/bogon address (e.g. an RFC 1918 address left in the glue) cannot be reached from the public internet and breaks resolution for outside clients. Second, each IP should have forward-confirmed reverse DNS (FCrDNS): a PTR record whose hostname in turn resolves back to the same IP. FCrDNS on a name server is a best-practice hygiene signal, not a security control.
Ratingfail (weight 2) if any name-server address is not globally routable (private/reserved/bogon). Otherwise a green check (good, not graded) when every address has forward-confirmed reverse DNS, and info when one or more addresses lack a confirmed PTR – the latter is best practice only and is not penalised, since it carries no security weight and large anycast operators frequently omit it. Forward-confirmation is tracked four ways: confirmed, measured-and-absent, not determined, and not looked up at all — a reverse lookup of ours that gave no conclusive answer (including REFUSED, common on reverse delegations) counts as the third and never as a missing PTR, and the fourth is a limit of the scan rather than of the resolver: the reverse lookups are optional work, so once the scan’s time budget for this section is spent they are not sent, and the report says so instead of naming a result. Neither of the two can lower the grade, and the green check requires every address to have been measured. The drill-down lists the name-server IPs that were checked — the first eight name servers by name, up to four addresses per family each and 32 in total — with their routability, PTR and forward-confirmation result. The counts in the verdict refer to that sample.
How to fix itUse only public, globally routable addresses for authoritative name servers. Optionally add a PTR record for each name-server IP whose hostname resolves back to that IP.
Zone transfer (AXFR) exposure #
AXFR (RFC 5936) is the DNS mechanism that copies an entire zone from a primary to its secondary name servers. RFC 5936 §5 leaves the access decision to the zone administrator — it opens with “A zone administrator has the option to restrict AXFR access to a zone” and asks a general-purpose implementation to be able to serve AXFR to anyone — but it also says such an implementation “SHOULD NOT have a default policy for AXFR requests to be ‘open to all’”, and NIST SP 800-81r3 recommends restricting transfers to the designated secondaries. So an open AXFR is not a protocol violation; it is a deviation from the recommended default with a real cost. A name server that answers AXFR to anyone lets a stranger download the complete zone – every hostname, sub-delegation and internal record – which is a classic information-disclosure / reconnaissance issue (Zonemaster NAMESERVER03). The scanner sends a real AXFR query over TCP/53 over both address families. The mechanism §5 names for granting access is the client’s source address (“An implementation SHOULD allow access to be granted to Internet Protocol addresses and ranges”, alongside key-based TSIG and SIG(0)), and a denial over IPv4 is no evidence of a denial over IPv6 — which is why both are probed rather than one. The probe is a stable sample, not full coverage: the first eight name servers by name, one address per family each, at most sixteen probes. Only the answer is classified; the zone contents are never stored.
Ratingfail (weight 2) if any name-server address returns zone data to the unauthenticated request. A green check (good, not graded) when every address that answered declined to hand over zone data. That is the measurement — “transfers are restricted to authorized secondaries” is the conclusion drawn from it, and the drill-down names the RCODE so the two can be told apart: REFUSED(5) is what access control looks like in practice and NOTAUTH(9) is one of the two codes RFC 5936 §2.2.1 note e) defines for an AXFR response, while FORMERR, SERVFAIL or NOTIMP disclose nothing either but say something about the request or the server rather than about a policy (note e) calls those generic errors, “not set as part of the AXFR-specific response processing”). Skipped in three situations, each of them a limit of the measurement and never a verdict: no name-server address answered on TCP/53 at all (e.g. filtered egress); every name-server address is one this scanner refuses to connect to; or every address accepted the connection and then ended it without answering — which is explicitly not “no route”, because the connections stood. The three are told apart in the text. An address that accepted the connection and then went silent without answering counts as neither refused nor open: our own silence is not the server’s refusal. The reported record count is the answer count of the FIRST response message, so it is a lower bound — the drill-down says “at least”. The drill-down lists the result per name-server address (IPv4 and IPv6), including addresses that were deliberately not contacted.
How to fix itRestrict AXFR to your designated secondaries only (allow-transfer / TSIG / firewall ACL), or disable it entirely if no secondary pulls from the server.
Name server distribution (RFC 2182) #
If all name servers share the same network/operator, the redundancy is only apparent – an outage there hits all of them at once. RFC 2182 therefore recommends topologically dispersed secondaries. The most useful signal observable from outside is the origin autonomous system (AS) each address is announced from — that is what Zonemaster CONNECTIVITY03 checks (“all IP addresses … are announced from different ASNs”). It is a proxy, not proof: two AS can belong to the same operator, or hang off the same upstream or internet exchange, and RFC 2182 §3.1 asks for topological and geographical dispersion “to minimise the likelihood of a single failure disabling all of them” — not for a number of AS.
RatingGraded primarily at the AS level: pass when the name servers resolve to at least two distinct autonomous systems; warn when they all sit in a single AS (weight 1). When all name servers belong to a recognised global anycast provider (Cloudflare, AWS Route 53, NS1, Google, Azure, Akamai, …), that single AS is announced worldwide from many locations, so in the routing sense this check measures it is not a single point of failure and it is reported as info instead of warn. The provider itself stays one shared dependency — a fault in its control plane or configuration can reach every location at once, and no external check sees that. That exemption runs off a curated list of name-server host names, so an operator that is not on the list is graded as clustered even when it announces from many locations worldwide; the finding names that limit where it hands out the warn, because a caveat is only as complete as the list it comes from. The AS lookup covers both address families and counts the union of the origin AS across them. That is a deliberate deviation from Zonemaster CONNECTIVITY03 (as of 2026-08), which grades IPv4 and IPv6 separately and requires both to pass, and it is the weaker rule: a second AS that exists only under IPv6 does nothing for a resolver that speaks IPv4 only. Where the second AS exists only across the families — neither IPv4 nor IPv6 carries more than one on its own — the finding says so and names the AS per family. It still passes, because a dual-stack resolver really does survive a routing failure in either AS and that is really measured; what is withdrawn there is the claim that no single routing failure can take the zone offline, since a resolver speaking one family sees one AS. The network proxy below is deliberately not unioned across families, and that is not a contradiction: a v4 /24 and a v6 /48 of one machine are the same site counted twice, whereas two origin AS are two routing domains whichever family announces them. AS grading begins once at least two name servers resolved to an autonomous system, and that need not be all of them — a lookup can fail, and a name server without an address of its own is never asked. Where some are missing, the value counts the measured name servers instead of all of them, the finding names the ones it left out, and the grade stays put: the servers that were measured really do sit where this says they do, and taking weight away for a partial measurement is how a report that measured less ends up scoring better. When AS-level data is unavailable, the check falls back to the coarser network proxy, graded per family (IPv4 /24 and IPv6 /48; pass when either family spans ≥ 2 distinct networks, warn when each family sits in a single one — a v4 /24 and a v6 /48 of the same site share fate and are never counted against each other). Informational when the distribution cannot be graded at all — that is, when fewer than two name servers had an autonomous system determined (the lookup can also simply fail) and no address family has two or more addresses across at least two name servers; skipped rather than informational when the NS lookup itself returned no conclusive answer, because there was then no name-server list whose distribution could be graded, and a count of zero would be a measurement nobody took. A single name server with two addresses therefore stays informational: a second address is not a second server, and RFC 1034 §4.1 requires a zone to be available on at least two of them. The drill-down lists each name server with its IPv4 and IPv6 address(es), autonomous system(s), /24 and /48 networks and detected anycast provider.
How to fix itDistribute name servers across different autonomous systems (ideally different providers or a secondary DNS service).
IP addresses (A / AAAA) #
The A record points to the web server’s IPv4 address, the AAAA record to its IPv6 address. IPv6 support is increasingly expected — without AAAA, an IPv6-only client depends on a translation service to reach the site at all (NAT64/DNS64, RFC 6146/6147, the normal case on mobile networks), and where none is deployed it is shut out; internet.nl grades IPv6 in a test category of its own. The drill-down shows up to eight addresses (the first four of each family, the remainder filled up from whichever family has more) with their reverse DNS (PTR). The PTR column is three-valued: a name, “no PTR record” only when the reverse lookup was conclusive, and “could not be determined” otherwise — a REFUSED answer, common on reverse delegations, counts as the third and never as a missing PTR. Where an address has several PTR names, the extras are summarised as “+N more”.
Ratingpass if an AAAA (IPv6) record is present – including IPv6-only domains, with or without an A record; warn with IPv4 only (no IPv6); info if no address records exist at all (e.g. www-only setups). Weight 1. Knowledge of the two families is tracked separately: records that came back prove themselves, but every ABSENCE statement (“no AAAA”, “no address records at all”) needs a conclusive answer for that family, and without one the check is skipped rather than graded — including the recommendation, since “add IPv6” told to a domain whose AAAA lookup merely failed is advice that gets acted on.
How to fix itSet an A record (or ALIAS/ANAME) and an AAAA record to the server’s addresses.
CNAME at the zone apex #
RFC 2181 §10.1 says a name holds either one CNAME or other records, never both — the only exception it names are DNSSEC records at an alias, and RFC 4035 §2.5 narrows that to RRSIG and NSEC, which is why an apex CNAME collides with DNSKEY as well. The apex must carry SOA and NS, so an apex CNAME creates a contradictory zone: it collides with those two and with every other record type at that name — MX, TXT and the DNSSEC records. Address resolution itself follows the CNAME, which is why the problem often shows up as broken mail or broken DNSSEC rather than as a site that does not load. The usual fix is a provider feature (ALIAS/ANAME/CNAME flattening) — a vendor mechanism, not a standard. An RFC 9460 HTTPS 0 target. record is not a substitute: §2.4.2 says operators will likely need to keep fallback A and AAAA records alongside it for clients that do not query type 65, and Appendix C.3 calls apex address records necessary for as long as such clients matter — operational advice rather than an RFC 2119 requirement, and C.3 expressly lets operators drop them once that traffic becomes negligible.
Ratingfail (weight 2) – only shown when the scanned name is the registrable domain (zone apex) and actually has a CNAME. A CNAME on a hostname such as www.example.com is a perfectly normal alias (CDN setup) and is not penalized. Apex-ness is decided against the Public Suffix List, so a name directly under a multi-label suffix (user.github.io, example.pages.dev) counts as an apex — it is one. Where the list gives no answer — it is not bundled, or the scanned name is itself a public suffix and therefore has no registrable domain — this scan’s own zone detection decides instead. If that detection also failed, the finding is not emitted: a weight-2 failure is not asserted on a guess, and its absence then means “not established”, not “fine”.
How to fix itReplace the apex CNAME with regular A/AAAA records, or use your DNS provider's ALIAS/ANAME/CNAME-flattening feature, which serves real addresses at the apex.
DNAME at the zone apex #
A DNAME record (RFC 6672) redirects a whole subtree: every name below its owner is answered from the corresponding name below the target, while the owner itself keeps its own records (§2.3: "the owner name of a DNAME is not redirected itself"). At a zone apex that is legal – unlike a CNAME – and typical for a domain that has moved its hostnames under another name. It also means nothing can be published directly below the apex any more: such records are occluded (§2.4), and a CNAME at the same name is forbidden.
Ratinginfo (weight 0) – shown only when the scanned name is the registrable domain (zone apex) and publishes a DNAME. Not graded: whether the redirect is intended is not something a scan can tell. A failed lookup makes no claim.
How to fix itNothing to fix if the redirect is intended. Check that the target zone holds the hostnames you expect (www, mail, autodiscover, …), since the names below your apex are no longer answered from your own zone.
HTTPS record (SVCB, RFC 9460) #
A DNS HTTPS record announces protocol support (alpn=h3,h2) during name resolution: Chrome and Firefox connect via HTTP/3 (QUIC) on the very FIRST request instead of discovering it via Alt-Svc – provided the browser’s own resolver returned the record – and both treat its presence as an https-upgrade signal that saves the initial cleartext request. It is not an authenticated one: RFC 9460 §9.2.2 states that HTTPS records “do not require or provide any assurance of authenticity”, and §9.5 that clients must trust the signal no further than a 307 redirect received over cleartext HTTP. DNSSEC authenticates the record towards a validating resolver, but the assurance a browser acts on comes from the TLS connection — so this is not a substitute for HSTS. The record can also carry a port, which moves the connection target away from 443 (§7.2), and an ech parameter — an Encrypted ClientHello configuration (RFC 9848). Browsers that support ECH encrypt the server name in the TLS handshake, so an observer on the network no longer sees which of the names behind a shared front-end is being visited; §8 of that RFC is explicit that the protection reaches only that anonymity set and “does not conceal the server name from the DNS resolver”.
Ratinglight-green check (good, weight 0) when present; info when absent – the record is an optional optimization, not a security requirement. One published form is info rather than a benefit: an AliasMode record whose TargetName is the root (HTTPS 0 .) announces the absence of a service instead of a shortcut to one, because RFC 9460 §2.5.1 gives it exactly that meaning — the service “is not available or does not exist” — and the next sentence makes the indication advisory, so clients may ignore it and connect anyway. If the type-65 lookup returns no conclusive answer, the check is skipped instead of reporting “not set”, and no advice to publish one is given either. An AliasMode record (priority 0) takes precedence over every ServiceMode record in the same RRset (§2.4.1). Mandatory keys are named: port and no-default-alpn are mandatory automatically (§9), and a client that does not implement every mandatory key ignores the record completely — for that client the https upgrade does not happen either (§8, §9.5). A record that breaks the rules of §2.2 (truncated inside a SvcParam, keys not in strictly increasing order, a key repeated) is reported as published-but-unreadable rather than as absent, because §2.2 has clients reject the whole RRset and fall back to a plain connection. Where several ServiceMode records share the lowest priority, the report says so and picks deterministically — an RRset is an unordered collection (§2.4.1) and answer order varies between lookups.
How to fix itPublish HTTPS 1 . alpn=h3,h2 (service mode, target . = same name) for the domain and www; only list h3 if the server actually offers HTTP/3.
RPKI (Route Origin Validation) #
RPKI cryptographically signs which autonomous system (AS) may originate an IP prefix in BGP (ROA = Route Origin Authorization). Networks that enforce Route Origin Validation then drop announcements which contradict the ROA. It is not a guarantee against hijacking: RFC 7115 (BCP 185) §7 states that “RPKI-based origin validation is expected to deal only with inadvertent mis-advertisement”, because the origin AS of an update is not itself signed, and that origin validation “does not address the problem of AS_PATH validation”. Checked via the public RIPEstat API.
Ratingpass with RPKI "valid" (ROA present, announcement authorized); info with "unknown" (no ROA) – common and controlled by the hosting/network provider, so it does not lower the grade; fail with "invalid" (announcement conflicts with an existing ROA). Weight 1. RPKI is checked on the addresses of the scanned name, so if the address lookup returned no conclusive answer there is no route to validate: the check is then shown as not measurable instead of disappearing from the report — a shorter list reads like “nothing to report here”. The same applies when the data source itself does not answer: if RIPEstat gives no usable reply for any checked address family, the entry reads “not testable”. Both are a skip, and a skip leaves the grade entirely — points and denominator alike — so the weight plays no part in either case. When only ONE address family could be determined, the verdict keeps its grade and its weight — the measured half genuinely holds, and dropping the weight would let a scan with less measurement score better — but the sentence names the family that stayed unmeasured and says it covers the other one only. Any inconclusive reply from RIPEstat is a failed request, never “no ROA”: an HTTP error, an answer carrying no prefix or AS, and a validation status we cannot read all read as “not testable”, and none of them is cached. A name that conclusively has no addresses keeps the entry hidden; there is genuinely nothing to check.
How to fix itHave the network operator/hosting provider create a valid ROA for the IP prefix (sign with RPKI).
Mail servers (MX records) #
MX records name the servers that accept email for the domain — and an empty MX RRset does not mean the domain accepts none. RFC 5321 §5.1: “If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.” So a domain that publishes address records but no MX still receives mail, on those very addresses. Only a Null MX record (0 ., RFC 7505) declares the intent to receive none.
Ratingpass when MX records are present, a Null MX included — publishing one is a valid, complete statement; warn when a Null MX (preference 0 pointing at the root) is published alongside real MX records, which RFC 7505 §3 forbids — and equally when a record points at the root with a preference other than 0, which the same section defines out of existence: the Null MX is preference 0 with a zero-length label, so such a record declares nothing and names no reachable host (the Mail server TLS & DANE section says the same about it); skipped when the MX lookup gave no conclusive answer, because “no mail servers” would then be a claim we did not measure, and equally when the RRset was published but no record in it could be read, since an unreadable set is not an empty one; otherwise info. Weight 1. The info case covers two situations and the report tells them apart: with address records present the domain is its own mail exchanger (implicit MX) and the Mail server TLS & DANE section probes that host — unless its addresses belong purely to a CDN edge network, which this scanner does not connect to on port 25 because an address published as the domain's own A/AAAA record inside a CDN edge range was published for the website, not for mail; with neither MX nor address records nothing can be delivered at all. Note how the address records are read, which is this scanner’s own guard rather than anything RFC 5321 §5.1 says — the section governs when the implicit MX applies at all, not what to do when only one of the two address lookups answers: one family answering with addresses is enough to establish the implicit MX, while “no address records either” is said only when BOTH address lookups came back conclusively. Presence needs no completeness; absence does.
How to fix itIf the domain should receive mail, set MX records — leaving them out does not switch mail off, it points delivery at the domain’s own A/AAAA records instead (RFC 5321 §5.1). If it should receive none, publish a Null MX (0 ., RFC 7505): that is the only way to say so, and it is a different statement from having no MX record at all.
MX targets valid #
An MX record must point at a hostname with its own address records. RFC 5321 §5.1 puts it positively: the data field “MUST contain a domain name” and “that domain name, when queried, MUST return at least one address record”. An IP address written into that field is not such a name — there is nothing for a sending MTA to look up. RFC 2181 §10.3 adds that the target must not be an alias: “The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias.” The cost it names is that an alias is not resolved in the additional section, which “can cause extra queries, and extra network burden, on every query”; how a particular sender copes is not defined by the standard — RFC 5321 §5.1 says a value that returns a CNAME when queried "lies outside the scope of this Standard" — which is why this is a warning rather than a failure. A target without any A/AAAA record makes mail delivery impossible.
Ratingfail when an MX target is an IP literal, or when both its A and AAAA lookups came back conclusive and empty; warn when the target is a CNAME alias; pass when every target that could be looked up is a hostname with address records; skipped when none of the targets could be looked up at all. A target whose lookups gave no conclusive answer is neither OK nor broken: it shows as “not checked” in the table and is left out of the verdict. Weight 1. Up to four MX hosts are checked, lowest preference first; when the verdict is a pass, the text names the hosts that were not covered. Not applicable for a Null MX, and a root target with a preference other than 0 is reported here rather than treated as a host.
How to fix itPoint each MX at a plain hostname that has its own A/AAAA records – no IP addresses, no CNAMEs.
CAA records #
CAA defines which certificate authorities may issue certificates for the domain – this reduces the risk of mis-issuance/abuse. The records are parsed per RFC 8659: issue restricts regular issuance, issuewild wildcard issuance, iodef names an address a CA should send reports of rejected or unauthorized requests to — the CA/Browser Forum Baseline Requirements (§4.2.2.1) explicitly do not require CAs to act on its contents, so it is an extra signal rather than monitoring. Only issue and issuewild restrict anything: with no issue property present, CAA does not restrict issuance at all (RFC 8659 §3).
Ratingpass only when the effective CAA set contains an issue or issuewild property — those are the only tags that restrict TLS issuance (RFC 8659 §3), and the check looks at the tag, not at the value, so a deliberate total prohibition (0 issue ";") counts as a set policy and passes. A set built solely from iodef, contactemail/contactphone or issuemail starts at info like a missing set, but unlike a missing set it can still escalate to warn on the pitfalls below; info when absent – CAA is a hardening bonus, not a requirement, so a missing record does not lower the grade; skipped when the lookup gave no conclusive answer, because “no CAA records” would then be a claim about a security control we did not measure. Weight 1. For hostnames, the whole name tree is walked upwards and the first non-empty CAA RRset counts, as CAs do it (RFC 8659 §3). That walk is one query per level and is bounded by the scan’s time budget for this section: where it has to be cut short, the levels above the name were not asked, and the check is skipped with that reason named — never reported as “no CAA records set”. A present-but-misconfigured set warns on three pitfalls. First, a critical flag (128) on a Property Tag a TLS CA will not act on — §4.1 requires refusing ALL issuance for a critical tag a CA does not know or does not support, which covers unregistered tags, the three names IANA lists as Reserved (auth, path, policy) and registered tags outside the TLS namespace such as issuemail or issuevmc — Second, an issue or issuewild value that does not match the grammar of RFC 8659 §4.2, which must be treated like an empty issuer-domain-name: on an issue property that forbids issuance outright, renewals included; on an issuewild property it blocks wildcard issuance only, because §4.3 has issuewild ignored for names that are not wildcards. Third, more than one accounturi parameter on one property, which RFC 8657 §3 makes unsatisfiable, so that property authorizes nobody — at a CA that implements RFC 8657, which §5.2 says must be established beforehand — while a second, satisfiable issue property still permits issuance, because CAA authorizations are additive (RFC 8659 §4.2). Separately, issuewild without issue leaves non-wildcard issuance unrestricted (§4.3) and is pointed out without a deduction, because a set that carries no CAA at all is not graded either and doing more must never score worse than doing nothing. An issue property with an empty value is likewise not a restriction but a deliberate total prohibition (§4.2) — and it passes, because it is a policy, and the strictest one. Records that cannot be parsed are counted and listed rather than dropped, and no statement is made about what they contain; the advice names the most severe state found, not the first one checked.
How to fix itSet CAA records, e.g. 0 issue "letsencrypt.org", plus a 0 iodef "mailto:…" (or an https: URL) as an address for reports of unauthorized issuance attempts — CAs should send them but need not act on them. If you pin issuance further with RFC 8657 parameters (accounturi, validationmethods), confirm with your CA that it supports them: §5.2 says a domain must not assume the restriction is effective without an explicit statement from the CA; CA/Browser Forum BR §4.2.2.1.2 makes processing a SHOULD today and a MUST for publicly trusted CAs from 2027-03-15.
CAA for S/MIME (issuemail) #
The issuemail property (RFC 9495) restricts which CAs may issue S/MIME (email) certificates for the domain. It is independent of issue/issuewild, which govern TLS/other certificates only and do not cover S/MIME. An empty value – 0 issuemail ";" – forbids S/MIME issuance as long as no other issuemail property names a CA: CAA authorizations are additive, so an 0 issuemail ";" published beside 0 issuemail "certum.pl" still lets Certum issue (RFC 9495 §5.4) – a second malformed property changes nothing, because §4 reads a malformed value as the empty issuer-domain-name too. When no issuemail property is present at all, S/MIME issuance is not restricted by CAA (RFC 9495 §4). The value syntax is identical to issue (an issuer domain, optionally followed by ; parameters).
RatingNot a check of its own: issuemail is evaluated as part of the CAA finding, and this entry explains that part. Restricting S/MIME issuers is optional and specific, so it is not scored separately. A critical (flag 128) issuemail record is not called an unknown tag — it is registered with IANA — but it is still reported, and for the reason the warning exists: RFC 8659 §4.1 requires a CA to refuse all issuance for a critical Property Tag it does not know or does not support, and being registered does not make a tag supported. RFC 9495 §6 states the consequence for this tag: “If a Certification Authority does not understand the Property, then it MUST NOT issue the certificate in question.” The advice is therefore to clear the flag rather than delete the record — leave it at 0 unless every CA you use is known to understand issuemail. The CAA generator can build issuemail records, and “load current record” surfaces the S/MIME issuers.
How to fix itAllow only your S/MIME provider, e.g. 0 issuemail "certum.pl"; forbid S/MIME entirely with 0 issuemail ";". Keep the flag at 0 (non-critical) unless every CA you use understands issuemail.
SOA record (zone configuration) #
The SOA record marks the start of the zone; its absence indicates a faulty delegation. The negative-cache TTL (RFC 2308) is how long a resolver may remember “this record does not exist”, so a large value really does delay newly created records. It is not simply the last SOA field: RFC 2308 §3 sets it to the smaller of the MINIMUM field and the TTL of the SOA record itself, and that smaller value is what is graded here — the report names both whenever they differ, and falls back to MINIMUM alone when the answer carries no usable SOA TTL. §3 says a resolver may cache the negative answer for that long; §5 recommends resolvers cap their own negative cache — it names one to three hours as a sensible default and calls values exceeding one day problematic — so how long an individual resolver actually holds it is that resolver’s decision. One caveat in our favour: a recursive resolver hands us a TTL that has already been counted down, so the value we compute is a lower bound of the published one. The refresh/retry/expire timers, by contrast, only govern replication to secondaries that poll the primary (AXFR or IXFR); where nobody polls the zone that way – the usual case on API-driven managed DNS – they have no effect, and the numbers those providers publish do not follow the conventions below – measured 2026-08: Google publishes refresh 900 / retry 900 / expire 1800 for its own zones and 21600 / 3600 / 259200 as the Cloud DNS default, and Apple 300 / 300 / 3628800, all of which the conventions below would flag, while Cloudflare (10000 / 2400 / 604800) and Route 53 (7200 / 900 / 1209600) happen to sit inside them. They are not always inert, though: a managed zone can feed real secondaries by transfer (Cloudflare, for one, offers outgoing AXFR/IXFR), and a scan cannot tell from outside whether it does. Either way the zone works, so they are reported as informational notes rather than penalised.
Ratingpass when the SOA is present and the negative-cache TTL is sane; warn only on a negative-cache TTL above one day; fail if no SOA record exists — but only when the lookup was conclusive, otherwise the check is skipped. Skipped as well when an SOA is published whose fields cannot be read as a zone configuration: an unreadable record is a limit of this evaluation, not a healthy zone. The refresh/retry/expire relations, a negative timer value and a zero serial are shown as informational notes only (they matter solely for zone-transfer-based secondaries), each naming the source it comes from — RFC 1912 §2.2 (“must be greater than the minimum and retry intervals”, “2-4 weeks are suggested values”), Zonemaster ZONE05 for the comparison against refresh and against one week, and Zonemaster ZONE03 for retry against refresh; the two Zonemaster checks are conventions of that tool, not standards, and its specification is a moving target (test cases as of 2026-08). One historical note applies to the whole list: RFC 1912 predates RFC 2308 and still reads the last SOA field as a default record TTL, a meaning RFC 2308 §4 replaced with the negative-response TTL — the expire-versus-minimum comparison is therefore an inherited convention about the same wire field, not a rule derived from its present meaning. There is deliberately no lower bound on refresh or retry: the usual minimums would flag healthy managed-DNS zones such as google.com or apple.com. Weight 1.
How to fix itCheck that the zone delegation is correct. Keep the negative-cache TTL well under a day. Note what RFC 2308 §5 actually is: one paragraph addressed to resolver implementers about the ceiling they should put on their OWN negative cache (“Values of one to three hours have been found to work well and would make sensible a default. Values exceeding one day have been found to be problematic.”). It sets no target for the zone’s field — but the protocol permits caching “for up to 68 years” (RFC 2308 §5; the number is the 2^31−1 second ceiling of RFC 2181 §8). No major resolver honours anything close to it: BIND caps negative answers at three hours by default and silently truncates any configured value above seven days, Unbound at one hour, Knot Resolver at one day. A very large value is flagged here as configuration hygiene, not because a resolver would act on it. The lever is whichever of the two inputs is currently smaller: MINIMUM or the SOA record’s own TTL. Lowering the larger one changes nothing. The other timers only matter if you run traditional AXFR-based secondaries.
DNS queries (nothing measurable) #
This entry appears in place of the whole DNS section when not a single DNS query for the domain returned a conclusive answer. It exists so the report does not do the alternative: invent findings about a domain it never reached. Measured before this was introduced, a dead outbound path produced a full set of findings and grade F for a flawless domain — the graded substance was identical to a genuine "no such domain" answer.
Ratingskip, weight 0 — the module is reported as “could not be graded” rather than graded badly. Three cases are distinguished in the text. No answer at all (both resolvers unreachable from this scanner) also shortens the caching of this answer. If answers did come back but none was conclusive (SERVFAIL and the like), the SOA lookup is repeated once with DNSSEC validation switched off (CD=1): if the zone answers that, its records exist and its name servers reply — what fails is the DNSSEC chain, which is why a validating resolver answers SERVFAIL for the zone instead of handing out its records (RFC 4035 §5.5 — only a query that carries the CD bit still gets the full response, and CD is the validating client's own tool), and the report says so. If the repeat stays silent too, a broken chain is ruled out and what remains is failing name servers or trouble on our side — those two cannot be told apart from here, so no culprit is named. The verdict never moves: an answer obtained with validation disabled is not graded, because the refusal is what real visitors get.
How to fix itNothing to do if the scan was simply unlucky — repeat it. If the report names the DNSSEC chain, fix it there (the DNSSEC section of this report shows which link is broken); until then the zone does not resolve for validating resolvers.
Direct queries to the zone’s name servers #
Three checks in this section do not ask a public resolver but the zone’s own name servers, directly on port 53: whether each of them answers authoritatively for the zone, whether they agree with one another, and whether the delegation held by the parent zone matches the NS records published for the zone. The third one reads both sides directly on port 53 as well, and falls back to the resolver’s NS answer for the zone side only when the zone’s own name servers did not return one agreed set. This entry appears in their place in three situations, and it says which one: the queries did not finish within this scanner’s time budget of nine seconds and were abandoned; none of the zone’s name servers answered at all; or not one of them resolves to an address, so there was nothing to ask. A name server that refuses the query — or one that drops it while others still answer — is a different case: that one is reported inside the three checks themselves.
Ratingskip, weight 0. It exists so that three findings do not simply vanish from the report: measured on a healthy zone, all three are a pass, so losing them silently moves the score from 15/15 to 10/10 — the grade stays the same and the report merely says less. A shrinking report that keeps its grade is the hardest kind of gap to notice, so it is named instead.
How to fix itNothing to do if the scan was unlucky — repeat it. If it recurs, check whether the zone’s name servers answer queries on TCP/UDP port 53 from the public internet.
Name servers answer authoritatively #
Being listed in a delegation and actually serving the zone are two different things. This check asks each of the zone’s own name servers directly on port 53 — not a public resolver, whose cache would hide the difference — and looks at the AA (Authoritative Answer) bit of the reply, defined in RFC 1035 §4.1.1: “this bit is valid in responses, and specifies that the responding name server is an authority for the domain name in question section”. A server that answers without it is listed in the delegation but not configured for the zone; resolvers that happen to pick it lose a round trip, and some treat the whole zone as broken.
Ratingfail when at least one reachable name server answers without the AA bit, or when a name server answers with an error code instead of the zone’s data (REFUSED, SERVFAIL and the like) — such an answer says nothing about the records, only that this server will not, or cannot, serve the zone the delegation lists it for. pass when every name server that could be judged answers authoritatively. Weight 2. Servers whose answer could not be retrieved, and servers whose reply came back truncated, are not counted either way; the value line names how many name servers were judged, or how many answered with an error code. If the direct queries as a whole do not finish, this check is replaced by the “Direct queries” entry rather than silently dropped.
How to fix itConfigure the affected servers as authoritative for this zone, or remove them from the delegation. A server answering with an error code may not have the zone loaded, may be blocked by an access rule, or may be failing temporarily (SERVFAIL).
Name servers agree with each other #
Every authoritative server for a zone should serve the same zone. This check compares what the zone’s own name servers return for it — the NS records they publish, and the SOA serial that identifies the zone version they are on. If they disagree, the answer a visitor gets depends on which server their resolver happened to reach, and that is a live inconsistency in the zone rather than a caching effect.
Ratingfail when the name servers return different records. warn on two different situations, told apart in the text: the servers agree on the records but report different SOA serial numbers — usually a zone transfer still in flight, which resolves itself within minutes, and a secondary that is not receiving updates if it persists — or nothing could be compared at all, because every reply was an error or was truncated beyond retrieval. The second is not a clean result but the absence of one, and it used to be reported green: “same data, same zone version” over zero comparisons is the strongest possible claim on the least possible evidence. pass when the comparable servers return the same records and the same zone version; the value line says how many were compared. Weight 1.
How to fix itIf the records differ, find out which server is out of date — usually a secondary that no longer receives zone transfers, or a leftover server that should have been removed. Differing serials alone are worth a second look a few minutes later before acting.
Delegation matches the zone #
The name servers your registrar publishes in the parent zone and the NS records inside your own zone are two separate lists, and they can drift apart. Resolvers reach the zone through the parent's delegation, but they do not stay there: RFC 2181 §5.4.1 ranks the zone's own NS RRset above the parent's delegation records, so once a resolver has the authoritative answer it replaces the delegation in its cache and uses the zone's list. A server listed only at the registry is asked at least until then, even if you no longer run it; a server listed only inside the zone is asked as soon as the child NS RRset is cached. Both sides can receive real traffic, which is why the two lists have to agree. After a provider change this is the classic leftover. RFC 1034 §4.2.2 asks that both sides of the cut stay consistent — the text is from 1987 and words it as “should insure”, not as a duty: “The administrators of both zones should insure that the NS and glue RRs which mark both sides of the cut are consistent and remain so.”
Ratingfail when the parent delegation names a different set of name servers than the zone itself publishes; pass when both name the same set. Weight 2. The drill-down shows which side lists what. The comparison needs an answer from both sides, and both are asked directly on port 53: the parent side at one of the parent zone’s name servers, the zone side at the zone’s own name servers — the same direct answers the two checks above are built from. The zone side is only read from them when they agreed on one NS set and answered authoritatively; where they did not, the NS answer of this scan’s resolver is used instead, and the check says so in its text and in the drill-down row “Zone side read from”. Without an answer from the parent it is never decided on half the evidence, and the report distinguishes two ways of getting there: when none of the zone’s name servers answered at all, the “Direct queries” entry covers this check together with the other two that depend on them; when only the parent lookup failed, this check leaves a skip entry of its own that names what could not be read.
How to fix itAlign the name servers at your registrar with the NS records in the zone, or the other way round. Change one side first, verify, then the other — never both at once.