tldr-dnssec
This page is the reference manual for tldr-dnssec at isitdns.net: DNSSEC answers in tldr-pages style. One input, one button, one huge verdict line, then terse bullets. The tool is deliberately this small; the drawn version of the same walk is dnssec-viz.
Type a domain and your browser walks its real DNSSEC chain over DNS-over-HTTPS (RFC 8484) to cloudflare-dns.com (1.1.1.1): DNSKEY per zone cut, DS per child, the leaf answer, then key tags computed per RFC 4034 appendix B, DS digests recomputed with WebCrypto, and RRSIG windows checked against your clock. The verdict line is assembled from that walked chain on every run; nothing is canned. The page accepts ?d=<domain> as a deep link.
Asks for an address and the signature over it.
dig @1.1.1.1 isitdns.net A +dnssecNOERRORThe server had no complaint about the question.
qrThis message is the answer coming back, not the question going out.
rdYou asked this server to go and find the answer for you.
raThis server says it is willing to go and find answers for you.
adThis server says it checked the signatures, and they held up.
AYou asked for the IPv4 address this name points at.
300How many seconds this answer can be reused before asking again. From a cache it is the time left, so it counts down.
Query timeHow long this one lookup took, start to finish.
good: ad on the flags line and an RRSIG beside the A record
bad: no ad, which means nothing validated this answer
The verdict line#
Three classes, colored like the rest of the site. The exact live wordings:
| Class | Line |
|---|---|
| Lime | SIGNED AND INTACT. it was not DNS this time. |
| Amber | UNSIGNED. no DS at the parent, nothing to break. |
| Red | BROKEN: <the first broken thing>. it was DNS. |
Lime means the whole path is signed, every DS digest the page could recompute matched byte for byte, the signature window is current, and the resolver vouched with AD=1 (RFC 4035 section 3.2.3). Red names the first break in the line itself; further breaks render as also broken: bullets. A broken chain is exactly the state where a validating resolver returns SERVFAIL for every query it cannot validate (RFC 4035 section 5.5: the name server "MUST return RCODE 2 to the originating client"), so red really does mean "it was DNS".
Amber covers every honest in-between, each with its own wording:
NXDOMAIN. <domain> does not exist. nothing to sign, nothing to break.A typo is named as a typo, never folded into UNSIGNED. The denial itself can be DNSSEC-signed; the long version shows the proof records.HALF SIGNED. <zone> has keys but no DS at the parent. a chain that starts nowhere.SIGNED, NOT VOUCHED. the chain checks out here, but the resolver left AD=0.
The bullets#
Under the verdict, tldr-pages style: one line each, evidence first, in a fixed order.
- The DS to DNSKEY match at every zone cut, leading. One bullet per DS, shaped
parent -> child: DS <tag> (<digest type>) -> DNSKEY <tag>.and finished with the three-state recompute verdict:recomputed here: MATCH, byte-identical, orrecomputed here: MISMATCH, ordigest type not computable here (WebCrypto)when the browser cannot hash that digest type. A cut with no DS says so:no DS at the parent. unsigned delegation.The one exception to "leading": a red verdict with more than one break puts its extraalso broken:lines first. - Keys and algorithm per zone:
<zone> keys: KSK <tag>, ZSK <tag>. algorithm ECDSAP256SHA256 (13). - The signature window over the answer: valid and when it expires, or expired and by how much, and which zone key signed it. An empty NOERROR answer is labeled NODATA, which is a legitimate state and not a failure; real failure rcodes stay red.
- The resolver's AD bit, as its own line, because it is the validating resolver's verdict and not this page's.
When a query SERVFAILed and the page refetched with CD=1 to show you the broken records, a red bullet says exactly that: the data shown was fetched with checking disabled.
The verdict here is computed from the walked chain, so it is this page's own finding and not the resolver's. The resolver's finding is the Extended DNS Error it attached to that SERVFAIL, which this page does not surface; read it in the dig tool or from dig, and decode it with extended-dns-errors. Two independent verdicts that agree are worth more than either alone.
Verify it yourself#
The page hands out three copy-ready commands for whatever domain you checked, because a verdict you cannot reproduce is a claim:
dig @1.1.1.1 isitdns.net A +dnssecThe answer with its RRSIG; a validating path shows ad in the flags (dig-flags).
dig @1.1.1.1 isitdns.net DS +dnssecThe parent's fingerprint of the zone key, the record the leading bullets check.
delv @1.1.1.1 isitdns.net A; fully validatedFull validation on your own machine, verdict in the first line. The page ships these with a warning worth repeating: run them from a seat you trust. An intercepting router answers port 53 itself, so dig @1.1.1.1 from behind one shows you the router, not 1.1.1.1. The page rides DoH on port 443, which is why the two can disagree, and when-its-dns is what to do when they do.
The long version#
The verdict links straight to the chain visualizer for the same domain: every key, DS, and signature as a live graph, values on hover. dnssec explains how the chain works; dnssec-troubleshooting is for when the verdict comes back red.
See also#
- dnssec-viz: the same walk, drawn, with the evidence on hover
- dnssec: the trust chain, and the two-step signed-or-not check
- dnssec-troubleshooting: diagnosing a BROKEN verdict
- extended-dns-errors: the resolver's own reason code for the same failure
- dig-flags: what
adandcdactually mean on the wire - when-its-dns: when this page and your terminal disagree