DNSSEC Test: Check DNS Security Extensions for a Domain

Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.

To check DNSSEC, first identify which question you need answered. A domain check verifies that a zone publishes a valid DNSSEC authentication chain from its delegation to its signed records. A resolver check tests whether one recursive DNS resolver actually validates DNSSEC signatures. These are different tests and can produce different results.

Use DNSViz or the Verisign DNSSEC Debugger for a domain-level diagnosis. To test a resolver, query ICANN’s deliberately broken dnssec-failed.org and interpret the response as described below.

#	Preview	Product	Price
1		Network Security: Private Communication in a Public World (Prentice Hall Series in Computer...	$63.20	Buy on Amazon
2		CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)	$41.83	Buy on Amazon
3		Cybersecurity For Dummies (For Dummies: Learning Made Easy)	$13.53	Buy on Amazon
4		Network Security, Firewalls, and VPNs	$66.62	Buy on Amazon
5		The Practice of Network Security Monitoring: Understanding Incident Detection and Response	$46.48	Buy on Amazon

Choose the DNSSEC test that matches your question

A successful answer to one question does not prove the other. A correctly signed domain can still appear unavailable through a broken resolver, while a non-validating resolver may return an answer for a domain whose DNSSEC chain is invalid.

Check a domain’s DNSSEC chain with DNSViz

DNSViz describes itself as a visual analysis tool for “the DNSSEC authentication chain for a domain name and its resolution path in the DNS namespace,” and it lists configuration errors detected by the tool. Enter the domain name without a URL scheme, such as example.com, and start a new analysis.

#1 Best Overall

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

Buy on Amazon

1. Open dnsviz.net.
2. Enter the domain you want to investigate and run an analysis.
3. Follow the delegation from the parent zone to the authoritative nameservers.
4. Inspect the DS and DNSKEY relationships and any signature or timing warnings shown in the chain.
5. Record the exact name, record type and server associated with each warning before contacting your DNS operator.

The visualization is useful because it shows the path a validating resolver follows rather than merely reporting “DNSSEC on” or “off.” A break can occur at the parent delegation, at the authoritative DNSKEY set, or in the signatures covering individual records. Treat the display as a diagnostic lead: confirm the underlying records and signing settings with the DNS provider or administrator responsible for the zone.

Current DNSViz availability note

The DNSViz page currently reports that the service is in maintenance mode. It can run new analyses, but it cannot load historical analyses and will not save new analyses to its database. This status can change, so check the notice on the service before relying on old analysis links.

Use the Verisign DNSSEC Debugger for an alternate or advanced check

The Verisign DNSSEC Debugger also accepts a domain name and reports problems in its DNSSEC setup. It has an option that is particularly useful when normal public delegation is not the situation you need to test: you can supply a DS or DNSKEY trust anchor and specify alternative authoritative starting nameservers.

1. Open the debugger and enter the domain.
2. Run the standard check first so you have a baseline for the publicly delegated chain.
3. For a controlled or pre-delegation test, provide the DS or DNSKEY trust anchor supplied by the zone operator.
4. If required, enter the authoritative nameserver addresses you want the debugger to query.
5. Compare the resulting chain with the records and signing configuration held by your DNS operator.

Custom trust anchors and nameservers are troubleshooting inputs, not evidence that the public Internet delegation is fixed. A test can succeed against an alternative starting point while ordinary validating resolvers still follow a broken parent DS delegation.

Rank #2

Sale

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

Buy on Amazon

Check whether a recursive resolver validates DNSSEC

Resolver validation is a behavior test. ICANN’s procedure uses dnssec-failed.org, a domain intentionally configured so that a validating resolver should reject it. Query the resolver you want to test, not merely the resolver configured on your own computer.

Using dig

dig @192.0.2.53 dnssec-failed.org A

Replace 192.0.2.53 with the resolver’s address. You can also test a local resolver by omitting the @ argument:

dig dnssec-failed.org A

In ICANN’s procedure, a SERVFAIL response indicates that the resolver is performing DNSSEC validation and rejected the intentionally failing domain. A NOERROR response indicates that the resolver is not validating in that test. These interpretations apply to this deliberate test case; do not generalize one response to arbitrary DNS queries.

Confirm which resolver answered

Check the SERVER line in dig‘s output. If your device points to a forwarding router, VPN, enterprise resolver or encrypted-DNS service, that is the component being tested. Repeat the query directly against each resolver whose behavior matters to your users.

Rank #3

Sale

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

Buy on Amazon

What a DNSSEC warning means—and what it does not

DNSSEC diagnostics identify a location to investigate, not a universal one-click repair. Common follow-up areas include:

• Parent DS mismatch: the DS published by the parent does not correspond to the active DNSKEY at the authoritative service.
• Missing or stale DNSKEY data: the authoritative servers do not publish the key expected by the delegation.
• Broken signatures: an RRSIG is absent, expired, not yet valid, or does not match the covered record.
• Inconsistent authoritative servers: different nameservers return different DNSKEY, DS-related or signed-record data.
• Key rollover timing: old and new keys or signatures were not published in an overlap that validating resolvers can use.
• Clock or retrieval effects: a diagnostic may observe transient data while a provider is deploying a change.

These are investigation categories, not conclusions about a particular domain. Copy the affected record names, types, values and authoritative server from the diagnostic output, then ask the DNS operator to verify them at the source. Do not delete DS records or disable signing as a first response; that can create a larger outage or remove the protection you were trying to verify.

Choose among DNSSEC diagnostic tools

ICANN’s DNSSEC Tools page lists DNSViz, DNS Check, DNSSEC Analyzer and SIDN DNSSEC Test. The available documentation does not establish a feature-by-feature ranking of those tools. Choose based on the question you need answered and the inputs your incident requires.

A repeatable DNSSEC investigation workflow

1. Define the scope. Write down the domain, the resolver or resolvers involved, and whether the symptom is an incorrect answer, timeout or SERVFAIL.
2. Run a domain-chain analysis. Start with DNSViz; use the Verisign debugger when you need an alternate trust anchor or authoritative starting nameserver.
3. Test resolver behavior separately. Query dnssec-failed.org directly against the resolver and record the response code and server.
4. Verify records at authoritative servers. Compare DS, DNSKEY, RRSIG and related records across all authoritative nameservers. Use the exact names and servers shown by the diagnostic.
5. Check deployment timing. If keys or signatures were recently changed, ask the DNS operator whether the parent DS and authoritative key sets have completed their intended rollover.
6. Retest from the affected path. Run the same domain and resolver checks again, because cached data and staged provider changes can make observations differ.

Or skip the browser setup

If you need a shareable image of a DNSViz or debugger result for an incident record, ScreenshotNeo can capture the page through one API request. It removes cookie-consent banners, newsletter popups and chat widgets before capture; bot checks, blank pages, failed loads and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info and capture_pdf tools for Claude, Cursor and other MCP clients.

cURL (see the ScreenshotNeo documentation):

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://dnsviz.net -o shot.webp

Python:

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://dnsviz.net"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://dnsviz.net' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

The Free plan includes 1,000 screenshots per month with no card. Paid plans start at $5 for 3,000 shots; every feature is on every plan. Create a free ScreenshotNeo account.

Rank #4

Sale

Network Security, Firewalls, and VPNs

$66.62

Buy on Amazon

Troubleshooting common results

DNSViz cannot load an old analysis

The service currently reports that historical analyses cannot be loaded and new analyses are not saved to its database. Run a fresh analysis and preserve the output yourself.

The domain works with one resolver but fails with another

Test each resolver directly. A validating resolver may return SERVFAIL when a non-validating resolver returns an answer. Use the domain-chain tools to find the record or signature inconsistency, then involve the DNS operator.

The resolver test returns NOERROR

For the ICANN procedure, this means that resolver is not validating DNSSEC. It does not prove that every query is insecure or that the domain you care about is misconfigured.

A warning appears immediately after a DNS change

Capture the exact warning and authoritative responses, then retest after the operator’s stated deployment interval. If the warning persists, compare DS and DNSKEY data and check all authoritative servers rather than changing records blindly.

Best Value

Sale

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

• Used Book in Good Condition

$46.48

Buy on Amazon

An alternate trust-anchor test passes but public validation fails

The custom anchor or nameserver may be correct while the parent delegation remains wrong. Repeat the standard public-chain analysis and have the registrar or DNS provider verify the DS workflow.

Frequently Asked Questions

Can I tell that DNSSEC is enabled just by seeing a DS record?

No. A DS record is only one link in the chain. The DS must match an authoritative DNSKEY, and signatures must validate for the records being queried. Use a chain diagnostic rather than checking one record in isolation.

Does a DNSSEC chain check test my ISP’s resolver?

No. DNSViz and the Verisign debugger analyze a domain’s published chain. To test a particular recursive resolver, query that resolver with ICANN’s dnssec-failed.org procedure.

Should I disable DNSSEC when a diagnostic reports an error?

Not as a first response. Preserve the diagnostic details and have the DNS operator verify DS, DNSKEY, signatures and rollover state; disabling signing can create additional risk or outage.

The Bottom Line

Use DNSViz or the Verisign DNSSEC Debugger to inspect a domain’s authentication chain, and test recursive-resolver validation separately with dnssec-failed.org. Interpret warnings as leads for checking authoritative records and provider configuration, not as an automatic diagnosis.

Quick Recap

Bestseller No. 1

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

SaleBestseller No. 2

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

SaleBestseller No. 3

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

SaleBestseller No. 4

Network Security, Firewalls, and VPNs

$66.62

SaleBestseller No. 5

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

Used Book in Good Condition

$46.48

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.