What is DNSSEC?

DNSSEC (Domain Name System Security Extensions) is a suite of IETF specifications (RFC 4033, RFC 4034 and RFC 4035, published in March 2005) that adds cryptographic signatures to DNS records. Without DNSSEC, a resolver has no way to verify that a DNS answer actually came from the authoritative server and was not modified in transit, which makes attacks like cache poisoning, DNS spoofing and on path attacks possible. With DNSSEC, every record set (A, AAAA, MX, TXT and so on) is signed with a private key held by the zone owner, and resolvers validate the signature using the matching public key. The root zone has been signed since 15 July 2010. As of 2025, more than 90 percent of country code top level domains and all major generic TLDs (com, net, org, info, biz) support DNSSEC, although end domain adoption varies widely by country, with the Netherlands, Sweden, the Czech Republic and Norway above 60 percent and many other countries still under 5 percent.

How does DNSSEC work?

Every DNSSEC enabled zone publishes a chain of trust built from four record types:

• DNSKEY: the public keys of the zone. There are usually two keys per zone, a Zone Signing Key (ZSK) that signs the actual records and a Key Signing Key (KSK) that signs the DNSKEY set.
• RRSIG: the digital signature attached to every record set, generated with the ZSK.
• DS (Delegation Signer): a hash of the child zone KSK, published in the parent zone. The DS record is what links a domain to its TLD and forms the global chain of trust.
• NSEC or NSEC3: proves that a record does not exist (authenticated denial of existence). NSEC3 is the privacy preserving variant that hashes the names so that zone walking is not trivial.

The validating resolver starts at the root, verifies the root KSK against a built in trust anchor (root key, last rolled in October 2018 from KSK 19036 to KSK 20326), then follows the chain through the TLD (for example .com) down to the queried zone. If any signature is missing or invalid, the resolver returns SERVFAIL and the user sees a generic DNS error.

What attacks does DNSSEC prevent?

• Cache poisoning: famously demonstrated by the Kaminsky attack in 2008. An attacker injects forged answers into a resolver cache so that bank.com resolves to an attacker controlled IP.
• DNS spoofing on a public WiFi or hostile ISP where a man in the middle alters answers to redirect users to phishing pages.
• BGP hijack consequences: when an attacker hijacks the route to a DNS provider, DNSSEC ensures the falsified answers cannot be signed correctly.
• Compromised authoritative server: limited protection. If the attacker also steals the private keys, DNSSEC offers no help.

What DNSSEC does NOT do

• It does not encrypt DNS queries. Anyone on the network path can still see which domains a user looks up. For privacy you need DNS over HTTPS (DoH, RFC 8484) or DNS over TLS (DoT, RFC 7858).
• It does not protect the last mile between the resolver and the client unless the client itself validates DNSSEC. Most operating systems delegate validation to the resolver.
• It does not stop DDoS against the DNS infrastructure. Ironically DNSSEC makes amplification attacks worse because signed responses are much larger than unsigned ones.
• It does not authenticate the website. That is the job of TLS certificates. DNSSEC and HTTPS complement each other.

How do I enable DNSSEC for my domain?

The process depends on whether you use the registrar nameservers, a managed DNS provider or your own nameservers. The general flow is:

1. Choose a DNS provider that supports DNSSEC. Cloudflare, AWS Route 53 (since December 2020), Google Cloud DNS, Azure DNS (since 2024), DNSimple, Hurricane Electric and most domain registrars (Namecheap, Gandi, OVH, INWX, Hetzner, Porkbun) all support it.
2. In the DNS provider control panel, enable DNSSEC for the zone. The provider generates the KSK and ZSK and starts signing records automatically.
3. Copy the DS record (digest, key tag, algorithm, digest type) shown by the provider.
4. Log into your domain registrar (where the domain is registered) and paste the DS record into the DNSSEC section. This record gets published in the parent TLD zone and closes the chain of trust.
5. Wait up to 48 hours for propagation. Validate with dig +dnssec yourdomain.com A and check that the response contains RRSIG records and that the AD flag is set in the header.

How do I verify DNSSEC for a domain?

Several tools make it easy:

• Online: DNSViz (dnsviz.net), Verisign DNSSEC Debugger (dnssec-debugger.verisignlabs.com), Internet.nl, MxToolbox DNSSEC test.
• Command line: dig +dnssec example.com or delv example.com (the latter is bundled with BIND).
• Browser: the extension "DNSSEC/TLSA Validator" from CZ.NIC adds a status icon to Firefox and Chrome.

A correctly signed domain returns RRSIG records and the AD flag in the response header. A broken DNSSEC setup returns SERVFAIL and breaks the domain completely, so testing on a staging domain first is recommended.

What cryptographic algorithms does DNSSEC use?

For new deployments in 2025, ECDSA P 256 (algorithm 13) or Ed25519 (algorithm 15) are recommended. They produce much smaller signatures than RSA, which reduces DNS response size and helps with the EDNS0 4096 byte UDP limit.

What is key rollover?

DNSSEC keys must be rotated periodically. Standard practice is to roll the ZSK every 1 to 3 months and the KSK every 1 to 2 years. ZSK rollover happens automatically inside the zone. KSK rollover requires updating the DS record at the registrar and is more involved, because the parent zone must publish the new DS before the old key is retired. The root zone KSK was rolled for the first time in October 2018 (KSK 19036 to KSK 20326). The next root KSK rollover is in planning by ICANN for 2026 or 2027.

What is the relation between DNSSEC and DANE?

DANE (DNS based Authentication of Named Entities, RFC 6698, August 2012) uses DNSSEC signed TLSA records to publish TLS certificate fingerprints in DNS. This lets clients verify a TLS certificate against the domain owner declaration in DNS, bypassing the public certificate authority (CA) system. DANE for SMTP is widely deployed (Germany since 2014 with Mail.de, Posteo, Mailbox.org; the EU eIDAS regulation references it). DANE for HTTPS in browsers never gained traction because no major browser implemented it.

What is the relation between DNSSEC and DNS over HTTPS (DoH)?

DNSSEC and DoH solve different problems:

• DNSSEC ensures that the DNS answer is authentic (signed by the zone owner).
• DoH ensures that the DNS query is encrypted on the wire and cannot be read by intermediate networks.

For full DNS security and privacy, both should be combined. Cloudflare 1.1.1.1, Google 8.8.8.8 and Quad9 9.9.9.9 perform DNSSEC validation and offer DoH/DoT to the client.

Common DNSSEC pitfalls

• Forgetting to update the DS record at the registrar after a key rollover, breaking the chain of trust.
• Mixing providers without coordinating DNSSEC: when migrating from one DNS provider to another, both must support multi signer DNSSEC or you must temporarily disable DNSSEC to avoid downtime.
• Choosing an algorithm not supported by all resolvers in the path.
• Not monitoring signature expiry. Signatures have a validity window (typically 7 to 30 days) and the zone must be resigned before they expire.
• Treating DNSSEC as a substitute for HTTPS or for email authentication.

How does InspectWP help with DNSSEC?

InspectWP queries the DNS records of every analyzed domain and reports whether the response carries DNSSEC signatures and a valid chain of trust. Domains without DNSSEC are flagged in the security and DNS section of the report.