Topics Glossary About Privacy Terms Free IP Tools →

What Is DNSSEC? Securing the Internet's Phone Book

dnssec dns security cryptography networking

DNSSEC (Domain Name System Security Extensions) is a suite of extensions that adds cryptographic authentication to DNS responses. Standard DNS has no way to verify that a response actually came from the legitimate authoritative server and wasn’t modified in transit. DNSSEC fixes this by digitally signing DNS records so that resolvers can verify their authenticity. It doesn’t encrypt DNS traffic (that’s what DNS over HTTPS does), but it prevents cache poisoning attacks where an attacker injects fake DNS records to redirect you to malicious websites.

The Problem DNSSEC Solves

Standard DNS operates purely on trust. When your resolver asks a nameserver for the A record of yourbank.com, it accepts whatever response comes back. There’s no built-in verification that the response is genuine.

This opens the door to DNS cache poisoning (also called DNS spoofing). An attacker can:

  1. Race the legitimate DNS response and inject a fake one
  2. Compromise a resolver and insert fake records into its cache
  3. Execute a man-in-the-middle attack between the resolver and the authoritative server

In any of these scenarios, users who query the poisoned resolver get directed to the attacker’s server instead of the real one. The attacker’s server can look identical to the real site and harvest login credentials, credit card numbers, or any data the user submits.

The Kaminsky vulnerability (discovered in 2008 by Dan Kaminsky) demonstrated that DNS cache poisoning was far easier than previously thought. It sent shockwaves through the security community and accelerated DNSSEC adoption efforts.

How DNSSEC Works

DNSSEC adds four new record types to DNS:

RRSIG (Resource Record Signature): Contains the cryptographic signature for a set of DNS records. When a DNSSEC-validating resolver receives DNS records, it also receives the corresponding RRSIG. The resolver uses the domain’s public key to verify the signature.

DNSKEY: Publishes the public key used to verify RRSIG signatures. There are typically two keys: the Zone Signing Key (ZSK) that signs individual records, and the Key Signing Key (KSK) that signs the ZSK for an extra layer of security.

DS (Delegation Signer): Published in the parent zone. The .wiki zone contains a DS record for whatismyip.wiki that links the parent zone to the child zone’s DNSKEY. This creates the chain of trust.

NSEC/NSEC3 (Next Secure): Proves that a record doesn’t exist. Without this, an attacker could serve fake “this domain doesn’t exist” responses. NSEC3 is the hashed version that prevents zone enumeration.

The Chain of Trust

DNSSEC validation follows a chain from the root zone down:

Root Zone (signed by IANA's root KSK)
  ↓ DS record for .wiki
.wiki TLD Zone (signed by .wiki's KSK)
  ↓ DS record for whatismyip.wiki
whatismyip.wiki Zone (signed by domain's KSK)
  ↓ RRSIG covering A record
A record: 116.203.189.147 ✓

Each level vouches for the next through DS records, creating an unbroken chain of trust from the root zone to the individual record. If any link in the chain is broken or invalid, the resolver rejects the response.

Adoption Status

Despite being standardized in 2005 (RFCs 4033 to 4035), DNSSEC adoption has been painfully slow:

  • About 30% of the top 1 million domains have DNSSEC enabled
  • The root zone and all major TLDs are signed
  • Several country-code TLDs mandate DNSSEC (.se, .nl, .br)
  • Major DNS providers (Cloudflare, Google, Quad9) validate DNSSEC by default

The slow adoption stems from several factors:

Complexity: Setting up DNSSEC correctly requires generating key pairs, signing zones, publishing DS records with your registrar, and managing key rotation. Misconfiguration can make your domain completely unreachable.

Key management: DNSSEC keys need to be rotated periodically. The KSK rollover for the root zone in 2018 was a major operational undertaking that required years of planning.

Operational risk: Expired signatures or failed key rotations cause hard failures. Unlike most DNS misconfigurations that result in slow degradation, DNSSEC failures result in complete unavailability for validating resolvers.

No visible benefit: End users don’t see a green padlock or any other indicator that DNSSEC is working. The protection is invisible, making it hard to justify the operational overhead to management.

Cloudflare has helped adoption significantly by offering one-click DNSSEC for all domains on their platform. If your domain uses Cloudflare DNS, enabling DNSSEC is trivially easy and Cloudflare handles key management automatically.

DNSSEC vs DNS Encryption

It’s important to understand that DNSSEC and DNS encryption (DoH/DoT) solve different problems:

DNSSECDoH/DoT
Protects againstResponse tamperingEavesdropping
EncryptionNo (data is signed but not encrypted)Yes
VerificationYes (proves data is authentic)No (data could still be tampered with)
Where it worksServer-side (zone signing)Client-side (query encryption)

The ideal setup uses both: DoH/DoT encrypts your queries (privacy), and DNSSEC verifies the responses (integrity). They’re complementary, not competing.

Test It Yourself

Check DNSSEC Status

Look up any domain's DNS records and check if DNSSEC is enabled. See DNSKEY and DS records.

Open Tool →

Frequently Asked Questions

No. DNSSEC adds digital signatures to DNS responses, allowing you to verify that the data hasn't been tampered with. But the queries and responses are still sent in plain text. For encryption, you need DNS over HTTPS (DoH) or DNS over TLS (DoT). DNSSEC and DoH/DoT solve different problems and ideally should be used together.
DNSSEC is complex to implement, can cause outages if misconfigured, and provides benefits that are invisible to end users. Many domain registrars still don't make DNSSEC easy to enable. The ROI calculation for most websites just doesn't favor the setup complexity.
If misconfigured, yes. Expired DNSSEC signatures or key rotation errors can cause your domain to be completely unreachable for DNSSEC-validating resolvers. This has happened to major organizations. The key is automation and monitoring.