The fix, in one snippet
dig +dnssec example.com | grep -E 'RRSIG|ad'Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now asks for the domain's DS record at the parent zone (published there by your registrar), the DNSKEY records at the zone itself, and then queries the domain's A record through a validating resolver with the DNSSEC OK bit set and reads the AD (authenticated data) flag on the answer. The check passes when a DS exists, a matching DNSKEY exists and the answer validates. It reports low severity when the zone is simply unsigned. It reports a distinct, higher-priority finding when a DS is published but validation fails (for example after a DNS-provider migration that left a stale DS behind), because validating resolvers, including Google Public DNS, Cloudflare 1.1.1.1 and Quad9, will then return SERVFAIL and the domain is unreachable for their users. The signing algorithm number is shown; RFC 8624 rates RSASHA1 (5 and 7) as not recommended and ECDSAP256SHA256 (13) and RSASHA256 (8) as the ones to use.
Why it matters
Plain DNS answers are unauthenticated UDP packets; an attacker who can inject a faster reply, or poison a resolver's cache, redirects your domain to a server they control. HTTPS limits the damage for web visitors because the impostor needs a certificate, but certificate authorities validate domain control by making DNS and HTTP requests, so DNS spoofing aimed at a CA's validation servers can yield a valid certificate for the impostor; DNSSEC closes that route when CAs validate signatures, which the major ones do. Email is more exposed still, since MX lookups have no certificate check at all. DNSSEC is also the foundation for DANE and for publishing SSH and TLS fingerprints in DNS. The trade-off is operational: a signed zone that breaks is offline for validating-resolver users, so it needs automation. Cloudflare, Route 53 and most registrars now sign with one click, which removes most of the historic risk. Related: caa-record, which limits which CAs may issue for the domain.
How to fix it
Enable signing at your DNS host, then publish the DS record it gives you at your registrar. Cloudflare: DNS > Settings > DNSSEC > Enable, then copy the DS record shown into the registrar's DNSSEC panel (if Cloudflare Registrar holds the domain, it adds the DS itself). The DS looks like:
example.com. IN DS 2371 13 2 1F987CC6583E92DF0890718C42E7D0DA4EBE0C7C7DCAB9F45B12F5E0A5C3E4B2Amazon Route 53: enable DNSSEC signing on the hosted zone with a KMS key, then create the DS at the registrar. BIND 9.16+ signs automatically with one line in the zone configuration:
zone "example.com" {
type primary;
file "example.com.zone";
dnssec-policy default;
inline-signing yes;
};Verify after the DS propagates (the ad flag should appear):
dig +dnssec example.com A | grep -E 'flags:|RRSIG'
delv @1.1.1.1 example.com AWhen moving DNS providers, remove the DS at the registrar, wait for the DS TTL to expire, migrate, then enable DNSSEC at the new host and publish the new DS. Doing it in the wrong order is the usual cause of the "signed but broken" state.
Where this fits
DNSSEC signing is check 6 of 8 that the website vulnerability scanner runs under dns and email authentication, ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits DMARC policy is p=none (monitoring only) (low), where the DMARC record exists but uses p=none, so receivers are asked to deliver spoofed mail normally. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
DNSSEC signing closes one route in. Immediately below it: DKIM selector discovered, where no DKIM public key was found under the common selector names, or the key found is weak or revoked; MX records, where a review of the domain's MX records: Whether mail is deliverable, whether every mail host resolves, and whether a domain that sends no mail says so with a Null MX.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Certificate chain and hostname validation, where the certificate presented for this hostname did not validate: The chain does not reach a trusted root, an intermediate is missing, the name does not match, or the certificate is self-signed or expired, and Exposed .env configuration file, where a .env configuration file is served from the web root. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: DNSSEC signing (low severity)
Scanner check id: dnssecThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.