What Is DNSSEC and Why Should You Enable It?

The Domain Name System is one of the most critical pieces of internet infrastructure. Every time you visit a website, send an email, or use an API, DNS translates human-readable domain names into the IP addresses that computers use to communicate. But DNS was designed in the 1980s without any built-in security mechanism to verify that the answers it provides are genuine.

This means that without additional protection, an attacker can intercept DNS queries and return forged responses, redirecting users to malicious servers without their knowledge. This is the foundation of an entire family of DNS attacks, from cache poisoning to hijacking. The attack is invisible to the end user because their browser still shows the correct domain name in the address bar.

DNSSEC (DNS Security Extensions) was created to solve this problem. It adds a layer of cryptographic verification to DNS, allowing resolvers to confirm that the DNS data they receive is authentic and has not been tampered with. Despite being standardized for over a decade, DNSSEC adoption remains surprisingly low. This article explains what DNSSEC is, how it works, why you should care, and how to enable it for your domain.

The Problem DNSSEC Solves: DNS Cache Poisoning and Spoofing

To understand why DNSSEC matters, you need to understand the attacks it prevents.

DNS Cache Poisoning

DNS resolvers cache query results to improve performance. When you visit example.com, your ISP's resolver stores the IP address so that subsequent requests do not require a full lookup. Cache poisoning occurs when an attacker injects a fraudulent DNS record into a resolver's cache.

Here is how a cache poisoning attack works in simplified terms:

1. The attacker sends a flood of forged DNS responses to a recursive resolver, each claiming to be the answer for bank.com.
2. If a forged response arrives before the legitimate one and matches the expected query ID, the resolver accepts it as valid.
3. The resolver now caches the attacker's IP address for bank.com.
4. Every user who queries that resolver for bank.com is sent to the attacker's server.
5. The attacker's server hosts a convincing replica of the bank's website, harvesting login credentials.

The most famous demonstration of this vulnerability was the Kaminsky attack in 2008, which showed that cache poisoning could be executed far more easily than previously thought. This discovery accelerated the push for DNSSEC deployment.

DNS Spoofing

DNS spoofing is a broader category that includes any attack where DNS responses are forged. This can happen through cache poisoning, man-in-the-middle attacks on network traffic, or hijacking DNS resolution at the registrar or nameserver level. The result is the same: users are directed to the wrong IP address while believing they are visiting the correct domain.

Without DNSSEC, a recursive resolver has no way to verify that a DNS response genuinely came from the authoritative server for that domain. It accepts whatever answer arrives first, as long as it matches the query parameters.

How DNSSEC Works: The Chain of Trust

DNSSEC does not encrypt DNS traffic (that is a common misconception). Instead, it uses public-key cryptography to sign DNS records, allowing resolvers to verify that responses are authentic and unmodified.

The Core DNSSEC Record Types

DNSSEC introduces several new DNS record types that work together:

RRSIG (Resource Record Signature)

Each authoritative record set in the zone (e.g., all A records for a domain) is signed with a digital signature, stored in an RRSIG record. When a resolver receives DNS data, it also receives the corresponding RRSIG, which it can verify using the zone's public key.

"Each authoritative record set" rather than "every record", because DNSSEC carves out deliberate exceptions (RFC 4035 Section 2.2). The NS RRset at the zone apex is signed, but the NS RRsets at delegation points, the ones in the parent zone that hand a subzone to its nameservers, MUST NOT be signed, and neither may the glue address records that accompany a delegation. An RRSIG is not itself signed either, which would otherwise recurse forever.

example.com.  300  IN  A      93.184.216.34
example.com.  300  IN  RRSIG  A 13 2 300 20250401000000 20250301000000 12345 example.com. <base64-signature-data>

DNSKEY (DNS Public Key)

Each DNSSEC-signed zone publishes its public keys in DNSKEY records. There are typically two keys:

• Zone Signing Key (ZSK) -- Used to sign the actual DNS records within the zone. This key is rotated more frequently.
• Key Signing Key (KSK) -- Used to sign the DNSKEY record set itself. This key is rotated less frequently and is the anchor of trust for the zone.

example.com.  3600  IN  DNSKEY  256 3 13 <base64-zsk-public-key>
example.com.  3600  IN  DNSKEY  257 3 13 <base64-ksk-public-key>

The flag field is where the KSK/ZSK convention shows up, and it is worth being precise about what it actually encodes. 256 sets the Zone Key bit. 257 sets the Zone Key bit plus the Secure Entry Point (SEP) bit. SEP is conventionally set on keys used for the parent handoff or as a trust anchor, which in a two-key setup means the KSK, so 257 is a reliable hint about intent. It is not a protocol declaration of role: validation assigns no meaning to SEP at all (RFC 6781 Section 3.2.3), and a single-key zone can carry SEP on the one key that does both jobs. The KSK/ZSK split is operational practice, not a requirement.

DS (Delegation Signer)

The DS record is the link between a child zone and its parent zone. It contains a hash of the child's KSK and is published in the parent zone. This is what creates the chain of trust: the parent zone vouches for the child zone's key.

example.com.  3600  IN  DS  12345 13 2 <sha256-hash-of-ksk>

NSEC / NSEC3 (Authenticated Denial of Existence)

These records prove that a specific domain name or record type does not exist. Without them, an attacker could forge "this domain doesn't exist" responses. NSEC3 uses hashed names to make zone walking and subdomain enumeration harder, though walking entire signed TLD zones is still possible against plain NSEC.

The Chain of Trust in Action

When a DNSSEC-validating resolver queries www.example.com, the verification process follows the DNS hierarchy:

1. Root zone (.) -- The resolver already has the root zone's public key built in (the root trust anchor). It verifies the DS record for .com using the root's DNSKEY.

2. TLD zone (.com) -- The resolver retrieves .com's DNSKEY records and verifies them against the DS record from the root. It then uses .com's key to verify the DS record for example.com.

3. Authoritative zone (example.com) -- The resolver retrieves example.com's DNSKEY records and verifies them against the DS record from .com. It then uses example.com's ZSK to verify the RRSIG on the A record for www.example.com.

4. Validation complete -- If every signature in the chain verifies correctly, the resolver marks the response as authenticated (AD flag set). If any link in the chain fails, the resolver returns a SERVFAIL error rather than delivering potentially poisoned data.

This hierarchical verification is what makes DNSSEC robust. An attacker would need to compromise the cryptographic keys at some level of the chain to forge a response, which is computationally infeasible with modern key sizes. The more realistic threat is a DNSSEC downgrade attack, where an attacker strips the signatures and tries to convince a resolver the zone was never signed at all.

Why DNSSEC Adoption Is Still Low

Despite the clear security benefits, DNSSEC adoption has been gradual. When I measured DNSSEC adoption across the global zone in 2026, only a small minority of domains were signed, and a smaller percentage of resolvers perform full validation.

Several factors contribute to slow adoption:

• Complexity. Setting up DNSSEC requires generating keys, signing zones, publishing DS records with your registrar, and managing key rollovers. Mistakes can take your domain offline.
• Key management burden. DNSSEC keys must be rotated periodically. A failed key rollover can cause widespread resolution failures for your domain.
• Larger DNS responses. DNSSEC signatures increase the size of DNS responses, which can cause issues with networks that block large UDP packets. This sometimes requires falling back to TCP, adding latency.
• Registrar support varies. Not all domain registrars make it easy to upload DS records or manage DNSSEC settings. Some charge extra for DNSSEC support. Support also varies by extension, which is worth weighing when picking a TLD for a new domain.
• Perceived low risk. Many domain owners do not consider cache poisoning a likely threat to their specific domain, so they do not prioritize the mitigation.

However, the landscape is shifting. Major DNS providers like Cloudflare, Google Cloud DNS, and AWS Route 53 now offer automated DNSSEC signing with one-click setup, dramatically reducing the operational burden.

How to Enable DNSSEC for Your Domain

The process for enabling DNSSEC depends on your DNS hosting provider and domain registrar. Here is the general workflow:

Step 1: Enable DNSSEC Signing at Your DNS Provider

Your authoritative DNS provider must sign your zone. With managed providers, this is typically a single toggle:

• Cloudflare: Navigate to DNS > Settings > DNSSEC and click "Enable DNSSEC." Cloudflare handles key generation and zone signing automatically.
• AWS Route 53: Enable DNSSEC signing in the hosted zone settings. Route 53 creates a KSK using AWS KMS.
• Google Cloud DNS: Enable DNSSEC on the managed zone. Google handles signing and key management.

If you run your own authoritative DNS servers (e.g., BIND or PowerDNS), you will need to generate keys and configure zone signing manually:

# Generate a KSK and ZSK for BIND
dnssec-keygen -a ECDSAP256SHA256 -f KSK example.com
dnssec-keygen -a ECDSAP256SHA256 example.com

# Sign the zone with NSEC (the default), which is what current
# best practice recommends for an ordinary zone
dnssec-signzone -N INCREMENT -o example.com -t example.com.zone

You will find plenty of older guides that reach for -3 with a randomly generated salt here, which selects NSEC3. Do not copy that. RFC 9276 Section 3.1 is the current best-current-practice guidance and it says to prefer NSEC unless you specifically need something NSEC3 offers. If you do need NSEC3, it says an iterations count of 0 MUST be used, and that operators SHOULD NOT use a salt (a zero-length salt, written - in presentation format). The recommended parameters are:

example.com.  IN  NSEC3PARAM  1 0 0 -

The salted, multi-iteration NSEC3 setups from a decade ago buy essentially no privacy against a determined enumerator while adding CPU-exhaustion DoS exposure and interoperability risk. Check your BIND version's dnssec-signzone syntax if you go the NSEC3 route, since the flags have shifted between releases.

Step 2: Publish the DS Record at Your Registrar

After your DNS provider signs the zone, you need to create a DS record in the parent zone. This is done through your domain registrar's control panel.

Your DNS provider will give you the DS record details, which typically include:

• Key Tag: A numeric identifier for the DNSKEY (e.g., 12345)
• Algorithm: The signing algorithm number (e.g., 13 for ECDSA P-256)
• Digest Type: The hash algorithm (e.g., 2 for SHA-256)
• Digest: The hash value of the KSK

Enter these values in your registrar's DNSSEC management section. The registrar then publishes the DS record in the parent zone (e.g., .com for a .com domain). Every TLD registry signs its own zone, so whether DNSSEC works smoothly can depend on the extension you chose, and the pool of available extensions has grown into the hundreds.

Step 3: Verify the Chain of Trust

After both the zone signing and DS record are in place, verify that the full chain of trust is working. You can use command-line tools:

# Request DNSSEC records (sets the DO bit) from a resolver you KNOW
# validates, then look for the "ad" flag in the header
dig +dnssec example.com A @1.1.1.1

# Verify the DS record exists in the parent zone
dig DS example.com @a.gtld-servers.net

# Use delv for full chain-of-trust validation
delv @8.8.8.8 example.com A +rtrace

Look for the ad (Authenticated Data) flag in the response header, which indicates the resolver successfully validated the DNSSEC signatures.

Two things to keep straight about that first command. +dnssec only sets the DO bit, asking for DNSSEC records to be included; dig itself does no validation. And the AD flag is set by the responding recursive resolver (RFC 4035 Section 3.2.3), so if your system's default resolver does not validate, you will get the RRSIGs back with no AD flag and nothing will have been checked. That is why the command names a resolver explicitly, and why delv below is the more direct answer: it validates locally rather than trusting someone else's verdict.

Verifying DNSSEC Configuration With DNS Checker

Checking whether a domain has DNSSEC properly configured is straightforward with the right tools.

Use the DNS Checker DNS Inspector to query a domain's DNSKEY and DS records. Treat both as indicators rather than verdicts.

DNSKEY records being present means the zone publishes keys. It does not prove the zone's RRsets are actually signed, that the DNSKEY RRset carries valid RRSIGs, or that anything chains back to a trust anchor: a zone can publish orphaned or unusable key material. RFC 4035 Section 2 defines a signed zone as one satisfying the whole set of signing rules, not one that merely has a DNSKEY RRset.

DS records in the parent likewise mean the parent asserts a secure delegation. They do not prove the digest still matches a usable DNSKEY in the child, and a stale or mismatched DS is one of the most common ways DNSSEC breaks in practice. RFC 4035 Section 2.4 is blunt about it: DS records that fail to point at a properly signed child DNSKEY "are not useful for validation."

For an actual verdict, validate: run delv or query through a resolver you know validates and check the AD flag.

You can also use the DNS Checker Propagation Checker to verify that DNSSEC-related records are consistent across DNS servers worldwide. Inconsistencies between servers during a key rollover can indicate a problem that needs immediate attention.

Key records to check:

• DNSKEY records at your domain to confirm zone signing is active.
• DS records in the parent zone to confirm the chain of trust is anchored.
• RRSIG records alongside your A, AAAA, MX, and other records to confirm they are being signed.

If you are in the process of enabling DNSSEC, monitoring propagation is especially important. The DS record must be visible in the parent zone before resolvers will attempt DNSSEC validation for your domain. If the DS record is published before your zone is fully signed, resolvers will see a broken chain and return SERVFAIL errors, taking your domain offline.

Key Takeaways

• DNSSEC adds cryptographic signatures to DNS records, allowing resolvers to verify that responses are authentic and unmodified. It does not encrypt DNS traffic.
• Cache poisoning and DNS spoofing are real threats that can redirect users to malicious servers without their knowledge. DNSSEC prevents these attacks.
• The chain of trust works hierarchically: the root zone vouches for TLD zones, TLD zones vouch for domain zones, through DS and DNSKEY records at each level.
• Four key record types power DNSSEC: RRSIG (signatures), DNSKEY (public keys), DS (delegation signer), and NSEC/NSEC3 (authenticated denial of existence).
• Adoption is growing but still incomplete. Major DNS providers now offer one-click DNSSEC setup, making it far easier to enable than it was even a few years ago.
• Misconfigurations can cause outages because resolvers return SERVFAIL when validation fails. Plan key rollovers carefully and monitor your DNSSEC records.
• Use the DNS Checker DNS Inspector to check whether a domain has DNSKEY and DS records, and the Propagation Checker to monitor DNSSEC record consistency across global DNS servers.

DNSSEC is one of the most impactful security improvements you can make for your domain, and with modern DNS providers, it is easier to deploy than ever. The threat of cache poisoning is not theoretical. It has been demonstrated repeatedly, and without DNSSEC, your domain's DNS responses have no cryptographic proof of authenticity.

Check your domain's DNSSEC status now using the DNS Checker DNS Inspector and verify that your records are properly signed and propagated worldwide with the Propagation Checker.