Lecture 216: Route 53 - DNSSEC
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：07:43
- 来源：Udemy Lecture 33170756
- Slide 数量：7
- 画面切换：01:45、02:42、03:39、04:36、05:34、06:00
扫描说明
逐条读取了 Udemy 页面中的 164 条英文 Transcript cue，并按时间轴扫描全长约 07:43 的视频。依据 DNS Poisoning、DNSSEC Signing、KSK/ZSK 与 TTL、启用准备、DS Chain of Trust、CloudWatch 监控、完整信任链划分为 7 个小节。截图均在 Transcript 侧栏关闭、播放器控件隐藏后复核，统一为 1364×770。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. DNS Poisoning 把错误 IP 注入 Resolver Cache，诱导 Client 访问恶意站点
时间范围：00:00–01:45
总结 / Summary
中文
正常情况下，Local DNS Server 从 Route 53 得到 example.com 的正确 IP 9.10.11.12。攻击者若向本地 Resolver 注入伪造映射 21.22.23.24，Browser 会误以为它是目标站点并访问恶意 Server。传统 DNS 缺少对 Response Origin 与 Integrity 的密码学验证，DNSSEC 正是用来缓解这种 Poisoning/Spoofing 风险。
English
Normally the local DNS server receives the correct example.com address, 9.10.11.12, from Route 53. If an attacker injects a forged mapping to 21.22.23.24, the browser may believe it is the legitimate site and reach a malicious server. Traditional DNS lacks cryptographic verification of response origin and integrity; DNSSEC mitigates this poisoning and spoofing risk.
Transcript
00:00 Let's talk about Route 53 DNSSEC.
00:03 But before I introduce a solution,
00:04 let me expose in a simplified version the problem.
00:09 So we have DNS poisoning or spoofing.
00:11 It's a type of attack.
00:13 So for example say we have our web server,
00:15 it's hosting the website we want, for example.com.
00:19 And it is at a specific IP 9.10.11.12.
00:23 So the web browser of a client
00:26 is going to ask the local DNS server for example.com.
00:30 Then the local DNS server needs to actually
00:32 get the record for it.
00:33 So it's going to figure out
00:35 that Route 53 has, on its DNS, the solution
00:39 for where example.com is located.
00:42 So it's going to ask, for example.com
00:44 and Route 53 is going to return
00:46 well, it's the IP 9.10.11.12.
00:49 Okay. Fair enough.
00:51 But then a hacker through some process
00:54 manages to inject the value example.com equals
00:57 21.22.23.24 in our local DNS server.
01:03 And this is because, to very much simplify it,
01:06 the DNS works on the UDP protocol
01:08 which makes it somewhat easy to hack
01:11 and also when we don't have a DNSSEC
01:14 there is no cryptographic DNS verification process.
01:18 So therefore our local DNS server has been spoofed
01:21 and now is going to return to our web browser, the wrong IP.
01:25 So 21.22.23.24.
01:28 And therefore the web browser
01:29 is going to think it accesses the correct server
01:32 but actually it accesses a malicious website
01:35 at a different IP.
01:38 So that's call DNS poisoning and spoofing
01:39 and DNSSEC actually is going to help mitigate that issue.
2. DNSSEC 为 Public Hosted Zone 的 Record 提供 Origin 与 Integrity 验证
时间范围：01:45–02:42
总结 / Summary
中文
DNSSEC 即 DNS Security Extensions，只适用于 Public Hosted Zone。Route 53 支持 Domain Registration 侧的 DNSSEC 以及 Hosted Zone Record Signing：Zone 使用 Private Key 为 DNS Data 签名，支持 DNSSEC 的 Client/Resolver 用对应 Public Key 验证 Response 确实来自预期 Zone 且未被篡改。它提供认证与完整性，不负责加密 DNS 内容。
English
DNSSEC, or DNS Security Extensions, applies only to public hosted zones. Route 53 supports DNSSEC at domain registration and for hosted-zone record signing. The zone signs DNS data with a private key, and DNSSEC-aware clients or resolvers use the public key to verify that a response came from the expected zone and was not altered. It authenticates data; it does not encrypt DNS contents.
Transcript
01:45 So DNSSEC is for DNS Security Extension
01:49 and it's a protocol that helps you secure DNS traffic
01:53 to verify the DNS data integrity as well at its origin.
01:56 It only works when the hosted zones are public,
02:00 so for public domain names.
02:02 So Route 53 is going to support DNSSEC
02:06 both for domain registration and signing of the DNS records.
02:11 So the DNSSEC signing is the ability to validate
02:15 that a DNS response actually came from Route 53
02:19 and has not been tempered with.
02:21 So no record has been injected.
02:23 And how does it work?
02:24 Well, Route 53 is going to sign each record
02:27 in the hosted zone using a private key.
02:30 And then the clients can verify with a public key
02:34 that the signature is correct.
02:36 So the client needs to have some sort of logic
02:39 to understand the DNSSEC process.
3. KSK 由客户 KMS Asymmetric CMK 支撑，ZSK 由 Route 53 管理
时间范围：02:42–03:39
总结 / Summary
中文
DNSSEC 使用两类 Key：Key-signing Key（KSK）由客户管理，并关联 AWS KMS 中的 Asymmetric Customer-managed Key；Zone-signing Key（ZSK）由 Route 53 管理，负责日常 Zone Data Signing。考试重点是记住 KSK 属于客户责任、ZSK 属于 AWS。启用 Signing 后，Hosted Zone 中 Record 的 TTL 上限为一周，原本更短的 TTL 不受影响。
English
DNSSEC uses two key roles. The key-signing key (KSK) is customer managed and backed by an asymmetric customer-managed key in AWS KMS. The zone-signing key (ZSK) is managed by Route 53 for routine zone-data signing. The exam distinction is customer responsibility for KSK versus AWS responsibility for ZSK. After signing is enabled, hosted-zone record TTLs are capped at one week; shorter TTLs remain unchanged.
Transcript
02:42 So we have two keys happening within the DNSSEC process.
02:46 And the first one is managed by you
02:49 and you must remember it.
02:50 It is the key signing key, the KSK,
02:53 and it's based on an asymmetric CMK that you create in KMS.
02:58 So this key is managed by you
03:00 and then you have another one managed by AWS
03:04 which is call the ZSK, the zone signing key.
03:08 And you must know which one is yours.
03:10 So the one we manage is the KSK.
03:12 The ZSK is managed by Route 53 directly.
03:16 So when you enable Route 53
03:18 there's going to be some DNS signing in DNSSEC
03:21 and so therefore
03:22 you can verify cryptographically your records.
03:25 And there's also a second measure of security
03:29 which is that the TTL becomes at most one week
03:33 for all records in the hosted zone.
03:34 And if you have a TTL of less than one week,
03:37 then they're not affected, of course.
4. 启用前先降 TTL，再开启 Signing 并创建 KSK
时间范围：03:39–04:36
总结 / Summary
中文
Step 1 是确认 Zone 正常可用，并把普通 Record TTL 降到建议的一小时、SOA Minimum 降到五分钟，缩短错误配置的缓存影响。Step 2 通过 Console 或 CLI 为 Hosted Zone 启用 DNSSEC Signing，让 Route 53 创建 KSK，并把它连接到客户管理的 KMS Asymmetric Key。此时 Zone 已签名，但信任链尚未建立完成。
English
Step 1 verifies zone availability, lowers ordinary record TTLs to a recommended one hour, and lowers the SOA minimum to five minutes to reduce the caching impact of mistakes. Step 2 enables DNSSEC signing through the console or CLI, creates the KSK, and links it to a customer-managed asymmetric KMS key. The zone is signed at this point, but the trust chain is not complete.
Transcript
03:39 So the exam may ask you,
03:41 "How do you enable DNSSEC on a hosted zone?"
03:44 So first one you need to prepare for DNSSEC signing
03:48 that needs make sure that the zone availability
03:51 is working good.
03:52 That means that the DNS is responding correctly.
03:54 And this is done through customer feedback.
03:57 Then you lower the TTL for all your records to, for example,
04:01 one hour and you lower the TTL of the SOA to,
04:06 the SOA minimum, sorry, to five minutes.
04:08 So this is to prepare for DNSSEC signing.
04:11 Then you are going to enable DNSSEC signing
04:14 on your hosted zone
04:15 and you're going to create a key signing key, a KSK.
04:19 So to enable DNSSEC you can use the console or the CLI.
04:23 And then Route 53 is going to create a KSK for us
04:27 and we link it to a customer managed CMK from KMS.
04:32 So once this is done, we have enabled DNSSEC signing
04:35 but that's not all.
5. 在 Parent Zone 发布 DS Record，建立到 Child Zone 的 Chain of Trust
时间范围：04:36–05:34
总结 / Summary
中文
Step 3 是让 Parent Zone 信任已签名的 Child Hosted Zone：在 Parent/Registrar 处创建 Delegation Signer（DS）Record。DS 包含用于验证 DNS Signature 的 Public Key 摘要，使 Parent 能证明下一层的 Signing Key 合法。Registrar 可以是 Route 53，也可以是第三方；没有 DS，签名 Zone 无法接入全局 DNSSEC Chain of Trust。
English
Step 3 makes the parent zone trust the signed child hosted zone by creating a Delegation Signer (DS) record at the parent or registrar. The DS contains a digest related to the public key used to validate DNS signatures, allowing the parent to authenticate the next zone's signing key. The registrar can be Route 53 or a third party; without the DS, the signed zone is not connected to the global DNSSEC trust chain.
Transcript
04:36 You need to establish a chain of trust.
04:39 And I will show you in the next slide
04:40 what that means, visually.
04:42 So chain of trust means that the hosted zone,
04:45 where we enable DNSSEC,
04:47 is going to tell the parent hosted zone to trust it.
04:50 And this is done by creating
04:52 a delegation signer, DS, record in the parent zone.
04:57 So it's very important.
04:58 The parent zone must have a record to trust the child zone.
05:03 So the DS record contains a hash of the public key
05:07 that's used to sign DNS records
05:08 and that's how the trust is established.
05:11 So your registrar that needs to trust your child zone
05:14 could be, for example, Route 53,
05:16 or it could be a third party registrar.
05:18 So once we've done that, we are signing all the records
05:22 using the key from step two.
05:25 And from step three, the parent hosted zone
05:27 knows to trust that signing key
05:29 thanks to the delegation signer, DS, record
05:32 that we insert in the parent zone.
6. 用 CloudWatch 监控 Internal Failure 与 KSK Needing Action
时间范围：05:34–06:00
总结 / Summary
中文
Step 4 是运维保护：为 DNSSECInternalFailure 与 DNSSECKeySigningKeysNeedingAction 指标创建 CloudWatch Alarm。前者提示 Route 53 Signing 内部失败，后者提示 KSK 需要人工处理。启用流程可记为：准备与降 TTL、开启 Signing + KSK、Parent DS 建信任链、CloudWatch 告警。
English
Step 4 adds operational protection with CloudWatch alarms for DNSSECInternalFailure and DNSSECKeySigningKeysNeedingAction. The first surfaces internal Route 53 signing failures, while the second signals that a KSK needs operator action. Remember the flow as preparation and lower TTLs, enable signing plus KSK, publish the parent DS, and monitor with alarms.
Transcript
05:34 And then finally, a very good to have in this setup
05:37 is to monitor for errors using CloudWatch Alarms
05:40 so you can create CloudWatch Alarms
05:42 for two specific type of metrics
05:44 and they can come in the exam.
05:46 We have the DNSSEC internal failure
05:48 and the DNSSEC key signing key needing action.
05:53 Okay, so all these things allow you to enable DNSSEC.
05:56 To remember them, okay:
05:58 step one, step two, three, and four.
7. Root → TLD → Registrar → Hosted Zone 的每一层都必须 DNSSEC-aware
时间范围：06:00–07:43
总结 / Summary
中文
完整查询从 Root DNS Server 到 TLD、Registrar、Hosted Zone，可能继续到 Subdomain Zone。Chain of Trust 需要沿途每一层都支持 DNSSEC：上层通过 DS Record 信任下层 Signing Key；若还有 Sub-hosted Zone，则 Parent Hosted Zone 再为它发布 DS。Resolver 逐层验证签名与 Public Key，从而检测任何一环被篡改的 DNS Response。
English
A complete lookup moves from the root DNS server through the TLD, registrar, hosted zone, and potentially a subdomain zone. Every link must be DNSSEC aware. Each parent authenticates the next zone's signing key through a DS record, and a hosted zone publishes another DS when delegating to a signed child. Resolvers validate signatures and public keys along the path to detect tampered DNS responses.
Transcript
06:00 And what is a chain of trust just to understand?
06:02 So in a DNS way, when we, for example,
06:05 query for a specific record,
06:06 we're first going to go to the root DNS server
06:08 which is going to point to the TLD DNS server's .com.
06:12 Then the registrar,
06:14 for example, for example.com on Route 53,
06:17 then the hosted zone, which contains the records.
06:19 And maybe if we have a second hosted zone in there
06:21 that is a sub.example.com,
06:24 then we may have children of children of hosted zones.
06:27 So the chain of trust can only work
06:29 if all of these DNS servers along the way
06:33 are DNSSEC aware.
06:35 So what's happening is that the root DNS server
06:39 is going to have a trust on the TLD DNS server.
06:43 And then the TLD DNS server is going to trust the registrar.
06:47 And then we set up DNSSEC on the hosted zone
06:51 and we insert a DS record
06:54 so that the registrar trusts the hosted zone.
06:57 And then if we have a sub hosted zone,
06:59 we insert, again in the parent hosted zone,
07:02 we insert a DNS DS record to trust the sub hosted zone
07:07 and so on.
07:08 And so that means that your client
07:09 when it does its queries,
07:11 is going to query every DNS server all at once.
07:14 And then all along the way, thanks to this chain of trust,
07:18 we can verify each DNS response and we can make sure,
07:22 and this is of course some logic implemented
07:24 in the libraries you're already using,
07:26 we can verify that all these units responses
07:29 have been encrypted correctly and signed correctly,
07:32 thanks to the associated public key.
07:34 And this is how DNSSEC works.
07:37 So that was a pretty long lecture
07:38 but hopefully now you understand how this works.
07:40 I hope you liked it.
07:41 And I will see you in the next lecture.
整讲总结 / Overall Summary
中文
DNSSEC 通过数字签名验证 Public DNS Data 的来源与完整性，缓解 Cache Poisoning/Spoofing。Route 53 中客户管理 KSK 及其 KMS Asymmetric Key，AWS 管理 ZSK。启用时先降 TTL，再开启 Signing、创建 KSK，并在 Parent/Registrar 发布 DS Record 建立信任链，最后用 CloudWatch 监控两类 DNSSEC 错误指标。
English
DNSSEC uses digital signatures to verify the origin and integrity of public DNS data and mitigate cache poisoning or spoofing. In Route 53, the customer manages the KSK and its asymmetric KMS key while AWS manages the ZSK. Lower TTLs, enable signing and create the KSK, publish a DS record at the parent or registrar to establish trust, and monitor the two DNSSEC error metrics in CloudWatch.
返回顶部 ↑