使用Cloud DNS配置域名后，服务器DNS无法解析的排查求助

执行dig -t NS dandyrobot.com.返回SERVFAIL状态且无NS记录返回，可通过以下步骤缩小问题范围：

• 绕开本地DNS直接查询根服务器
  跳过系统本地DNS缓存（127.0.0.53），直接从根域名服务器查询，确认顶级域的权威服务器是否已同步你的NS配置：

  dig @a.root-servers.net -t NS dandyrobot.com.
  

  • 若无结果：说明域名的NS记录在注册商侧未更新或未生效
  • 若有结果：说明本地DNS缓存或递归DNS服务器存在同步问题

• 核对域名注册商的NS配置
  登录域名注册商后台，确认已正确替换为GCP提供的完整名称服务器地址（通常是类似ns-cloud-a1.googledomains.com这类格式），避免输入错误或未保存配置。

• 验证GCP DNS区域配置
  登录GCP控制台进入Cloud DNS区域，检查：

  • 区域类型为公共区域（而非私有区域）
  • GCP自动生成的NS记录未被手动修改
  • 已添加指向服务器IP的A/AAAA记录（若需要解析到服务器）
    也可通过GCP命令行工具确认记录：

  gcloud dns record-sets list --zone=你的区域名称
  

• 直接查询GCP权威DNS
  用GCP提供的NS服务器直接查询，确认权威端配置是否正确：

  dig @ns-cloud-a1.googledomains.com -t A dandyrobot.com.
  

  （将ns-cloud-a1.googledomains.com替换为你的GCP区域实际NS地址）

  • 若能返回正确记录：说明权威配置正常，问题出在全球DNS同步（通常需1-24小时）
  • 若返回错误：说明GCP侧DNS配置存在问题

• 排查本地DNS缓存与公共DNS测试

  • 清除Ubuntu本地DNS缓存：

    sudo systemd-resolve --flush-caches
    

  • 切换公共DNS服务器测试，比如谷歌DNS或Cloudflare DNS：

    dig @8.8.8.8 -t NS dandyrobot.com.
    dig @1.1.1.1 -t NS dandyrobot.com.
    

  若公共DNS能返回结果，说明本地DNS服务器存在异常。

• 检查DNSSEC配置（若已开启）
  若在GCP或注册商侧开启了DNSSEC，确认签名配置正确，错误的DNSSEC签名会导致递归服务器验证失败，返回SERVFAIL。

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