Here’s a scenario that happens more often than most people admit: a domain owner enables DNSSEC through their registrar’s dashboard, sees a green checkmark, and assumes everything is working. Weeks later, their monitoring tool flags that 30% of users are getting SERVFAIL errors. The DNSSEC chain was broken the whole time — they just never checked properly.
Enabling DNSSEC and verifying DNSSEC are two completely different things. And in cybersecurity, “I think it’s working” is never good enough.
DNSSEC enabled checking isn’t a one-time event. It’s an ongoing practice — one that requires the right tools, the right commands, and a clear understanding of what a healthy DNSSEC chain looks like versus a broken one.
In this guide, I’m going to walk you through everything you need: why checking DNSSEC status matters, what to look for, and exactly how to perform DNSSEC enabled checking using both command-line tools and web-based platforms. By the end, you’ll be able to verify any domain’s DNSSEC status in under five minutes.
Key Fact: According to APNIC’s 2024 global DNS measurement data, approximately 31% of internet users are now served by DNSSEC-validating resolvers. Yet studies show that a significant percentage of DNSSEC-signed domains have configuration errors — meaning their signatures exist but may not validate correctly.
Why DNSSEC Status Checking Actually Matters!
Most domain owners treat DNSSEC like a light switch: flip it on, job done. But DNS security doesn’t work that way. A DNSSEC configuration can appear active while silently failing in ways that range from inconvenient to catastrophic.
Here’s why actively performing DNSSEC enabled checking is a critical security practice:
- Silent failures are common: DNSSEC breakages often go undetected for hours or even days. Expired RRSIG records don’t generate alerts by default — they just quietly block resolution for millions of users on validating resolvers.
- Configuration drift: DNS environments change constantly. Zone transfers, provider migrations, and registrar updates can corrupt your DNSSEC chain without any obvious notification.
- Partial validation: Your domain might have DNSSEC signing enabled but no DS record at your registrar — meaning the chain of trust is incomplete and validators still reject your domain.
- Compliance requirements: Government agencies, financial institutions, and healthcare organizations operating under frameworks like FedRAMP, PCI-DSS, or HIPAA increasingly require verified DNSSEC deployment — not just claimed deployment.
- Vendor accountability: Checking independently confirms your DNS provider or registrar is actually doing what they promised. Provider dashboards can show “Enabled” while the actual cryptographic chain has issues.
The bottom line: never trust a dashboard indicator alone. Trust the cryptographic verification.
What a Healthy DNSSEC Configuration Looks Like?
Before you can spot problems, you need to know what “good” looks like. A properly configured DNSSEC setup requires all of the following components to be present and valid:
- DNSKEY records: Your zone must publish at least two DNSKEY records — a Zone Signing Key (ZSK) and a Key Signing Key (KSK). These are your zone’s public keys.
- RRSIG records: Every DNS resource record set in your zone must have a corresponding RRSIG (Resource Record Signature) that is valid, non-expired, and verifiable against your DNSKEY.
- DS record in parent zone: Your registrar must have published a Delegation Signer (DS) record in your parent zone (.com, .org, etc.). This DS record is the fingerprint of your KSK and anchors the chain of trust.
- NSEC or NSEC3 records: These records authenticate negative responses (proving a record doesn’t exist). Their presence confirms your zone signing is complete.
- Unbroken chain: The cryptographic chain from the DNS root → TLD → your domain must be intact. Every validator in the path must be able to verify the next level.
Important Distinction: There’s a critical difference between a signed zone and a validated zone. Your zone can be signed (RRSIG records exist) but not validate correctly if the DS record is missing, mismatched, or if signatures have expired. DNSSEC enabled checking must verify both signing and validation.
Method 1: Web-Based DNSSEC Checking Tools
If you’re not comfortable with the command line, or you want a quick visual overview, these web tools are your best friends for DNSSEC enabled checking.
Tool 1: DNSViz (dnsviz.net)
DNSViz is the gold standard for DNSSEC visualization. It maps your entire DNSSEC chain graphically, showing every record, every link, and every validation step — color-coded for instant diagnosis.
How to use it:
- Go to dnsviz.net in your browser.
- Type your domain name in the search box and click Analyze.
- Wait 30–60 seconds while DNSViz queries the live DNS chain.
- Review the visual output: green nodes and solid lines indicate a healthy chain. Red nodes, dashed lines, or warning icons indicate problems.
- Click on any node or connection to see detailed diagnostic information about that specific record.
What to look for: a fully green diagram from the root through to your domain means your DNSSEC chain is intact and validating correctly. Any red, orange, or broken elements require investigation.
Tool 2: Verisign DNSSEC Analyzer
Verisign’s DNSSEC Debugger provides a detailed text-based analysis of your DNSSEC configuration. It’s particularly useful for identifying exactly which record or link is causing a validation failure.
Access it at: dnssec-analyzer.verisignlabs.com — simply enter your domain and hit Enter. The report will walk through each DNSSEC component and flag any issues with plain-language explanations.
Tool 3: Zonemaster (zonemaster.net)
Zonemaster performs comprehensive DNS and DNSSEC testing, including checks for common misconfigurations that other tools might miss. It’s especially valuable for pre-launch DNSSEC verification and post-migration testing.
Zonemaster tests for:
- Correct DNSKEY algorithm types (flagging deprecated algorithms like RSASHA1).
- RRSIG expiry windows that are too short or already expired.
- DS record presence and correctness at the parent zone.
- NSEC / NSEC3 record availability and configuration.
- Consistency across all authoritative nameservers.
Tool 4: DNSSEC Lookup (dnssec-analyzer.com / mxtoolbox.com)
For a quick, no-frills DNSSEC enabled checking result, MXToolbox’s DNSSEC lookup tool gives you an instant pass/fail status. Navigate to mxtoolbox.com/SuperTool.aspx, select “DNSSEC” from the dropdown, enter your domain, and run the test. It’s not as detailed as DNSViz, but it’s fast and beginner-friendly.
Method 2: Command-Line DNSSEC Checking
For security professionals and sysadmins, command-line tools provide the most precise and scriptable DNSSEC enabled checking. The primary tool is dig (Domain Information Groper), available on Linux, macOS, and Windows Subsystem for Linux.
Check 1: Verify DNSKEY Records Exist
Run: dig DNSKEY yourdomain.com +short — This queries for your zone’s public keys. A healthy response returns one or more DNSKEY records. No output means DNSKEY records are missing — a fundamental DNSSEC failure.
Check 2: Verify RRSIG Records and Expiry
Run: dig +dnssec A yourdomain.com — Look for RRSIG records in the ADDITIONAL section of the response. Check the expiry date embedded in the RRSIG — it’s listed as a timestamp. If that date is in the past, your signatures are expired.
Check 3: Verify DS Record in Parent Zone
Run: dig DS yourdomain.com @8.8.8.8 — This queries Google’s resolver specifically for your DS record in the parent zone. A healthy response returns a DS record with a key tag, algorithm number, and digest. No DS record means your registrar hasn’t published the delegation signer — your chain of trust is broken even if your zone is signed.
Check 4: Full DNSSEC Validation Test
Run: dig +dnssec +cd yourdomain.com A @1.1.1.1 — The +cd flag disables checking (returns the response even if validation fails), which lets you compare against a +dnssec query without +cd. If the +cd query works but the regular query returns SERVFAIL, your DNSSEC is broken.
Check 5: Test From a Validating Resolver
Run: dig +dnssec yourdomain.com @8.8.8.8 — If this returns a valid answer with the AD (Authenticated Data) flag set in the response flags section, your DNSSEC is validating correctly. The AD flag is your cryptographic green light.
The AD Flag: When you run a dig query and see “ad” in the flags line of the response header (e.g., flags: qr rd ra ad), that Authenticated Data flag confirms the resolver successfully validated the DNSSEC signatures. This is the most reliable single indicator of working DNSSEC from a user perspective.
Interpreting Your DNSSEC Check Results
Once you’ve run your checks, here’s how to interpret what you’re seeing:
- SERVFAIL response: The validating resolver rejected your DNSSEC. Something in your chain is broken — expired signatures, DS mismatch, or missing records. Use DNSViz to pinpoint the exact failure.
- No RRSIG records: Your zone isn’t signed. Either DNSSEC signing was never enabled at your DNS provider, or the signing pipeline has failed silently.
- No DS record: Your zone may be signed, but the chain of trust isn’t anchored. Your registrar hasn’t published the DS record — or it was deleted accidentally.
- AD flag missing: The resolver processed the query but didn’t validate DNSSEC. Either the resolver doesn’t validate, or your signatures didn’t pass validation.
- Algorithm type 1 or 5: Deprecated RSASHA1 algorithms. Some validators may still accept these, but you should upgrade to Algorithm 8 (RSA/SHA-256) or Algorithm 13 (ECDSA P-256) immediately.
- Expiry date within 7 days: Urgent: your signatures are about to expire. Trigger a re-sign immediately and investigate why your automated signing isn’t refreshing them.
Common Gotcha: Many registrars and DNS providers display “DNSSEC: Active” or show a green status indicator in their dashboards even when the underlying cryptographic chain has issues. These dashboard indicators check whether DNSSEC is configured in their system — not whether it’s actually validating correctly on the public internet. Always verify externally.
Building DNSSEC Monitoring Into Your Security Routine
A single point-in-time check isn’t enough. DNSSEC is a living configuration that can break at any time due to expiry, provider changes, or configuration drift. Here’s how to build ongoing DNSSEC enabled checking into your operations:
- Set signature expiry alerts: Configure monitoring to alert you at least 14 days before RRSIG expiry. Most professional monitoring platforms (Datadog, New Relic, Nagios) support DNSSEC checks via plugins or custom scripts.
- Automate weekly DNSViz checks: Schedule a weekly automated query to DNSViz or Zonemaster and pipe results into your SIEM or alerting channel. Many teams use cron jobs with the Zonemaster CLI for this.
- Monitor the DS record: Regularly verify your DS record against your DNSKEY with: dig DS yourdomain.com @8.8.8.8 and compare the digest to your current KSK. A mismatch means silent failure is imminent.
- Test after every DNS change: Make DNSSEC verification a mandatory post-change checklist item. Any zone update, nameserver change, or provider modification should be followed by a full DNSSEC check.
- Use synthetic monitoring: Services like StatusCake, Uptime Robot (with custom DNS checks), and Catchpoint can perform ongoing DNSSEC validation tests from multiple geographic locations.
Frequently Asked Questions
1. What’s the fastest way to check if DNSSEC is working for my domain?
The fastest method is a dig command: run dig +dnssec yourdomain.com @8.8.8.8 and look for the AD (Authenticated Data) flag in the response header. If you see “ad” in the flags line, your DNSSEC is validating correctly. For a visual check without the command line, enter your domain at dnsviz.net — a fully green diagram means your chain is healthy. Both checks take under two minutes.
2. My registrar dashboard says DNSSEC is enabled, but my checks show problems. Why?
Registrar dashboards report whether DNSSEC is configured in their system — they don’t always perform live cryptographic validation. Common causes of this disconnect include: a DS record that was set up but never matches the current KSK (especially after a key rollover), RRSIG records that have since expired at the DNS provider level, or a provider migration that left the DS record pointing to the old provider’s key. Always trust external verification over dashboard indicators.
3. How often should I check my DNSSEC status?
At minimum, you should perform a full DNSSEC enabled checking after any DNS change — zone updates, nameserver modifications, provider migrations, or registrar account changes. Beyond that, set up automated monitoring to check weekly and alert you when RRSIG records are within 14 days of expiry. For high-traffic or security-critical domains (financial, healthcare, government), daily automated checks are standard practice.
4. What does SERVFAIL mean when I’m checking DNSSEC?
SERVFAIL (Server Failure) from a validating resolver almost always means your DNSSEC failed validation. The resolver tried to verify your DNS responses cryptographically and couldn’t — so it refuses to return an answer rather than return an unverified one. This is DNSSEC working as designed: fail-closed to protect users. Common SERVFAIL triggers include expired RRSIG signatures, a DS record mismatch in the parent zone, missing DNSKEY records, or a broken NSEC/NSEC3 chain. Use DNSViz immediately to pinpoint which component failed.
5. Can I check DNSSEC status for domains I don’t own?
Absolutely. DNSSEC records are publicly verifiable by design — that’s the whole point. You can check the DNSSEC status of any domain using dig, DNSViz, or Zonemaster without owning or having admin access to the domain. This is useful for vendor security assessments, competitive analysis, or verifying that a third-party service you rely on has proper DNS security in place. Many security teams include DNSSEC verification in their third-party risk management processes.
Don’t Guess. Verify. Protect.
Assuming your DNSSEC is working is one of the most dangerous habits in DNS management. Broken DNSSEC doesn’t announce itself — it silently blocks your users, tanks your traffic, and leaves your domain vulnerable until someone notices.
The tools to verify your DNSSEC status are free, fast, and available right now. There’s no excuse for not knowing whether your chain of trust is intact.
Take these steps in the next 10 minutes:
- Go to dnsviz.net and run a DNSSEC check on your domain right now.
- Run: dig +dnssec yourdomain.com @8.8.8.8 and look for the AD flag.
- Verify your DS record: dig DS yourdomain.com @8.8.8.8 — make sure it matches your KSK.
- Check your RRSIG expiry dates — if they’re within 14 days, escalate immediately.
- Set up automated DNSSEC monitoring with alerts — don’t rely on manual spot checks.
- Add DNSSEC verification to your post-change checklist for every DNS update.
A five-minute check today could prevent a multi-hour outage tomorrow. Your users and your brand deserve that assurance.
