Lecture 223: Solution Architectures for DNS
- 课程：[NEW] AWS Certified Advanced Networking Specialty 2026
- 视频时长：05:05
- 来源：Udemy Lecture 28556471
- Slide 数量：4
- 画面切换：01:15、02:20、03:45
扫描说明
逐条读取了 Udemy 页面中的 131 条英文 Transcript cue，并按时间轴扫描全长约 05:05 的视频。依据 Split-View DNS 的外部查询、VPC 内部查询、Multi-Account Inbound Resolution、Centralized Outbound Forwarding 四个阶段划分小节。4 张截图均在 Transcript 侧栏关闭、播放器控件隐藏后复核，统一为 1364×770。
Transcript 来自 Udemy 页面自带的英文自动字幕，没有使用 ASR。下面保留页面原文，包括其中的语法或识别错误。
1. Split-View DNS：同名 Public/Private Hosted Zone 返回不同答案
时间范围：00:00–01:15
总结 / Summary
中文
Split-View DNS（也称 Split-Horizon DNS）允许 Public Hosted Zone 与 Private Hosted Zone 使用相同的 Domain Name，例如 example.com。Internet Client 查询 app.example.com 时，只会访问 Public Hosted Zone 并得到 Public IP；若 db.example.com 仅存在于 Private Hosted Zone，公网查询不会继续转发到私有 Zone，因此无法取得该 Record。这个设计能让外部用户只看到公开服务，同时隐藏内部资源名称与地址。
English
Split-view, or split-horizon, DNS allows a public hosted zone and a private hosted zone to use the same domain name, such as example.com. An Internet client querying app.example.com reaches only the public hosted zone and receives a public IP. If db.example.com exists only in the private hosted zone, the public lookup is not forwarded into that private zone and returns no usable record. This exposes public services while keeping internal names and addresses private.
Transcript
00:00 So now let's talk
00:01 about some solution architecture around DNS,
00:04 and one of them is called a split-view DNS or split-horizon.
00:07 This is when you want to use the same domain name
00:09 for internal and external uses,
00:11 and that means that the public and the private hosted zones
00:15 will have the exact same name.
00:16 For example, example.com.
00:18 So imagine a VPC, we have a public hosted zone example.com,
00:22 and we'll also have private hosted zone
00:23 associated with a VPC for example.com as well.
00:26 Now, if we enter some records in the public hosted zone
00:29 and we enter other records in the private hosted zone
00:31 with different values, obviously,
00:33 then what's going to happen?
00:35 Well, if a client is outside of your VPC
00:37 and issues a DNS query for app.example.com,
00:41 there is going to be sent automatically,
00:43 of course, to the public hosted zone
00:44 because it doesn't have access to their private hosted zone,
00:46 because it's outside of the VPC.
00:48 Therefore the IP returned by this record
00:51 is going to be a public IP.
00:53 And maybe this is the public IP of an EC2 instance
00:55 in a public subnet as so the client knows
00:57 how to get to this EC2 instance.
01:00 If the client is training for db.example.com,
01:03 of course, that record does not exist
01:04 in the public hosted zone,
01:06 and it's not going to be forwarded
01:07 to the private hosted on either.
01:08 So the records in the private hosted zone
01:10 are not going to be accessible from the internet,
01:13 so there will just be an empty response from the DNS query.
2. VPC 内部 Client 优先使用 Private Hosted Zone
时间范围：01:15–02:20
总结 / Summary
中文
与 Private Hosted Zone 关联的 VPC 内部 Client（例如 Amazon WorkSpaces）查询同一个 app.example.com 时，Route 53 Resolver 使用私有 Zone 中的 Record，返回 10.0.0.65 等 Private IP。于是相同 FQDN 可依据 Query 来源返回不同地址、内容或认证入口。重点是：同名 Public/Private Hosted Zone 是合法且常见的架构，内部查询不会因为 Public Zone 里也有同名 Record 就绕过 Private Zone。
English
A client inside a VPC associated with the private hosted zone, such as Amazon WorkSpaces, resolves the same app.example.com name from the private zone and receives a private address such as 10.0.0.65. The same FQDN can therefore return different addresses, content, or authentication paths according to where the query originates. Public and private hosted zones with the same name are valid and common; an internal lookup does not bypass the private zone merely because a matching public record exists.
Transcript
01:18 Now, if we consider instances or systems in our VPC,
01:22 for example, EC2 instance in the workspaces.
01:25 Now, if workspaces is going to ask for app.example.com,
01:30 it is within your VPC,
01:32 the VPC is associated with a private hosted zone,
01:35 and so therefore, what's going to happen
01:36 is that this workspace is going to get a new reply
01:40 from the private zone with a private IP,
01:43 and is going to be redirected for example,
01:45 to another EC2 instance in the private subnets.
01:47 So as you can see, the same DNS query
01:49 made from two different places
01:51 is going to return two different IPs,
01:53 and therefore send us to two different EC2 instances.
01:56 So, why do we do this?
01:58 Well, maybe because sometimes
01:59 we want you to serve different contents,
02:01 or we want to require different authentication
02:03 for internal and external users or whatever.
02:06 There are tons of efficacy for this,
02:07 but as you can see, it is doable in AWS.
02:08 It is completely fine to have a public hosted zone
02:11 and the private hosted zone for the same domain,
02:13 and this can come up again in the exam.
02:17 Another architecture
02:18 is around at multi-account DNS management
3. Central DNS Account 集中处理 Multi-Account Inbound Resolution
时间范围：02:20–03:45
总结 / Summary
中文
Multi-Account 环境可建立一个 Central DNS Account，在其 VPC 中集中部署 Route 53 Resolver Inbound/Outbound Endpoint 与顶层 Private Hosted Zone。各业务 Account 为自己的 Subdomain 建立 Private Hosted Zone 并完成关联或委派，例如 acc1.awscloud.private。On-Premises DNS Resolver 经 VPN 或 Direct Connect 把 AWS 私有域名 Query 送到 Central Inbound Endpoint，再解析到相应 Member Account 的 Resource；这样不必在每个 Account 重复部署 Resolver Endpoint。
English
A multi-account environment can use a central DNS account that hosts Route 53 Resolver inbound and outbound endpoints plus a top-level private hosted zone. Each workload account creates and associates or delegates a private hosted zone for its own subdomain, such as acc1.awscloud.private. On-premises DNS resolvers send AWS-private queries across VPN or Direct Connect to the central inbound endpoint, which can resolve resources in the appropriate member account. This avoids deploying resolver endpoints independently in every account.
Transcript
02:20 while using Route 53 Resolvers.
02:22 So imagine we want to extend what we learned before
02:25 about hybrid DNS,
02:26 but now we have a lot of different accounts.
02:28 We don't wanna link all these accounts together,
02:30 and create resolvers in all the accounts.
02:32 That would be highly inefficient.
02:34 So how do we do an architecture with that?
02:36 Well, we have our on-premises data center,
02:37 which contains our server and our DNS resolver
02:40 at onprem.private.
02:43 This is connected obviously to your central DNS accounts.
02:47 And then in our DNS accounts,
02:50 we're going to have a classic architecture
02:52 with a private hosted zone.
02:54 A resolver inbound endpoints, a resolver outbound endpoints,
02:57 and by default, the Routes 53 Resolvers.
02:59 So this is something we've seen from the past lectures.
03:02 But now what's going to happen is that we want to delegate
03:05 the sub domains to the other accounts.
03:07 So we're linking two lectures together right now.
03:09 So in each account,
03:10 we're going to create a private hosted zone
03:12 for a sub domain.
03:13 For example, account one dot blah, blah, blah,
03:16 account two dot blah, blah, blah, and so on.
03:17 And we're, of course, going to associate them together
03:20 by creating an association,
03:22 and also making sure that the name servers have matched
03:25 based on the sub domains.
03:28 So once this is associated,
03:29 what's going to happen is that any request
03:31 that comes inbound, of course,
03:33 is going to be redirected to my private hosted zone.
03:36 The private hosted zone knows about the name servers
03:38 of the other private hosted zones, and so therefore,
03:41 the inbound requests from on-premises
03:43 into our multi-accounts will be working just fine,
4. 用 AWS RAM 共享 Central Outbound Forwarding Rules
时间范围：03:45–05:05
总结 / Summary
中文
反向的 Outbound Resolution 也由 Central DNS Account 统一管理：为 onpremise.private 等 On-Premises Domain 创建 Forwarding Rule，Target IP 指向企业 DNS Resolver，并由 Central Outbound Endpoint 转发。随后通过 AWS Resource Access Manager（AWS RAM）把这些 Resolver Rule 共享给 Member Account，再关联到其 VPC。Member Account 无需复制 Rule 或 Endpoint，也能解析 On-Premises Name；规则、目标地址与变更都保持集中治理。
English
Outbound resolution can also be centralized. The DNS account creates forwarding rules for on-premises domains such as onpremise.private, targets the corporate DNS resolver, and sends queries through the central outbound endpoint. AWS Resource Access Manager shares these resolver rules with member accounts, which associate them with their VPCs. Member accounts can resolve on-premises names without duplicating rules or endpoints, while targets and changes remain centrally governed.
Transcript
03:46 and they will be managed, obviously, within each accounts.
03:50 So these three EC2 instances
03:52 are now accessible from your on-premises data center.
03:56 Now for the outbound is a little bit more tricky,
03:58 because the private hosted zone is to go up one level
04:01 to the private hosted zone in the main DNS account,
04:04 and then all the way to the on-premises data center.
04:07 And to do this, well,
04:08 we're going to create the forwarding rules
04:10 on the central DNS accounts, of course,
04:12 saying, "Hey, for on-premises data center,
04:15 "please go to this IP."
04:17 But these forwarding rules do not have to be recreated
04:20 in every single accounts,
04:22 otherwise that would be extremely painful.
04:24 So there is the AWS RAM service,
04:27 which allows you to share resources with other accounts.
04:29 And some things that can be shared with other accounts
04:32 are forwarding rules.
04:33 So we can share these forwarding rules with other accounts
04:35 and associate them, of course,
04:37 with the private hosted zones and so on.
04:39 And the idea behind this is that now
04:41 there's only one central place in the central DNS accounts
04:44 where these forwarding rules are going to be managed.
04:47 And then therefore, the account A, B and C
04:50 now have the capability of also resolving the DNS names
04:54 of on-premises data center servers, for example.
04:57 And this is how you do multi-account DNS management
05:00 using resolvers.
05:01 So I hope that makes sense.
05:02 I hope you liked this lecture,
05:03 and I will see you in the next lecture.
整讲总结 / Overall Summary
中文
本讲把 Route 53 DNS 组合成两类常考架构：Split-View DNS 让同一个 Domain 在公网与 VPC 内返回不同答案；Multi-Account DNS 则把 Resolver Inbound/Outbound Endpoint、Private Hosted Zone 与 Forwarding Rule 放在 Central DNS Account，并通过 Subdomain 关联/委派和 AWS RAM 服务所有 Member Account。核心收益是内部外部隔离、跨环境双向解析，以及集中管理而非逐 Account 重复建设。
English
This lecture combines Route 53 features into two common architectures. Split-view DNS returns different answers for the same domain inside and outside a VPC. Multi-account DNS centralizes resolver inbound and outbound endpoints, private hosted zones, and forwarding rules in a DNS account, then serves member accounts through subdomain association or delegation and AWS RAM sharing. The result is internal/external separation, bidirectional hybrid resolution, and centralized management instead of per-account duplication.
返回顶部 ↑