--- title: "CTP Topic 19 Configuring DNS within AWS LZs" type: source tags: [] date: 2026-04-14 --- ## Source File - [[Cloud & DevOps/Public-Cloud-Learning-Sessions/08_Networking/ctp-topic-19-configuring-dns-within-aws-lzs]] ## Summary(用中文描述) - 核心主题:在 AWS Landing Zone 多账号环境中配置集中化 DNS 管理架构 - 问题域:跨账号、跨云与本地数据中心(On-prem)之间的域名解析难题 - 方法/机制:设立专用 DNS 账号集中管理 Route 53 私有托管区,通过 Route 53 Resolver Inbound/Outbound Endpoints 打通 AWS 与本地 DNS,AWS RAM 跨账号共享解析规则,Terraform 实现自动化部署 - 结论/价值:集中化 DNS 管理优于分散式,是多账号 AWS 环境的标准最佳实践 ## Key Claims(用中文描述) - 集中化 DNS 管理优于分散管理:应在 Landing Zone 中设立专门的 DNS 账号,而非在每个业务账号中分散创建私有托管区,便于统一维护路由规则和域名记录 - Route 53 Resolver 是混合 DNS 架构的核心组件:Inbound Endpoints 接收来自本地数据中心的解析请求,Outbound Endpoints 将 AWS 内部请求转发至本地 DNS 服务器 - AWS RAM 实现跨账号规则共享:通过 AWS Resource Access Manager 将 DNS 账号中定义的 Resolver Rules 共享给各个业务账号 - 跨账号 VPC 与私有托管区关联必须先授权再关联:授权(Authorization)必须在关联(Association)之前完成 - Terraform 是自动化部署 DNS 架构的核心工具:新业务 VPC 创建时自动完成规则共享与 VPC 关联,确保新账号上线即具备完整解析能力 ## Key Quotes > "我们推荐在 Landing Zone 中设立一个专门的 DNS 账号,所有私有托管区都集中在这里管理,而不是在每个业务账号中创建各自的托管区。" — Sankar Gopov,解释集中化 DNS 管理的优势 > "Inbound Endpoints 用于接收来自本地数据中心的 DNS 查询请求;Outbound Endpoints 用于将 AWS 内部的 DNS 查询转发到本地 DNS 服务器。" — Sankar Gopov,Route 53 Resolver Endpoints 的双向作用 > "跨账号关联时,必须先由托管区拥有者进行授权(Authorization),然后才能由 VPC 拥有者执行关联(Association)。" — Sankar Gopov,跨账号关联的必须步骤 ## Key Concepts - [[Route 53 Resolver]]:AWS Route 53 的 DNS 解析组件,通过 Inbound/Outbound Endpoints 实现混合云 DNS 架构 - [[Private Hosted Zone]]:AWS Route 53 的私有托管区,用于在指定 VPC 内部解析自定义域名,不对互联网开放 - [[Route 53 Resolver Rules]]:解析规则,定义特定域名的解析路径(如将某后缀的域名转发至本地数据中心) - [[VPC Association Authorization]]:跨账号关联流程,PHZ 拥有者先授权,VPC 拥有者再执行关联 - [[AWS RAM]]:Resource Access Manager,用于在组织内跨账号共享 Resolver Rules 等资源 - [[Hybrid DNS Resolution]]:混合 DNS 解析,AWS VPC 与本地数据中心之间的跨环境域名解析机制 - [[Terraform DNS Automation]]:使用 Terraform 自动化部署 DNS 架构的实践 ## Key Entities - [[Sankar Gopov]]:本次视频讲师,AWS Landing Zone DNS 架构专家 - [[AWS Landing Zone]]:AWS 多账号环境规范,是 DNS 架构的承载基础 ## Connections - [[ctp-topic-22-global-dns-service-offerings]] ← extends ← [[ctp-topic-19-configuring-dns-within-aws-lzs]] - 两者同属 DNS 专题,后者(前文)讲企业级全局 DNS 服务架构(Infoblox + Route 53),后者(本文)聚焦 Landing Zone 内部的具体配置实施 - [[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]] ← depends_on ← [[ctp-topic-19-configuring-dns-within-aws-lzs]] - Landing Zone 顶层设计包含 DNS 账户的规划 - [[ctp-topic-25-labs-landing-zone-overview-itom-teams]] ← relates_to ← [[ctp-topic-19-configuring-dns-within-aws-lzs]] - Labs LZ 中 Core 账户托管 DNS 服务(Swimford.net) - [[ctp-topic-17-active-directory-services-in-gruntwork-aws-lzs]] ← depends_on ← [[ctp-topic-19-configuring-dns-within-aws-lzs]] - AD 服务依赖 DNS 完成域名解析,int-sas.local 等域名的解析由 DNS 架构提供 ## Contradictions - 与 [[ctp-topic-22-global-dns-service-offerings]] 潜在视角差异: - 冲突点:DNS 账号是否应包含公共托管区(Public Hosted Zone) - 当前观点(Topic 19):DNS 账号专注于私有托管区和 Route 53 Resolver 管理 - 对方观点(Topic 22):Route 53 还需管理公共域名解析(Route 53 Hosted Zone + Route 53 Resolver) - 注:两者可能适用于不同的环境(Topic 22 侧重 DNS 服务提供者的全局架构,Topic 19 侧重 Landing Zone 内部的落地配置)