DNSSEC: Authenticating DNS Responses

In 2008, researcher Dan Kaminsky disclosed a critical attack against DNS resolvers. The attack exploited the small 16-bit transaction ID field in DNS responses. By flooding a resolver with forged responses containing random transaction IDs, an attacker could statistically succeed in matching the legitimate transaction ID before the real response arrived. A poisoned cache redirects all users of that resolver to attacker-controlled servers for weeks until the cache expires.

DNSSEC (DNS Security Extensions) adds cryptographic authentication to DNS responses. Every DNS record set in a DNSSEC-signed zone is accompanied by a digital signature. Validating resolvers check these signatures before accepting records. A forged or modified response will have an invalid signature and be rejected. DNSSEC protects against cache poisoning and response forgery but does not encrypt DNS queries.

DNSSEC uses a two-key hierarchy per zone. The Zone Signing Key (ZSK) is used for day-to-day signing of individual DNS record sets. The Key Signing Key (KSK) signs only the DNSKEY record set, which contains both the ZSK and KSK public keys. The ZSK can be rotated frequently (monthly) while the KSK changes less often (annually), because the KSK hash must be registered in the parent zone and rotation is operationally complex.

Every signed DNS record set (called an RRset) has a corresponding RRSIG record that contains the cryptographic signature over that RRset. When a resolver requests a DNS record, the response includes both the record and its RRSIG. The resolver verifies the RRSIG using the zone's public key. The signature covers the record content, type, class, and expiry time, preventing both modification and replay of old valid signatures.

The chain of trust in DNSSEC is built through Delegation Signer (DS) records. When a zone delegates to a child zone, the parent zone publishes a DS record containing a hash of the child zone's KSK. A resolver that trusts the parent can verify the child's KSK hash matches the DS record, establishing trust in the child zone's signatures. This chain extends from the DNS root zone down through TLDs to individual domain zones.

Every DNSSEC-signed zone publishes its public signing keys in DNSKEY records. There are typically two DNSKEY records: one for the ZSK and one for the KSK. The KSK's public key hash is registered as a DS record in the parent zone, anchoring the zone's trust to its parent. The root zone's KSK hash is hardcoded into validating resolvers as the ultimate trust anchor, called the Root Zone Trust Anchor.

DNSSEC validation starts at the root zone, whose KSK trust anchor is hardcoded in resolvers. The root zone's DNSKEY is used to verify its RRSIG, which authenticates the DS records for TLDs like .com. The .com zone's DNSKEY verifies its RRSIG on DS records for individual domains. This chain of cryptographic verification extends from the root to the queried domain, ensuring every link is authenticated.

When a DNSSEC-validating resolver receives a response, it performs the full chain of trust verification. It retrieves DNSKEY records, verifies RRSIG signatures, traces DS records up to the root anchor, and checks signature expiry times. If validation fails, the resolver returns a SERVFAIL error rather than the potentially forged records. Most major public resolvers including Cloudflare's 1.1.1.1 and Google's 8.8.8.8 perform DNSSEC validation.

DNSSEC deployment has been slow despite its security benefits. Key rollover requires coordination between zone operators and parent registries. A mistake during KSK rollover can make the entire zone unreachable. The 2019 ICANN root KSK rollover required years of preparation. Zone size increases significantly with signatures. Operators must implement automated key rotation and monitoring. These operational complexities have led many smaller domain operators to avoid DNSSEC.

A common misconception is that DNSSEC provides privacy for DNS queries. It does not. DNSSEC only authenticates responses; queries and responses still travel as plaintext UDP packets on port 53. Anyone monitoring the network can still see every domain name queried. DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) provide query privacy by encrypting the DNS traffic. DNSSEC and DoH/DoT are complementary: one provides authenticity, the other provides confidentiality.

As of 2024, approximately 90 percent of the DNS root zone and major TLDs are signed with DNSSEC. However, only about 20 to 30 percent of individual domain names are signed. Browser and application adoption of DNSSEC validation is uneven. The security benefit of DNSSEC is greatest when combined with DANE (DNS-Based Authentication of Named Entities), which uses DNSSEC to publish TLS certificate fingerprints and allows clients to verify certificates without relying solely on CAs.

How does a DNSSEC-validating resolver establish trust in a domain's DNS records starting from scratch?

DNSSEC adds cryptographic signatures to DNS responses to prevent cache poisoning and response forgery. ZSKs sign record sets; KSKs sign DNSKEY records; DS records chain trust between parent and child zones. Validation starts from the hardcoded Root Zone Trust Anchor. DNSSEC does not encrypt DNS traffic; DoH and DoT provide privacy while DNSSEC provides authenticity. Operational complexity including key rollover has slowed widespread adoption.