DNSSEC Checker

Why check DNSSEC?

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS responses. Without these signatures, attackers can forge answers and hijack traffic. This attack is called DNS cache poisoning, and it is undetectable by the end user.

One misconfigured DS record is enough to break the entire chain. When that happens, validating resolvers return SERVFAIL. Your site looks fine from your network, but millions of users see nothing. No uptime monitor, no HTTP check, no ping will detect this. Only a DNSSEC-specific test reveals the problem.

An orphan DS from a botched key rollover. A signature that expired overnight. These silent failures persist for days until someone runs a check.

Four reasons to verify your DNSSEC now:

• Security: Only an intact chain of trust guarantees visitors reach your servers, not an attacker's copy
• Availability: A broken chain blocks validating resolvers, roughly one third to 40% of global DNS queries per APNIC measurements. Google, Cloudflare, and Quad9 all reject the response.
• Compliance: Financial institutions, government agencies, and healthcare organizations increasingly require DNSSEC for all domains
• Proactive detection: Spot orphan DS records, deprecated algorithms, and expiring RRSIG signatures before they trigger an outage

How to use the DNSSEC Checker in 3 steps

Step 1: Enter your domain

Type the domain you want to check: cloudflare.com, nic.fr, or any other. The tool accepts both signed and unsigned domains. If DNSSEC is not enabled, you will know instantly.

Step 2: Choose the analysis mode

• Simple mode (default): Validates the complete chain of trust by querying one authoritative server per zone. Results in 1 to 3 seconds.
• Full mode: Everything in Simple, plus DNSKEY consistency across all authoritative servers and RRSIG validation on data records (SOA, NS, A, MX). Results in 5 to 10 seconds.

Use Full mode after a key rollover, after a DNS provider migration, or during a security audit. If in doubt, start with Simple.

Step 3: Analyze the report and fix issues

The report classifies every finding by severity, zone by zone:

• Errors: Broken chain, invalid signatures, server inconsistencies. These block resolution.
• Warnings: Orphan DS, weak algorithms, RRSIG expiring soon. These need attention.
• Info: CSK detected, out-of-bailiwick NS, DS count at parent. Good to know, no action required.

What is the DNSSEC chain of trust?

The DNSSEC chain of trust works like a relay of cryptographic handoffs. Each zone vouches for the next. It starts at the DNS root and ends at your domain:

Root (.)
  |-- TLD DS --> verifies the TLD DNSKEY (KSK)
  |-- The TLD ZSK signs your domain's DS
        |-- Your domain's DS --> verifies your DNSKEY (KSK)
        |-- Your KSK signs the DNSKEY RRSet
        |-- Your ZSK signs the data (A, MX, SOA, NS)

Key records:

Every link depends on the one above it. Break one, and the entire chain collapses. Resolvers return SERVFAIL for the whole domain, not just the broken zone.

NSEC and NSEC3: authenticated proof of non-existence

DNSSEC does not only sign records that exist. It also proves, in an authenticated way, that a given name or record type does not exist. Without this proof, an attacker could deny the existence of a record that is in fact signed. Two mechanisms provide this proof of non-existence:

• NSEC (Next Secure) chains the zone's names in alphabetical order. Each NSEC record points to the next existing name. The drawback: by following this chain step by step, anyone can enumerate every name in the zone. This is called zone walking.
• NSEC3 (RFC 5155) fixes this by publishing hashes of the names instead of the names in clear text. Zone walking becomes far more expensive, since the hashes must be cracked. NSEC3 adds a salt and an iteration count.

NSEC3 opt-out is an option intended for very large zones (TLDs, zones with many unsigned delegations). It skips generating an NSEC3 proof for insecure delegations, which reduces zone size and signing cost. The trade-off is that opt-out does not authenticate the absence of those delegations.

For most domains, either NSEC or NSEC3 is fine. NSEC3 is preferable if zone enumeration is a concern.

What exactly does the tool check?

Simple mode

Full mode (additional checks)

Common diagnostics and solutions

Orphan DS (DNSSEC_DS_ORPHAN)

Symptom: A DS record is published at the parent but no matching DNSKEY exists in your zone.

Likely cause: Incomplete key rollover. The old key was removed from the zone before the DS was updated at the registrar.

Action: Remove the orphan DS via your registrar's interface. Or re-add the matching DNSKEY to your zone. Rerun the checker to confirm the chain is clean.

Weak algorithm (DNSSEC_WEAK_ALGO)

Symptom: Your zone uses a signing algorithm considered insecure per RFC 8624.

Affected algorithms: RSAMD5 (1), DSA (3), and DSA-NSEC3-SHA1 (6) are forbidden for signing. RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) are not recommended.

Action: Migrate to a recommended algorithm: RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14), or Ed25519 (15). Rerun the checker to confirm.

SHA-1 digest (DNSSEC_WEAK_DIGEST)

Symptom: Your DS uses SHA-1 (type 1) as the digest type.

Action: Add a DS with SHA-256 (type 2), or SHA-384 (type 4) if your registrar supports it, alongside the existing SHA-1 DS. Wait 48 hours for propagation, then remove the SHA-1 DS. Rerun the checker to confirm.

SERVFAIL after enabling DNSSEC

Symptom: Your domain returns SERVFAIL for validating resolvers after enabling DNSSEC.

Common causes:

• DS at the registrar does not match your zone's DNSKEY
• RRSIG signatures not generated or expired
• Authoritative servers not serving DNSKEY records

Action: Run the test in Full mode. The tool pinpoints exactly which link in the chain is broken. Start by checking that the DS at the registrar matches your zone's KSK: same key tag, same algorithm.

DNSKEY inconsistency between servers (DNSSEC_SERVER_INCONSISTENT)

Symptom: Your authoritative servers return different DNSKEY sets. This is only detected in Full mode.

Likely cause: Zone transfer between primary and secondaries did not complete. Or one server has stale data.

Action: Verify replication between your DNS servers. Force a zone transfer (AXFR/IXFR) if needed. Wait a few minutes, then rerun the test.

Check DNSSEC from the command line (delv and dig)

For system administrators, two tools let you verify DNSSEC manually. delv (shipped with BIND 9.10 and later) performs a full chain of trust validation and prints a final verdict. dig queries the raw records (DS, DNSKEY, RRSIG) but does not validate the chain itself.

Note: the old dig +sigchase and +trusted-key options have been removed from modern BIND releases. Use delv instead for validation.

# Validate the full chain of trust (final verdict)
delv captaindns.com A

# Trace each step of the validation
delv @1.1.1.1 captaindns.com A +rtrace

# Validate and display the zone's DNSKEY records
delv captaindns.com DNSKEY

# View the DS records published at the parent
dig DS captaindns.com +short

# View the DNSKEY records and their RRSIG signatures (no validation)
dig DNSKEY captaindns.com +dnssec

# View the RRSIG on an A record
dig A captaindns.com +dnssec

A validated delv response shows ; fully validated; a validation failure shows ; resolution failed. These commands require terminal access and DNS expertise. The DNSSEC Checker above automates the entire process and presents the results visually, with no command line.

DNSSEC by DNS host

DNSSEC activation depends on your DNS host and your registrar working together. Here is how the major providers compare:

After enabling DNSSEC at your host, always verify the chain of trust with the checker above. The #1 mistake: a DS at the registrar that does not match the DNSKEY generated by the host.

DNSSEC best practices

Signing algorithm: Prefer an elliptic curve algorithm: ECDSAP256SHA256 (13) or Ed25519 (15). RSASHA256 (8) and ECDSAP384SHA384 (14) remain widely deployed and accepted. ECDSA produces signatures roughly 3.5 to 4 times more compact than RSA-2048, which reduces response size.

DS digest: Publish a DS with SHA-256 (type 2); SHA-384 (type 4) is also accepted. SHA-1 (type 1) is deprecated: never publish a SHA-1 DS on its own.

Key rollover: Follow the practices in RFC 6781 and 7583 (see the dedicated section below). Never remove the old DS before the new one has propagated.

Monitoring: Check the chain after every DNS change. A zone that is not re-signed in time triggers SERVFAIL.

Provider migration: Confirm the new provider supports the same algorithm. Both key sets must coexist during propagation.

Signing key rollover

A DNSSEC key does not last forever. It must be replaced periodically (a rollover) without breaking the chain of trust. RFC 6781 (operational practices) and 7583 (timing) describe these procedures. The exact steps differ depending on the key type.

KSK rollover (Key Signing Key). The KSK is referenced by the DS at the parent. The common method is the double-DS approach: publish the DS for the new KSK at the parent, wait until all caches have picked up both DS records, switch the DNSKEY RRSet signature to the new KSK, then remove the old DS. The delay depends on the TTL of the DS at the parent.

ZSK rollover (Zone Signing Key). The ZSK signs the data and is not tied to the parent. Two methods:

• Pre-publish: publish the new ZSK in the DNSKEY RRSet before using it, wait for propagation, sign the data with the new key, then remove the old one. This is the recommended method for the ZSK.
• Double-signature: sign the data with both the old and new ZSK at the same time. Easier to reason about, but it doubles the number of signatures and inflates responses.

Risks of a botched rollover. Removing a key or a DS before the caches that reference it have expired breaks the chain: validating resolvers return SERVFAIL. Never remove the old key or the old DS before all the relevant TTLs have expired. Check for orphan DS records after every KSK rollover.

CDS and CDNSKEY: automating the DS at the parent

The weak point of a KSK rollover is updating the DS manually at the registrar. A bad copy-paste breaks the chain. The CDS and CDNSKEY records (RFC 7344 and 8078) automate this step.

The child zone publishes a CDS (Child DS) or a CDNSKEY (Child DNSKEY) that tells the parent which DS to publish. The registrar or registry periodically scans these records and updates the DS automatically, with no manual intervention. Two uses:

• Bootstrapping (RFC 8078): the first DNSSEC activation, when no DS yet exists at the parent.
• Maintenance: updating the DS during subsequent KSK rollovers.

Not every registry supports CDS/CDNSKEY yet, but adoption is growing. Where they are supported, they remove the main source of error in KSK rollovers. Afterwards, check the chain with the DNSSEC Checker to confirm the published DS matches your KSK.

Real-world use cases

Enabling DNSSEC at a new registrar

You just enabled DNSSEC. Run a Simple mode check right away. Confirm that the DS at the parent matches your zone's DNSKEY. One mismatch means SERVFAIL for every validating resolver.

Key rollover

After a key rollover, check for orphan DS records with Simple mode. A leftover DS does not break resolution today, but it signals incomplete maintenance. It will complicate your next rollover.

DNS provider migration

Migrating to Cloudflare, Route 53, or another host? Run Full mode. Verify three things: DS records point to the new DNSKEY, signatures are valid on all authoritative servers, and keys are consistent across every server.

Security audit

Full mode is your DNSSEC compliance report. It covers DNSKEY consistency across all authoritative servers, signature validity on data records (SOA, NS, A, MX), and days until each RRSIG expires.

Domain returning SERVFAIL

Users report your site is unreachable from certain networks? Those networks likely use validating resolvers. Run the test immediately. If the chain is broken, the tool shows you exactly where.

FAQ - Frequently asked questions

Q: What is DNSSEC and why should you enable it?

A: DNSSEC adds cryptographic signatures to DNS responses. Without DNSSEC, an attacker can forge responses and redirect traffic. Enabling DNSSEC ensures visitors reach your servers, not an attacker's.

Q: How do I check if DNSSEC is enabled on my domain?

A: Enter your domain in the tool above. If it shows "DNSSEC is not enabled", no DS record is published at the parent. Contact your registrar to enable DNSSEC.

Q: What is an orphan DS?

A: A DS record at the parent with no matching DNSKEY in the child zone. It happens during an incomplete key rollover. Not blocking as long as another valid DS exists, but it signals an incomplete configuration.

Q: Why does my domain return SERVFAIL after enabling DNSSEC?

A: The chain of trust is broken. Common causes: a DS that does not match the DNSKEY, missing or expired RRSIG signatures, DNSKEY records not being served. Run Full mode to pinpoint the failing link.

Q: What is the difference between Simple and Full modes?

A: Simple checks the DS/DNSKEY/RRSIG chain on one server per zone. Full adds multi-server DNSKEY consistency and validates RRSIG on SOA, NS, A, and MX.

Q: Which DNSSEC algorithms are recommended?

A: The common, recommended algorithms are RSASHA256 (8), ECDSAP256SHA256 (13), ECDSAP384SHA384 (14), and Ed25519 (15). Per RFC 8624, RSAMD5 (1), DSA (3), and DSA-NSEC3-SHA1 (6) are forbidden; RSASHA1 (5) and RSASHA1-NSEC3-SHA1 (7) are not recommended.

Q: NSEC or NSEC3: what is zone walking?

A: NSEC and NSEC3 provide authenticated proof that a name does not exist. NSEC lists names in clear text, which makes it possible to enumerate the entire zone (zone walking). NSEC3 (RFC 5155) publishes hashes instead of names to prevent this enumeration.

Q: What are CDS and CDNSKEY records for?

A: CDS and CDNSKEY (RFC 7344 and 8078) let the child zone signal to the parent which DS to publish. The registrar or registry scans these records to create and then automatically maintain the DS, with no manual copy-paste on every KSK rollover.

Q: Does DNSSEC slow down DNS resolution?

A: The impact stays limited, but signed responses are larger. They can exceed the size of a UDP packet and cause fragmentation or a fallback to TCP. Resolvers cache validated results, which amortizes the cost after the first query.

Complementary tools

Useful resources

• RFC 4033 - DNS Security Introduction: Introduction to and requirements for the DNSSEC extensions
• RFC 4034 - Resource Records for DNSSEC: Specification of the DS, DNSKEY, RRSIG, and NSEC records
• RFC 4035 - Protocol Modifications for DNSSEC: Behavior of validating resolvers and servers
• RFC 5155 - DNSSEC Hashed Authenticated Denial of Existence: Specification of NSEC3
• RFC 6781 - DNSSEC Operational Practices: Operational best practices and rollovers
• RFC 7583 - DNSSEC Key Rollover Timing: Key rollover timing
• RFC 8624 - Algorithm Implementation Requirements: DNSSEC algorithm requirements
• Verisign DNSSEC Debugger: Reference tool for DNSSEC debugging
• DNSViz: Advanced DNSSEC chain visualization