Concept
Getting DNSSEC turned on correctly (Lesson 5) is the easy part; operating it over time is where deployments actually break in production. Keys need periodic rollover (replacing an aging signing key with a new one) without ever creating a gap where the chain fails to validate — this requires a specific ordering: publish the new key, wait long enough for the OLD key's TTL to fully expire everywhere, then update the DS record at the parent to point at the new key. Doing these steps out of order, or too fast, produces exactly the SERVFAIL failures this lesson trains you to recognize.
Common Misconception
"A key rollover is just replacing one key with another, order doesn't matter much." Order matters completely — if the DS record at the parent is updated to point at a new key BEFORE that new key has actually propagated to all resolvers (or before the old key's signatures have expired from caches), some resolvers will be validating against a DS that doesn't match what they're currently caching, and DNSSEC validation fails outright. This is the single most common cause of real-world "my DNSSEC-signed domain suddenly stopped resolving" incidents — not malicious attack, just a rollover ordering mistake.
Hands-On Exercise
No lab environment needed for the diagnostic half:
- marinadns.io/dnssec — run this against any domain mid-rollover (or one that's had a rollover mistake) to see exactly what a broken chain reports.
- noda.marinadns.io — DNSSEC Multi-Algorithm Signing and DNSSEC Algorithm Ban List checks (CAT-SEC) surface operational DNSSEC issues beyond simple on/off status.
For actually performing a key rollover and deliberately breaking DNSSEC to recognize the SERVFAIL signature firsthand — this genuinely requires your own lab domain, never a production zone — see Lesson 6 in the DNS Admin Course Lab Environment page.
Commands to Run
# Baseline: confirm current validation is clean
delv yourdomain.com A
# Initiate a key rollover via your provider's dashboard, then monitor the transition:
dig yourdomain.com DNSKEY +short # watch for two keys present during rollover overlap
dig yourdomain.com DS +short # confirm DS updates at parent AFTER new DNSKEY is live, not before
# Deliberately break it (lab domain only — never on a production zone):
# e.g. let the DS record go stale relative to a rolled key, or truncate a signature manually if your provider allows raw record edit
dig yourdomain.com A +dnssec # observe SERVFAIL and the exact error against a validating resolver
delv yourdomain.com A # delv will show precisely which link in the chain failed
The goal is recognizing the SERVFAIL pattern from a validating resolver (typically what end users report as "domain X doesn't work") and tracing it back to the specific broken link via delv, rather than guessing.
Mastery Checkpoint
You should be able to explain, without looking anything up:
- The correct ordering of a key rollover and why reversing any step breaks validation.
- Why a rollover mistake is usually the cause behind "domain stopped resolving after enabling DNSSEC," not an attack.
- Why a single atomic infrastructure-as-code deploy that changes DNSKEY and DS at the same time is dangerous.
If you can answer all three without re-reading this lesson, move to Lesson 7.
← DNS Admin Course Lab Environment
