The DNSSEC chain, walked live
try
vantage: your browser → cloudflare-dns.com (1.1.1.1) over DoH, JSON API
How we walked it
One column per zone, a box per key, DS, and signature, edges colored by what the page verified, amber where it could not, and one verdict line under the graph.
values: fetched live by your browser / walk fails: no graph
Asks for the keys the visualiser draws the chain from.
dig @1.1.1.1 isitdns.net DNSKEY +dnssecGO NOERROR, the DNSKEY set, and an RRSIG over it
NO GO SERVFAIL; if the same query with +cd answers NOERROR, validation failed
The vantage#
The queries run from your browser, over DNS-over-HTTPS to cloudflare-dns.com (1.1.1.1), using Cloudflare's JSON API with the DO bit set (do=1, the EDNS0 flag that asks for DNSSEC records, RFC 6891). That JSON format is a Cloudflare and Google extension, not RFC 8484: RFC 8484 defines DoH carrying application/dns-message, the wire format. The page states the vantage above the graph.
DoH rides port 443, so a router that intercepts port 53 cannot answer in Cloudflare's place; the chain you see is the chain 1.1.1.1 sees. It is still one vantage. During a key rollover, two resolvers hold different DNSKEY sets for a zone when their cached copies differ.
Reading the graph#
Columns are zones, left to right from the root: . (root), the TLD, the zone, then a final column headed the answer. Each column's subhead reports what came back: the key count and the resolver's answer for that zone (AD=1, or the SERVFAIL it returned).
Boxes are the records:
| Box | What it is |
|---|---|
DNSKEY <tag> | A zone key, labeled KSK or ZSK by its flags field, with the algorithm. KSK boxes get an accent border. The root KSK carries a TRUST ANCHOR badge; see the boundary section for why. |
DS <tag> | The parent's fingerprint of a child DNSKEY. Drawn in the parent's column, because that is where DS records live. |
RRSIG <type> | The signature over the final RRset, in the answer column. |
<type> RRset | The answer itself: the records, TTL, rcode, and the resolver's AD flag. |
no DNSKEY / no DS for <zone> | Note boxes for the absences: an unsigned zone, or an unsigned delegation. When the parent's negative answer carried an NSEC/NSEC3 denial proof, the tooltip says so. |
Edges are the relations, and the color is the verdict:
| Edge | Means |
|---|---|
| Solid lime | Verified by the page. |
| Dashed amber | Not verifiable by the page. |
| Solid red | Mismatch, or a signature out of its window. |
Hover or tap any box or edge for the evidence: the raw field values, and a PASS / FAIL / NOTE line for each check the page ran on it. Click to pin the tooltip.
Below the graph, How we walked it lists every step in order: who we asked, what came back, per zone. The verdict renders last, after the evidence.
The verdicts#
One line under the graph:
| Verdict | When |
|---|---|
CHAIN INTACT (lime) | The chain checks out and the resolver validated the answer. |
UNSIGNED PATH (amber) | A delegation in the path is unsigned. |
SIGNED, BUT (amber) | The chain checks out; the resolver did not set AD on the answer. |
NXDOMAIN (amber) | The name does not exist. |
BROKEN (red) | A break in the chain, named. |
Three worked states#
Live links; this page accepts ?d=<domain> and runs the walk on load.
Intact: isitdns.net. Every trust edge is solid lime. Verdict: CHAIN INTACT.
Unsigned: github.com. The root and com columns fill in normally, then com publishes no DS for github.com and the zone publishes no DNSKEY. The delegation edge draws dashed amber with a no DS note box, and the answer arrives with no RRSIG. Verdict: UNSIGNED PATH.
Broken: dnssec-failed.org. This zone is deliberately signed wrong: the DS at org fingerprints a key the zone does not serve. The DS-to-key edge is solid red. Verdict: BROKEN, naming the SERVFAIL and the orphaned DS. Cloudflare's own reason for that SERVFAIL is EDE 9, DNSKEY Missing, which is the same break stated in one line instead of drawn (extended-dns-errors). dnssec-troubleshooting covers chains like this one.
The same walk from your terminal#
Every section of the graph has a one-line dig equivalent. The DoH vantage note applies in reverse here: these ride your local port-53 path. When a router intercepts port 53, those reads come from the router, not the resolver named (when-its-dns).
The keys column for any zone:
dig @1.1.1.1 isitdns.net DNSKEY +dnssecThe DS boxes in the parent column:
dig @1.1.1.1 isitdns.net DS +dnssecThe answer column, RRset plus RRSIG, with the ad flag as the resolver's verdict:
dig @1.1.1.1 isitdns.net A +dnssecAnd the whole verdict at once, validated on your own machine:
delv @1.1.1.1 isitdns.net A; fully validateddelv is the BIND validator and requires a full BIND install with crypto support (the macOS system delv at /usr/bin/delv printed no crypto support when run on 2026-10-14).
What the page does not verify#
- Signatures are not verified here. Where a relation rests on a signature alone, the edge is dashed amber, and the resolver's AD flag (RFC 4035 section 3.2.3) is labeled as the resolver's verdict, not the page's.
- The root KSK is a trust anchor, not a conclusion. A trust anchor is a key you configure rather than derive (RFC 4033 section 2). The root DNSKEY RRset is fetched live, but trust in it comes from resolver configuration; the page does not fetch the IANA trust-anchor file, so the
TRUST ANCHORbadge marks an assumption, not a proof. - One vantage. Your browser, one DoH resolver. During a rollover, a resolver with an older cached DNSKEY set returns a different chain.
NSEC proofs, per-server views: DNSViz
See also#
- dig-flags: the
ad,cd, anddobits this page keeps citing - DNSSEC chain check: the job page, one name in, with a reading of example.com