Lion Cipher Lab
Validate DNSSEC and turn on DNSSEC validation in your own resolver
- Cyber / Security Engineer
- Intermediate
- ~40 min
- Free · no account required
Why it matters
Plain DNS has no way to tell a genuine answer from a forged one, which is exactly how cache-poisoning and on-path spoofing send people to fake login pages. DNSSEC fixes that by attaching cryptographic signatures a resolver can check, refusing tampered answers instead of trusting them. In the previous lab you pasted DNSSEC lines into Unbound and took it on faith; here you make validation visible — you watch a good answer carry the 'authenticated data' flag, watch a deliberately-broken domain get rejected with SERVFAIL, and watch delv print the whole chain of trust from the root down. Then you…
What you'll learn
- what DNSSEC actually proves (integrity and origin authenticity, not secrecy)
- reading DNSKEY, RRSIG and DS records and the chain of trust from the root
- spotting the 'ad' (authenticated data) flag in dig output
- recognising SERVFAIL as a validating resolver refusing a forged answer
- using +cd (checking disabled) to see what a non-validating resolver would accept
- using delv to walk and print the full validation chain
- confirming and enabling DNSSEC validation on your own Unbound resolver
- knowing when to reach for DNSSEC versus DoT/DoH
Steps in this lab
- What DNSSEC proves — and, just as important, what it does NOT
- The three records that make the chain of trust: DNSKEY, RRSIG, DS
- See validation working: find the 'ad' flag and the RRSIG
- See validation FAIL, and prove the resolver refuses the forgery
- Use delv to see the whole chain in one command
- Confirm (or turn on) validation in your OWN Unbound resolver
- Prove your resolver validates — the same two tests, at home
- When to reach for this — and the pro move: validate AND encrypt