What is DNSSEC?
DNSSEC (DNS Security Extensions) cryptographically signs DNS answers. Every zone owns a key pair used to sign its records (RRSIG). The public key (DNSKEY) is anchored in the parent zone through a DS record, which in turn is signed by the parent, all the way up to the root zone. A validating resolver follows this chain and detects forged or tampered answers.
DNSSEC therefore protects against cache poisoning and DNS spoofing, attacks that silently redirect users to a foreign IP without the browser noticing. It is also a prerequisite for DANE, which lets mail servers publish their certificates via DNS.
The three states
The checker distinguishes three outcomes:
- Not signed: no DS record in the parent zone. The domain is reachable but unprotected. For most domains this is the normal state, not an error.
- Validated: DS record present and a validating resolver confirms the chain (AD flag set). Everything is correct.
- Bogus: DS record present but validation fails. Validating resolvers answer SERVFAIL. This is the critical case.
Why bogus is the most dangerous DNS error
If the DS record in the parent zone does not match the DNSKEY in the zone, or the signatures have expired, every validating resolver rejects the answer. Google Public DNS, Cloudflare, Quad9 and the resolvers of most ISPs validate. For their users the domain simply ceases to exist: no website, no mail, no subdomains.
The insidious part: the office computer often uses a resolver without validation, and there everything works. The problem only surfaces when clients call. Typical triggers are a hosting migration where the DS record stays at the registry while the new zone has no matching keys, or an expired key after an unfinished rotation.
What a DS record looks like
The DS record lives in the parent zone (for example.com that is the .com registry) and contains key tag, algorithm, digest type and the hash of the DNSKEY. A typical record with ECDSA P-256 (algorithm 13) and SHA-256 (digest type 2):
example.com. IN DS 2371 13 2 1F987CC6583E92DF0890718C42A5A1E64E4F3F1A9A5A3C4B7B8C2D3E4F5A6B7CEnabling DNSSEC and changing providers safely
Signing is almost always handled by the DNS host; you only need to place the DS record with your registrar. When changing DNS hosts the order matters: first remove the DS record at the registry, wait for the parent zone TTL to expire, then move the zone, and only then add the new DS record. If you leave the DS record in place and move the zone, the domain is bogus for hours or days.
- Before every DNS migration, check whether the domain is signed.
- Remove the DS record, wait for the TTL (often 24 hours at the registry), then migrate.
- After the migration add the new DS record and validate it with this checker.
- Prefer algorithm 13 (ECDSA P-256) over 8 (RSA): smaller answers, same security.
Monitor DNSSEC continuously
A domain never goes bogus on purpose. It happens during migrations, key rotations or when a host changes its signing setup. DomainWarn checks the DNSSEC chain of all client domains regularly, reports a broken state immediately as a critical incident and also notices when DNSSEC was switched off unnoticed.
Frequently asked questions
- Do I need DNSSEC at all?
- For a normal company website DNSSEC is optional; the domain works without it. It makes sense for domains using DANE for mail and wherever DNS manipulation is a realistic risk. What matters most is that a signed domain never becomes bogus.
- Why does my domain work for me but not for clients?
- That is the classic picture of a bogus domain: your resolver does not validate, theirs does. Check the DS record at the registry and the DNSKEY records in the zone. After a recent migration, removing and re-adding the DS record usually fixes it.
- How long until a DS record takes effect?
- The registry usually publishes it within minutes to a few hours. Resolver caches keep old answers until the TTL expires, so it can take up to a day until all users see the new state.