On this page
01 What DNSSEC adds to DNS
DNSSEC, the DNS Security Extensions, is four record types and a validation procedure that let a resolver check where a DNS answer came from. RFC 4033 states the goal: origin authentication and integrity for DNS data, plus authenticated denial of existence. A validating resolver can tell that the answer for www.example.com was signed by the holder of the example.com zone key and arrived unaltered.
RFC 4034 defines the records. DNSKEY holds a zone's public key. RRSIG holds a signature over one record set (all the A records for one name, say) with the algorithm, key tag, inception and expiration. DS, the delegation signer, lives in the parent zone and carries a hash of the child's key; it is how trust crosses a delegation. NSEC, or its hashed form NSEC3 from RFC 5155, proves a name or type does not exist, so a forged NXDOMAIN fails like a forged address. In the lane on authenticity at the network layer every answer is a claim until something outside it confirms it; for DNS, that is this chain of keys.
02 The chain of trust from the root trust anchor
Validation starts from one key the resolver trusts without proof: the root zone key signing key, or KSK. IANA publishes it as root-anchors.xml with a detached signature. At the time of writing IANA lists KSK-2017 (key tag 20326) as active and KSK-2024 (key tag 38696) as pre-published, with a rollover scheduled for October 2026. A resolver holding only the old anchor fails after that.
Most zones split their keys. The KSK signs only the DNSKEY record set and is what the parent's DS points to. The zone signing key, or ZSK, signs everything else and can be rolled without touching the parent.
RFC 4035 names four outcomes: secure (every link verified), insecure (a proven unsigned delegation), bogus (a link failed) and indeterminate (no anchor covers the name). Bogus answers are dropped; the client sees SERVFAIL.
03 What a validating resolver proves, and what it does not
A secure result proves two things: the record set was signed by a key the chain vouches for, and the data is byte-identical to what was signed. It proves nothing about unsigned zones. If example.net is unsigned, its parent's NSEC record shows there is no DS, the result is insecure, and anyone on the path can still forge answers for it. Nor does DNSSEC encrypt; DNS over TLS (RFC 7858) and DNS over HTTPS (RFC 8484) hide the exchange and prove the resolver, not the data.
| Mechanism | Proves origin of the data | Proves data unaltered | Hides the query | Trust rests on |
|---|---|---|---|---|
| Plain DNS | No | No | No | First reply with a matching ID |
| DNSSEC | Yes, signed zones | Yes, from the zone | No | Root anchor and DS chain |
| DNS over TLS or HTTPS | No, only the resolver | Client to resolver only | Yes | Resolver's TLS certificate |
| Both together | Yes, signed zones | Yes, end to end | Yes | Both; the resolver must validate |
04 Checking DNSSEC validation with dig and delv
The quickest check is dig +dnssec, which sets the EDNS DO bit and asks for signatures back. Two things in the output matter: an RRSIG in the answer section and the ad flag in the header. RFC 4035 section 3.2.3 defines the AD (Authentic Data) bit: set only when every record set in the answer and authority sections validated as secure. The signature shows the zone is signed; the flag shows the resolver checked.
$ dig @192.0.2.53 www.example.com A +dnssec
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
; EDNS: version: 0, flags: do; udp: 1232
;; ANSWER SECTION:
www.example.com. 3600 IN A 203.0.113.10
www.example.com. 3600 IN RRSIG A 13 3 3600 (
20261010000000 20260920000000 51234 example.com.
kZ3v...Qw== )
$ delv @192.0.2.53 www.example.com A
; fully validateddelv, shipped with BIND 9, validates on its own from a built-in root anchor, so it works against any resolver. Its first line is the verdict: ; fully validated, ; unsigned answer, or a failure such as RRSIG has expired; +rtrace prints each step. dig +cd (checking disabled) returns data from a broken zone instead of SERVFAIL.
05 Worked example: validating one name by hand
Take www.example.com at 203.0.113.10, the zone signed with algorithm 13 (ECDSA P-256 with SHA-256) and a ZSK with key tag 51234. Query the root for com DS: the answer holds a SHA-256 digest and an RRSIG by the root ZSK, which delv +rtrace shows chaining up to anchor 20326.
Query com for example.com DS. Its digest must equal the hash of the example.com KSK; a stale digest left at the registrar after a key change fails here and the whole name goes bogus. Check the RRSIG over the example.com DNSKEY set with the KSK, then the RRSIG over the A record: algorithm 13, key tag 51234, valid from 20260920000000 to 20261010000000. The resolver's clock must fall inside that window.
06 Enabling validation on a resolver
Validation belongs on the recursive resolver, where the chain is walked and the flag is set. The steps suit Unbound or BIND; directive names differ, the sequence does not.
Install the root trust anchor
Fetch
root-anchors.xmlfrom IANA and verify its detached signature, or use the anchor your resolver package ships. Record the key tag and the date.Turn on automatic anchor updates
Enable RFC 5011 tracking (
auto-trust-anchor-filein Unbound,dnssec-validation autoin BIND) so the resolver learns the successor key and survives the root rollover.Enable validation and check the clock
Set validation on and confirm the host runs NTP. Signature times are absolute; a clock hours off makes every signed zone bogus.
Test a signed and a broken name
Query a name you know is signed and confirm
adis set, then a deliberately mis-signed public test zone and confirm SERVFAIL.Log validation failures and watch SERVFAIL
A jump in SERVFAIL after enabling validation is normally a stale clock, blocked EDNS packet sizes or expired signatures, in that order.
07 Signing a zone and the operational risks
Signing mirrors validation. Generate a KSK and a ZSK, sign every record set with the ZSK and the DNSKEY set with the KSK, add NSEC or NSEC3 records, publish, then hand the parent a DS through the registrar. Modern authoritative servers do this inline and re-sign on a schedule. RFC 9364 (BCP 237) collects the RFCs on algorithms, keys and rollover; read it before choosing parameters.
The risks are operational. An expired signature makes a zone vanish for every validating resolver while staying visible to the rest. A KSK roll needs the new DS at the parent before the old key retires. Zones that feed DNS-based traffic steering across sites add a twist: answers are built per query, so signing must happen on the fly or in a separately signed zone. The reverse zones for space announced by a backbone router at the core deserve the same care; a signed reverse tree is what makes a PTR check worth trusting.
DNSSEC answers for names what origin validation of BGP announcements answers for prefixes: not whether the data is good, but whether the party entitled to publish it did. Neither is worth anything unchecked.
08 Pitfalls: clocks, packet size, stale DS and false comfort
- A clock out of step. A resolver with a wrong clock marks good zones bogus; a signer with a wrong clock makes signatures not yet valid. Run NTP on both.
- Fragmented or blocked EDNS responses. Signed answers are larger. A path that drops UDP fragments or blocks TCP 53 turns a validating query into a timeout. Advertise a 1232-byte buffer and allow TCP.
- A stale DS at the registrar. Changing DNS providers or rolling the KSK without updating the parent's
DSbreaks the chain. Remove the oldDSonly after the new one has outlived its TTL. - Trusting the AD bit over an untrusted path. The flag is one bit in a UDP packet. A stub that trusts it across an open network trusts whoever can forge that packet. Validate locally or use DoT or DoH.
DNSSEC is one of three public verification systems in this lane. Certificate Transparency logs that make TLS issuance auditable answer the same question for certificates, and the SPF, DKIM and DMARC records a receiving edge checks on mail live in the very zone DNSSEC signs, which is why the two are usually deployed together.
09 Questions
Does DNSSEC encrypt DNS traffic?
No. DNSSEC signs data so a resolver can verify the origin and integrity of an answer; the query and response travel in clear. Encrypting the exchange is the job of DNS over TLS (RFC 7858) or DNS over HTTPS (RFC 8484), which stack with DNSSEC.
What does the ad flag mean in dig output?
The AD (Authentic Data) bit, defined in RFC 4035, is set by a validating resolver when every record set in the answer and authority sections validated as secure. It is the resolver's verdict, so it means something only if you trust the resolver and the path.
What is the difference between a KSK and a ZSK?
A key signing key signs the zone's DNSKEY record set and is the key the parent's DS record refers to. A zone signing key signs every other record set. The split lets operators roll the ZSK often without involving the parent.
What happens when a DNSSEC signature expires?
Validating resolvers return SERVFAIL for every name in the zone while non-validating resolvers keep answering, so the zone is partly unreachable and the operator often cannot see it from inside. Automated re-signing and a monitor on remaining signature lifetime prevent it.
How do I know my resolver is validating?
Query a signed name with dig +dnssec and look for the ad flag, then query a known-broken test zone and confirm SERVFAIL. Or run delv, which validates on its own from the root anchor and prints a verdict line either way.
DNSSEC turns a DNS answer from a claim into a record with a checkable origin. Install the trust anchor, enable validation, sign the zones you own and keep the signatures fresh; the chain does the rest.