📚 课程目录第2章 Route 53托管区域与记录管理

2. Route 53托管区域与记录管理

托管区域（Hosted Zone）是Route 53中承载DNS记录的容器，也是域名解析治理的基本单元。理解托管区域的类型差异、记录类型的语义、TTL与别名机制，是构建企业级DNS体系的第一步。本节围绕公有与私有托管区域的创建、记录类型与TTL策略、别名记录与CNAME的差异，以及批量导入与版本化变更四条主线展开。

一、公有托管区域与私有托管区域

公有托管区域面向互联网，其记录可被全球递归解析器查询。创建时需指定域名，例如 corp.example.com。创建完成后，Route 53 会分配一组 NS 记录（形如 ns-123.awsdns-45.com 等四条），必须将这组 NS 记录配置到父域注册商处，委派才生效。同时会生成 SOA 记录，其中包含序列号、刷新间隔、重试间隔、过期时间与最小TTL等参数。

私有托管区域仅对关联的VPC可见，用于内部服务发现。创建时需指定域名并至少关联一个VPC。私有区域同样有NS与SOA记录，但NS不对外委派。关键差异在于：私有区域的解析请求只来自关联VPC内的实例，且可以启用 enableDnsHostnames 与 enableDnsSupport 两个VPC属性，否则实例无法解析私有区域名称。

一个常见的企业实践是“同名公有+私有”双区域：corp.example.com 同时存在公有与私有托管区域。内部实例查询时优先命中私有区域，外部用户查询时命中公有区域。这种拆分让内外网解析路径彼此隔离，避免内部地址泄露。

二、记录类型与TTL策略

Route 53 支持的标准记录类型包括 A、AAAA、CNAME、MX、TXT、NS、SOA、SRV、PTR、CAA 等。A 记录将域名映射到 IPv4 地址，AAAA 对应 IPv6。CNAME 将域名指向另一个域名，常用于将 www 指向负载均衡器域名。MX 用于邮件路由，TXT 用于域名验证与 SPF/DKIM 策略，CAA 用于限制可签发证书的 CA。

TTL（Time To Live）决定递归解析器缓存该记录的时间。TTL 越短，变更传播越快，但查询量越大、成本越高；TTL 越长，缓存命中率高、查询成本低，但变更生效慢。企业常见策略是：稳定记录（如 MX、NS）使用 3600 秒或更长；需要快速切换的记录（如灰度发布、故障转移）使用 60 秒甚至 30 秒。变更前可先将 TTL 调低，等待旧 TTL 过期后再执行变更，变更完成并稳定后再调回较高值，这是“TTL 预热”的标准做法。

需要注意，TTL 是建议值，部分递归解析器可能不严格遵守。因此不能把 TTL 当作精确的切换时间保证，而应视为“最长缓存窗口”的近似控制。

三、别名记录与CNAME的差异

别名记录（Alias Record）是 Route 53 特有的扩展记录类型，外观上像 A/AAAA 记录，但目标指向 AWS 资源（如 ALB、CloudFront、S3 网站端点、另一个 Route 53 记录）。它与 CNAME 的核心差异如下：

适用根域：CNAME 不能用于区域顶点（如 example.com），而 Alias 可以，这是根域指向负载均衡器的唯一标准做法。
计费：对 AWS 资源的 Alias 查询不计费；CNAME 查询按标准查询计费。
健康检查：Alias 可绑定 Route 53 健康检查，实现故障转移；CNAME 不能直接绑定。
目标类型：Alias 目标必须是 AWS 资源或同区域记录；CNAME 可指向任意域名。
解析行为：Alias 在解析时直接返回目标资源的 IP，不产生额外 CNAME 链；CNAME 会产生一次额外解析跳转。

因此，面向 AWS 资源的场景应优先使用 Alias；只有指向外部域名（如第三方 SaaS）时才使用 CNAME。

四、批量导入与版本化变更

当记录数量达到数十上百条时，逐条控制台操作效率低下。Route 53 支持通过 BIND 格式的区域文件批量导入，也支持通过 ChangeResourceRecordSets API 批量提交变更。批量变更以“变更批次”为单位，每个批次包含一组 CREATE、DELETE、UPSERT 操作，Route 53 保证批次内操作的原子性。

版本化变更的核心思路是：将区域文件纳入 Git 管理，每次变更通过 PR 审核，合并后由 CI 调用 API 提交。这样每次变更都有记录、可回滚、可审计。下面是一个批量变更请求的示例结构：

{
  "ChangeBatch": {
    "Comment": "release-2024-06-01 add api record",
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "api.corp.example.com",
          "Type": "A",
          "TTL": 60,
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "dualstack.internal-alb-123456.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      },
      {
        "Action": "DELETE",
        "ResourceRecordSet": {
          "Name": "old.corp.example.com",
          "Type": "CNAME",
          "TTL": 300,
          "ResourceRecords": [{"Value": "legacy.example.com"}]
        }
      }
    ]
  }
}

提交后可通过 GetChange 查询变更状态，返回 INSYNC 表示已传播到所有 Route 53 权威服务器。注意：INSYNC 只代表 Route 53 侧完成，不代表全球递归解析器已刷新缓存，后者仍受 TTL 约束。

批量变更中，DELETE 操作必须精确匹配现有记录的 Name、Type、TTL 和 Value，否则会报 InvalidChangeBatch。建议先用 ListResourceRecordSets 导出当前状态再构造删除请求。

私有托管区域不支持通过 BIND 文件导入，批量操作需通过 API 或 CLI 完成。公有区域导入时，若文件中包含与现有记录冲突的条目，导入会失败并回滚整个批次。

综合来看，托管区域管理的关键在于：明确公有/私有边界，按记录用途选择合适类型与 TTL，优先使用 Alias 对接 AWS 资源，并通过版本化批量变更实现可审计、可回滚的治理流程。这四点构成了后续流量策略与故障转移能力的底座。