How DNSSEC Works: Securing the Domain Name System

The Domain Name System (DNS) is one of the most critical pieces of internet infrastructure. Every web request, email delivery, and API call depends on DNS to translate human-readable domain names into IP addresses. Yet DNS was designed in the 1980s with no built-in authentication. A resolver asking "what is the IP for example.com?" has no way to verify that the answer it receives is genuine. DNSSEC (Domain Name System Security Extensions) fixes this by adding cryptographic signatures to DNS records, allowing resolvers to prove that a response has not been forged or tampered with.

DNSSEC does not encrypt DNS queries (that is the job of DNS over HTTPS or DNS over TLS). Instead, it provides authentication and integrity -- it lets you verify that the answer you received actually came from the authoritative source and was not modified in transit.

Why DNS Needs Security

Traditional DNS is vulnerable to several attacks:

Cache poisoning -- An attacker injects forged DNS responses into a resolver's cache. All subsequent queries for that domain are directed to the attacker's server. The Kaminsky attack (2008) demonstrated that this could be done against any resolver in seconds.
Man-in-the-middle -- An attacker on the network path between a client and resolver (or between a resolver and authoritative server) intercepts and modifies DNS responses.
Pharming -- Users are silently redirected to fraudulent websites that look identical to the real ones, enabling credential theft and malware distribution.

Without DNSSEC, a resolver has no cryptographic means to distinguish a legitimate DNS response from a forged one. The resolver can check that the response matches the query (same transaction ID, same question section), but those fields are easily guessed or observed. DNSSEC eliminates this class of attack entirely.

The Chain of Trust

DNSSEC builds a hierarchical chain of trust that mirrors the structure of DNS itself. Just as DNS delegates authority from the root zone down through TLDs to individual domains, DNSSEC delegates cryptographic trust along the same path.

The chain works as follows:

Root zone -- The root zone is signed with a well-known key called the trust anchor. Every DNSSEC-validating resolver has this key built in. It was first published in 2010 and rolled over to a new key in 2018.
TLD zone -- The root zone contains a DS (Delegation Signer) record for each signed TLD. This DS record is a hash of the TLD's key-signing key, creating a cryptographic link from the root to the TLD.
Domain zone -- The TLD zone contains a DS record for each signed domain beneath it (e.g., .com holds a DS record for example.com). The domain's zone is signed with its own keys.
DNS records -- The domain's actual records (A, AAAA, MX, etc.) are signed with the zone's key. A resolver can verify the signature using the zone's public key, then verify that key using the parent's DS record, and so on up to the root.

If any link in the chain is missing or broken -- for example, a TLD does not publish a DS record for a domain -- then DNSSEC validation cannot proceed for that domain. The chain must be complete from root to leaf.

DNSSEC Record Types

DNSSEC introduces four new DNS record types that work together to provide authentication:

RRSIG (Resource Record Signature)

An RRSIG record contains the cryptographic signature for a set of DNS records of the same type. Every record set in a DNSSEC-signed zone has a corresponding RRSIG. When a resolver receives an A record, it also receives the RRSIG for that A record, allowing it to verify the signature.

example.com.  3600  IN  A      93.184.216.34
example.com.  3600  IN  RRSIG  A 13 2 3600 (
    20260501000000 20260401000000 12345 example.com.
    oJB7aNfYm7...base64-signature... )

The RRSIG contains: the algorithm used (13 = ECDSA P-256), the number of labels in the name, the original TTL, signature expiration and inception timestamps, the key tag identifying which DNSKEY signed it, the signer's name, and the signature itself. RRSIG records have expiration dates, meaning zones must be re-signed periodically -- typically every few days to weeks.

DNSKEY (DNS Public Key)

A DNSKEY record publishes the public key for a zone. Resolvers use this key to verify the RRSIG signatures on records within the zone. There are two types of DNSKEY, distinguished by their flags field:

Zone Signing Key (ZSK) -- flags = 256. Used to sign all the record sets in the zone. This is the key referenced by RRSIG records.
Key Signing Key (KSK) -- flags = 257. Used only to sign the DNSKEY record set itself. The KSK is the key whose hash is published as a DS record in the parent zone.

; Zone Signing Key (ZSK)
example.com.  3600  IN  DNSKEY  256 3 13 (
    base64-encoded-public-key... )

; Key Signing Key (KSK)
example.com.  3600  IN  DNSKEY  257 3 13 (
    base64-encoded-public-key... )

The separation between KSK and ZSK exists for operational reasons. The ZSK is used frequently (it signs every record set) and may need to be rotated more often. The KSK is used rarely (it only signs the DNSKEY set) and its rotation requires updating the DS record in the parent zone, which is a more involved process.

DS (Delegation Signer)

A DS record lives in the parent zone and contains a hash of the child zone's KSK. This is the glue that links one level of the chain of trust to the next. The root zone contains DS records for .com, .org, .net, and every other signed TLD. The .com zone contains DS records for every DNSSEC-signed .com domain.

; In the .com zone, pointing to example.com's KSK
example.com.  86400  IN  DS  12345 13 2 (
    a]4b5c6d7e8f...sha256-hash-of-KSK... )

The DS record contains: a key tag (a numeric identifier for the referenced DNSKEY), the algorithm number, the digest type (2 = SHA-256), and the digest (hash) of the child's KSK. When a resolver encounters a delegation to a signed zone, it retrieves the DS record from the parent and uses it to verify the child zone's DNSKEY set.

NSEC and NSEC3 (Authenticated Denial of Existence)

One of the harder problems DNSSEC solves is proving that a name does not exist. When you query for nonexistent.example.com and get an NXDOMAIN response, how can the resolver verify that the name truly does not exist, rather than an attacker suppressing the real answer?

DNSSEC solves this with NSEC and NSEC3 records. These records are covered in detail in a later section.

Zone Signing: How It Works in Practice

When a zone operator enables DNSSEC, the following steps occur:

Generate keys -- Create a KSK and ZSK keypair. Modern deployments typically use ECDSA P-256 (algorithm 13) or Ed25519 (algorithm 15) for compact signatures and fast verification.
Sign the zone -- Every record set in the zone gets an RRSIG record generated by the ZSK. The DNSKEY record set gets an additional RRSIG generated by the KSK.
Publish DNSKEY records -- The ZSK and KSK public keys are published as DNSKEY records in the zone.
Submit DS to parent -- A DS record (hash of the KSK) is submitted to the parent zone's operator. For a .com domain, this means submitting the DS record to the .com registry, typically through your domain registrar.
Re-sign periodically -- RRSIG records have expiration timestamps. The zone must be re-signed before the signatures expire, typically automated by the DNS software (BIND, Knot DNS, PowerDNS, etc.).

Many managed DNS providers (Cloudflare, Google Cloud DNS, AWS Route 53) handle all of this automatically. Enabling DNSSEC is often a single click in the dashboard, followed by adding a DS record at your registrar.

The Validation Process

When a DNSSEC-validating resolver (like Google's 8.8.8.8, Cloudflare's 1.1.1.1, or Quad9's 9.9.9.9) resolves a query for a DNSSEC-signed domain, it performs additional verification steps beyond normal DNS resolution:

Query the records -- The resolver queries for the desired record (e.g., A record for example.com) and receives both the record and its RRSIG.
Fetch the DNSKEY -- The resolver queries for the DNSKEY records of example.com's zone. It receives the ZSK and KSK, along with their RRSIG (signed by the KSK).
Verify the RRSIG -- Using the ZSK from the DNSKEY set, the resolver verifies the RRSIG on the A record. If the signature is valid and not expired, the record is authenticated.
Verify the DNSKEY set -- The resolver verifies the RRSIG on the DNSKEY set using the KSK.
Check the DS record -- The resolver fetches the DS record for example.com from the .com zone. It computes the hash of the KSK and compares it to the DS record's digest. If they match, the KSK is authenticated.
Walk up the chain -- The resolver repeats steps 2-5 for the .com zone (checking its DNSKEY against the DS in the root zone), and finally verifies the root zone's DNSKEY against the built-in trust anchor.

If every step succeeds, the response is marked as authenticated data (AD). If any step fails -- a signature is invalid, a DS record is missing, or a signature has expired -- the resolver returns a SERVFAIL error, refusing to provide an unverifiable answer.

This is strict by design. A validating resolver would rather return no answer than return one it cannot prove is authentic. This strictness is also why DNSSEC misconfigurations (expired signatures, mismatched DS records) can cause complete outages for a domain -- worse than having no DNSSEC at all.

NSEC: Proving Non-Existence

The original approach to authenticated denial of existence is the NSEC (Next Secure) record. Each NSEC record contains the next domain name in the zone (in canonical order) and a bitmap of the record types that exist at the current name.

alpha.example.com.  IN  NSEC  beta.example.com. A AAAA RRSIG NSEC

This record says: "The next name after alpha.example.com is beta.example.com, and alpha has A, AAAA, RRSIG, and NSEC records." If someone queries for anything-between.example.com, the resolver can return this NSEC record (with its RRSIG) to prove that no name exists between "alpha" and "beta" in the zone.

The problem with NSEC is zone enumeration. By walking the chain of NSEC records (query for alpha, get pointed to beta, query for beta, get pointed to gamma...), an attacker can enumerate every name in the zone. For many zone operators, this is unacceptable -- they do not want their full list of subdomains exposed.

NSEC3: Hashed Denial of Existence

NSEC3 (RFC 5155) solves the zone enumeration problem by replacing plaintext domain names with their cryptographic hashes. Instead of "the next name after alpha is beta," NSEC3 says "the next hash after H(alpha) is H(beta)," where H is a salted iterated hash function.

;; NSEC3 record (hashed names)
a1b2c3d4e5.example.com.  IN  NSEC3  1 0 10 aabbccdd (
    f6g7h8i9j0 A AAAA RRSIG )

The fields are: hash algorithm (1 = SHA-1), flags, iterations (number of additional hash rounds), salt, next hashed owner name, and the type bitmap. An attacker can see the hashed names but cannot easily reverse them to discover the actual domain names in the zone.

However, NSEC3 is not perfect. Because domain names are drawn from a limited space, offline dictionary attacks can reverse many hashes, especially for common subdomain names like "www", "mail", "api", and so on. Tools like nsec3walker and hashcat can crack NSEC3 hashes at high speed.

NSEC3 Opt-Out

Large TLD zones like .com contain millions of delegations, most of which are not DNSSEC-signed. Generating NSEC3 records for every unsigned delegation would massively inflate the zone. The opt-out flag allows NSEC3 records to skip unsigned delegations, covering only signed ones. This is essential for TLD operators where the majority of domains have not deployed DNSSEC.

Key Rollover

Cryptographic keys do not last forever. Keys can be compromised, algorithms can become weak, and operational best practices require periodic rotation. DNSSEC defines procedures for rolling over both ZSKs and KSKs, though they differ significantly in complexity.

ZSK Rollover

ZSK rollovers are relatively straightforward because the ZSK is only referenced within the zone itself (by RRSIG records). No parent zone changes are required. The most common approach is pre-publication:

Publish the new ZSK in the DNSKEY record set alongside the old one (both signed by the KSK).
Wait for the old DNSKEY RRset to expire from resolver caches (at least two TTL periods).
Start signing new and modified records with the new ZSK.
Once all RRSIG records generated by the old ZSK have expired, remove the old ZSK from the DNSKEY set.

ZSK rollovers are typically performed every one to three months and are automated by DNS software.

KSK Rollover

KSK rollovers are more complex because the KSK's hash is published as a DS record in the parent zone, requiring coordination with the parent operator (e.g., the TLD registry). The double-DS method works as follows:

Generate the new KSK and add it to the DNSKEY set. Sign the DNSKEY set with both old and new KSKs.
Submit the new DS record to the parent zone. At this point, the parent has DS records for both keys.
Wait for the old DS record to expire from caches.
Remove the old KSK from the DNSKEY set and request removal of the old DS from the parent.

The most significant KSK rollover in history was the root zone KSK rollover in October 2018. ICANN replaced the root zone's key-signing key -- the single key that anchors trust for all of DNSSEC. The process took over two years of planning and was delayed by a year due to concerns about resolvers that had not updated their trust anchors. Ultimately, the rollover succeeded with minimal disruption, thanks to RFC 5011 automated trust anchor updates implemented by most major resolver software.

Algorithm Rollover

The most disruptive type of rollover is an algorithm rollover, where a zone migrates from one cryptographic algorithm to another (e.g., RSA/SHA-256 to ECDSA P-256). During the transition, the zone must publish keys and signatures using both algorithms simultaneously, since some validators may not yet support the new algorithm. Algorithm rollovers are infrequent but necessary as cryptographic standards evolve.

DNSSEC Algorithms

DNSSEC supports multiple cryptographic algorithms, each identified by a number in the DNSKEY and RRSIG records:

Algorithm 8: RSA/SHA-256 -- Widely supported and still common. RSA signatures are large (typically 128-512 bytes), which increases DNS response sizes and can cause UDP fragmentation issues.
Algorithm 13: ECDSA P-256/SHA-256 -- Produces much smaller signatures (64 bytes) than RSA, reducing response sizes and fragmentation. Recommended for new deployments.
Algorithm 14: ECDSA P-384/SHA-384 -- Higher security margin than P-256 but larger signatures. Used by some government and high-security zones.
Algorithm 15: Ed25519 -- The newest standardized algorithm (RFC 8080). Very compact signatures, fast verification, and strong security properties. Support is growing but not yet universal.

Signature size matters for DNSSEC because DNS responses must fit within UDP packet size limits. Responses exceeding 1232 bytes (the recommended EDNS buffer size) may fall back to TCP, increasing latency. ECDSA and Ed25519 significantly reduce this problem compared to RSA.

Trust Anchors

A trust anchor is a DNSKEY or DS record that a validating resolver trusts without needing to verify it through the chain of trust. The most important trust anchor is the root zone's KSK, which is the starting point for all DNSSEC validation.

The root trust anchor is distributed with resolver software (BIND, Unbound, Knot Resolver, etc.) and through IANA's trust anchor publication. Its current key tag is 20326 (since the 2018 rollover). Resolvers that support RFC 5011 (Automated Updates of DNS Security Trust Anchors) can automatically track root key rollovers without manual intervention.

Organizations can also configure additional trust anchors for zones that are not connected to the global DNSSEC chain. This is sometimes done in enterprise environments where internal zones are signed but the parent zone (e.g., a ccTLD) does not support DNSSEC.

DNSSEC and Other Security Mechanisms

DNSSEC does not work in isolation. It complements other internet security technologies:

DNSSEC + DANE

DNS-Based Authentication of Named Entities (DANE, RFC 6698) uses DNSSEC to publish TLS certificate information in DNS via TLSA records. Instead of relying solely on Certificate Authorities, a server can publish the hash of its TLS certificate in DNS, secured by DNSSEC. Clients can then verify that the certificate presented during a TLS handshake matches what the domain owner published in DNS. DANE is widely deployed for email (SMTP) and growing for HTTPS.

DNSSEC + DNS over HTTPS/TLS

DNSSEC and DNS over HTTPS (DoH) solve different problems. DNSSEC provides authentication (proving the answer is genuine), while DoH provides confidentiality (hiding the query from observers). They are complementary: a validating resolver using DoH to communicate with clients provides both authenticity and privacy.

DNSSEC + RPKI

Both DNSSEC and RPKI use public key cryptography to secure internet infrastructure, but at different layers. RPKI secures BGP routing (ensuring IP prefixes are announced by authorized networks), while DNSSEC secures DNS (ensuring name resolution returns authentic answers). A complete security posture requires both: RPKI to ensure traffic reaches the right network, and DNSSEC to ensure it reaches the right server within that network.

Deployment Challenges and Current Status

DNSSEC adoption has been gradual and uneven. As of 2026, approximately 30-40% of global DNS queries are validated, and many major TLDs (.com, .org, .net, .se, .br, .nl) are signed. However, only a fraction of individual domains under those TLDs have deployed DNSSEC.

Why Deployment Is Slow

Operational complexity -- Managing key rollovers, signature expiration, and DS record updates adds operational burden. Misconfiguration can cause complete domain outages (not just degraded security, but total failure).
No visible user benefit -- Unlike HTTPS, which shows a padlock icon, DNSSEC is invisible to end users. There is little market pressure to deploy it.
Response size inflation -- DNSSEC signatures increase DNS response sizes by 2-10x, which can cause issues with UDP fragmentation and require TCP fallback.
Amplification risk -- Larger signed responses make DNSSEC-signed zones more attractive for DNS reflection/amplification attacks.
Registrar support -- Some domain registrars still do not support DS record management, making it impossible for their customers to deploy DNSSEC.

Who Has Deployed DNSSEC

Despite the challenges, DNSSEC is broadly deployed in certain areas:

Root zone -- Signed since July 2010. All 13 root server identities serve DNSSEC-signed responses.
Major TLDs -- .com, .org, .net, .gov, .edu, and most ccTLDs are signed.
Government domains -- The US (.gov), the Netherlands (.nl), Brazil (.br), and Sweden (.se) mandate or strongly encourage DNSSEC for government domains.
Major resolvers -- Google Public DNS, Cloudflare's 1.1.1.1, and Quad9 all perform DNSSEC validation by default.
Managed DNS providers -- Cloudflare, Google Cloud DNS, AWS Route 53, and others offer automatic DNSSEC signing.

Common DNSSEC Failures and Debugging

When DNSSEC breaks, the failure mode is total: a validating resolver returns SERVFAIL rather than an unverified answer. Common causes include:

Expired RRSIG -- The zone has not been re-signed and signatures have passed their expiration date. This is the most common DNSSEC failure and usually indicates a broken signing automation.
DS/DNSKEY mismatch -- The DS record in the parent zone does not match any DNSKEY in the child zone. This happens after a botched KSK rollover or when the DS record was never updated after a key change.
Missing DNSKEY -- The zone serves RRSIG records but the corresponding DNSKEY has been removed.
Algorithm mismatch -- The DS record references an algorithm that the zone no longer uses.
Clock skew -- RRSIG records have inception and expiration timestamps. If a resolver's clock is significantly wrong, valid signatures may appear expired or not yet valid.

Debugging tools include dig +dnssec for querying DNSSEC records, delv (a DNSSEC-aware replacement for dig included with BIND), and web-based tools like DNSViz that visualize the full chain of trust.

# Query DNSSEC records for a domain
dig +dnssec example.com A

# Check the DNSKEY records
dig +dnssec example.com DNSKEY

# Check the DS record in the parent zone
dig +dnssec example.com DS

# Use delv for DNSSEC validation
delv @8.8.8.8 example.com A +rtrace

The Future: DNSSEC and Beyond

Several developments are shaping the future of DNSSEC:

Multi-signer DNSSEC (RFC 8901) -- Allows multiple DNS providers to independently sign the same zone, eliminating the single-provider lock-in that has been a barrier to DNSSEC adoption for organizations using multiple DNS providers.
Compact Denial of Existence -- A technique where authoritative servers synthesize minimal NSEC records on the fly, avoiding the need to pre-generate NSEC/NSEC3 records for the entire zone. This simplifies zone signing and eliminates the zone enumeration concern entirely.
Post-quantum algorithms -- Current DNSSEC algorithms (RSA, ECDSA, Ed25519) are all vulnerable to quantum computers. Research is ongoing into post-quantum signature schemes suitable for DNSSEC, though the large signature sizes of most post-quantum algorithms present a challenge for DNS's size constraints.

Explore DNS and Routing

DNSSEC secures the mapping from domain names to IP addresses, while RPKI secures the BGP routing that delivers traffic to those addresses. Together, they form two critical layers of internet infrastructure security. Use the looking glass to explore how DNS and BGP work together -- look up any domain to see its DNS records and the BGP routing information for its resolved IP address:

cloudflare.com -- DNSSEC-signed, RPKI-valid routes
google.com -- One of the most queried domains on the internet
1.1.1.1 -- Cloudflare's DNSSEC-validating resolver
8.8.8.8 -- Google's DNSSEC-validating resolver