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 30%+ of global DNS queries. 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:
| Record | Role | Where it is published |
|---|---|---|
| DS (Delegation Signer) | Hash of a child DNSKEY, creates the link between zones | Parent zone |
| DNSKEY | Zone public key (KSK = flags 257, ZSK = flags 256) | Child zone |
| RRSIG | Cryptographic signature of a record set | Child zone |
| NSEC/NSEC3 | Authenticated proof of non-existence of a record | Child zone |
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.
What exactly does the tool check?
Simple mode
| Element | Description | Result |
|---|---|---|
| DS Records | DS records published at the parent | Match with DNSKEY, orphans, weak digest |
| DNSKEY Records | Zone public keys (KSK/ZSK) | Presence, algorithm, DS association |
| RRSIG on DS | DS RRSet signature by the parent's ZSK | Cryptographic validity + time window |
| RRSIG on DNSKEY | DNSKEY RRSet signature by the KSK | Cryptographic validity + time window |
| Algorithms | Signing algorithm type | Deprecated algorithm detection (RFC 8624) |
| DS Digests | DS hash type | Deprecated SHA-1 detection |
Full mode (additional checks)
| Element | Description | Result |
|---|---|---|
| DNSKEY consistency | Compares DNSKEY across all authoritative servers | Detects inconsistencies between servers |
| RRSIG on SOA | SOA record signature | Validity + time until expiration |
| RRSIG on NS | NS records signature | Validity + time until expiration |
| RRSIG on A/MX | A and MX records signatures | Validity + time until expiration |
| RRSIG expiration | Time until each signature expires | Alert if expiring within 7 days |
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), DSA-NSEC3-SHA1 (6) are forbidden. RSASHA1-NSEC3-SHA1 (7) is not recommended.
Action: Migrate to ECDSAP256SHA256 (algorithm 13) or ED25519 (algorithm 15). Both are stronger and produce signatures 4x smaller than RSA-2048.
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) alongside the existing SHA-1 DS. Wait 48 hours for propagation. Only then remove the SHA-1 DS. Removing the old one first will break the chain.
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 with dig (command line)
For sysadmins who prefer the terminal, dig can verify DNSSEC manually:
# Check DS records at the parent
dig DS captaindns.com +short
# Check the zone's DNSKEY records
dig DNSKEY captaindns.com +dnssec +short
# Check RRSIG on a record
dig A captaindns.com +dnssec
# Check the full chain with validation
dig captaindns.com +sigchase +trusted-key=./root.keys
These commands require DNS expertise and terminal access. The DNSSEC Checker above does the same work automatically, with visual results and zero 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:
| Host | DNSSEC | Activation | Default algorithm |
|---|---|---|---|
| Cloudflare | Automatic | One click in the dashboard, then add the DS at the registrar | ECDSAP256SHA256 (13) |
| OVH | Supported | Activation via the control panel or API | Varies by configuration |
| AWS Route 53 | Supported | Via the AWS console, create KSK then DS at the registrar | ECDSAP256SHA256 (13) |
| Gandi | Automatic | Enabled by default if Gandi is both registrar and DNS host | ECDSAP256SHA256 (13) |
| Infomaniak | Supported | Activation via the manager | ECDSAP256SHA256 (13) |
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: Use ECDSAP256SHA256 (13) or ED25519 (15). ECDSA produces signatures 4x smaller than RSA-2048. Avoid RSA unless compatibility requires it.
DS digest: Publish a DS with SHA-256 (type 2). Add SHA-384 (type 4) if your registrar supports it. Never publish SHA-1 alone.
Key rollover: Follow the RFC 7583 process. Never remove the old DS before the new one has fully propagated. Run the DNSSEC Checker after every rollover to confirm zero orphan DS records.
Monitoring: Check the chain of trust after every DNS change. RRSIG signatures have a finite lifetime. If your zone is not re-signed before expiration, resolvers return SERVFAIL without warning.
Provider migration: Before switching, confirm the new provider supports DNSSEC with the same algorithm. During migration, both key sets must coexist until propagation completes.
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 enable it?
A: DNSSEC adds cryptographic signatures to DNS responses. Without it, attackers can forge answers and redirect your traffic (cache poisoning). With DNSSEC, resolvers can verify that responses are authentic.
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 exists at the parent registry. Contact your registrar to enable it.
Q: What is an orphan DS?
A: A DS record at the parent with no matching DNSKEY in the child zone. This typically results from an incomplete key rollover. Not blocking if another valid DS exists, but it signals a configuration gap.
Q: Why does my domain return SERVFAIL after enabling DNSSEC?
A: The chain of trust is broken. Three common causes: DS/DNSKEY mismatch at the registrar, missing or expired RRSIG signatures, or authoritative servers not serving DNSKEY records. Run Full mode to find the exact 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 (1-3 seconds). Full adds multi-server DNSKEY consistency and validates RRSIG on data records: SOA, NS, A, MX (5-10 seconds).
Q: Which DNSSEC algorithms are recommended?
A: ECDSAP256SHA256 (13) and ED25519 (15). Avoid RSAMD5, DSA, and RSASHA1-NSEC3-SHA1. RFC 8624 classifies them as weak or forbidden.
Q: Does DNSSEC slow down DNS resolution?
A: Negligible impact with modern resolvers. Responses are slightly larger due to signatures, but resolvers cache validated results the same way they cache unsigned ones.
Complementary tools
| Tool | Purpose |
|---|---|
| DNS Domain Check | Complete DNS configuration audit including basic DNSSEC verification |
| DNS Lookup | Manually query DS, DNSKEY, or RRSIG records |
| DNS Propagation Test | Check the propagation of DNSSEC changes worldwide |
| RDAP Lookup | Check DNSSEC status at the registrar level |
Useful resources
- RFC 4033 - DNS Security Introduction: Introduction to DNSSEC extensions
- RFC 4034 - Resource Records for DNSSEC: Specification of DS, DNSKEY, RRSIG, NSEC records
- RFC 8624 - Algorithm Implementation Requirements: DNSSEC algorithm requirements
- RFC 7583 - DNSSEC Key Rollover Timing: Guide for key rollover
- Verisign DNSSEC Debugger: Reference tool for DNSSEC debugging
- DNSViz: Advanced DNSSEC chain visualization