DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS so a resolver can prove the answers it receives are genuine and unaltered. Plain DNS has no built-in way to tell a real answer from a forged one, which leaves it open to cache poisoning and on-path spoofing. DNSSEC does not encrypt anything and it does not hide your records; it authenticates them. If you only remember one idea, make it this: DNSSEC is about integrity and origin, not privacy.
The machinery rests on three record types that work together, plus one record that lives in your parent zone. Those three are DNSKEY, RRSIG, and DS, and understanding how they chain is the whole game.
The three records that do the work
| Record | Holds | Answers |
|---|---|---|
| DNSKEY | A public key for the zone | Which key signed these records? |
| RRSIG | A signature over a record set | Is this record set authentic? |
| DS | A hash of a DNSKEY, stored in the parent zone | Can I trust this zone's key? |
Every signed record set in your zone gets a matching RRSIG. The RRSIG is a signature produced with your private key over that specific set, for example all the A records for one name. A validating resolver uses the matching public DNSKEY to check the signature. If it verifies, the records are authentic and were not modified in flight.
Two keys: KSK and ZSK
Most zones use two key pairs rather than one, which sounds like extra work but makes operations far safer.
- The Zone Signing Key (ZSK) signs the ordinary records in your zone: your A, AAAA, MX, TXT, and so on. It is used constantly, so operators like to keep it shorter and rotate it often.
- The Key Signing Key (KSK) signs only the DNSKEY record set. It is the key your parent zone vouches for, so it changes rarely and can be kept longer and better protected.
The split means you can rotate the busy ZSK without ever touching the DS record in your parent, because the parent only commits to the KSK. That separation is why the two-key model is the near-universal default.
The chain of trust
A signature is only as good as the key that made it, so the real question is how a resolver decides to trust your DNSKEY in the first place. The answer is a chain that climbs from your zone to the DNS root.
Your parent zone (for example .com) publishes a DS record for your domain. The DS is simply a hash of your KSK. When a resolver is handed your zone, it fetches your DNSKEY, hashes the KSK itself, and checks that the result matches the DS the parent published. The parent's DS record is in turn signed by the parent's keys, whose DS sits in the root zone, whose keys are the one thing a resolver trusts outright: the IANA root trust anchor, shipped with the resolver.
- Resolver verifies the answer's RRSIG using your ZSK (a DNSKEY).
- It verifies that DNSKEY set using your KSK, also in your DNSKEY set.
- It hashes your KSK and confirms the hash equals the DS record in your parent zone.
- It checks the parent's DS RRSIG against the parent's keys, whose DS lives in the root.
- It reaches the root trust anchor it already trusts, and the chain is complete.
Break any link and validation fails safe: a resolver that cannot verify the chain returns SERVFAIL rather than a possibly forged answer. That fail-closed behavior is the point, but it is also why a broken DS record takes a domain offline for validating resolvers.
Seeing it with dig
Add +dnssec to ask for signatures, and look for the ad (authenticated data) flag in the header to confirm a validating resolver verified the chain.
$ dig cloudflare.com A +dnssec +short
104.16.132.229
104.16.133.229
A 13 2 300 20261101000000 20261030000000 2371 cloudflare.com. ...
$ dig cloudflare.com DNSKEY +short
257 3 13 mdsswUyr3DPW132mOi8V9xESWE8jTo0d... # flags 257 = KSK
256 3 13 oJMRESz5E4gYzS/q6XDrvU1qMPYIjCWz... # flags 256 = ZSK
$ dig cloudflare.com DS +short
2371 13 2 32996839A6D808AFE3EB4A795A0E6A7A39A76FC52FF228B22B8F8D9A ...In the DNSKEY output, flags 257 marks the KSK and 256 marks the ZSK. The 13 in each line is the algorithm number. The DS line shows the key tag (2371), the algorithm (13), the digest type, and the hash itself.
Algorithms: prefer ECDSA
DNSSEC supports several algorithms, identified by number. The modern recommendation is algorithm 13, ECDSA P-256 with SHA-256. Compared with the older RSA algorithms (such as 8, RSASHA256), ECDSA produces much smaller keys and signatures at equivalent security, which keeps responses small and reduces the risk of fragmentation or fallback to TCP. Algorithm 15 (Ed25519) is also excellent where supported. Unless you have a specific reason, choose 13.
Turning it on without breaking things
Enabling DNSSEC is a two-side operation: your DNS provider signs the zone, and your registrar publishes the DS at the parent. The order matters.
- Enable signing at your DNS host. It generates the KSK and ZSK and starts producing RRSIGs.
- Confirm the zone serves DNSKEY and RRSIG records and still answers normally.
- Copy the DS record (or the DNSKEY, if your registrar generates the DS for you) to your registrar.
- Wait for the parent zone to publish the DS, then verify the full chain validates.
The classic outage happens when the DS at the registrar no longer matches the live KSK, which occurs if you migrate DNS providers or roll the KSK without updating the DS. Always publish the new DS, let it propagate, and only then retire the old key. When moving providers, the safe path is often to remove the DS first, wait out its TTL to go insecure, migrate, re-sign, and add the new DS.
What DNSSEC does and does not give you
- It does: prove answers are authentic, detect tampering and cache poisoning, and provide authenticated denial of existence so a forged "no such record" can be caught.
- It does not: encrypt your DNS traffic, hide which names you look up, or protect against a compromised authoritative server that signs bad data with a valid key.
For privacy of the query path you want DNS over HTTPS or DNS over TLS, which are separate and complementary to DNSSEC.
Verify the chain before you rely on it
Because DNSSEC fails closed, a misstep is not a soft error; it can make your domain disappear for validating resolvers. After you sign a zone, roll a key, or move providers, confirm that the DS, DNSKEY, and RRSIG records line up and that the chain validates from multiple vantage points. You can check propagation and record consistency with the Valla DNS propagation checker, and the Valla DNS /learn/ guides on DS records, DNSKEY rotation, and SOA negative TTL go deeper on each moving part.