DNS Security Extensions: Chain of Trust

## What "Chain of Trust" Means in DNSSEC DNSSEC validation is built on a single foundational assumption: resolvers trust the DNSSEC public key of the DNS Root Zone. Everything else follows from that trust anchor via a cryptographically verifiable chain of delegation. If the chain is intact from the root to your domain, a validating DNS Resolver can be certain your DNS (Domain Name System) data was not tampered with. If any link in the chain is broken, the resolver returns SERVFAIL. Understanding the chain of trust is essential for anyone deploying DNSSEC, because it is the chain — not any individual zone's configuration — that actually produces validated responses. A perfectly signed zone with a broken DS record at the parent is indistinguishable from an attack, as far as the resolver is concerned. ## The Root Zone Trust Anchor The chain begins at ICANN's root zone. ICANN operates the root with a KSK (Key Signing Key) that was generated in a highly audited ceremony and is published publicly. The current root KSK has key tag 20326 (as of 2017, replacing the original 19036). This public key is embedded in all major validating resolver software: ```bash # View the root trust anchor in Unbound grep trust-anchor /etc/unbound/unbound.conf # Or check the managed key file cat /var/lib/unbound/root.key # The root KSK DNSKEY record dig DNSKEY . @a.root-servers.net +short ``` Every validating resolver — BIND, Unbound, systemd-resolved, OS resolvers — ships with this trust anchor. It is the only key that must be pre-configured. Every other key in the DNS hierarchy is validated by working up to the root. ## Layer 1: Root Zone → TLD The root zone signs NS records for every TLD delegation AND publishes DS records for every DNSSEC-signed TLD. For `.com`: ```bash # DS record for .com in the root zone dig DS com. @a.root-servers.net # DNSKEY record for .com (published by Verisign) dig DNSKEY com. @a.gtld-servers.net +short ``` When a resolver encounters a referral to `.com`, it: 1. Retrieves the `.com` DNSKEY record 2. Retrieves the DS record from the root zone 3. Hashes the `.com` DNSKEY and compares to the DS digest 4. Validates the root zone's RRSIG over the DS record using the root KSK 5. Now the `.com` DNSKEY is trusted The DS record format contains four fields: key tag, algorithm number, digest type, and the digest itself (a hash of the DNSKEY). ``` com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CFC41A5766 ``` ## Layer 2: TLD Zone → Second-Level Domain The same mechanism repeats one level down. When Verisign's `.com` zone contains: ``` example.com. 86400 IN DS 31406 8 2 F78CF3344F72137235098ECBBD08947C2C9001C7F6A085A17F518B5D8F6B916D ``` ...and the `.com` zone's RRSIG over that DS record can be verified using the trusted `.com` KSK, then the resolver can trust the `example.com` KSK whose hash matches the DS. ```bash # Check DS record for a domain at the TLD level dig DS example.com @a.gtld-servers.net # Check the corresponding DNSKEY in the domain's own zone dig DNSKEY example.com @ns1.example.com +short ``` To verify manually: hash the `example.com` DNSKEY and compare to the DS digest. `dnssec-dsfromkey` does this: ```bash # Generate DS from a DNSKEY record echo "example.com. IN DNSKEY 257 3 8 AwEAAZ0aqu1r..." | dnssec-dsfromkey -f - example.com ``` ## Layer 3: Zone Signing (ZSK and KSK Roles) Within each signed zone, the KSK (Key Signing Key) and ZSK (Zone Signing Key) play distinct roles: **KSK** (flags field = 257): - Its hash appears in the parent zone's DS record - It signs only the DNSKEY RRset within the zone - It is kept offline or in an HSM for security - Rolled infrequently (every 1–3 years) **ZSK** (flags field = 256): - Signs all other RRsets in the zone (A, MX, TXT, NS, etc.) - Kept online (the signing server needs it) - Rolled frequently (every 30–90 days) ```bash # View DNSKEY records for a domain, note the flags field dig DNSKEY example.com +short # 256 3 13 oJMRESz5... ← ZSK (flags=256) # 257 3 13 mdsswUyr... ← KSK (flags=257) # The RRSIG over the DNSKEY RRset is signed with the KSK dig RRSIG example.com DNSKEY +short ``` Every other RRSIG in the zone is signed with the ZSK. The resolver trusts the ZSK because it is in the DNSKEY RRset, which is signed by the KSK, whose DS is in the parent zone. ## What Breaks the Chain **Expired RRSIG**: Signatures have validity windows (inception and expiration timestamps). If the zone's signing automation fails to re-sign, RRSIGs expire and the resolver rejects answers. Check: `dig RRSIG example.com A +short` and inspect the expiry date. **DS mismatch**: The DS record at the parent does not match any published DNSKEY in the child zone. This happens during key rollovers that were not executed correctly, or after transferring a domain to a new registrar without re-submitting DS records. **Algorithm mismatch**: The DS record specifies a different algorithm than the DNSKEY. Algorithm numbers are standardized (8 = RSA/SHA-256, 13 = ECDSA P-256 SHA-256, 15 = Ed25519). **Missing DS record**: The child zone is signed but no DS record exists in the parent. The resolver treats the zone as unsigned (insecure delegation), bypassing validation entirely. This is not a validation failure — the resolver accepts unsigned answers — but it means DNSSEC provides no protection. ```bash # Diagnose chain issues # Check if AD bit is set (authenticated data) dig example.com A +dnssec # Get detailed validation trace (with Unbound) unbound-host -d -v example.com # Use online tools # https://dnsviz.net — visual chain-of-trust diagram # https://dnssec-analyzer.verisignlabs.com ``` ## Negative Trust Anchors (NTA) When a zone has a broken DNSSEC chain and the operator cannot fix it immediately (e.g., waiting for a registrar to update the DS record), some resolvers allow temporary Negative Trust Anchors — an instruction to bypass validation for a specific domain. In Unbound: `unbound-control insecure_add example.com` This should be used only as a temporary emergency measure while the underlying chain issue is corrected. NTAs remove the security guarantee of DNSSEC for the named domain. For a deeper look at DNSSEC operational practice including key rollovers and zone signing workflows, see DNSSEC Deep Dive: Signing, Validation, and Troubleshooting. For self-hosted signing using Nameserver software, see Running Your Own DNS Server: BIND vs PowerDNS. DNS Record Helper