DNSSEC end to end: from the root's key to a validated answer

After reading, you can follow a DNSSEC validation from the root's trust anchor down to a signed answer, name the record that carries each link, and say why a resolver returned SERVFAIL, an ad flag, or nothing special at all. You will also know which root key is signing today, which algorithms the IANA registry still allows, and how to check a validation yourself with dig and delv.

View as Markdown

A Domain Name System (DNS) answer carries no proof of who produced it, and a resolver that accepts a forged one caches it for every client behind it; that is the opening cache poisoning exploits (see The Kaminsky DNS flaw). The DNS Security Extensions () sign the data itself to "add data origin authentication and data integrity to the Domain Name System" (RFC 4033, Abstract). Every signature is checked along a chain from one configured key, the root's, to the record you asked for. That chain is the subject: the records, the tests at each link, the four verdicts, the root key of today, the allowed algorithms, and the commands that show the result.

What DNSSEC gives you, and what it does not

DNSSEC protects data, not connections: it "is concerned with object security of DNS data, not channel security of DNS transactions", and the signing key belongs to the zone, not to its name servers (RFC 4033, section 3.1), so a signed record set survives any cache or forwarder. The services are origin authentication, integrity and authenticated denial of existence (RFC 4033, section 3). The omissions matter as much: "Due to a deliberate design choice, DNSSEC does not provide confidentiality" (RFC 4033, section 12); there is no access control, no protection against denial of service, and nothing for zone transfers or dynamic update (RFC 4033, section 4); and a validating resolver "may cause entire legitimate zones to become effectively unreachable due to DNSSEC configuration errors or bugs" (RFC 4033, section 12). 4033, 4034 and 4035 of 2005 are "the third iteration of the DNSSEC specification" after RFC 2065 and 2535, and RFC 9364, a Best Current Practice (BCP 237), names DNSSEC "the best current practice for adding origin authentication of DNS data" (RFC 9364, sections 2 and 1.1; see the DNS family history).

The four records, and the RRset as the unit of signing

Signing works on sets: "DNSSEC uses public key cryptography to sign and authenticate DNS resource record sets (RRsets)" (RFC 4034, section 2), an RRset being all records with one owner name, class and type, the grouping you see in a DNS answer for any of the record types. The four records are "Resource Record Signature (RRSIG), DNS Public Key (), Delegation Signer (DS), and Next Secure ()" (RFC 4033, section 3): DNSKEY (type 48) holds the zone's public key at the apex, RRSIG (46) one signature, NSEC (47) a proof of absence, and DS (43) sits on the parent's side of the delegation, as "authoritative data in the parent zone" (RFC 4034, section 5). Their RDATA (RFC 4034, sections 2.1, 3.1, 4.1 and 5.1):

Record	Field	Size	Meaning
DNSKEY	Flags	2 octets	Bit 7 Zone Key; bit 15 Secure Entry Point (SEP); bit 8 REVOKE (RFC 5011)
DNSKEY	Protocol	1 octet	Always 3
DNSKEY	Algorithm	1 octet	number
DNSKEY	Public Key	variable	Key material
RRSIG	Type Covered	2 octets	Type of the signed RRset
RRSIG	Algorithm	1 octet	As in DNSKEY
RRSIG	Labels	1 octet	Labels in the owner name; detects wildcards
RRSIG	Original	4 octets	Time to live in the zone
RRSIG	Signature Expiration	4 octets	Seconds since 1 January 1970
RRSIG	Signature Inception	4 octets	Same form
RRSIG	Key Tag	2 octets	Hint to the DNSKEY
RRSIG	Signer's Name	variable	The signing zone
RRSIG	Signature	variable	Over the RRSIG RDATA plus the canonical RRset
DS	Key Tag	2 octets	Of the child DNSKEY
DS	Algorithm	1 octet	Of the child DNSKEY
DS	Digest Type	1 octet	IANA number
DS	Digest	variable	Hash of the DNSKEY owner name and RDATA
NSEC	Next Domain Name	variable	Next name in canonical order
NSEC	Type Bit Maps	variable	Types at this name

Flags print as a decimal, "0, 256, and 257" (RFC 4034, section 2.2): 256 is Zone Key alone, 257 adds SEP. The key tag, a 16-bit sum over the DNSKEY RDATA, is not unique: "Implementations MUST NOT assume that the key tag uniquely identifies a DNSKEY RR" (RFC 4034, Appendix B), so a validator tries every matching key (RFC 4035, section 5.3.1). RFC 4033 counts four records; 's guide counts eight, adding (50), NSEC3PARAM (51), CDS (59) and CDNSKEY (60) (BIND 9 DNSSEC Guide, "What Does DNSSEC Add to DNS?"); the core four appear in DNSSEC records in dig output.

The chain of trust, link by link

"The typical authentication chain is therefore DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more DS->DNSKEY subchains" (RFC 4033, section 3.1). The first DNSKEY is a trust anchor, "A configured DNSKEY RR or DS RR hash of a DNSKEY RR" obtained outside the DNS (RFC 4033, section 2); each DS->DNSKEY pair crosses one delegation, the cuts dig +trace walks; the last DNSKEY signs the answer. The anchor must appear in its zone's apex DNSKEY RRset and verify an RRSIG over it (RFC 4035, section 5); then, at each delegation, "the child zone's apex DNSKEY RRset can be authenticated if all of the following hold" (RFC 4035, section 5.2):

"The DS RR has been authenticated using some DNSKEY RR in the parent's apex DNSKEY RRset";
"The Algorithm and Key Tag in the DS RR match the Algorithm field and the key tag of a DNSKEY RR in the child zone's apex DNSKEY RRset, and, when the DNSKEY RR's owner name and RDATA are hashed using the digest algorithm specified in the DS RR's Digest Type field, the resulting digest value matches the Digest field of the DS RR";
"The matching DNSKEY RR in the child zone has the Zone Flag bit set, the corresponding private key has signed the child zone's apex DNSKEY RRset, and the resulting RRSIG RR authenticates the child zone's apex DNSKEY RRset".

The DS RRset is signed; the delegating NS RRset and glue "MUST NOT be signed" (RFC 4035, sections 2.4 and 2.2).

KSK, ZSK and SEP. "Designating an authentication key as a key signing key is purely an operational issue: DNSSEC validation does not distinguish between key signing keys and other DNSSEC authentication keys" (RFC 4033, section 2). By convention a Key Signing Key (KSK) signs only the apex DNSKEY RRset and is what the parent's DS points to, a Zone Signing Key (ZSK) signs the rest, and one key for both is a "Single-Type Signing Scheme" (RFC 6781, section 3.1); the split keeps the KSK offline (RFC 4033, section 9) and lets a ZSK roll without the parent (RFC 6781, section 3.2). The SEP bit, set on KSKs by convention (hence 257 against 256), is likewise a hint: "validators MUST NOT alter their behavior during the signature validation process in any way based on the setting of this bit" (RFC 4034, section 2.1.1), and to a validator "zones can be signed by any key" (BIND guide, "Types of Keys").

Four verdicts, one SERVFAIL, and three bits

A validating resolver ends in one of four states (RFC 4033, section 5):

State	RFC 4033, section 5
Secure	"The validating resolver has a trust anchor, has a chain of trust, and is able to verify all the signatures in the response."
Insecure	"The validating resolver has a trust anchor, a chain of trust, and, at some delegation point, signed proof of the non-existence of a DS record. This indicates that subsequent branches in the tree are provably insecure."
Bogus	"The validating resolver has a trust anchor and a secure delegation indicating that subsidiary data is signed, but the response fails to validate for some reason: missing signatures, expired signatures, signatures with unsupported algorithms, data missing that the relevant NSEC RR says should be present, and so forth."
Indeterminate	"There is no trust anchor that would indicate that a specific portion of the tree is secure. This is the default operation mode."

RFC 4035 defines Indeterminate differently: "An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs" (RFC 4035, section 4.3); one text means a missing anchor, the other missing data, and both are the standard.

Secure answers carry the (Authenticated Data) bit; Insecure and Indeterminate ones do not, and the signalling does not tell those two apart (RFC 4033, section 5). Bogus is withheld: "the name server MUST return 2 to the originating client. However, it MUST return the full response if and only if the original query had the CD bit set" (RFC 4035, section 5.5). RCODE 2 is SERVFAIL, so a validation failure looks like a broken server.

The three bits divide the work. DO (DNSSEC OK), in the EDNS OPT record, says the resolver "is able to accept DNSSEC security RRs" (RFC 3225, section 3); a recursive server sets it upstream regardless and strips the DNSSEC records a client did not ask for (RFC 4035, section 3.2.1). CD (Checking Disabled), set by the resolver, tells the server to return data its own validation would reject (RFC 4035, section 3.2.2). AD, set by the name server, appears only if it "considers all RRsets in the Answer and Authority sections of the response to be authentic" (RFC 4035, section 3.2.3), and "A resolver MUST disregard the meaning of the CD and AD bits in a response unless the response was obtained by using a secure channel" (RFC 4035, section 4.6).

Proving that a name does not exist

NSEC lets a resolver "authenticate a negative reply for either name or type non-existence with the same mechanisms used to authenticate other DNS replies" (RFC 4033, section 3.2). The zone's names form a chain in canonical order, each NSEC naming the next and listing the types at its own name, the last pointing back to the apex (RFC 4034, section 4.1.1). A name matching an NSEC owner lacks whatever the bit map omits; a name falling between an owner and its Next Domain Name does not exist, once the validator also proves "that no possible wildcard RRset exists" (RFC 4035, section 5.4). The price is enumeration: "an attacker can query these NSEC RRs in sequence to obtain all the names in a zone" (RFC 4033, section 12).

NSEC3 (type 50) chains -1 hashes of the names instead, with flags, iterations and salt in the record, and its Opt-Out flag lets a large parent omit records for unsigned delegations (RFC 5155, sections 3, 3.1.2.1 and 11). In 2008 the advice was a salt of "at least 64 bits" and up to 2,500 iterations (RFC 5155, sections 12.1.1 and 10.3). RFC 9276, BCP 236, reversed it: "NSEC SHOULD be used in preference to NSEC3", "an iterations count of 0 MUST be used", "Operators SHOULD NOT use a salt", and for all zones "bcp.example. IN NSEC3PARAM 1 0 0 -" (RFC 9276, section 3.1), because the zone name already salts every hash (RFC 9276, section 2.4). BIND agrees: "Contrary to popular belief, adding salt provides little value" (BIND guide, "NSEC3 Salt").

The root's trust anchor today

"The Root Key Signing Key (KSK) acts as the trust anchor for DNSSEC for the Domain Name System" (IANA, Trust Anchors and Rollovers). IANA publishes it as root-anchors.xml, in the format of RFC 9718, with validFrom and validUntil attributes bounding each key's use (RFC 9718, sections 2.2 and 3.1). The two valid anchors on 13 October 2026:

Key	Key tag	Algorithm	Digest type	IANA's status
KSK-2017	20326	8	2	"Post-Publication"; "Signed between 2018-10-11 and 2026-10-11. Remains a valid trust anchor."
KSK-2024	38696	8	2	"Active"; "Signing since 2026-10-11."

Algorithm 8 is /SHA-256, digest type 2 is SHA-256, both carry Flags 257, and in DS form they are ". IN DS 20326 8 2 E06D44B80B8F1D39A95C0B0D7C65D08458E880409BBC683457104237C7F8EC8D" and ". IN DS 38696 8 2 683D2D0ACB8C9B712A1948B27F741219298D0A450D612C483AF444A4C0FB2B16" (RFC 9718, section 2.3; root-anchors.xml). The rollover, as IANA lists it under "Expected Date":

Event	Expected date	IANA's description
Publication of KSK-2024	11 January 2025	"KSK-2024 was introduced in the DNS root zone."
RFC 5011 Trust of KSK-2024	10 February 2025	"KSK-2024 should begin to be trusted by resolvers that follow the mechanisms described in RFC 5011."
Rollover to KSK-2024	11 October 2026	"KSK-2024 is now signing the zone; KSK-2017 is no longer signing the zone. Validating resolvers must have updated trust anchors to continue validating the root zone."
Revocation of KSK-2017	11 January 2027	"KSK-2017 is scheduled to be published in the root zone with the REVOKE bit set, allowing resolvers that follow RFC 5011 to revoke it as a trust anchor."
Removal of KSK-2017	22 March 2027	"KSK-2017 is scheduled to be removed from the root zone following its revocation."

(IANA, Trust Anchors and Rollovers.) The 11 October 2026 row fell two days before these pages were read; IANA states it as done, and that statement, not a query of the root zone, is the source here. One date disagrees: RFC 9718's Appendix B has the KSK-2017 anchor "first published on 2018-11-11", against validFrom 2017-02-02 in the XML and signing from 2018-10-11 on IANA's page; the sources read do not resolve this, and the dates here are IANA's (RFC 9718, Appendix B).

Resolvers keep up through updates, IANA's fetch-and-verify tool, or RFC 5011 (IANA, Trust Anchors and Rollovers), which "was used in 2018 to update the DNS root trust anchor" (RFC 9364, section 4). RFC 5011, Internet Standard 74, trusts a new SEP key only after a hold-down of 30 days or the key set's TTL, whichever is greater (RFC 5011, section 2.4.1), hence the 30 days between IANA's first two rows, and drops a key for good once it appears self-signed with the REVOKE bit, bit 8 of the Flags (RFC 5011, sections 2.1 and 3), the January 2027 row.

Algorithms and key rollovers, the operator's side

Since November 2025 the algorithm rules live in the IANA registry: RFC 9904 "moves the canonical source of algorithm implementation requirements and usage guidance for DNSSEC from RFC 8624 to the IANA DNSSEC algorithm registries" (RFC 9904, Abstract), and RFC 8624 is "(Obsoleted by RFC9904)" (RFC Editor index). RFC 9905 (SHA-1) and RFC 9906 (ECC-GOST) changed rows the same month. The registry on 13 October 2026 ("Last Updated 2026-08-10"), in RFC 9904's four columns (RFC 9904, section 2):

No.	Mnemonic	Use for signing	Use for validation	Implement for signing	Implement for validation
1	RSAMD5	MUST NOT	MUST NOT	MUST NOT	MUST NOT
3	DSA	MUST NOT	MUST NOT	MUST NOT	MUST NOT
5	RSASHA1	MUST NOT	RECOMMENDED	NOT RECOMMENDED	MUST
6	DSA-NSEC3-SHA1	MUST NOT	MUST NOT	MUST NOT	MUST NOT
7	RSASHA1-NSEC3-SHA1	MUST NOT	RECOMMENDED	NOT RECOMMENDED	MUST
8	RSASHA256	RECOMMENDED	RECOMMENDED	MUST	MUST
10	RSASHA512	NOT RECOMMENDED	RECOMMENDED	NOT RECOMMENDED	MUST
12	ECC-GOST	MUST NOT	MUST NOT	MUST NOT	MUST NOT
13	ECDSAP256SHA256	RECOMMENDED	RECOMMENDED	MUST	MUST
15	ED25519	RECOMMENDED	RECOMMENDED	RECOMMENDED	RECOMMENDED

(IANA, DNS Security Algorithm Numbers.) The remaining zone-signing algorithms (14, 16, 17, 18 and 23) are MAY to sign. Three are RECOMMENDED for signing, 8, 13 and 15, and "operators should choose the best algorithm according to local policy" (RFC 9904, section 3). SHA-1 shows the pattern: RSASHA1 "MUST NOT be used when creating DNSKEY and RRSIG records", yet validators "MUST continue to support validation using these algorithms" (RFC 9905, section 2). The DS digest registry ("Last Updated 2026-01-13") reads the same way: SHA-1 MUST NOT for new delegations yet MUST to implement for validation, SHA-256 RECOMMENDED (IANA, DS RR Type Digest Algorithms); and "users MUST upgrade the DS algorithm first before rolling to a new KSK" (RFC 9904, section 6).

Rollovers are delicate because old keys and signatures live on in caches (RFC 6781, section 4.1). For a ZSK, Pre-Publish has four stages ("initial", "new DNSKEY", "new RRSIGs", "DNSKEY removal"), the new key waiting at least one key-set TTL plus propagation time before it signs (RFC 6781, section 4.1.1.1); Double-Signature has three stages and doubles the zone's signatures meanwhile (RFC 6781, section 4.1.1.3). A KSK rollover adds a "DS change" stage and a wait of at least the old DS's TTL (RFC 6781, section 4.1.2). CDS (Child DS, type 59) and CDNSKEY (Child DNSKEY, type 60), published at the child's apex and signed with a key already in the DS, tell the parent "the desired contents of the zone's DS resource record set" (RFC 7344, sections 3 and 4.1); RFC 8078 made that Standards Track and defined "CDS 0 0 0 0" or "CDNSKEY 0 3 0 0" to mean the DS RRset must be removed (RFC 8078, section 4). Until the parent publishes the DS, "your zone still appears to be insecure" (BIND guide, "Uploading Information to the Parent Zone").

Seeing validation with dig and delv

nslookup "is not DNSSEC-aware"; dig "fully supports the DNSSEC standard" (BIND 9 DNSSEC Guide, "Using dig to Verify"). The guide's dig @10.53.0.1 ftp.isc.org. A +dnssec +multiline sets DO (the line reads "flags: do; udp: 4096") and returns "flags: qr rd ra ad": "The important detail in this output is the presence of the ad flag in the header", meaning the answer "has passed the validation process" (same section). The RRSIG returned, "ftp.isc.org. 300 IN RRSIG A 13 3 300 ( 20200401191851 20200302184340 27566 isc.org. ...)", reads algorithm 13, 3 labels, Original TTL 300, expiration, inception, key tag 27566 and signer (BIND guide, "How Are Answers Verified?"); with validation off the same query returns "flags: qr rd ra" and the same records, unchecked. The dig command builder composes such a query; the dig output explainer names each field.

Failure looks like a dead server, and the test is CD: "If the query succeeds with dig +cd, but ends in SERVFAIL without it, you know you are dealing with a validation problem", and "Do not be tempted to disable DNSSEC validation just because some names are failing to resolve" (BIND guide, "How Do I Know I Have a Validation Problem?"); www.dnssec-failed.org is set up to fail for that test (BIND guide, "Verifying Protection From Bad Domain Names"). delv validates by itself: delv @192.168.1.13 -a /tmp/example.key +root=example.com example.com. SOA +multiline prints "; fully validated" with a trust anchor you supply (BIND guide, "Verification"). One caution closes the loop: the ad flag is the resolver's verdict, and a stub "MUST NOT place any reliance on signature validation allegedly performed on its behalf" except over a secure channel to a trusted recursive server (RFC 4035, section 4.9.3).

What to remember

DNSSEC gives DNS data origin authentication and integrity, by design no confidentiality; the key belongs to the zone, not the server.
The RRset is the unit of signing: RRSIG signs it, DNSKEY verifies it, DS links parent to child, NSEC or NSEC3 proves absence.
The chain is DNSKEY->[DS->DNSKEY]*->RRset, and a DS link holds when algorithm, key tag and digest match a child DNSKEY that signs its own apex DNSKEY RRset.
KSK, ZSK and the SEP bit (257 against 256) are operational conventions; validators ignore them.
A validator ends Secure, Insecure, Bogus or Indeterminate; Bogus becomes SERVFAIL unless the query set CD, and AD means something only over a trusted path.
On 13 October 2026 the root's anchors are KSK-2017 (20326) and KSK-2024 (38696), algorithm 8, digest type 2; KSK-2024 signs since 2026-10-11, KSK-2017 is due for revocation on 11 January 2027 and removal on 22 March 2027.
The algorithm rules are the IANA registry's: sign with 8, 13 or 15, no new SHA-1 or ECC-GOST material, and NSEC3 only as "1 0 0 -".