DNSSEC

What it is

DNS Security Extensions add cryptographic signatures to DNS records. A signed zone publishes a public key (DNSKEY); each record set is signed (RRSIG); the parent zone publishes a hash of your key (DS) so a resolver can build a chain of trust from the DNS root down to your domain. Defined originally in RFC 4033 and 4035, with operational guidance in RFC 9364.

A validating resolver that asks for www.example.com checks every signature on the way and refuses to return a forged answer.

Why it matters

Plain DNS is unauthenticated. Anyone on the network path — a coffee-shop router, a compromised ISP, a malicious resolver — can lie about which IP your domain points to, where mail should go, or what TXT records exist. That undermines TLS issuance (because Domain Validation depends on DNS or HTTP that depends on DNS), email security (SPF, DKIM, DMARC live in TXT records), and CAA enforcement.

DNSSEC closes the cache-poisoning and on-path spoofing surface for any resolver that validates. It is also a prerequisite for protocols like DANE, which pin TLS keys in DNS.

The honest caveat: DNSSEC is operationally tricky. A misconfiguration — a missing DS record after a key rollover, an expired signature — takes your whole domain offline for validating resolvers, which is much worse than the average outage. The benefit is real but only worth taking on with tooling that handles rollovers automatically.

How to implement

1. Check support. Your DNS provider must sign your zone, and your registrar must publish a DS record at the parent registry. Most managed DNS providers (Cloudflare, Route 53, Google Cloud DNS, DNSimple) can do both, often with a single toggle. Some legacy registrars cannot.
2. Enable signing at the DNS provider. This generates a Key Signing Key (KSK) and a Zone Signing Key (ZSK), publishes DNSKEY records, and signs every record set.
3. Publish the DS record at the registrar. Some providers automate this via CDS/CDNSKEY; otherwise you copy the DS from the provider’s UI to the registrar’s UI.
4. Verify the chain. Use dig +dnssec or Verisign DNSSEC Debugger to confirm every signature validates and the DS at the parent matches.

Example records (truncated):

example.com.    3600    IN    DNSKEY    257 3 13 mdsswUyr3DPW132mOi8V9xESWE8j...
example.com.    3600    IN    RRSIG     A 13 2 3600 20260701000000 20260601000000 12345 example.com. ...
com.            86400   IN    DS        12345 13 2 1F987CC6583E92DF0890718C42...

Algorithm 13 (ECDSA P-256 with SHA-256) is the recommended modern default; it is small, fast, and widely supported.

Operational hygiene:

• Automate key rollovers (KSK and ZSK). Manual rollovers fail.
• Monitor signature expiry. An expired RRSIG is an outage.
• Re-publish DS whenever the KSK rotates.
• Pair with CAA records for defence in depth around certificate issuance.

Common mistakes

• Signing the zone but never publishing the DS. Resolvers ignore the signatures — no protection.
• Manual key management. Rollovers will be missed. Use automation.
• Forgetting to update DS after migrating DNS provider. The chain breaks; the domain disappears.
• Treating DNSSEC as a replacement for TLS. It is complementary, not a substitute.

Verification

• dig +dnssec example.com returns RRSIG records and the ad (authenticated data) flag.
• DNSViz and the Verisign DNSSEC Debugger both visualise the chain.
• Set up monitoring that alerts before any RRSIG expires.
• Test from a validating resolver (Cloudflare 1.1.1.1, Google 8.8.8.8). Forged answers should be rejected.

Related topics

• DNS CAA records
• HTTPS and TLS
• HSTS (Strict-Transport-Security)

Sources & further reading

• RFC 4033 — DNS Security Introduction and Requirements — IETF
• RFC 4035 — Protocol Modifications for the DNS Security Extensions — IETF
• ICANN — DNSSEC — ICANN
• Internet Society — Deploying DNSSEC — Internet Society