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.
Looking good
- Chain of trust intactThe parent’s DS record matches key 63608, which signs the zone’s key set.
- Validated end to endA validating resolver checked every signature from the root down and accepted them.
- Algorithm ECDSAP256SHA256 (13)Recommended for signing, and supported by every major validator.
- NSEC3 parameters follow RFC 9276No extra iterations, no salt.
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 |
|---|---|---|---|
| 63608 | ECDSAP256SHA256 (13) |
SHA-256 (2) e6a8a3179dae9bebb2e1dea43ba5fec67ee01efbe62e2e9c255ea2e42194fe99
|
key 63608, digest verified |
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 |
|---|---|---|---|---|
| KSK · trusted by DS | 63608 | ECDSAP256SHA256 (13) | 256-bit | RECOMMENDED |
| ZSK | 25915 | ECDSAP256SHA256 (13) | 256-bit | RECOMMENDED |
Signatures checked
| Covers | Signed by | Algorithm | Valid from | Valid until (UTC) |
|---|---|---|---|---|
| DNSKEY | 63608 | ECDSAP256SHA256 (13) | 2026-10-25 21:32 | 2026-11-08 23:02 |
| SOA | 25915 | ECDSAP256SHA256 (13) | 2026-10-26 13:11 | 2026-11-09 14:41 |
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.