What is DNSSEC? A Plain-Language Guide to DNS Security

DNSSEC — short for DNS Security Extensions — is the only widely-deployed defence against DNS cache poisoning, the attack that lets a network adversary lie to resolvers about where your domain points. It's been a standard since 2005, every major TLD now signs its zone, and every major managed DNS provider supports it. If your public domain doesn't have DNSSEC turned on, you're trusting that nobody between your users and your authoritative nameserver has the means or motivation to redirect them somewhere malicious. That's a bet that's no longer reasonable to take.

This guide is the plain-language entry point: what DNSSEC actually does, why it exists, how the chain of trust works at a high level, and what you should expect from your DNS provider. For the operational mechanics — KSK vs ZSK roles, key rollovers, algorithm choices — read the deeper DNSSEC Key Management guide once you have the basics.

What DNSSEC Does (and Doesn't)

DNSSEC adds digital signatures to DNS records. When your authoritative nameserver returns an A record saying example.com is at 192.0.2.1, it also returns a cryptographic signature over that record. A resolver that supports DNSSEC validation can check the signature against your zone's public key — and check that public key against a chain leading all the way up to a hard-coded trust anchor — and refuse to accept the answer if the signatures don't verify.

That's the entire job. DNSSEC:

• ✅ Proves the answer came from the right authoritative server. A man-in-the-middle attacker can't forge a record without breaking the signature.
• ✅ Detects tampering on the wire or in a cache. Even if a resolver's cache is poisoned, the signatures don't validate.
• ✅ Proves a record doesn't exist (negative answers are signed too, via NSEC/NSEC3 records).

DNSSEC does not:

• ❌ Encrypt DNS queries or answers. Anyone watching the network can still see what you're looking up. Use DNS over HTTPS or DNS over TLS for that.
• ❌ Hide your zone's structure. DNSSEC signatures are public; anyone can pull them.
• ❌ Replace TLS or HTTPS. DNSSEC protects DNS itself; once you have an IP address, the security of the connection is up to the application protocol.
• ❌ Defend against compromised authoritative servers. If an attacker controls your nameserver, they can sign whatever they want with your zone's private keys. DNSSEC trusts the keyholder.

Why DNSSEC Exists — The Cache-Poisoning Problem

The original DNS protocol from the 1980s was designed for a network where nobody actively tried to cheat. Resolvers asked authoritative servers for answers in plain UDP, and trusted whatever came back as long as the source IP and a 16-bit transaction ID matched.

That trust model held until 2008, when Dan Kaminsky demonstrated practical cache poisoning at scale. The attack works like this:

1. The attacker triggers a recursive resolver to look up a name they control (anything.example.com).
2. While the resolver is waiting for an answer from the authoritative server, the attacker floods it with forged responses guessing the 16-bit transaction ID.
3. If a forged response wins the race, the resolver caches the attacker's answer — a fake A record for example.com — and serves it to every subsequent query for the entire TTL.

Every user of that resolver — potentially millions of people — is now silently redirected to wherever the attacker chose. Web traffic, email, software updates: all routed to the attacker's server until the bad cache entry expires.

The DNS community responded with three layers of mitigation:

1. Source-port randomisation at resolvers (RFC 5452, 2009) — made the race much harder by adding 16 more bits of unpredictability.
2. DNS over HTTPS / DNS over TLS at the resolver-to-client hop — encrypted the conversation so an attacker on the local network can't see or alter queries.
3. DNSSEC at the authoritative-to-resolver hop — added cryptographic signatures so a poisoned cache produces invalid signatures that a validating resolver rejects.

DNSSEC is the only one of the three that actually solves the underlying problem at the authoritative level. Source-port randomisation makes the attack harder; DoH/DoT changes who can see the query but not who can lie about the answer. DNSSEC verifies the answer itself.

The Chain of Trust — A High-Level View

The thing that makes DNSSEC work at internet scale is that resolvers don't need to know your specific public key in advance. Instead, they walk a chain of trust from a hard-coded root key down to your zone:

Root zone (.)
    │  signs with root KSK
    │  publishes DS record for .com at the root
    ▼
.com TLD
    │  signs with .com KSK
    │  publishes DS record for example.com in .com
    ▼
example.com
    │  signs all records with its own keys
    │  signature on the requested record
    ▼
A record: example.com → 192.0.2.1

A validating resolver follows this chain in reverse:

1. It receives the signed A record from your authoritative server.
2. It fetches the DS record for example.com from the .com nameservers and checks that the hash matches your zone's KSK.
3. It fetches the DS record for .com from the root nameservers and checks the hash against the .com zone's KSK.
4. It checks the root zone's signature against the trust anchor it has hard-coded (the root KSK, also published by IANA at https://data.iana.org/root-anchors/).

If any link in the chain fails to verify, the answer is treated as untrusted. Most validating resolvers will return SERVFAIL rather than serve a potentially-tampered answer.

You don't need to understand the mechanics to use DNSSEC. Your DNS provider generates and rotates keys for you; your only job is to publish one piece — the DS record — at your registrar so the chain reaches your zone.

For the full mechanical breakdown — KSK vs ZSK roles, RRSIG records, NSEC/NSEC3 for authenticated denial of existence — see How DNSSEC Works.

How to Tell If a Domain Has DNSSEC

Run dig with the +dnssec flag against a validating resolver:

dig +dnssec example.com @1.1.1.1

Look for two things:

1. RRSIG records in the answer section, paired with each record set being queried. These are the signatures.
2. The AD (Authenticated Data) flag in the response header, indicating the resolver successfully validated the chain.

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
                                ^^
                                 │
                          AD flag set = validation succeeded
 
;; ANSWER SECTION:
example.com.         300  IN  A      192.0.2.1
example.com.         300  IN  RRSIG  A 13 2 300 20260601000000 ...
                                         ^^
                                          │
                                   signature record

If you see the RRSIGs but no AD flag, the resolver isn't validating — try 1.1.1.1 or 9.9.9.9, both of which validate by default. If you see no RRSIGs, the zone isn't signed.

For visualisation, DNSViz and the Verisign DNSSEC Debugger draw the full chain of trust and highlight any breakages.

When You Should Enable DNSSEC

In short: always, for any public domain.

Specific cases where it's especially important:

• High-trust services — banking, e-commerce, identity providers, government — where a successful cache-poisoning attack has direct consequences.
• Email — DNSSEC is a prerequisite for DANE/TLSA, which protects SMTP TLS against downgrade attacks. MTA-STS is a partial alternative for organisations not yet ready for DANE.
• EU regulated entities under NIS2 — Article 21(2)(h) requires "policies and procedures regarding the use of cryptography." A DNS provider that doesn't offer DNSSEC, or a deployment that hasn't enabled it, is at risk of being judged non-compliant. See the NIS2 and DNS guide for the full mapping.
• Compliance-driven environments — PCI DSS, HIPAA, ISO 27001, and various national frameworks list DNSSEC as a recommended or expected control.

There are essentially no situations where DNSSEC is a bad idea for a public zone. The historical objections — operational complexity, key-management risk, resolver compatibility — are largely solved by managed DNS providers that handle key generation, rotation, and DS publication automatically.

What to Look for in a DNSSEC-Capable DNS Provider

When evaluating a DNS provider's DNSSEC support, ask:

Enabling DNSSEC on DNScale

DNScale enables DNSSEC with one click per zone:

1. From the dashboard, open the zone.
2. Click Enable DNSSEC. DNScale generates a CSK (Combined Signing Key) using ECDSA P-256.
3. Copy the displayed DS record to your registrar. Some registrars accept it directly; some take it via API; some still require manual entry.
4. Wait 24–48 hours for the DS to propagate at the TLD.
5. Verify with dig +dnssec yourdomain @1.1.1.1 and confirm the AD flag.

Key rotation, signature refresh, and parent-zone synchronisation happen automatically. Algorithm upgrades are coordinated rolls that DNScale runs without customer-visible downtime.

For the full step-by-step including registrar-specific instructions, see DNSSEC Setup Guide for DNScale. For the underlying mechanics, see How DNSSEC Works and DNSSEC Key Management.

References

• RFC 4033 — DNS Security Introduction and Requirements
• RFC 4034 — Resource Records for the DNS Security Extensions
• RFC 4035 — Protocol Modifications for the DNS Security Extensions
• RFC 5155 — DNS Security (DNSSEC) Hashed Authenticated Denial of Existence (NSEC3)
• RFC 6781 — DNSSEC Operational Practices, Version 2
• RFC 8901 — Multi-Signer DNSSEC Models
• IANA Root Zone Trust Anchors
• DNSViz — visualiser for DNSSEC chains of trust
• Verisign DNSSEC Debugger

Related Reading

• How DNSSEC Works — KSK/ZSK/DS/DNSKEY mechanics
• DNSSEC Key Management — operational rollover procedures
• DNSSEC Setup Guide for DNScale — product walkthrough
• DNSSEC vs DNS over HTTPS — integrity vs privacy
• NIS2 and DNS Compliance — regulatory mapping
• DNS Cache Poisoning — the attack DNSSEC defeats