Lion Cipher Lab

Sign your own DNS zone with DNSSEC and prove tamper-detection

• Cyber / Security Engineer
• Advanced
• ~60 min
• Free · no account required

Why it matters

Plain DNS has no security at all: any device on the path between a resolver and a name server can forge an answer, and the resolver has no way to tell a real reply from a fake one. That is how cache-poisoning attacks redirect users to attacker servers. DNSSEC (DNS Security Extensions) fixes exactly that one thing — it lets the OWNER of a zone cryptographically SIGN their records so a resolver can prove an answer really came from the zone owner and was not altered in flight. It does this with public-key signatures: the zone signs each RRset (a group of records of the same name and type) with a…

What you'll learn

• running your own AUTHORITATIVE name server (BIND 9 named) that serves a zone you created — the opposite role to a recursive resolver that merely looks answers up
• understanding what a zone, an RRset, and the record types RRSIG, DNSKEY, DS, and NSEC/NSEC3 actually are, and being able to point at each one in real dig output
• generating a Key-Signing Key (KSK) and a Zone-Signing Key (ZSK) with dnssec-keygen and explaining why DNSSEC splits the job into two keys
• signing a zone with dnssec-signzone so every RRset gains an RRSIG (a cryptographic signature) and the zone publishes its public keys as a DNSKEY RRset
• generating the DS (Delegation Signer) record — a hash of your KSK — that a parent zone publishes to vouch for your zone, forming one link of the chain of trust
• querying your signed zone with `dig +dnssec` and reading the RRSIG and DNSKEY records in the reply
• validating the zone's signatures by hand with dnssec-verify and delv, and seeing the 'fully signed / fully validated' verdict
• TAMPERING with a record in the signed zone and watching validation flip to bogus (a real validating resolver returns SERVFAIL and drops the AD bit) — proving DNSSEC detects forgery
• explaining the chain of trust end to end: DS in the parent -> KSK signs the DNSKEY RRset -> ZSK signs the data RRsets -> RRSIGs, anchored at the signed root
• knowing DNSSEC's hard limits and hazards: it authenticates, it does NOT encrypt (that is DoT/DoH); RRSIGs EXPIRE and must be re-signed on a schedule or the zone goes bogus; a KSK rollover that forgets to update the parent DS breaks the chain; NSEC leaks every name (zone-walking) while NSEC3 hashes them; ECDSA over RSA for smaller answers and less amplification

Steps in this lab

1. The one thing DNSSEC does — and the one thing it does not
2. Stand up an authoritative BIND 9 server in a container
3. Create the unsigned zone (plain DNS first)
4. Generate the two keys: a KSK and a ZSK
5. Sign the zone — RRSIGs, the DNSKEY RRset, and the DS record
6. Serve the signed zone and query it with dig +dnssec
7. Validate the chain by hand
8. TAMPER: forge a record and watch DNSSEC catch it
9. NSEC vs NSEC3 — proving a name does NOT exist without leaking the zone
10. The judgment: what this costs to run, and when it is worth it
11. What you did — and the reflex to keep

Open the full interactive lab →