DNSSEC: How to Enable and Verify It

How DNS Security Extensions protect against cache poisoning and how to check your domain's signing chain.

What DNSSEC protects against

The DNS protocol was designed without authentication. A resolver that queries for example.com A has no way to verify that the answer it receives is genuine — it could have been injected by an attacker anywhere between the resolver and the authoritative server. This is the basis of the Kaminsky cache poisoning attack (published 2008): by flooding a resolver with forged responses, an attacker can cause it to cache a malicious IP address for a domain, silently redirecting all users who query through that resolver.

DNSSEC (DNS Security Extensions, RFC 4033–4035) addresses this by adding cryptographic signatures to DNS records. A validating resolver can verify that a response was signed by the legitimate zone owner and has not been tampered with in transit.

What DNSSEC does not protect: it does not encrypt DNS queries (that is DNS-over-HTTPS or DNS-over-TLS), it does not prevent DDoS against authoritative servers, and it does not protect against a compromised authoritative server. DNSSEC proves authenticity, not confidentiality or availability.

How it works

DNSSEC builds a chain of trust from the DNS root downward. Each zone signs its records and publishes the public key in DNS itself. Parent zones vouch for child zones by publishing a hash of the child's key.

The core record types involved:

DNSKEY: the zone's public signing key, published in DNS
RRSIG: a cryptographic signature over a resource record set, created with the zone's private key
DS (Delegation Signer): a hash of the child zone's DNSKEY, published in the parent zone
NSEC / NSEC3: authenticated denial of existence — proves that a queried name does not exist

Zones typically use two key pairs: the Key Signing Key (KSK), which signs the DNSKEY RRset itself and whose hash is published as the DS record in the parent zone, and the Zone Signing Key (ZSK), which signs all other records in the zone. The KSK is changed rarely (low rollover overhead from the parent); the ZSK rotates more frequently (no parent interaction needed for ZSK rollover).

Validation works by traversing from root to leaf: the resolver trusts the root zone's DNSKEY (distributed as a trust anchor), uses it to verify the .com DS record, uses that to verify example.com's DNSKEY, and uses that DNSKEY to verify the RRSIG on the A record.

How to enable it

Enabling DNSSEC involves two parties: your DNS provider (who manages the zone) and your registrar (who manages the parent DS record).

The standard procedure:

Enable signing at your DNS provider. Most managed DNS providers (Cloudflare, Route 53, Google Cloud DNS) handle key generation and RRSIG creation automatically when you enable DNSSEC in the control panel.
Retrieve the DS record. After signing is enabled, your DNS provider will give you a DS record — a digest of your KSK — to publish in the parent zone.
Submit the DS record to your registrar. Log into your domain registrar's control panel and enter the DS record (key tag, algorithm number, digest type, digest). This links the parent zone to your zone's signing key.
Verify the chain. After propagation (usually minutes to an hour), validate using a DNSSEC-aware resolver.

Key rollover requires updating the DS record at the registrar. Pre-publish the new DNSKEY, wait for caches to expire, then update the DS record at the registrar, then remove the old DNSKEY. Skipping the wait causes a validation gap.

Algorithm choices

The signing algorithm determines the key type and signature scheme. Current recommendations:

Ed25519 (algorithm 15): the preferred modern choice — small keys, fast verification, strong security. Supported by all major DNS providers and resolvers as of 2023.
ECDSAP256SHA256 (algorithm 13): widely supported, good choice if Ed25519 is not available. Smaller than RSA keys with equivalent security.
RSASHA256 (algorithm 8): acceptable but produces larger keys and signatures; only use if older resolver compatibility is required.

Algorithms to avoid: RSASHA1 (algorithm 5) and DSA (algorithm 3) are deprecated. SHA-1-based algorithms are prohibited by most validators. If your zone was signed years ago and has never been reviewed, check the algorithm number in your DNSKEY record.

How to verify

To manually verify a domain's DNSSEC chain, query each link in the chain:

example.com DNSKEY — should return one or two keys (KSK and ZSK)
example.com DS — query this at a parent-zone resolver; the hash should match a digest of the DNSKEY
example.com A RRSIG — the signature over the A record; check the signer's name and expiry date

A valid chain shows: DS in .com matches DNSKEY in example.com, and RRSIG signatures are present and within their validity window. A DNSSEC-validating resolver returns the AD (Authenticated Data) flag in the response when validation succeeds.

Use the +dnssec flag in the DNS inspector to run a full chain validation that shows each step, flags algorithm numbers, and checks RRSIG expiry dates.

Common failure modes

Expired RRSIG signatures: RRSIG records have validity windows (typically 14–30 days). If the zone's automatic re-signing fails (a cron job outage, an API key rotation), signatures expire and the zone becomes unresolvable for validating resolvers. Monitor RRSIG expiry.
Missing DS after key rollover: The new KSK was published in the zone but the registrar DS record was not updated. Validating resolvers find no matching DS for the published DNSKEY and return SERVFAIL.
Lame delegation with DNSSEC: The parent DS record was published but the zone is no longer signed (e.g., migrated to a DNS provider that disabled DNSSEC). Resolvers expecting a signed zone get unsigned responses and treat them as bogus.
Algorithm mismatch: DS record uses a different algorithm number than the published DNSKEY. This prevents chain validation and is usually caused by an incomplete key rollover.

DNSSEC and DANE

DANE (DNS-based Authentication of Named Entities) publishes TLS certificate pins as TLSA records in DNS. DANE is only meaningful when the DNS records are DNSSEC-signed — otherwise an attacker who can manipulate DNS can also replace the TLSA record with one matching their own certificate. DNSSEC is a prerequisite for DANE, not an optional add-on. If you intend to deploy DANE for SMTP (for email transport security), DNSSEC on your domain must be working correctly first.