DNS Admin Course · Lesson 5/11

DNSSEC I: Chain of Trust

DNSSEC adds cryptographic signatures to DNS records so a resolver can verify a response actually came from the legitimate authoritative source and wasn't forged or tampered with in transit. The trust chain works top-down: the root zone signs the TLD's key, the TLD signs your domain's key (via a DS record published at the parent), and your domain's key signs its own records. Break any single link in that chain and the whole thing fails to validate — DNSSEC has no partial-credit state; a zone is either fully validated or the resolver must treat the answer as untrustworthy.

"I enabled DNSSEC in my dashboard, so it's working." Enabling it publishes a DNSKEY at your nameserver — but the chain isn't actually complete until the corresponding DS record is also published at the PARENT zone (your registrar, not your DNS provider, in many setups). Many operators enable signing and stop there, never confirming the DS record actually made it to the parent, leaving a broken, non-validating chain that LOOKS configured but provides zero actual protection.

No lab environment needed for verification:

  • marinadns.io/dnssec — checks whether your domain's chain of trust actually validates end-to-end, not just whether a DNSKEY exists.
  • noda.marinadns.io — the DNSSEC check under CAT-SEC reports the same validation status as part of a full domain assessment.

For actually signing a zone and watching the DS record populate at the parent step by step (the single best teaching moment in this course, per the syllabus), see Lesson 5 in the DNS Admin Course Lab Environment page.

# Before signing: confirm no DNSKEY exists yet
dig yourdomain.com DNSKEY +short

# Enable DNSSEC via your provider's dashboard (one-click on Cloudflare/Route53/most modern hosts), then:
dig yourdomain.com DNSKEY +short
dig yourdomain.com DS +short          # queried from the PARENT

# Full chain validation (requires a validating resolver)
delv yourdomain.com A                 # delv reports "fully validated" or shows exactly where the chain breaks

# Confirm a validating public resolver agrees
dig @1.1.1.1 yourdomain.com A +dnssec +cd    # AD flag present = validated

delv (ships with BIND) is the most direct tool for this — it walks the actual trust chain, not just "is DNSSEC on."

You should be able to explain, without looking anything up:

  • Why enabling DNSSEC at your DNS provider is necessary but not sufficient — what the second, separate step is.
  • Why DNSSEC validation is all-or-nothing rather than degrading gracefully.
  • The difference between a DNSKEY (published at your nameserver) and a DS record (published at the parent).

If you can answer all three without re-reading this lesson, move to Lesson 6.

Practice with these tools

← DNS Admin Course Lab Environment