Walking the chain of trust

Validation is a chain of small checks, and the whole reason to do it by hand once is that a DNSSEC failure is always a specific broken link. A tool tells you it failed; walking the chain tells you where.

The chain

root                    trust anchor — the resolver already has this key
  |  DS for "com"        signed by the root
  v
com                     DNSKEY — verified against the root's DS
  |  DS for "certadns.com"   signed by com
  v
certadns.com            DNSKEY — verified against com's DS
  |  RRSIG over each RRset   signed by this zone's key
  v
the answer you asked for

Note where each piece lives. A zone’s DNSKEY is in the zone; the DS that vouches for it is in the parent. That split is the source of most real failures, because the two are changed by different systems — the DNSKEY by your DNS provider, the DS by your registrar.

Walking it

Take certadns.com, checked 2026-09-12.

Step 1 — does the parent vouch for this zone?

29357 13 2 6F68DA43155EDAF9F929BD97C7820CB316BB423A4951AA3FC648D66C A216E2B3

Key tag 29357, algorithm 13, digest type 2. An empty answer here means the zone is not signed as far as the world is concerned, no matter what is in it.

Step 2 — does the zone publish that key?

257 3 13 00uWWtb/MvPAHwXTy6vzCvBJEvM++9AK...

Flag 257, algorithm 13 — consistent with the DS. The DS digest should be a hash of this key; confirming that by hand needs a tool, but the algorithm and key tag matching is already enough to catch the common failure, which is a DS left pointing at a key that no longer exists.

Step 3 — are the signatures current?

certadns.com. 3600 IN RRSIG SOA 13 2 3600 20260924000000 20260903000000 29357 certadns.com. <sig>

Expiry 2026-09-24, inception 2026-09-03, key tag 29357 — matching the DS. Twelve days of validity remaining at the time of checking. A signature already past its expiry is the single most common cause of a domain vanishing behind DNSSEC.

Step 4 — does a validating resolver agree?

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, ...

The ad flag — authenticated data — is the resolver stating that it validated the chain successfully. Its presence is the short answer to "is DNSSEC working for this domain".

What each result tells you

• No DS, no DNSKEY — the zone is simply unsigned. Not a fault, just an absent control.
• DNSKEY present, no DS — signed but not connected. Validators treat it as unsigned, so the signing is doing nothing. Usually means the DS was never submitted to the registrar, or was removed during a transfer.
• DS present, no matching DNSKEY — actively broken. The parent vouches for a key the zone does not have, so every validating resolver returns SERVFAIL. This is the state a mishandled key rollover leaves behind.
• Both present, SERVFAIL — go to the RRSIG dates and the algorithm numbers. Expired signatures first.