DNSprobe Wiki · DNSSEC section
DNSSEC (Domain Name System SECurity extensions) zone signing and validation checks
DNSprobe inspects your DNSSEC configuration to make sure your zone is properly signed and resolvers can validate your records reliably.
DNSSEC adds a cryptographic signature layer on top of classic DNS. It protects your users against cache poisoning and certain man-in-the-middle attacks by allowing resolvers to verify that the DNS data really comes from you.
However, DNSSEC is unforgiving: a single missing record, an expired key or a broken DS at the parent can instantly make your domain unreachable for validating resolvers.
DNSprobe helps you understand how your DNSSEC chain is built, where problems can appear, and how to fix them before they cause outages.
What DNSprobe checks in the DNSSEC section
How DNSprobe evaluates DNSSEC for your domain
DNSprobe queries your authoritative nameservers with DNSSEC-enabled queries (+dnssec) in order to retrieve RRSIG, DNSKEY, DS and NSEC/NSEC3 records. When needed, it also talks to parent TLD servers to compare what they publish for your domain.
The tool then reconstructs the trust chain, checks that signatures match the right keys and that key algorithms and sizes are considered secure according to current best practices.
If anything looks inconsistent, missing or weak, DNSprobe flags it clearly in the DNSSEC section so you can correct the issue at your DNS provider or registrar.
1. Zone signed
This test verifies whether your zone is signed with DNSSEC and if the main records (SOA, NS, A/AAAA, MX, etc.) have valid RRSIG signatures.
Why this matters
If your zone is not signed, DNSSEC offers no protection at all. If it is partially signed or signatures are missing on key records, validating resolvers may treat responses as insecure or even bogus, depending on the situation.
How DNSprobe checks it
DNSprobe sends queries with the DO (DNSSEC OK) bit to your nameservers and inspects the presence and validity of RRSIGs for the most important RRsets. It also checks whether the signing keys use algorithms that are still considered secure.
Typical problems detected
- The zone is not signed at all (no RRSIG records for any RRset).
- RRSIG records are present but expired or not yet valid (clock or rollover issues).
- Critical records (SOA, NS, apex A/AAAA) are missing signatures, or signatures use deprecated algorithms.
Best practices
- Enable DNSSEC signing for the whole zone at your DNS provider, not only for a subset of records.
- Monitor key rollover schedules so RRSIG validity windows never overlap incorrectly.
- Use recommended algorithms and key sizes (for example, ECDSA P-256 or RSA 2048+), and keep your DNS software up to date.
2. DNSKEY records
DNSKEY records publish the public keys used to sign your zone. They are the foundation of DNSSEC validation for your domain.
Why this matters
If DNSKEY records are missing, inconsistent, or use weak algorithms, resolvers cannot verify your signatures reliably. A broken DNSKEY set can turn your entire domain into a SERVFAIL for validating resolvers.
How DNSprobe checks it
DNSprobe queries the DNSKEY RRset at your zone apex and verifies that key tags and algorithms match the RRSIGs it observes on your records. It also checks whether separate KSK/ZSK roles are used and if key sizes are within recommended ranges.
Typical problems detected
- Missing DNSKEY RRset or only one key where a split KSK/ZSK setup is expected.
- Algorithms or key sizes that are deprecated or considered too weak for production.
- RRSIGs referring to key tags that do not exist in the published DNSKEY set (stale or incomplete rollover).
Best practices
- Use a dedicated KSK for signing the DNSKEY RRset and one or more ZSKs for the rest of the zone.
- Follow your DNS software’s recommended rollover procedures to avoid mismatches between DNSKEY and RRSIG.
- Avoid obsolete algorithms; prefer modern choices recommended by your registry or DNS operator.
3. DS record in parent
This test checks whether the parent zone (for example, .com or .ca) publishes a DS record that correctly points to your DNSKEY, closing the trust chain from the root down to your domain.
Why this matters
Without a correct DS record in the parent zone, resolvers cannot build a full DNSSEC chain of trust. Your zone might be signed, but it will still be treated as insecure by validating resolvers.
How DNSprobe checks it
DNSprobe queries the parent TLD nameservers for DS records, compares their digest, key tag and algorithm with your DNSKEY set, and verifies that they match one of your published KSKs.
Typical problems detected
- No DS record published at the parent while the child zone is signed.
- DS record present but using a digest or key tag that does not correspond to any of your current DNSKEYs.
- Old DS records left in place after a key rollover, causing validation failures for some resolvers.
Best practices
- After enabling DNSSEC, always publish the DS at your registrar and confirm it matches the active KSK.
- During key rollover, update the DS in the parent in sync with your DNSKEY changes.
- If you disable DNSSEC, remove the DS record from the parent before or at the same time as you stop signing the zone.
4. NSEC / NSEC3 records
NSEC and NSEC3 records are used to provide authenticated denial of existence: they prove that a name or record type does not exist in your zone.
Why this matters
If NSEC or NSEC3 chains are broken or inconsistent, negative answers may fail validation and be treated as SERVFAIL. Poorly configured NSEC3 can also leak more information than intended or make troubleshooting harder.
How DNSprobe checks it
DNSprobe sends queries for non-existent names and types to trigger NSEC or NSEC3 responses, then inspects whether the denial-of-existence records and their signatures are consistent with the rest of your zone.
Typical problems detected
- Missing NSEC/NSEC3 records when DNSSEC is enabled and negative answers should be signed.
- NSEC or NSEC3 records present but with invalid or expired RRSIGs.
- Inconsistent NSEC3 parameters between records, or configurations that may expose too much zone structure.
Best practices
- Choose between NSEC and NSEC3 according to your registry and privacy requirements.
- Make sure your DNS software maintains correct and continuous NSEC/NSEC3 chains after every zone update.
- Review NSEC3 parameters (iterations, salt) so they balance privacy and performance and follow your registry’s recommendations.
5. Test DNSSEC manually from your own terminal
The DNSSEC section in DNSprobe checks whether your zone is signed, whether DNSKEY and DS records are present and if denial-of-existence is correctly configured with NSEC or NSEC3. You can inspect these records yourself from a terminal using dig with the +dnssec option.
Linux: using dig with +dnssec
On most Linux distributions, the dig command is provided by the BIND utilities package. The examples below show how to verify that your zone is signed, that DNSKEY and DS records exist, and that denial-of-existence records are returned for names that do not exist:
dig example.com A +dnssec +noall +answer
# Check if the A record for example.com is accompanied by an RRSIG, which indicates the zone is signed
dig example.com DNSKEY +dnssec +noall +answer
# List the DNSKEY records for your zone (these contain the public keys used to validate signatures)
dig example.com DS +dnssec +noall +answer
# Check for DS records published at the parent; these link your zone keys to the registry
dig nonexistent-subdomain.example.com A +dnssec +noall +answer
macOS: using dig from the built-in tools
macOS ships with dig as part of its standard command-line tools. Open Terminal and run the same commands as on Linux to verify signatures on your records, inspect DNSKEYs and confirm that DS records exist in the parent zone:
dig example.com A +dnssec +noall +answer
# Check if the A record for example.com is accompanied by an RRSIG, which indicates the zone is signed
dig example.com DNSKEY +dnssec +noall +answer
# List the DNSKEY records for your zone (these contain the public keys used to validate signatures)
dig example.com DS +dnssec +noall +answer
# Check for DS records published at the parent; these link your zone keys to the registry
dig nonexistent-subdomain.example.com A +dnssec +noall +answer
Windows: using dig via WSL
Windows does not include dig by default, but if you enable the Windows Subsystem for Linux (WSL), you can run the same dig commands as on Linux/macOS. From a Command Prompt or PowerShell window, prefix the commands with wsl:
wsl dig example.com A +dnssec +noall +answer
REM Check if the A record for example.com is accompanied by an RRSIG, which indicates the zone is signed
wsl dig example.com DNSKEY +dnssec +noall +answer
REM List the DNSKEY records for your zone (these contain the public keys used to validate signatures)
wsl dig example.com DS +dnssec +noall +answer
REM Check for DS records published at the parent; these link your zone keys to the registry and allow validation to chain from the TLD
wsl dig nonexistent-subdomain.example.com A +dnssec +noall +answer
Important: only query DNS records for domains that you own or are authorised to analyse. Repeated automated DNSSEC lookups against third-party domains or TLD servers without permission may be treated as abusive traffic by some providers.
Summary: keeping DNSSEC healthy
A robust DNSSEC setup requires all pieces to work together: a fully signed zone, correct DNSKEY records, a matching DS at the parent and healthy NSEC/NSEC3 chains for negative answers.
DNSprobe gives you a human-readable view of this chain and points out exactly where misconfigurations appear, so you can fix them quickly with your DNS provider or registrar.
Need help understanding a DNSSEC error in your report?
If a DNSSEC warning or failure in DNSprobe is unclear, contact your DNS hosting provider or registrar with a screenshot of the DNSSEC section. Many providers also document their DNSSEC rollover and DS publish procedures—following them carefully is the safest way to avoid outages.