DNSSEC Records Table
| Record | Purpose | Key detail |
|---|---|---|
| DNSKEY | Public key for the zone | Used to verify RRSIG signatures; two types: KSK (key signing) and ZSK (zone signing) |
| RRSIG | Digital signature for a record set | Covers one record type at a time; has validity window (inception to expiration) |
| NSEC | Proves a record does not exist | Points to the next existing record; the chain proves what is absent |
| NSEC3 | Hashed non-existence proof | Like NSEC but hashes names to prevent zone walking |
| DS | Delegation Signer: links child zone to parent | Hash of the child DNSKEY stored in the parent zone - the chain of trust link |
DNSSEC adds cryptographic signatures to DNS responses, proving that the answer came from the authoritative nameserver and was not modified in transit. Five record types make this work: DNSKEY holds the public key, RRSIG holds the signature, NSEC/NSEC3 prove non-existence, and DS links the child zone to its parent in the chain of trust.
Without DNSSEC, any network operator between the resolver and the authoritative server can rewrite a DNS answer - redirecting traffic, intercepting email, or serving malicious content. With it, forgeries are detected because the RRSIG signature won’t verify.
How to use
- Filter by record type or purpose - keys, signatures, trust chain - to understand each role.
- Click any record type to copy it into DNS documentation or a configuration checklist.
- Read the chain-of-trust explanation in the note: root KSK → TLD DS → your domain’s DS → your DNSKEY.
Frequently asked questions
Does DNSSEC encrypt my DNS queries?
No - DNSSEC provides data origin authentication and integrity, not confidentiality. Your DNS queries are still visible to anyone on the network. For encryption, use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT), which are separate protocols that can be combined with DNSSEC.
What is the chain of trust?
The root zone’s DNSKEY is signed by the IANA root KSK (trusted by every resolver through pre-configuration). The TLD (.com, .org) stores a DS record in the root that hashes its DNSKEY. Your domain stores a DS record in the TLD. A resolver follows this chain downward, verifying each link - if any link fails, the response is marked bogus.
Why was NSEC3 introduced when NSEC already existed?
NSEC records chain from one existing name to the next, which means an attacker can walk the entire zone by following the chain - discovering every hostname. NSEC3 hashes the names before linking, so the chain proves non-existence without revealing the actual names. Some zones opt out of NSEC3 for performance reasons.
Why should I enable DNSSEC if nobody is attacking my DNS?
DNS attacks are not targeted at individuals - they are mass exploits at the resolver level. Enabling DNSSEC costs nothing at the DNS provider level (a checkbox in most panels) and protects every visitor to your domain from cache poisoning and DNS rewriting attacks that they cannot detect.