<aside> 🧭

Module 07 · DNSSEC

You have met ad, cd and do flags, an RRSIG in a +trace, a DS record at the .se delegation, and secure: no in rndc zonestatus — every one deferred to "Module 07". This is it. You will sign the lab.internal zone from Module 05, validate it, then break it on purpose and watch it fail the way DNSSEC always fails: as a bare SERVFAIL with no explanation.

🧠 concept → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (answers hidden)

Prerequisite: Modules 01–05. You need RRsets (02 A1), the SOA and delegation (02, 03), EDNS and the do bit (04 B3), and a working BIND primary (05).

</aside>

Part A · What DNSSEC is for

A1 · The problem, restated precisely

<aside> 🎭

The analogy. Think of anyone being able to print a letter on your company letterhead.

You can make the letterhead harder to copy — fancier paper, a watermark, a serial number. Each one makes forgery less likely, and none of them makes it impossible.

A signature the bank can check against a specimen on file is a different kind of protection altogether. That is the step DNSSEC takes.

</aside>

<aside> 📖

Official docs: RFC 9364 — DNS Security Extensions (DNSSEC), BCP 237 · RFC 4033 — DNS Security Introduction and Requirements · RFC 5452

</aside>

Module 04 C ended on an uncomfortable note: source-port randomisation, 0x20 and DNS cookies all make forgery unlikely. None makes it impossible, because all of them are guessing games and the attacker gets unlimited attempts.

<aside> 🔑

DNSSEC changes the question from "could this be forged?" to "is this signed by the key the parent vouched for?" — and that is a question with a definite answer.

The zone owner signs each RRset with a private key. The public key is published in DNS. The parent zone publishes a hash of that public key, and the parent's own key is vouched for by its parent, up to the root — whose key is the one thing every validating resolver is configured with in advance.

So a forged answer needs the zone's private key. Guessing is off the table.

</aside>

<aside> ⚠️

Three things DNSSEC does not do, and interviewers ask about all three.

  1. It does not encrypt anything. Every query and response stays in plaintext, readable by anyone on the path. DNSSEC is authentication and integrity, never confidentiality. Encryption is DoT/DoH/DoQ — Module 09
  2. It does not protect the last hop. It secures the path from the zone to the validating resolver. Between that resolver and your laptop there is nothing but the ad bit, which anything could set. If you do not trust the channel to your resolver, ad is worth nothing
  3. It does not say a domain is trustworthy. A phishing site can be perfectly signed. DNSSEC proves the data came from the domain's owner, not that the owner is honest </aside>

A2 · The chain of trust

<aside> 🛂

The analogy. Think of a passport at an immigration desk.

The officer does not know you. He trusts the passport because he trusts the country that issued it — and he trusts that country because of an agreement his own government already holds.

Every level vouches for the one below it, all the way up to something he was given in advance and simply accepts. In DNS, that pre-agreed thing is the root's key, and it is shipped with every resolver.

</aside>

<aside> 📖

Official docs: RFC 4033 §5 — the chain of trust · RFC 4035 — Protocol Modifications · IANA Root Servers

</aside>

flowchart TD
    ROOT["ROOT ZONE<br>DNSKEY - the trust anchor<br>shipped with every resolver"]
    ROOT -->|"root signs a DS for se"| DSSE["DS record for se<br>lives in the ROOT zone"]
    DSSE -->|"hash of"| SEKEY["se DNSKEY<br>lives in the SE zone"]
    SEKEY -->|"se signs a DS for the child"| DSCH["DS record for example.se<br>lives in the SE zone"]
    DSCH -->|"hash of"| CHKEY["example.se DNSKEY"]
    CHKEY -->|"signs"| RRSIG["RRSIG over every RRset<br>A, MX, TXT, NS ..."]
    RRSIG --> DATA["the records you asked for"]
    style ROOT fill:#8b5cf6,color:#fff
    style DSCH fill:#f59e0b,color:#fff
    style DATA fill:#22c55e,color:#fff

<aside> 🔑

Read the diagram for one structural fact: the DS record lives in the PARENT, and everything else lives in the child. That single split is the reason DNSSEC is operationally hard.

Your keys, your signatures and your DNSKEY records are all yours to change whenever you like. The DS is not — it sits in your parent's zone and is published through your registrar. It is the same problem as glue records in Module 03 A4: a piece of your configuration that lives in somebody else's system, on somebody else's change cadence.

Get the ordering wrong — change keys before the parent's DS catches up — and your entire domain goes dark for every validating resolver in the world. Not degraded. Dark.

</aside>

🧪 Exercise A2.1 — See a real chain, and see where it stops

# the root is signed
dig . DNSKEY +noall +answer +dnssec | head -3

# .se is signed, and the ROOT publishes its DS
dig se DS +noall +answer

# does seamless.se have a DS in .se?
dig seamless.se DS +noall +answer +comments | head -4