What is DNSSEC and why does it matter?

DNSSEC (Domain Name System Security Extensions) is a set of DNS protocol extensions that cryptographically signs DNS responses so resolvers can verify the answers they receive have not been forged or tampered with in transit. Without DNSSEC, DNS is trust-on-first-use — a spoofed response or a poisoned cache can redirect users to a malicious server, and nothing in the base protocol lets the client detect it. DNSSEC adds a chain of digital signatures that can be traced all the way back to the root zone, which is signed by ICANN.

The problem DNSSEC solves

DNS traffic is typically unauthenticated UDP. An attacker who can see or influence the network path between a client and a resolver (or between a resolver and an authoritative server) can inject a forged answer. The Kaminsky attack of 2008 demonstrated how practical cache poisoning was at scale, and every resolver built since then has had to add random source ports, 0x20 case mixing, and other defenses — all workarounds that do not actually authenticate the data.

DNSSEC is the authentication layer that makes those workarounds unnecessary. If a resolver validates DNSSEC, a poisoned or forged response will produce a SERVFAIL instead of a wrong answer.

The record types

DNSSEC introduces several new record types:

• DNSKEY — the public key for a zone. There are typically two: a Zone Signing Key (ZSK) and a Key Signing Key (KSK).
• RRSIG — a signature over an RRset, created with the corresponding DNSKEY.
• DS — a hash of the child zone's KSK, published in the parent zone. This is how the chain of trust flows from root to TLD to your domain.
• NSEC / NSEC3 — authenticated denial-of-existence records.
• CDS / CDNSKEY — child-to-parent synchronization records for automated DS updates (RFC 7344).

How the chain of trust works

When a validating resolver asks for www.example.com, it:

1. Asks the root (.) for the authoritative name servers for com, and receives an RRSIG signed with the root ZSK. The resolver validates that using the root KSK, which it trusts by configuration.
2. Fetches the DS record for com from the root zone. This DS is a hash of the com KSK.
3. Queries com for the example.com name servers and a DS for example.com, signed by the com ZSK.
4. Queries example.com for the A record, signed by the example.com ZSK, and validates the ZSK via the DNSKEY RRset signed by the KSK — which is hashed into the DS record in the com zone.

Break the chain at any step (a missing DS, an expired RRSIG, a mismatched KSK) and validation fails.

What DNSSEC does not do

DNSSEC is not encryption. Queries and responses travel in plaintext; a passive observer can still see which domains you look up. For query privacy, pair DNSSEC with DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH).

DNSSEC also does not protect against a compromised authoritative server. If an attacker gets the zone's private key, they can sign whatever they want. Operationally, this means key storage and rotation matter.

Deploying DNSSEC

Most managed DNS providers (Cloudflare, Route 53, Google Cloud DNS, NS1, Azure DNS) support DNSSEC with one or two clicks. The workflow:

1. Enable DNSSEC at the DNS provider. This generates a KSK and ZSK and starts signing.
2. The provider displays a DS record (hash, algorithm, key tag).
3. Log into your domain registrar and paste the DS record.
4. The registrar publishes the DS in the TLD zone.
5. Wait for the TLD TTL to propagate (usually up to 48 hours).

Once the DS is visible, use a validator to confirm:

dig +dnssec example.com A
dig DS example.com @a.gtld-servers.net

A healthy response has the AD (Authenticated Data) flag set.

Algorithm choices in 2026

ECDSA P-256 (algorithm 13) is the current recommendation. It produces compact signatures, supports elliptic-curve performance, and is universally supported by validating resolvers. Ed25519 (algorithm 15) is more modern but has marginally less resolver coverage. Avoid RSA/SHA-1 (5), which is deprecated, and RSA/SHA-256 (8) produces large responses that can fragment over UDP.

TLD support and real-world gotchas

Not every TLD supports DNSSEC at the registry level. As of 2026, the .ai ccTLD operated by Anguilla does not accept DS records at the registry — you cannot create a chain of trust for .ai domains regardless of your DNS provider. The same is true of a shrinking but still notable list of ccTLDs. Before committing to DNSSEC, confirm your TLD is in the DNSSEC-enabled list at IANA.

Other real gotchas:

• Expired signatures. RRSIGs have an inception and expiration time. If your signer is broken or clock skew is large, resolvers will SERVFAIL.
• KSK rollovers. A botched rollover leaves stale DS records in the parent and breaks your domain globally. Use CDS/CDNSKEY and automation.
• CDN fronting. Some CDNs strip DNSSEC because they inject ALIAS/flattened records. Ensure your CDN supports DNSSEC if you enable it.

Troubleshooting

"My domain resolves everywhere except inside one corporate network." That network is likely running a validating resolver (Google Public DNS 8.8.8.8, Quad9 9.9.9.9, Cloudflare 1.1.1.1 all validate). Check the AD flag and the RRSIG expiration.

"I enabled DNSSEC and my site went down." Verify the DS record at the registrar matches the KSK at the provider. One digit off — one wrong key tag — breaks resolution.

"DNSKEY validates but no DS published." Your domain is signed but has no chain of trust. Validators will treat it as insecure rather than bogus, so there is no protection.

When to use IntoDNS.ai

IntoDNS.ai runs a full DNSSEC validation against your domain, checks each link in the chain (DS at parent, DNSKEY at child, RRSIG coverage, algorithm strength, signature expiration), and flags the specific broken step when validation fails. If your TLD does not support DNSSEC, it will tell you that too, rather than leaving you to guess why the DS record will not publish.

Key rollovers in operational detail

A KSK rollover is the single riskiest DNSSEC operation because it involves coordination with the parent zone (TLD). The canonical RFC 7583 "Double-DS" method:

1. Generate a new KSK.
2. Publish the new KSK's DNSKEY record alongside the old one.
3. Publish the new DS record at the parent (via the registrar's DNSSEC interface).
4. Wait for the TTL of the old DS to expire at resolvers worldwide (up to 48 hours for many TLDs).
5. Remove the old DS at the registrar.
6. Remove the old KSK DNSKEY.

Most managed DNS providers handle this automatically via CDS/CDNSKEY records (RFC 7344). The provider publishes CDS records with the new hash; the registrar's DNSSEC automation picks up the change and updates the parent DS without human intervention. Verify that your registrar supports CDS/CDNSKEY — many do; some still require manual DS updates.

ZSK rollovers are easier because they only require the child zone to change. The "pre-publish" method publishes the new ZSK DNSKEY alongside the old one for one signature validity period, then starts signing with the new ZSK and removes the old DNSKEY after the old signatures have aged out.

DNSSEC and DNS providers

Not every provider handles DNSSEC gracefully. Cloudflare, Route 53, Google Cloud DNS, NS1, and Azure DNS all support one-click signing with automated key rotation. Smaller providers may require you to bring your own keys, handle rotation manually, or not support DNSSEC at all.

Before committing to DNSSEC, check:

• Does your provider support CDS/CDNSKEY automation?
• How do they handle zone updates? Zone edits during signing can produce inconsistent responses briefly.
• Do they support negative caching with NSEC or NSEC3?
• Can they sign with ECDSA P-256? (Recommended over RSA/SHA-256 for compact responses.)

The AD flag

Validating resolvers set the AD (Authenticated Data) flag in responses to signal that DNSSEC validation succeeded. When you query:

dig @1.1.1.1 +dnssec example.com

Look for flags: qr rd ra ad in the header. The ad flag confirms Cloudflare's resolver validated the response. Absence means either DNSSEC is not deployed, the CD (Checking Disabled) bit was set in your query, or validation quietly failed — in which case you would have received SERVFAIL instead of answers.