📚 课程目录第1章混合云DNS架构总览

1. 混合云DNS架构总览

当企业把一部分业务留在自建机房、另一部分迁移到 AWS 之后，最先暴露出来的往往不是计算或存储问题，而是“名字解析”问题。用户在本地数据中心访问 app.corp.example.com，在 AWS 上访问 app.aws.example.com，两个环境各自有一套 DNS，彼此却互不知晓。混合云 DNS 要解决的核心命题就是：让分布在不同网络域、不同云平台、不同 DNS 实现中的名字空间，能够被统一、可控、可观测地解析。

一、混合云 DNS 到底在解决什么

从概念上讲，混合云 DNS 是跨越本地数据中心与公有云的域名解析体系，它包含三个层次：名字空间规划（谁拥有哪个域、子域如何划分）、解析路径打通（查询如何从一侧到达另一侧）、解析结果一致性（同一名字在不同位置返回什么地址）。AWS 侧的主要构件是 Amazon Route 53（公有托管区、私有托管区、Resolver 入站/出站终端节点）与 VPC DNS；本地侧通常是 BIND、Windows DNS 或企业级 DNS 设备。

业务驱动通常来自四类诉求：一是应用现代化过程中新旧系统需要互相调用；二是并购或多云并存导致域名体系需要整合；三是合规要求某些数据必须留在本地，但控制面在云上；四是故障切换，希望本地 DNS 挂掉时云上仍能解析关键服务。这些诉求最终都落到同一个技术挑战上——解析路径必须双向可达，且不能把整个内网暴露出去。

二、整体工程框架

一个可落地的混合云 DNS 框架，通常由四部分组成：

名字空间与托管区划分：确定哪些域由 Route 53 私有托管区承载，哪些保留在本地 DNS，避免同一名字在两处都有权威记录。
解析通道：通过 Route 53 Resolver 出站终端节点（Outbound Endpoint）把云上查询转发到本地 DNS，通过入站终端节点（Inbound Endpoint）让本地 DNS 把云上域的查询转发进 VPC。
网络连通：解析通道依赖 VPC 与本地之间的连通性，通常是 Site-to-Site VPN 或 Direct Connect，且需要放行 UDP/TCP 53。
转发规则与关联：在 Route 53 Resolver 中为本地域建立转发规则（Forwarding Rule），并关联到需要使用的 VPC。

下面这张图给出典型的双向解析拓扑：左侧是本地数据中心 DNS，右侧是 AWS VPC 内的 Route 53 Resolver，中间通过两条方向相反的解析通道连接。

三、关键技术挑战

第一是名字空间冲突。如果本地和云上都存在 example.com 的权威区，解析结果就会随查询位置漂移。工程上的做法是明确划分：本地保留 corp.example.com，云上使用 aws.example.com，两者通过转发规则互相引用，而不是各自复制对方的记录。

第二是转发环路。当本地 DNS 把 aws.example.com 转发给 Inbound Endpoint，而云上 Resolver 又因为某条规则把该域转回本地时，就会形成循环。规避方法是：转发规则只覆盖对方独有的域，且 Route 53 私有托管区中的域不再配置指向本地的转发规则。

第三是解析延迟与超时。跨 VPN 的 DNS 查询会引入额外 RTT，若本地 DNS 对云上域设置过短超时，会出现间歇性解析失败。实践中建议对转发域设置合理的超时与重试，并在两端都保留缓存。

四、一个可参考的起步配置

假设本地域为 corp.example.com，云上域为 aws.example.com，VPC 为 vpc-0a1b2c3d。起步阶段可以按以下顺序落地：

# 1. 在 Route 53 创建私有托管区
aws route53 create-hosted-zone \
  --name aws.example.com \
  --vpc VPCRegion=ap-northeast-1,VPCId=vpc-0a1b2c3d \
  --caller-reference hybrid-dns-001

# 2. 创建 Inbound Endpoint（供本地 DNS 转发进来）
aws route53resolver create-resolver-endpoint \
  --name inbound-hybrid \
  --direction INBOUND \
  --ip-addresses SubnetId=subnet-1111,SubnetId=subnet-2222

# 3. 创建 Outbound Endpoint（供云上查询转发出去）
aws route53resolver create-resolver-endpoint \
  --name outbound-hybrid \
  --direction OUTBOUND \
  --ip-addresses SubnetId=subnet-1111,SubnetId=subnet-2222

# 4. 为本地域建立转发规则并关联 VPC
aws route53resolver create-resolver-rule \
  --name forward-corp \
  --rule-type FORWARD \
  --domain-name corp.example.com \
  --resolver-endpoint-id rslvr-out-xxxx \
  --target-ips Ip=10.0.1.10,Port=53 Ip=10.0.1.11,Port=53

配置完成后，判断是否打通可以用两条命令验证：在 VPC 内的一台 EC2 上执行 dig app.corp.example.com，应返回本地地址；在本地一台机器上执行 dig app.aws.example.com @<Inbound Endpoint IP>，应返回 VPC 内地址。若前者超时，检查 Outbound Endpoint 到本地 DNS 的 53 端口连通性；若后者超时，检查本地转发器是否指向了正确的 Inbound Endpoint IP。

起步阶段建议只打通一个非关键域，验证双向解析、缓存行为和故障切换后再逐步扩展，避免一次性改动全部名字空间导致排障困难。

整体来看，混合云 DNS 的工程框架并不复杂，难点在于名字空间的边界划分与解析路径的闭环验证。把“谁权威、往哪转、怎么验”这三件事定义清楚，后续的跨域解析、故障切换与可观测性才有稳定的基础。