lab/notes
← All notes

DNSSEC validation chains: tracing a real query

April 15, 2026 · lab notes · dns · dnssec · security

DNSSEC is the only widely-deployed mechanism for verifying that the DNS answer you got is the answer the zone owner published. It is also the protocol that operators most love to have failed somewhere they don’t have to debug.

Here’s what validation actually looks like, traced through one query.

The chain

When you resolve a DNSSEC-signed name, the validating recursor does roughly this:

  1. Resolve the name normally — gets the RRset and its RRSIG.
  2. Resolve the zone’s DNSKEY records — these contain the public keys that signed the RRset.
  3. Verify the RRSIG against the DNSKEY.
  4. Resolve the zone’s DS record from the parent zone — this is a hash of the DNSKEY.
  5. Verify the DS matches the DNSKEY.
  6. Recurse: resolve the parent zone’s DNSKEY, verify it matches the parent’s DS in the grandparent, and so on, up to the root.

The root’s DNSKEY is the trust anchor. It’s hardcoded in your recursor (or in IANA’s published trust anchor file) and the chain stops there.

What can go wrong

The chain breaks at any link, and each break has a different operational signature.

Expired RRSIG. Signatures have an expiration. If the zone’s signing infrastructure stops working — operator forgot to renew, signing daemon crashed, automation broke — the existing signatures expire and validation fails. Recursors that validate return SERVFAIL. Stub resolvers see “name not found” or timeouts.

Algorithm mismatch. A zone might publish DNSKEYs using algorithm 13 (ECDSA P-256) and sign with algorithm 8 (RSA SHA-256). Validation fails. This usually happens during a key rollover that wasn’t completed correctly.

Missing DS at parent. You publish a DNSKEY but forget to register the DS record at your registrar. The chain breaks at step 4. The zone resolves fine without DNSSEC validation; with validation it returns SERVFAIL.

DS hash algorithm mismatch. You registered DS using SHA-1 (algorithm 1) but your DNSKEY published only allows SHA-256 (algorithm 2). Some registrars still default to SHA-1 in their UI. Worth checking.

Debugging

Three commands handle most cases:

dig +dnssec example.com

Returns the answer with ad flag set if validation succeeded, or SERVFAIL if it didn’t. Use +cd to disable validation and see the raw answer.

dig +trace +dnssec example.com

Walks the chain from the root down, printing each step. If you see SERVFAIL only at one level, that level is broken.

delv example.com

delv (provided by BIND) does a full validation walk and prints exactly which step failed. The output is verbose but tells you everything.

For zones you operate, also test with https://dnsviz.net/d/example.com/dnssec/ — it visualizes the chain and highlights specific failures.

When you’ve broken it

If your zone’s DNSSEC has broken validation:

  1. Don’t panic-disable DNSSEC. Removing the DS at the parent takes hours to propagate (TTL of the parent zone), and during that window, validating recursors will SERVFAIL your domain to the world. Clients that don’t validate (most browsers, most stub resolvers) will keep working. Validating resolvers (1.1.1.1, 8.8.8.8, increasingly default) will fail.

  2. Fix the chain instead. Identify the broken link, fix it, wait for caches to expire.

  3. If you must turn DNSSEC off, do it as a planned maintenance: lower the parent DS TTL ahead of time, then remove the DS, wait for the lowered TTL to expire, then remove the DNSKEY records.

DNSSEC is more brittle than the rest of DNS. The default state should be working signatures with monitoring that alerts when they’re about to expire.