🔐Module 07 — DNSSEC

$ dig se DS +noall +answer
se.			86400	IN	DS	35734 8 2 ADD3C9E3D19A0C4B2A1F3EE43F4F1CBA6C6E9F...

$ dig seamless.se DS +noall +answer +comments
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21993
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

.se has a DS in the root, so .se is signed and the root vouches for it. That is the DS record you saw in the +trace output in Module 03 A3.1 and could not read.

seamless.se returns NOERROR with ANSWER: 0 — NODATA. There is no DS, so the chain of trust stops at .se. The zone is unsigned, and a validating resolver will treat it as insecure rather than bogus — which is a critical distinction: unsigned is fine, signed-and-broken is fatal.

This is the same finding as Module 02 D1.1, where DNSKEY returned (none). Now you know exactly what it means: nobody has signed seamless.se, and nobody has published a DS for it at the registrar. Both steps are required, in that order.

And note the ad flag on that second response. The resolver validated the proof of non-existence of the DS record — .se cryptographically asserts "there is no DS here", and the resolver checked that assertion. Even the absence of DNSSEC is authenticated on a signed parent. That is what NSEC/NSEC3 in B4 are for.

Klab.internal.+013+50540        <- KSK
Klab.internal.+013+63231        <- ZSK

Klab.internal.+013+50540.key
Klab.internal.+013+50540.private
Klab.internal.+013+63231.key
Klab.internal.+013+63231.private

lab.internal. IN DNSKEY 257 3 13 3PqgQ08vhhPv0cv6FZy2022cURmQ2LHEgNhvOCzKNMYIsCq2g0rf8BNP MKjruVY9MtdNZ2ZQsxAAB4HSvIKfIA==
lab.internal. IN DNSKEY 256 3 13 FHswsH8ibj4a6OWN5DRPJ6d6F6MRN23JqHb8rAJi0vXuaJqPMPWPamyS MWZMyZ10PgiLM8hiIDyMVRsPPmxqwA==

Read the filenames — they encode everything. Klab.internal.+013+50540: zone name, algorithm 013, key tag 50540. That key tag is what the RRSIG and the DS both point at, so when a signature says key tag 63231 you can tell at a glance it was the ZSK.

Flags 257 versus 256 is the only difference between the two keys in the record. The maths is identical; the flag is a declaration of intent.

Two files per key, and the .private one is the crown jewels. Anyone holding it can sign anything for your zone. It should never be in Git, never in a container image, and on a serious deployment it lives in an HSM. -f KSK on the first command is what sets the 257 flag.

Zone fully signed:
Algorithm: ECDSAP256SHA256: KSKs: 1 active, 0 stand-by, 0 revoked
                            ZSKs: 1 active, 0 stand-by, 0 revoked
zone.db.signed
Signatures generated:                       15
Signatures retained:                         0
Signing time in seconds:                 0.004

And inside zone.db.signed:

lab.internal.		300	IN SOA	ns1.lab.internal. hostmaster.lab.internal. (
					2026081704 ; serial
					... )
			300	RRSIG	SOA 13 2 300 (
					20260919024216 20260820024216 63231 lab.internal.
					uO6F+05v9Si/GfhRAlxUtHMwyC4dkFX9haZD ... )
			300	NS	ns1.lab.internal.
			300	RRSIG	NS 13 2 300 (
					20260919024216 20260820024216 63231 lab.internal. ... )
			300	A	192.0.2.99

Fifteen signatures for a nine-record zone. One RRSIG per RRset, plus the NSEC3 chain and its signatures. This is why signing roughly triples response size — the claim made in Module 04 D2 and now visible.

-N INCREMENT bumped the serial for you, from ...03 to ...04. Signing is a zone change, and Module 05 C3's rule applies: without a serial bump your secondaries would keep serving the unsigned copy.

Read the two dates in every RRSIG: 20260919024216 20260820024216. Expiration first, inception second. Thirty days. Put that date in your calendar right now — or better, use dnssec-policy so a machine owns it.

-3 <salt> selects NSEC3. Per RFC 9276 the modern recommendation is 0 extra iterations and an empty salt; the salt here exists only to show the flag. The iterations were always a bigger cost to your own servers than to an attacker.

-t printed the statistics; -K said where the keys live; -A kept the NSEC3 opt-out behaviour off. The output file is zone.db.signed, and that is what named must now serve — not the original.

zone lab.internal/IN: loaded serial 2026081704 (DNSSEC signed)

lab.internal.		IN DS 50540 13 2 E2DF051E442951F9B46525F79FA1E11B3346266D24321D376E04780B321472A0

(DNSSEC signed) is BIND confirming it recognised the signatures. If that suffix is missing, you pointed named at the unsigned file — the single most common mistake at this step, because both files sit in the same directory with almost the same name.

The DS names key tag 50540 — the KSK, not the ZSK. That is the whole point of the split from B1.

Now the step that is not a command: you send that DS line to your registrar, through their control panel or API. Until the parent publishes it, resolvers see an unsigned zone and validate nothing.

And the ordering rule, which is the one that causes outages: publish the DS after the signed zone is live and serving correctly on every nameserver. If the DS appears first, resolvers start demanding valid signatures from servers that are not yet serving them, and your domain goes bogus — SERVFAIL everywhere — for the length of the parent's TTL.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62290
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: b94da364249d9917010000006a8677ba19ec6af7f5026ca5 (good)
;; ANSWER SECTION:
lab.internal.		300	IN	A	192.0.2.99
lab.internal.		300	IN	RRSIG	A 13 2 300 20260919024216 20260820024216 63231 lab.internal. /zV0OBf6xNANBvrriInY4z3im2KMXTW1Mdj3mWVUD1ZiR1dT6wVxI1ej 5wEI0RVnY9Ayy4q4R28xGwIhVVTt/A==

ad is set, and this time you know precisely what it cost. The resolver fetched the DNSKEY RRset, checked it against the trust anchor, verified the RRSIG over the A record with the ZSK, and only then set that one bit.

flags: do in the OPT record is what asked for the signature — Module 04 A2's DNSSEC-OK bit, which is why DNSSEC cannot work without EDNS.

ANSWER: 2 for a single address: the A record and its RRSIG. That doubling, across every RRset, is the size cost.

A note on delv, because it will confuse you here. delv validates using the system's trust anchors, not your resolver's, so against this lab zone it reports broken trust chain resolving 'lab.internal/DNSKEY/IN' — correctly, since the system has never heard of lab.internal. On a real signed domain (dig/delv against org or se) delv prints ; fully validated and is the better tool. The error is a true statement about your machine's trust configuration, not a fault in the zone.

The zone owner signs each RRset with a private key, producing RRSIG records. The public key is published as DNSKEY. The parent zone publishes a DS record — a hash of the child's key-signing key — and the parent's own keys are vouched for by its parent, up to the root, whose key is the trust anchor every validating resolver is preconfigured with.

So a resolver walks down from the root, and at each delegation the parent's signed DS authenticates the child's key.

The three things I would add, because they are where candidates separate. It provides authentication and integrity, not encryption — queries stay in plaintext. It protects the path to the validating resolver, not the last hop to your laptop, where only the ad bit exists and anything could set it. And it says nothing about whether a domain is trustworthy — a phishing site can be perfectly signed.

Because one of them is expensive to change and the other is not. The DS in the parent points at the KSK, so changing the KSK means a registrar transaction and waiting out the parent's TTL. The ZSK is referenced only inside your own zone, so it can be rolled freely with no external coordination.

The KSK signs only the DNSKEY RRset; the ZSK signs everything else.

The design consequence worth stating: the split lets you rotate the key that does all the signing work frequently and safely, while touching the externally-visible key rarely. It is a separation of operational cadence, not of cryptographic strength — the algorithms are identical.

With NSEC or NSEC3 records, which sign the gaps between names. Sort the zone's names; publish a signed record saying "the next name after api is mail". A query for dev gets that record back and can verify cryptographically that nothing exists between the two.

NSEC3 hashes the names before sorting, so a walk yields hashes rather than plaintext.

The consequence that makes this more than trivia: plain NSEC allows complete zone enumeration — follow the chain and you have every name, no guessing. That is one of the six enumeration methods from Module 02 D3. NSEC3 raises the cost but does not eliminate it, since hashes can be cracked offline, and RFC 9276 now recommends zero extra iterations because the added work punished the zone's own servers more than the attacker. If names must be secret, the answer is split-horizon, not NSEC3.

--- authoritative server, no validation ---
198.51.100.1

--- through the VALIDATING resolver ---
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53643
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

--- same resolver, validation disabled ---
198.51.100.1

This is the diagnostic pattern, and it is worth memorising as a shape rather than a fact.

Line 1 — the authoritative server hands over the tampered record happily. It does not validate its own data; it just serves the file. So "the authoritative server answers fine" tells you nothing about DNSSEC.

Line 2 — SERVFAIL, and note ad is gone. The resolver checked the signature against the data, found they disagreed, and refused to return anything at all. It did not return the record with a warning. DNSSEC fails closed.

Line 3 — +cd returns 198.51.100.1. The data was there the whole time; only validation was blocking it. A name that SERVFAILs normally and resolves with +cd is a DNSSEC failure, full stop.

And observe what a real attack would look like from the user's side: SERVFAIL. Not a wrong address. DNSSEC's protection is that you get nothing rather than something forged — which is why an over-eager "fix" of disabling validation to make an outage go away is exactly the wrong instinct.

Restore the lab: re-run dnssec-signzone, bump the serial, rndc reload.

First I confirm it is DNSSEC at all: query normally, then with +cd. SERVFAIL that becomes NOERROR with +cd means validation is failing and the data itself is fine. If both fail, it is not DNSSEC and I go back to reachability and delegation.

Then the four causes in order of likelihood: expired RRSIGs — check the expiration field, and this is the most common by a distance; a DS/DNSKEY mismatch after a key roll; blocked TCP/53, since signed responses often exceed the UDP buffer; and clock skew on the validator.

The point I would make explicitly, because it is counter-intuitive: "we didn't change anything" is not exculpatory, it is the diagnosis. Signatures expire on a wall-clock date whether or not the zone changes, so a zone nobody has touched for a month is exactly the zone that breaks. Re-signing is a scheduled job, not a step in a change process — which is why dnssec-policy exists.

Because a validating resolver that cannot authenticate an answer must not return it, and it has no authenticated way to explain why — a detailed error would itself be forgeable. So it returns the generic server-failure code.

It means DNSSEC failures are indistinguishable from network failures on first inspection, which is why +cd is the essential tool: it isolates validation from everything else in one query.

The design point worth adding: this is DNSSEC failing closed, and that is the intended behaviour. Under attack, the user gets nothing rather than something forged. It also explains why the instinctive fix — turning off validation to make the outage stop — is precisely backwards, and why a signed zone raises your operational stakes as well as your security.

1. dnssec-keygen -f KSK produces flags 257, plain dnssec-keygen produces 256. From the signed zone: every RRSIG over ordinary RRsets carries the ZSK's key tag (63231 here), while the RRSIG over the DNSKEY RRset carries the KSK's (50540). Read the key tags in the RRSIGs — that is the evidence, not the man page.

2. cat p/dsset-lab.internal. → lab.internal. IN DS 50540 13 2 E2DF05... — a hash of the KSK. You generate it; your parent publishes it; you get it there through your registrar. It never appears in your own zone file. lab.internal has no real parent, which is why the lab uses a static trust anchor instead.

3. The ad flag in the resolver's response. Not the presence of RRSIG records — those appear whenever +dnssec is used, signed or not, and prove nothing. ad means this resolver verified the chain.

4. Edit one record in zone.db.signed and reload without re-signing:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
;; flags: qr rd ra;                        <- note: no ad

The RRSIG no longer matches the data it covers. No key was touched — the requirement's constraint — and the zone is still bogus.

5. dig @resolver lab.internal A +cd +short → 198.51.100.1. SERVFAIL normally, data with +cd, therefore validation is the failure. One command, and the network is eliminated.

6. Because an authoritative server does not validate its own data — it serves the file it was given. Signatures are checked by resolvers, not by the server that publishes them. This is why "the nameserver is up and answering" is worthless evidence in a DNSSEC incident, and why you must test through a validating resolver.

7. KSK rollover, in order: generate the new KSK → publish it in the DNSKEY RRset alongside the old → sign the DNSKEY RRset with both → submit the new DS to the registrar → wait out the parent's DS TTL → stop signing with the old KSK → remove it.

The pace is set by the parent's DS TTL — a value in someone else's zone that you do not control, and typically 24–48 hours at a TLD. That is the entire reason KSK rolls are rare and ZSK rolls are routine.

8. Expired signatures. RRSIG records carry a wall-clock expiration — 30 days by default — and expire whether or not anything changes.

It is invisible to change management because there is no change. No deployment, no ticket, no diff. A zone nobody has touched for a month is precisely the zone that goes dark, and every after-the-fact review finds an empty change log. The fix is not process, it is automation: dnssec-policy re-signing on a schedule, plus monitoring that alerts on the expiry date approaching, not on validation failing.

The five things most people miss:

1. Reading key tags in requirement 1 rather than asserting which key does what
2. Requirement 3 — that RRSIG presence is not evidence. +dnssec shows signatures whether or not anyone validated them; only ad means validation occurred
3. Requirement 6 — that authoritative servers never validate. It reframes the entire debugging approach
4. Naming the parent's DS TTL in requirement 7. "Wait a bit" is not an answer; the number belongs to someone else
5. Requirement 8's second half. Everyone names expiry; far fewer explain why change management cannot catch it

It guarantees authenticity and integrity: the data came from the zone's key holder and was not modified in transit.

It does not provide confidentiality — queries and answers remain plaintext. It does not protect the last hop from your validating resolver to your device, where only the ad bit exists. And it says nothing about trustworthiness — a phishing domain can be perfectly signed.

Because the parent's DS points at the KSK, so changing the KSK needs a registrar transaction and a wait on the parent's TTL. The ZSK is referenced only inside your zone and can be rolled freely.

The KSK signs only the DNSKEY RRset; the ZSK signs everything else.

It is a separation of operational cadence, not of cryptographic strength.

In the parent zone, published through your registrar — never in your own zone file.

It matters because it is a piece of your security configuration in someone else's system, on someone else's change cadence and TTL. Exactly the same class of problem as glue records.

It also dictates ordering: publish the DS after the signed zone is live, and remove it before un-signing.

Expired RRSIGs. Signatures carry a wall-clock expiration — 30 days by default — and expire whether or not the zone changes.

It is invisible to change management because there is no change to review. Re-signing must be a scheduled job, which is what dnssec-policy exists to own.

Query normally, then with +cd. SERVFAIL that becomes NOERROR with +cd means the data is reachable and validation is what is failing.

If both fail, it is not DNSSEC — go back to reachability, delegation and the transport checks.

Because the resolver must not return data it could not authenticate, and any detailed error would itself be unauthenticated and therefore forgeable.

DNSSEC fails closed by design: under attack you get nothing rather than something forged. It is also why disabling validation to end an outage is exactly the wrong instinct.

Because authoritative servers do not validate. They serve the zone file they were given; signature checking is a resolver function.

So "the nameserver is up and answering" is worthless evidence in a DNSSEC incident. You must test through a validating resolver.

NSEC/NSEC3 sign the gaps between sorted names, so a resolver can verify that nothing exists between two neighbours.

The cost is zone enumeration: plain NSEC lets anyone walk the chain and list every name. NSEC3 hashes the names, raising the cost but not removing it, and RFC 9276 now recommends zero extra iterations because they burdened your servers more than the attacker.

If names must be secret, use split-horizon rather than relying on NSEC3.

That TCP/53 works end to end. Signing roughly triples response sizes, and with the modern 1232-byte EDNS buffer many signed responses truncate and require a TCP retry.

If a firewall allows only UDP/53, signing converts a working domain into an intermittently broken one — small queries fine, signed ones hanging.

Choosing algorithm 13 rather than RSA keeps signatures about a quarter the size and reduces how often this matters.

Always overlap, and never withdraw anything until every cache that could hold it has expired.

Publish the new key alongside the old, wait for the relevant TTL, switch signing, wait again, then remove the old key. For a KSK the pace is set by the parent's DS TTL, which you do not control.

Every rollover outage is the same mistake: removing something too early.

Every key, signature, DS record, validated response and SERVFAIL in this module was produced for real on 20 August 2026: lab.internal signed with dnssec-keygen/dnssec-signzone 9.18 using ECDSAP256SHA256, served by a BIND primary on port 5301, and validated by a second BIND instance on port 5303 configured with the KSK as a static trust anchor. The tampering in D1.1 and the resulting SERVFAIL / +cd pair are captured output.

Specifications verified directly: RFC 4033, RFC 4034, RFC 4035, RFC 5155, RFC 5910, RFC 6781, RFC 6840, RFC 7129, RFC 8624, RFC 9276, RFC 9364, plus the BIND 9 DNSSEC Guide.

Question selection cross-referenced against publicly published 2026 DNS and networking interview question sets:

• Top 25 DNS Interview Questions and Answers for 2026 — nitizsharma.com — "What Is DNSSEC? Explain With Cryptographic Detail" verbatim
• Top 30 Most Common DNS Interview Questions — Verve AI — how DNSSEC enhances security and what DNS spoofing is
• Top 100 Network Security Interview Questions for Network Engineers (2026) — The Network DNA
• 75+ Network Engineer Interview Questions for 2026 — Taggd

Answers were rewritten and deepened rather than reproduced. Published sets describe the chain of trust and stop. The parts that actually come up once an interviewer has operated a signed zone — that signatures expire on a date rather than on a change, that authoritative servers never validate their own data, that every failure looks identical, and that the DS lives in someone else's system — appear in almost none of them.