DNSSEC Explained: What It Is and How to Enable It

DNS was built on trust and zero authentication. When a resolver asks for the IP address behind your domain, nothing in the original protocol proves the answer is legitimate. DNSSEC fixes that. This guide covers what DNS Security Extensions are, how the chain of trust works, how to enable DNSSEC on every major registrar, and how to verify it is working.

The Problem DNSSEC Solves

The Domain Name System was designed in 1983. Its job is simple: translate human-readable domain names into IP addresses. When your browser wants to load example.com, it sends a DNS query to a resolver, which responds with the corresponding IP. The entire exchange happens in plaintext, with no mechanism to verify that the response is genuine.

This means any device sitting between your resolver and the authoritative nameserver -- or any attacker who can reach your resolver -- can forge a DNS response. The resolver has no way to tell the difference between a legitimate answer and a fabricated one.

In 2008, security researcher Dan Kaminsky disclosed a critical vulnerability that made DNS cache poisoning practical at scale. The attack works by flooding a resolver with forged responses timed to arrive before the real answer. If the attacker guesses the correct transaction ID (a 16-bit field, meaning only 65,536 possibilities), the forged response gets cached. From that point forward, every client using that resolver gets sent to the attacker's IP address instead of the real server.

The consequences are severe:

• Phishing at the infrastructure level. Users type the correct domain into their browser and land on a perfect replica controlled by the attacker. The URL bar shows the right domain. Even careful users have no visual indicator that anything is wrong.
• Email interception. By poisoning MX records, attackers redirect all inbound email for a domain to their own servers. They read every message, then forward it to the real server so the victim never notices.
• Credential harvesting. Combined with a valid-looking login page, a poisoned DNS cache turns every user of that resolver into a target. Corporate resolvers serving thousands of employees are especially valuable.
• Malware distribution. Poisoning the DNS for a software update domain lets attackers serve malicious binaries to every machine that checks for updates through that resolver.

The Kaminsky attack was patched with source port randomization, which made the guessing harder but did not eliminate the fundamental problem: DNS responses are unauthenticated. DNSSEC was the protocol-level fix.

What Is DNSSEC?

DNSSEC stands for DNS Security Extensions. It is a set of specifications (RFCs 4033, 4034, and 4035) that add cryptographic authentication to DNS responses. When DNSSEC is enabled, every DNS response includes a digital signature that the resolver can verify. If the signature does not match, the response is rejected.

It is critical to understand what DNSSEC does and does not do:

• DNSSEC authenticates DNS data. It proves that the response you received is exactly what the authoritative nameserver published, and that it has not been modified in transit.
• DNSSEC does not encrypt DNS queries or responses. The data still travels in plaintext. Encryption is handled by separate protocols: DNS over HTTPS (DoH) and DNS over TLS (DoT). These solve a different problem -- privacy. DNSSEC solves integrity.
• DNSSEC does not protect against a compromised authoritative server. If an attacker gains control of your actual nameserver and publishes malicious records with valid signatures, DNSSEC will not help. It protects the path between the authoritative server and the resolver, not the server itself.

The mechanism works through a chain of trust that extends from the DNS root zone all the way down to your individual domain. Every link in that chain is cryptographically signed, and every resolver that supports DNSSEC validation can verify the entire chain before accepting a response.

How DNSSEC Works

DNSSEC introduces four new DNS record types. Understanding these is essential for both enabling and troubleshooting DNSSEC.

Zone Signing Key (ZSK) and Key Signing Key (KSK)

Each DNSSEC-enabled zone uses two key pairs. The Zone Signing Key (ZSK) signs the actual DNS records in the zone (A records, MX records, TXT records, etc.). The Key Signing Key (KSK) signs the ZSK itself. This two-key architecture exists so you can rotate the ZSK frequently (it signs a lot of data) without needing to update the parent zone every time. Both keys are published in DNSKEY records in your zone.

RRSIG Records

Every DNS record set in a signed zone gets an RRSIG record -- the actual cryptographic signature. When a resolver queries for example.com A, it receives the A record plus its corresponding RRSIG. The resolver uses the ZSK (published in the DNSKEY record) to verify the RRSIG. If the signature is valid, the response is authentic.

DS Records

The DS (Delegation Signer) record is what links your domain's DNSSEC to its parent zone. It is a hash of your KSK, published in the parent zone (e.g., the .com TLD zone). This is the critical handoff point -- your registrar submits the DS record to the TLD registry, which publishes it in their zone. Without the DS record in the parent zone, the chain of trust is broken and DNSSEC validation fails.

The Chain of Trust

Think of it like a chain of notarized documents. The DNS root zone is the original notary -- everyone trusts it implicitly (its public keys are hardcoded into every validating resolver). The root signs the keys for .com. The .com TLD signs the keys for example.com. And example.com signs its own DNS records.

The chain looks like this:

Root Zone (.)
  Signs DNSKEY for .com  -->  DS record in root zone points to .com's KSK
    .com TLD
    Signs DNSKEY for example.com  -->  DS record in .com zone points to example.com's KSK
      example.com
      ZSK signs A, MX, TXT, etc.  -->  RRSIG records on every record set

A validating resolver walks this chain from the root down. If every signature checks out, the response is accepted. If any link is broken -- a missing DS record, an expired signature, a mismatched key -- the resolver returns a SERVFAIL and the query fails. This is by design: a failed validation is safer than an unverified response.

Why You Should Enable DNSSEC

DNSSEC is not optional security theater. It provides concrete, measurable protection against real attacks.

• Prevents cache poisoning. The attack vector that Kaminsky demonstrated becomes impossible. Forged responses fail signature validation and are discarded by the resolver.
• Protects email routing. Your MX records determine where email for your domain is delivered. Without DNSSEC, an attacker who poisons your MX records can silently intercept all inbound email. With DNSSEC, the MX records are signed and any tampering is detected. This is especially important if you have configured SPF, DKIM, and DMARC -- those protections rely on DNS records that themselves need to be trustworthy.
• Required by compliance frameworks. NIST SP 800-53 (FedRAMP), the EU's eIDAS regulation, and several financial-sector compliance standards require or strongly recommend DNSSEC. If you are pursuing SOC 2 or ISO 27001 certification, enabling DNSSEC removes a finding that auditors will flag.
• Mitigates combined BGP + DNS attacks. Advanced attackers combine BGP hijacking (rerouting network traffic) with DNS spoofing to intercept traffic at scale. DNSSEC breaks the DNS spoofing half of this attack chain.
• Enables DANE/TLSA. DNS-Based Authentication of Named Entities (DANE) lets you publish your TLS certificate's fingerprint in a DNS record (TLSA). This binds your certificate to your domain at the DNS level, reducing dependence on the certificate authority system. DANE requires DNSSEC -- without it, an attacker could simply forge the TLSA record.

How to Enable DNSSEC

Enabling DNSSEC is a two-step process. First, you enable zone signing at your DNS provider (the service that hosts your DNS records). Second, you submit the DS record to your registrar (the company where you registered the domain). If your DNS provider and registrar are the same company, this is often handled automatically. If they are different, you need to manually copy the DS record from the DNS provider to the registrar.

Cloudflare

Cloudflare makes this the simplest of any provider.

1. Log in to the Cloudflare dashboard and select your domain.
2. Go to DNS in the left sidebar, then click the DNSSEC tab.
3. Click Enable DNSSEC.
4. Cloudflare displays the DS record details. If Cloudflare is also your registrar, the DS record is added automatically. If your registrar is elsewhere, copy the DS record values and add them at your registrar.

The DS record values Cloudflare provides look like this:

DS Record:
  Key Tag:    2371
  Algorithm:  13 (ECDSAP256SHA256)
  Digest Type: 2 (SHA-256)
  Digest:     abc123...def456

Namecheap

1. If you use Namecheap's own DNS (BasicDNS or PremiumDNS), go to Domain List, select your domain, then click Advanced DNS.
2. Scroll to the DNSSEC section and click Add new DS record.
3. Enter the DS record values: Key Tag, Algorithm, Digest Type, and Digest.
4. If your DNS is hosted elsewhere (e.g., Cloudflare), your DNS provider generates the DS record and you add it here at Namecheap as the registrar.

Namecheap supports DS record management for most TLDs, but some country-code TLDs have restrictions. Check their knowledge base if your TLD is not .com, .net, or .org.

Google Domains / Google Cloud DNS

1. If using Google Cloud DNS, go to the Cloud DNS console, select your zone, and click DNSSEC at the top. Set the state to On. Cloud DNS generates the DNSKEY records and signs the zone automatically.
2. Cloud DNS displays the DS record. Copy the Key Tag, Algorithm, Digest Type, and Digest values.
3. At your registrar (Google Domains or elsewhere), add the DS record. In Google Domains, go to DNS > DNSSEC and enter the values.

If both your DNS hosting and domain registration are on Google, the DS record propagation is typically handled within minutes.

GoDaddy

1. GoDaddy supports DNSSEC for domains using their own nameservers. Go to My Products, select your domain, then DNS.
2. Scroll to DNSSEC and click Add.
3. If your DNS is hosted at GoDaddy, they handle both the zone signing and the DS record. If your DNS is hosted elsewhere, enter the DS record values from your DNS provider.

Note: GoDaddy's support for DNSSEC with third-party nameservers varies by TLD. For .com and .net domains it works reliably.

AWS Route 53

Route 53 added DNSSEC signing support for public hosted zones. The setup is more involved than other providers because AWS uses a KMS key for the KSK.

1. In the Route 53 console, go to Hosted zones, select your zone, and click the DNSSEC signing tab.
2. Click Enable DNSSEC signing. Create or select a KMS customer managed key (CMK) in us-east-1 -- Route 53 requires the key be in that region.
3. Route 53 creates the KSK and signs the zone. It provides the DS record information.
4. Add the DS record at your registrar. If your registrar is also Route 53, you can add it via the Registered domains section under DNSSEC keys.

Via the CLI:

# Enable DNSSEC signing on a hosted zone
aws route53 enable-hosted-zone-dnssec \
  --hosted-zone-id Z0123456789ABCDEF

# Create a Key Signing Key
aws route53 create-key-signing-key \
  --hosted-zone-id Z0123456789ABCDEF \
  --name example-com-ksk \
  --key-management-service-arn arn:aws:kms:us-east-1:111122223333:key/your-key-id \
  --status ACTIVE

The two-step nature of DNSSEC enablement is the most common source of confusion. Signing your zone at the DNS provider is step one. Publishing the DS record at the registrar is step two. Both must be completed for DNSSEC to work. If you only do step one, resolvers have no way to find your keys and the chain of trust is broken.

How to Verify DNSSEC Is Working

After enabling DNSSEC and allowing time for DNS propagation (typically 15 minutes to a few hours depending on TTLs), you should verify that the chain of trust is intact.

Using dig

The dig command with the +dnssec flag requests DNSSEC records alongside the normal response:

dig +dnssec example.com

In a properly signed zone, you will see RRSIG records alongside the answer, and the ad (Authenticated Data) flag in the response header:

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0

;; ANSWER SECTION:
example.com.        300  IN  A      93.184.216.34
example.com.        300  IN  RRSIG  A 13 2 300 20260315000000 20260215000000 12345 example.com. (
                        aBcDeFgHiJkLmNoPqRsTuVwXyZ...)

The ad flag means the resolver validated the DNSSEC signatures and the chain of trust is intact. If you see the answer but no ad flag, either DNSSEC is not configured or your resolver does not perform validation.

To check the DS record in the parent zone:

dig DS example.com +short
# Expected output:
# 2371 13 2 abc123...def456

If this returns empty, the DS record has not been published at the registrar.

Online Tools

DNSViz (dnsviz.net) provides a visual graph of the entire DNSSEC chain of trust for any domain. It shows every key, every signature, and highlights exactly where the chain breaks if something is misconfigured. This is the best tool for diagnosing DNSSEC issues.

Verisign DNSSEC Debugger (dnssec-debugger.verisignlabs.com) walks through validation step by step and reports pass/fail for each link in the chain.

Scanward

Scanward's DNS scanner checks DNSSEC status automatically as part of every domain scan. You do not need to run separate tools or remember command-line flags. The scan reports whether DNSSEC is enabled, whether the DS record is present in the parent zone, and whether the chain of trust validates successfully.

Common DNSSEC Pitfalls

DNSSEC is powerful but unforgiving. A misconfiguration does not degrade gracefully -- it causes resolution failures. These are the most common issues domain administrators encounter.

Key rollover failures

DNSSEC keys should be rotated periodically. The ZSK is typically rolled every 1-3 months, and the KSK every 1-2 years. If a key rollover is not executed correctly -- for example, the new key is published before it is used for signing, or the old DS record is removed before the new one propagates -- the chain of trust breaks and your domain stops resolving for validating resolvers.

Domain transfers break DNSSEC

When you transfer a domain between registrars, the DS record at the old registrar is typically removed. If the new registrar does not automatically re-add it (most do not), your zone is still signed but the parent zone has no DS record pointing to your keys. This means DNSSEC validation fails. The safest approach is to disable DNSSEC before the transfer, complete the transfer, then re-enable it at the new registrar.

Registrar support gaps

Not all registrars support DNSSEC DS record management for all TLDs. Some only support it for .com, .net, and .org. Some do not support it at all. Before choosing a registrar, verify they support DNSSEC for your TLD. If your current registrar does not support it, consider transferring to one that does.

DNSSEC with CDNs

If you use a CDN like Cloudflare as your DNS provider, they handle DNSSEC signing on their nameservers. But if you use a CDN in front of your origin while hosting DNS elsewhere, make sure the CDN does not interfere with DNSSEC records. Some CDN configurations strip or modify DNS responses in ways that break signatures. Test thoroughly after enabling.

Expired signatures

RRSIG records have an expiration timestamp. If your zone signing process stops working (e.g., a misconfigured cron job, a crashed signing daemon, or a lapsed managed DNS service), the signatures will eventually expire. Once expired, validating resolvers treat the records as unsigned and return SERVFAIL. Monitor your RRSIG expiration dates -- they are visible in the dig +dnssec output.

NSEC vs. NSEC3 zone walking

DNSSEC's mechanism for proving a record does not exist (NSEC records) can inadvertently reveal all records in a zone. If zone enumeration is a concern, ensure your DNS provider uses NSEC3 with opt-out, which hashes record names and prevents trivial zone walking.

DNSSEC and Your Domain Security Score

Scanward's domain security scanner evaluates DNSSEC as part of the DNS configuration category. A domain without DNSSEC enabled loses 15 points from its DNS score, which directly impacts your overall A-F security grade. For a domain that otherwise scores well, missing DNSSEC alone can be the difference between an A and a B+.

The DNS category accounts for 15% of your total domain security score. Within that category, the scan checks for:

• DNSSEC presence and chain-of-trust validation
• Proper record configuration (A, AAAA, MX, NS, TXT)
• Dangling CNAME records (subdomain takeover risk)
• Nameserver redundancy and geographic distribution

Enabling DNSSEC is one of the fastest ways to improve your score. On most providers, it takes under five minutes. Combined with proper email authentication (SPF, DKIM, DMARC) and HTTP security headers, DNSSEC closes one of the last major gaps in your domain's external attack surface.

DNS is the foundation that everything else sits on. If your DNS responses can be forged, your SSL certificates, your email authentication, and your security headers are all built on sand. DNSSEC is the bedrock.