58 lines
4.7 KiB
Markdown
58 lines
4.7 KiB
Markdown
---
|
||
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 内部的落地配置）
|