Security

🔬 DNSViz: the DNSSEC chain, visualized

Reach for it when dig +dnssec and delv say a chain is bogus and you can't see where. Paste a domain in and get every DNSKEY, DS, RRSIG and NSEC as a graph, with the broken edge in red: it shows which link failed, not only that the chain failed.

Web UI: https://dnsviz.net/
CLI: https://github.com/dnsviz/dnsviz: full validation locally; same output
On this site: the live chain: live DoH walk of any domain, values on hover

Asks a deliberately broken zone for an address, before opening the visualiser.

$ dig @1.1.1.1 dnssec-failed.org A

; <<>> DiG 9.20.11-0ubuntu0.2-Ubuntu <<>> @1.1.1.1 dnssec-failed.org A

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9166

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

;; QUESTION SECTION:

;dnssec-failed.org. IN A

;; Query time: 51 msec

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)

;; WHEN: Mon Sep 14 17:42:31 CDT 2026

;; MSG SIZE rcvd: 103

GO SERVFAIL, which is what a broken chain looks like from a client

NO GO an address, which means nothing in the path validated

run this query in the dig tool →

what each part of this output means →

Reading a DNSViz graph#

The graph clusters nodes by zone, one box per zone in the chain, and carries the information in three layers.

The boxes (nodes)#

Shape	Meaning
Ellipse	A DNSKEY (signing key); gray fill marks the SEP bit, a double border marks a trust anchor, a thick border marks the revoke bit
Ellipse (at the parent, labeled DS)	A DS record (delegation hash at the parent); DS RRs sharing an algorithm and key tag draw as one node
Rounded rectangle	A signed RRset (the data being signed)
Rectangle with compartments	The NSEC or NSEC3 records proving a negative response; each top compartment is one record (one to three of them), the bottom compartment carries the NSEC or NSEC3 label

Shapes per the official legend: dnsviz.net/doc/dnssec.

The arrows (edges)#

Arrow style	Meaning
Solid blue	Valid: secure delegation, valid RRSIG, or a DS digest that matches the DNSKEY
Solid black	Insecure delegation: no DNSSEC at this link
Solid red	Broken: invalid signature or DS digest mismatch
Dashed red	Bogus delegation; also a DS or RRSIG whose use is invalid, such as one pointing at a revoked key
Dashed gray	RRSIG or DS with no matching DNSKEY (the missing key draws with a dashed gray border)
Dashed yellow	Lame or incomplete delegation
Solid yellow	Unknown or unsupported algorithm (a DS digest type or RRSIG algorithm the tool cannot check)
Solid purple	RRSIG outside its validity window (expired or not yet valid)

The colors (status)#

Node outlines carry the validation status: blue means secure (an unbroken chain of trust from an anchor), red means bogus (the chain broke somewhere), black means insecure (no chain exists at all). DNSViz does not color by algorithm; the algorithm and key tag are printed as text inside each DNSKEY node (for example alg=13, id=2371), which is how you spot old and new algorithms side by side during a rollover.

When to reach for it#

Situation	Use DNSViz for
`EDE 6 (DNSSEC Bogus)` (RFC 8914) and you don't know why	The graph shows which edge is red
Planning a KSK rollover	Snapshot before + during + after; verify the parent DS lines up
Migrating between DNS providers	Snapshot the source zone; do not start migration until the chain is clean
Algorithm rollover (RSA → ECDSA)	See both algorithms present during the transition
Auditing a customer / partner zone before integration	"Is your DNSSEC actually working?" in one URL

A DS change settles slower than a re-sign. RFC 9520 §3.2 caps resolution-failure caching at 5 minutes, and DNSSEC validation failures are in scope (§3.4), but a resolver that cached the old DS keeps validating against it until that record's own TTL runs out. Re-snapshot a rollover once that TTL has passed, not five minutes later.

CLI variant#

Script DNSSEC checks (for example in a probe runner) with the dnsviz CLI:

dnsviz probe cloudflare.com > probe.json

Probes the zone and its full delegation chain from the root (the default) and writes a JSON snapshot. Add -A to query the authoritative servers directly instead of a recursive resolver. -d sets the debug log level (0 to 3), not delegation depth; see the dnsviz-probe man page.

dnsviz grok < probe.json

Analyzes the JSON and prints a structured report of every object in the chain and its status.

dnsviz probe cloudflare.com | dnsviz graph -Tsvg > chain.svg

Renders the same graph the web UI shows, as an SVG, without a network round-trip to dnsviz.net.

dnsviz probe cloudflare.com | dnsviz grok -l error

One-shot problem check: -l error limits the report to error-level findings, so a clean chain prints a near-empty result. Per the dnsviz-grok man page, the exit code only reflects program errors (bad usage, missing dependencies, I/O), not DNSSEC status; for a CI pass/fail signal, test whether the output contains errors. (-t is for a trusted-keys file, not filtering.)