AWS Route 53子域DNS委托至EC2自定义DNS服务器故障排查

让我来帮你梳理一下这个问题——我之前也处理过类似的子域委托场景，咱们一步步来搞定它。

首先要明确：SOA记录不需要在Route53的example.com托管区里配置，而是要在你那台运行在X.X.X.X上的自定义DNS服务器上配置。因为你已经把sub.example.com委托给了ns.sub.example.com，所以所有属于sub.example.com域的权威DNS记录（包括SOA）都得由这台自定义服务器来提供。

具体配置要点（以常见的BIND服务为例）：

• SOA的主名称服务器（MNAME）必须填ns.sub.example.com，也就是你在Route53里指定的NS记录值
• 管理员邮箱（RNAME）要把@换成点，比如原本的admin@example.com要写成admin.example.com
• 其余参数可以用通用默认值，也可以根据需求调整：
  • 序列号：建议用时间戳格式（比如2024052001），后续更新记录时递增即可
  • 刷新时间：86400（24小时）
  • 重试时间：7200（2小时）
  • 过期时间：3600000（约42天）
  • 最小TTL：3600（1小时）

对应的BIND配置片段大概是这样：

sub.example.com.   IN   SOA   ns.sub.example.com. admin.example.com. (
                              2024052001   ; 序列号，每次更新要+1
                              86400        ; 从服务器刷新间隔
                              7200         ; 刷新失败后的重试间隔
                              3600000      ; 从服务器过期时间
                              3600 )       ; 记录最小TTL

你已经配置了Route53的NS和A记录，但查询出错，大概率是以下几个环节出了问题：

1. 确认Route53的NS记录配置无遗漏 #

• 登录Route53控制台，找到example.com的托管区，检查sub.example.com的NS记录：
  • 必须只包含ns.sub.example.com（如果有多个自定义DNS节点，要全加上）
  • 暂时把TTL设为300（5分钟），避免缓存导致的生效延迟

2. 验证自定义DNS服务器的可达性与服务状态 #

• 先ping一下ns.sub.example.com，确认能解析到X.X.X.X
• 用dig @X.X.X.X sub.example.com SOA直接查询你的自定义DNS，看是否能返回正确的SOA记录。如果这一步失败，说明：
  • EC2的安全组/防火墙没开放UDP 53端口（DNS默认用UDP，大查询会用TCP）
  • 自定义DNS服务没正确创建sub.example.com的区域配置
  • 服务监听的是127.0.0.1而不是公网IP

3. 排查DNS缓存问题 #

• 本地机器可能缓存了旧记录，用nslookup sub.example.com 8.8.8.8（用谷歌公共DNS查询），或者dig sub.example.com @ns-xxx.awsdns-xx.com（直接查Route53的权威DNS），确认是否能获取到sub.example.com的NS记录
• 手动刷新本地缓存：Windows用ipconfig /flushdns，Linux用systemd-resolve --flush-caches

4. 确认NS记录的A记录有效性 #

• 检查Route53里ns.sub.example.com的A记录，必须指向正确的公网IP X.X.X.X（不能是内网IP）
• 用dig ns.sub.example.com验证该记录是否能被正常解析

等所有配置调整完成后，按以下步骤测试：

1. 执行dig sub.example.com NS，应该返回ns.sub.example.com
2. 执行dig @ns.sub.example.com sub.example.com SOA，应该返回你配置的SOA记录
3. 如果自定义DNS上还有其他记录（比如test.sub.example.com的A记录），执行dig test.sub.example.com应该能拿到正确结果

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