🔐 Route 53 DNSSEC

Domain Name System Security Extensions — Learning Hub

route53.jideaws.ai

📹 Route 53 DNSSEC SME Videos

Curated video resources from internal SME sessions on DNSSEC:

🎬 Feature Demo: DNSSEC in Route 53

Presenter: Jorge Prada (Technical Account Manager)

Topics Covered: DNSSEC theory, enabling DNSSEC signing in Route 53, creating KSK, establishing chain of trust with DS records, enabling DNSSEC validation in VPC

▶️ Watch on Broadcast

Key demo steps: Enable DNSSEC signing → Create KSK with CMK → Add DS record to registrar → Verify chain of trust via DNSViz → Enable DNSSEC validation on VPC

🎬 Route53 DNSSEC CloudFormation Integration Deep Dive

Topics Covered: Automating DNSSEC setup via CloudFormation

▶️ Watch on Broadcast

🎬 DNSSEC Knowledge Transfer Session (Aug 2023)

Topics Covered: DNSSEC internals, troubleshooting, key rotation

▶️ Watch on Broadcast

🎬 DNS, DNSSEC, and High Level Architecture of Route 53 DaaS

Topics Covered: DNS fundamentals, DNSSEC architecture, Route 53 DaaS internals

▶️ Watch on Broadcast

Broadcast Channel: Route 53 DNSSEC Channel

📚 DNSSEC Topics & Key Concepts

1. What is DNSSEC?

A suite of extensions that add cryptographic authentication to DNS responses. Prevents DNS spoofing and cache poisoning.

2. DNSSEC Resource Records

RRSIG — Signature for each RRSet
DNSKEY — Public key for verification
DS — Delegation Signer (hash of KSK)
NSEC — Authenticated denial of existence

3. Signing Keys

ZSK (Zone Signing Key) — Signs all record sets
KSK (Key Signing Key) — Signs the DNSKEY records

4. Chain of Trust

DS record in parent zone → validates KSK → validates ZSK → validates all records. Anchored at the DNS root.

5. Route 53 Implementation

Uses KMS for key management. KSK backed by asymmetric CMK (ECC_NIST_P256). Uses "black-lies" for negative responses.

6. Common Issues

Broken KMS key policy, deleted CMK, DS record mismatch, key rotation failures, chain of trust breaks.

Key Notes for Support Engineers

⚠️ KMS Key Dependency: If a customer's KMS key backing their DNSSEC KSK becomes inaccessible (deleted or broken policy), their zone will fail resolution for DNSSEC-validating resolvers. Customer must fix their KMS key and KSK.
🔄 Key Rotation: KSK should be rotated periodically. Errors during rotation can cause downtime. Always verify chain of trust after rotation using DNSViz.
✅ Validation: DNSSEC validation must be explicitly enabled per VPC. Use Route 53 Resolver settings to enable.

🧒 DNSSEC Explained for Kids (Ages 8-10)

📬✉️

Imagine the Internet is a Post Office...

When you type "youtube.com" in your browser, it's like sending a letter asking: "Hey, where does YouTube live?"

A helper (called a DNS resolver) looks up the address for you and says: "YouTube lives at house number 142.250.80.46!"

Your browser then goes to that house to show you the website.

😈🏠

The Problem: Sneaky Tricksters!

What if a bad person changed the address book? They could write: "YouTube lives at MY house!"

Then when you try to go to YouTube, you'd end up at the bad person's fake website instead! This is called DNS Spoofing — like someone putting a fake sign on the wrong house.

🔐🦸

The Solution: DNSSEC is like a Magic Seal!

DNSSEC adds a special sticker (a digital signature) to every address in the address book.

Think of it like this:

  • 📝 The Zone Signing Key (ZSK) is like a teacher's stamp that marks every page in the class notebook as "real"
  • 👑 The Key Signing Key (KSK) is like the principal's stamp that says "this teacher's stamp is real"
  • 🏫 The DS Record is like the school board saying "this principal is real"
  • 🌍 The Root is like the government saying "this school board is real"

So there's a chain of trust — like a chain of grown-ups all vouching for each other, all the way up to the top!

🎯✅

What DNSSEC Does & Doesn't Do

✅ Does: Makes sure the address you get is the REAL address (not a fake one)

✅ Does: Tells you if someone tried to change the address

❌ Doesn't: Hide what websites you visit (that's a different job for HTTPS!)

It's like checking that a letter really came from your friend by recognizing their special sticker — but anyone can still see the envelope!

🧪🔬

Try It Yourself!

Ask a grown-up to help you visit dnsviz.net — type in any website name and you can SEE the chain of trust drawn as a picture! Green means everything is good. Red means something is broken.

🧠 Daily DNSSEC Quizzes

Practice questions based on real Route 53 support scenarios from the R53 ticket queue.

📅 Day 1: DNSSEC Fundamentals

Q1: What does DNSSEC protect against?
  1. DDoS attacks on DNS servers
  2. DNS cache poisoning and spoofing
  3. Unauthorized zone transfers
  4. DNS query logging
Show AnswerB — DNSSEC provides data origin authentication and integrity, preventing cache poisoning and man-in-the-middle attacks.
Q2: Which AWS service is used to store the KSK private key in Route 53 DNSSEC?
  1. AWS Secrets Manager
  2. AWS KMS (Key Management Service)
  3. AWS Certificate Manager
  4. AWS CloudHSM
Show AnswerB — Route 53 DNSSEC uses an asymmetric KMS CMK (ECC_NIST_P256) to back the KSK.
Q3: A customer reports their DNSSEC-signed zone is failing validation. What is the FIRST thing to check?
  1. Whether the VPC has DNSSEC validation enabled
  2. Whether the KMS key backing the KSK is accessible
  3. Whether the DS record in the parent zone matches the KSK
  4. Whether the zone has any RRSIG records
Show AnswerC — A broken chain of trust (DS record mismatch) is the most common cause of validation failure. Verify the DS record matches the KSK hash.

Based on: Customer outreach for broken KMS key/KSK scenarios

📅 Day 2: Chain of Trust & Key Management

Q1: A customer deleted their KMS key that backs the DNSSEC KSK. What happens?
  1. Nothing — the zone continues to work normally
  2. The zone fails resolution only for non-DNSSEC resolvers
  3. The zone fails resolution for DNSSEC-validating resolvers
  4. Route 53 automatically creates a new KMS key
Show AnswerC — When the KMS key is inaccessible, Route 53 cannot sign records. DNSSEC-validating resolvers will reject the responses, causing resolution failure for those clients.
Q2: What is the correct order to establish DNSSEC chain of trust in Route 53?
  1. Create DS record → Enable signing → Create KSK
  2. Enable signing → Create KSK → Add DS record to parent zone
  3. Create KSK → Add DS record → Enable signing
  4. Add DS record → Create KSK → Enable signing
Show AnswerB — First enable DNSSEC signing (which creates the ZSK), then create a KSK (backed by KMS), then add the DS record to the parent zone to complete the chain of trust.
Q3: Which record type links a child zone's DNSSEC to its parent zone?
  1. RRSIG
  2. DNSKEY
  3. DS (Delegation Signer)
  4. NSEC
Show AnswerC — The DS record is a hash of the child zone's KSK DNSKEY, published in the parent zone to establish the chain of trust.

Based on: KMS key accessibility issues and chain of trust establishment

📅 Day 3: Troubleshooting DNSSEC

Q1: A customer's domain is resolving fine for most users but failing for some corporate networks. What's the likely cause?
  1. The domain's TTL is too low
  2. Those networks use DNSSEC-validating resolvers and the chain of trust is broken
  3. Route 53 is throttling requests from those networks
  4. The hosted zone has too many records
Show AnswerB — If DNSSEC is misconfigured (broken chain of trust), only resolvers that validate DNSSEC will reject the responses. Non-validating resolvers will still work fine.
Q2: What tool can you use to visualize and verify the DNSSEC chain of trust?
  1. dig +dnssec
  2. DNSViz (dnsviz.net)
  3. nslookup
  4. Both A and B
Show AnswerD — Both `dig +dnssec` (for command-line verification) and DNSViz (for visual chain-of-trust analysis) are useful. DNSViz shows green/red indicators for each link in the chain.
Q3: Route 53 uses which method for authenticated denial of existence (negative responses)?
  1. NSEC records
  2. NSEC3 records
  3. "Black-lies" (RFC draft)
  4. "White-lies"
Show AnswerC — Route 53 implements "black-lies" for negative responses, which synthesizes minimal NSEC records on-the-fly rather than pre-generating them for the entire zone.

Based on: Zone resolution failures and DNSSEC validation issues

📅 Day 4: Route 53 DNSSEC Operations

Q1: A customer wants to disable DNSSEC on their hosted zone. What must they do FIRST?
  1. Delete the KMS key
  2. Remove the DS record from the parent zone
  3. Delete all RRSIG records manually
  4. Disable DNSSEC validation on all VPCs
Show AnswerB — You must remove the DS record from the parent zone FIRST to break the chain of trust safely. Then disable signing. If you disable signing while the DS record exists, validating resolvers will reject responses (SERVFAIL).
Q2: What KMS key type is required for Route 53 DNSSEC KSK?
  1. Symmetric AES-256
  2. Asymmetric RSA_2048
  3. Asymmetric ECC_NIST_P256
  4. HMAC SHA-256
Show AnswerC — Route 53 DNSSEC requires an asymmetric KMS key with key spec ECC_NIST_P256 and key usage SIGN_VERIFY.
Q3: A customer enabled DNSSEC signing but forgot to add the DS record. What is the impact?
  1. The zone will fail resolution for all resolvers
  2. No impact — the zone works normally, but DNSSEC validation cannot be performed
  3. Route 53 will automatically add the DS record
  4. The KSK will be automatically deactivated
Show AnswerB — Without the DS record in the parent zone, there's no chain of trust. The zone still resolves normally, but DNSSEC-validating resolvers cannot verify the signatures (they treat it as unsigned).

Based on: R53 DNSSEC operational procedures and customer guidance

📅 Day 5: Advanced Scenarios

Q1: Multiple accounts have DNSSEC KSKs backed by inaccessible KMS keys. What is the recommended customer outreach action?
  1. Disable DNSSEC signing on their behalf
  2. Notify customers to fix their KMS key policy or KSK
  3. Delete the hosted zones
  4. Create new KMS keys for them
Show AnswerB — Per the Route 53 runbook, support should reach out to customers to inform them they need to fix their KMS key and KSK. We cannot modify customer KMS keys.
Q2: A customer has DNSSEC enabled and wants to transfer their domain to a different registrar. What DNSSEC consideration applies?
  1. DNSSEC must be disabled before transfer
  2. The DS record must be re-established at the new registrar
  3. The KSK must be rotated after transfer
  4. Both A and B could be valid approaches
Show AnswerD — Either disable DNSSEC before transfer (simpler) or coordinate DS record migration with the new registrar. The key is maintaining or safely breaking the chain of trust during the transition.
Q3: DNSSEC provides which of the following? (Select all that apply)
  1. Data origin authentication
  2. Data confidentiality (encryption)
  3. Data integrity protection
  4. Authenticated denial of existence
Show AnswerA, C, D — DNSSEC provides authentication, integrity, and authenticated denial of existence. It does NOT provide confidentiality — responses are signed but not encrypted.

Based on: Multi-account KMS key outreach tickets and domain transfer scenarios

📖 Additional Resources