Google Cloud DNS 配置后域名无法通过公共DNS解析的故障求助

核心异常特征提取 #

通过两组dig测试结果的对比，可以定位两个关键矛盾点：

• 直接指定权威DNS服务器ns-cloud-d1.googledomains.com查询fake.fqdn.com的A记录时，可正常返回绑定的公网IP，状态为NOERROR，证明该权威服务器上的A记录配置本身无语法、权限类问题
• 通过公共递归DNS 8.8.8.8查询同一域名时，返回NXDOMAIN（域名不存在）状态，且返回的SOA记录关联域名为yourenotadog.com，对应权威服务器为ns-cloud-b1.googledomains.com，与你测试正常的权威服务器不属于同一DNS托管Zone

问题根因为：域名在顶级域（.com）层级的NS委派指向了错误的权威DNS区域
递归DNS的解析逻辑为逐层追溯：根DNS → .com顶级域 → 目标域名的权威NS。当前8.8.8.8发起查询时，.com顶级域返回的委派信息指向yourenotadog.com对应的DNS区域权威服务器，而非你存储了fake.fqdn.com A记录的DNS区域。递归DNS在错误的权威区域中未找到对应域名记录，因此直接返回域名不存在，与DNS传播延迟无关，即便等待超过72小时也无法自动恢复。

分步修正流程 #

1. 校验顶级域层级的实际NS委派记录
   执行命令dig NS fqdn.com，对比返回的NS列表，与你存储了fake.fqdn.com A记录的DNS Zone对应的官方NS列表是否完全一致：
   • 匹配错误的常见场景：创建Cloud DNS Zone时误将Zone根域设置为yourenotadog.com，但实际需要解析的域名为fqdn.com；域名管理后台手动配置NS时，错填了其他Zone分配的NS服务器地址
2. 修正NS委派配置
   登录域名管理后台，进入fqdn.com的设置页，将NS记录修正为与存储A记录的DNS Zone绑定的4台Google Domains权威NS地址，移除关联yourenotadog.com的错误NS条目
3. 验证配置生效
   修正后每隔15分钟重复执行dig @8.8.8.8 NS fqdn.com，直到返回的NS列表与后台配置完全匹配
   待NS委派传播完成后，再执行dig @8.8.8.8 A fake.fqdn.com，确认可正常返回对应的公网IP。通常NS记录的顶级域TTL为48小时，最长等待周期远低于你之前等待的72小时
4. 附加校验
   确认存储A记录的DNS Zone根域设置为fqdn.com，确保子域名fake.fqdn.com处于该Zone的解析覆盖范围内

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