DNSSEC
DNSSEC signs a domain’s DNS answers so a resolver can tell a real answer from a forged one. We check the chain from the registry down — and whether it is signed with algorithms the rest of the internet still accepts.
Errors
- No DNSKEY matches the DS recordThe DS at the parent names a key the zone does not publish, or one whose digest does not match. Validating resolvers will refuse to resolve the domain. This is the classic broken key rollover, or a move between DNS hosts without updating the DS.
- A validating resolver rejects this domainAsked normally, this server’s validating resolver returned SERVFAIL; asked with checking disabled, it returned records. That combination is a DNSSEC validation failure.
Worth knowing
- An out-of-date signature over DNSKEY is still published1 signature has expired or is not yet valid, alongside one that is current. Validators use the current one.
Looking good
- Algorithm ECDSAP256SHA256 (13)Recommended for signing, and supported by every major validator.
- NSEC for denial of existenceRFC 9276 prefers NSEC when NSEC3’s features are not needed.
DS records at the parent
Published by the registry. Each must name a key the zone publishes, by key tag, algorithm and digest.
| Key tag | Algorithm | Digest | Matches |
|---|---|---|---|
| 42069 | ECDSAP256SHA256 (13) |
SHA-256 (2) 62726f6b656e20636861696e206f662074727573742073656e642068656c7021
|
no matching key |
DNSKEY records
The zone’s public keys. The key-signing key (KSK) signs the key set and is what the DS points at; zone-signing keys (ZSK) sign everything else.
| Role | Key tag | Algorithm | Size | IANA guidance |
|---|---|---|---|---|
| ZSK | 32784 | ECDSAP256SHA256 (13) | 256-bit | RECOMMENDED |
| KSK | 50719 | ECDSAP256SHA256 (13) | 256-bit | RECOMMENDED |
Signatures checked
| Covers | Signed by | Algorithm | Valid from | Valid until (UTC) |
|---|---|---|---|---|
| DNSKEY | 50719 | ECDSAP256SHA256 (13) | 2026-03-04 22:57 | 2026-07-02 22:57 expired |
| DNSKEY | 32784 | ECDSAP256SHA256 (13) | 2026-10-21 22:52 | 2026-10-29 01:57 |
| SOA | 32784 | ECDSAP256SHA256 (13) | 2026-10-21 22:52 | 2026-10-29 01:57 |
Checked through 93.95.224.28, a validating resolver.
HOW TO READ THIS
What each part is forTwo halves, two places
The keys and signatures live with your DNS host. The DS record — a fingerprint of your key — lives at the registry, put there by your registrar. Both halves have to agree. Changing DNS host without updating the DS is the most common way a signed domain disappears.
Broken is worse than unsigned
An unsigned domain resolves everywhere; it just cannot prove its answers are genuine. A domain with a DS that does not match its keys fails to resolve at every validating resolver — Google, Cloudflare, Quad9 and most ISPs. That is why a mismatch is an error here and not signing at all is not.
Which algorithm
The IANA registry, the canonical source since RFC 9904, recommends ECDSAP256SHA256 (13) and ED25519 (15) for signing, with RSASHA256 (8) still recommended. RFC 9905 (2025) moved the SHA-1 algorithms (5 and 7) to MUST NOT. Changing algorithm is a key rollover your DNS host handles.
NSEC3 settings
RFC 9276 says NSEC3 must use zero extra iterations and should not use a salt — the recommended parameters are 1 0 0 -. Higher counts cost every resolver CPU without hiding names, and validators may treat them as insecure.
DNSSEC is also what makes DANE possible: a TLSA record in an unsigned zone protects nothing.