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: July 2026 · 14 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.
Ratingpass with ≥ 2 name servers; warn with exactly one (single point of failure); fail with none or a lame delegation (an NS with no A/AAAA). Weight 2.
How to fix itRun at least two name servers – preferably separated by network/location (RFC 2182).
Name servers reachable over IPv6 #
IPv6-capable name servers ensure resolution even for IPv6-only clients.
Ratingpass if at least one NS has an AAAA address; otherwise warn. 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-03). 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. The drill-down lists each name-server IP with its routability, PTR and forward-confirmation result.
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. It must be restricted to authorized secondaries. 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 to each name server over both address families (IPv4 and IPv6) — access control is per listener, so a server can refuse over one family while leaving the other open — and only classifies the answer; 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 reachable address refuses (REFUSED/NOTAUTH/FORMERR/empty). Skipped when no name server is reachable over TCP/53 from the scanner (e.g. filtered egress), so it is never reported as a false pass or a false failure. The drill-down lists the result per name-server address (IPv4 and IPv6).
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 strongest practical signal for shared fate is the autonomous system (AS): name servers in different AS do not share routing or operational fate (Zonemaster CONNECTIVITY03).
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, …), a single AS is announced worldwide and is NOT a single point of failure, so it is reported as info instead of warn. The AS lookup covers both address families, so a name server whose IPv4 is anycast-single-AS but whose IPv6 sits in a different AS is credited for that diversity. 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 fewer than two name-server addresses are resolvable. 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 reachability is increasingly expected (and required, e.g., by internet.nl) – without AAAA, IPv6-only clients are excluded. The drill-down shows IPv4 and IPv6 addresses with their reverse DNS (PTR).
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.
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 forbids a CNAME next to other data at the same name. The apex must carry SOA and NS records, so an apex CNAME creates a contradictory zone. Depending on the resolver this breaks mail delivery (MX lookups), DNSSEC, and sometimes resolution of the entire domain.
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.
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.
HTTPS record (SVCB, RFC 9460) #
A DNS HTTPS record announces protocol support (alpn=h3,h2) during name resolution: browsers connect via HTTP/3 (QUIC) on the very FIRST request instead of discovering it via Alt-Svc, and modern browsers treat the mere presence as an authenticated https-upgrade signal (especially with DNSSEC).
Ratinglight-green check (good, weight 0) when present; info when absent – the record is an optional optimization, not a security requirement.
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 announce an IP prefix via BGP (ROA = Route Origin Authorization). This protects against traffic to the server IP being redirected via route hijacking. 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.
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.
Ratingpass if MX records are present; otherwise info (the domain presumably receives no mail). Weight 1.
How to fix itIf the domain should receive mail, set MX records; otherwise consider Null MX.
MX targets valid #
An MX record must point at a hostname with its own address records. RFC 5321 §5.1 forbids IP address literals as MX targets, and RFC 2181 §10.3 forbids CNAME aliases – both confuse or break a substantial share of sending MTAs. A target without any A/AAAA record makes mail delivery impossible.
Ratingfail when an MX target is an IP literal or resolves to no address at all; warn when the target is a CNAME alias; otherwise pass. Weight 1. Checked for up to 4 MX hosts; not applicable for Null MX.
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 a reporting address for rejected requests.
Ratingpass if CAA is set; info when absent – CAA is a hardening bonus, not a requirement, so a missing record does not lower the grade. Weight 1. For hostnames, CAA inherited from the registrable domain also counts as pass – CAs climb the DNS tree per RFC 8659 §3. A present-but-misconfigured set still warns on two pitfalls: a critical flag (128) on an unknown tag (CAs that do not understand it must refuse ALL issuance, §4.1 – blocks renewals) and issuewild without issue (non-wildcard issuance then remains unrestricted, §4.3).
How to fix itSet CAA records, e.g. 0 issue "letsencrypt.org" and a 0 iodef "mailto:…" so you get notified of unauthorized issuance attempts.
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 entirely; when no issuemail property is present, S/MIME issuance is not restricted by CAA. The value syntax is identical to issue (an issuer domain, optionally followed by ; parameters).
RatingNot scored separately – restricting S/MIME issuers is optional and specific. Because issuemail is a registered CAA tag, a critical (flag 128) issuemail record is not treated as a critical-unknown tag. Note, however, that any CA which does not understand issuemail must refuse all issuance – including TLS – whenever the flag is critical (RFC 9495 §6), so leave the flag at 0 unless every CA you use is known to understand it. 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 last SOA field is the negative-cache TTL (RFC 2308) – how long EVERY resolver remembers "this record does not exist", so a huge value really does delay newly created records. The refresh/retry/expire timers, by contrast, only govern classic primary→secondary zone transfer (AXFR); anycast and API-driven managed DNS (Google, Cloudflare, Route 53, …) set them arbitrarily and work fine, 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. The refresh/retry/expire relationship and a zero serial are shown as informational notes only (they matter solely for zone-transfer-based secondaries). Weight 1.
How to fix itCheck that the zone delegation is correct. Keep the negative-cache TTL (last SOA field) around 1–3 h (RFC 2308 §5); the other timers only matter if you run traditional AXFR-based secondaries.