不同注册商父域名下Route 53子域名DNS解析失败问题

我来帮你一步步定位问题，跨服务商托管父域名+Route 53管理子域名的场景，最容易在DNS衔接环节出问题，咱们从核心点开始检查：

1. 先确认父域名的NS记录已经完全切换到Route 53 #

这是最关键也最容易忽略的一步！你在Route 53创建example.com托管区后，AWS会自动生成4条NS（域名服务器）记录。你必须登录你的域名注册商（domain.com）后台，找到example.com的DNS设置，把原来的NS服务器地址全部替换成Route 53托管区里的那4个NS地址。

• 验证方法：在命令行执行dig example.com NS，如果返回的NS地址和Route 53托管区里的一致，说明切换生效；如果不一致，说明注册商那边的NS记录没改对。
• 注意：DNS变更的全球生效时间通常是1-24小时，测试时可以用dig @[Route53的NS地址] example.com直接查询Route 53的记录，跳过本地缓存。

2. 检查Route 53中CNAME记录的配置细节 #

确保你的CNAME记录符合以下要求：

• 记录名称：只需要填api（因为托管区是example.com，系统会自动补全为api.example.com）
• 记录类型：选择CNAME
• 值：必须是API Gateway自定义域名对应的目标地址——如果是边缘优化的自定义域名，这个值是CloudFront分配的域名（比如d123456.cloudfront.net）；如果是区域型自定义域名，值是API Gateway的区域域名（比如abc123.execute-api.us-east-1.amazonaws.com）
• TTL：建议设为300秒（5分钟），方便测试时快速刷新缓存
• 路由策略：默认的「简单路由」就足够，不需要复杂配置

3. 验证API Gateway自定义域名的部署状态 #

CNAME指向的目标必须是已经正确配置并部署的API Gateway自定义域名：

• 登录AWS控制台，进入API Gateway → 自定义域名，确认api.example.com的状态是「已部署」
• 检查基础路径映射：确保已经将自定义域名的路径（比如/）关联到你的Lambda对应的API阶段（比如prod）
• 确认SSL证书：你在ACM申请的证书必须覆盖api.example.com，如果是边缘优化域名，证书必须部署在us-east-1区域，且已经通过域名验证

4. 用命令行工具直接验证解析结果 #

用以下命令排除本地缓存干扰，直接查询Route 53的记录：

• 执行dig @[Route53的其中一个NS地址] api.example.com，把[Route53的其中一个NS地址]替换成你托管区里的NS（比如ns-1234.awsdns-12.org）
• 如果返回结果里包含你设置的CNAME值，说明Route 53的记录没问题；如果返回空或者错误，说明记录配置有误

5. 排查Route 53托管区的权限设置 #

默认创建的托管区是允许公共DNS查询的，但如果你手动修改过权限策略，可能会导致解析失败：

• 进入Route 53托管区的「权限」标签，确认没有添加限制公共查询的策略
• 检查托管区的「关联账户」设置，确保没有错误的账户关联导致记录无法被查询

常见误区避坑 #

• 不要在Route 53托管区里手动添加额外的NS记录，自动生成的4条足够，多余的NS会导致解析混乱
• 注册商那边的NS记录必须全部替换，不能保留原来的NS只加Route 53的，否则会出现部分地区能解析、部分地区不能的情况
• 如果API Gateway自定义域名还没部署完成，即使CNAME配置正确，也会解析失败，一定要先确保自定义域名状态正常

内容的提问来源于stack exchange，提问作者danish