DNSSEC Deep Dive: Signing, Validation, and Troubleshooting

## What DNSSEC Actually Does (and Doesn't Do) DNSSEC — DNS Security Extensions — solves a specific, well-defined problem: it lets a DNS resolver verify that the answer it received came from the authoritative source and was not tampered with in transit. It does **not** encrypt your DNS queries. That is the job of DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). DNSSEC is about data integrity and authentication, not privacy. Without DNSSEC, DNS (Domain Name System) responses travel as plain UDP packets with no cryptographic proof of origin. An attacker on the path between a resolver and an authoritative server — or one who has poisoned the resolver's DNS Cache (TTL) — can substitute a forged response pointing to their own IP. DNS Spoofing (Cache Poisoning) attacks of this kind can redirect users to phishing sites even when they type the correct domain name. DNSSEC closes this gap. ## The Key Types Involved DNSSEC introduces several new DNS record types. Understanding each one is essential before you can reason about the overall system. **DNSKEY** — Contains a public key used to verify signatures. A zone typically publishes two keys: a Zone Signing Key (ZSK) and a Key Signing Key (KSK). The ZSK signs individual resource records. The KSK signs the DNSKEY record set itself (and only that), creating a clean separation of duties. **RRSIG** — A signature record attached to every signed resource record set (RRset). It contains the signature value, which signing key was used, the inception and expiration timestamps, and the algorithm identifier. **NSEC / NSEC3** — Authenticated denial of existence. When a query returns NXDOMAIN, the resolver needs proof the name really does not exist. NSEC chains canonical names; NSEC3 hashes them to prevent zone enumeration. **DS** — Delegation Signer. This record lives in the *parent* zone and contains a hash of the child zone's KSK. It is the glue that stitches the chain of trust together across zone boundaries. Without a DS record at the parent, the child zone is unsigned from the resolver's perspective, regardless of how carefully the child is configured. ## How Zone Signing Works When you sign a DNS Zone File, a DNSSEC-aware authoritative server (or an offline signing tool like BIND's `dnssec-keygen` + `dnssec-signzone`) goes through every RRset in the zone and produces an RRSIG record for each one. A typical signing workflow with BIND looks like this: ```bash # Generate a ZSK (algorithm 13 = ECDSA P-256 SHA-256) dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE example.com # Generate a KSK dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE -f KSK example.com # Sign the zone (produces example.com.signed) dnssec-signzone -A -3 $(head -c 16 /dev/urandom | xxd -p) \ -N INCREMENT -o example.com -t example.com # Resulting files: example.com.signed, dsset-example.com. ``` The `dsset-example.com.` file contains the DS record(s) you must upload to your registrar or parent zone operator. That upload is the critical step that activates DNSSEC for your domain in the global chain of trust. Modern managed DNS Hosting providers (Cloudflare, NS1, Route 53) handle key generation and signing automatically and present a DS record for you to copy into your registrar's control panel. ## The Chain of Trust The chain of trust begins at the root zone. ICANN publishes the root zone's trust anchor — the public KSK of the root zone — and major operating systems and resolver software ship this key hardcoded. Every DNSSEC-validating DNS Resolver trusts this anchor implicitly. From there: 1. The root zone contains DS records for every signed TLD (`.com`, `.org`, `.io`, etc.) 2. Each TLD zone contains DS records for every signed second-level domain registered under it 3. Each second-level domain zone contains DS records for any signed subzones it delegates The resolver walks this chain upward until it reaches the trusted root anchor. At every step it verifies the RRSIG using the DNSKEY it already trusts, then uses the DS record to validate the next zone's KSK. If any link in the chain fails cryptographic verification, the resolver returns SERVFAIL — it refuses to hand the caller an answer it cannot authenticate. For a detailed treatment of how this chain is assembled, see DNS Security Extensions: Chain of Trust. ## Validating DNSSEC with dig The `+dnssec` flag tells `dig` to request DNSSEC records. The `+cd` (checking disabled) flag temporarily bypasses validation so you can see raw data even when things are broken. ```bash # Check whether a domain is signed and validated dig +dnssec example.com A # Look for the AD (Authenticated Data) flag in the response header # If AD is set, the resolver validated the chain successfully # Fetch the DNSKEY records dig +short DNSKEY example.com # Fetch the DS record from the parent TLD dig +short DS example.com @a.gtld-servers.net # Check NSEC3 records (denial of existence) dig +dnssec NSEC3PARAM example.com ``` If you see `SERVFAIL` and the `AD` bit is absent, something in the chain is broken. Common causes include expired RRSIG records (check the validity window with `dig RRSIG example.com`), a DS record at the parent that no longer matches the current KSK, or a key rollover that was not completed cleanly. ## Key Rollover Keys should be rolled periodically. The ZSK can be rolled more frequently (every 90 days is typical) because the process only requires updating signatures inside the zone — no parent interaction needed. The KSK rollover is more delicate: you must publish the new KSK DNSKEY, update the DS record at the parent, wait for the old DS to expire from caches (based on the parent zone's TTL (Time To Live)), and only then remove the old KSK. BIND 9.16+ and PowerDNS support automated key management (KASP — Key and Signing Policy) that handles rollover scheduling without manual intervention. ## Common Troubleshooting Scenarios **SERVFAIL on a previously working domain**: The RRSIG has expired. This happens when automated signing fails silently. Check `dig RRSIG example.com +short` for the expiration date. Resolution: re-sign the zone and ensure your signing automation is monitored. **SERVFAIL after changing registrars**: The old DS record was removed but the new registrar's DS was not submitted. The resolver sees a signed zone with no trust anchor at the parent. Resolution: submit the DS record at the new registrar immediately after transfer, before deactivating the old nameservers. **DNSSEC works with one resolver but not another**: Some resolvers implement stricter validation. Test against multiple resolvers and use DNSSEC debuggers like Verisign's DNSSEC Analyzer or dnsviz.net to visualize the chain. **Zone delegation broken after adding DNSSEC**: If you added Glue Record entries for your Nameserver hostnames but forgot to include their RRSIG, sub-resolvers may reject the delegation. Ensure glue records are included in the signed zone output. ## When to Use DNSSEC DNSSEC is strongly recommended for any domain that matters: banking, healthcare, government, SaaS products with login flows, and anything where DNS cache poisoning could cause real harm. It is increasingly required — the US CISA mandates DNSSEC for `.gov` domains; many ccTLD registries require it for enterprise registrations. The operational overhead is real but manageable with modern Managed DNS providers. The risk of getting it wrong (SERVFAIL for your entire domain) is also real, which is why understanding the mechanics — not just clicking "enable DNSSEC" — matters. For the chain-of-trust model that DNSSEC depends on, see DNS Security Extensions: Chain of Trust. For zone file management including Glue Record records used alongside signed zones, see Zone Files: Structure and Management. DNS Record Helper