昨天，我将域名 bagtheweb.com 的 DNS 托管从 Godaddy 切换到 CloudFlare。Cloudflare 表示转移成功，除我的办公室外，DNS 解析在其他任何地方都运行良好。有时它可以正常工作，有时我使用 会收到 SERVFAIL 响应dig bagtheweb.com。
我的办公室计算机使用 AT&T 网关作为 DNS。我查看了网关控制面板，它显示使用 68.94.156.9 和 68.94.157.9 作为 DNS。
我尝试直接使用这两个 DNS 解析器进行挖掘：dig @68.94.156.9 bagtheweb.com和dig @68.94.157.9 bagtheweb.com。
大约一半的时间结果是好的（我看到指向 IP 地址的 A 记录），一半的时间我收到 SERVFAIL 响应。我尝试了很多次，但我总是看到两个响应似乎是随机的。自从我完成转移以来已经过去了大约 20 个小时，我仍然看到这种情况。
我尝试挖掘 CloudFlare 的 DNS 服务器 theo.ns.cloudflare.com. 和 vita.ns.cloudflare.com.，每次都运行良好。我还尝试挖掘 Google 的 DNS 服务器 8.8.8.8，也运行正常。
所以我唯一的结论是 AT&T 太差劲了，每个 DNS 服务器 IP 都由一组服务器支持，其中一些服务器更新正确，而另一些服务器则混乱不堪。我希望 24 小时将成为这些糟糕服务器更新的神奇阈值。
知道为什么会发生这种情况吗？我还能做些什么来调查或强制更新吗（除了打电话给 AT&T 并浪费我 4 个小时的时间）？在区域转移之前我可以做些什么来消除这个问题吗？我知道我可以使用 Google 的 DNS 自行修复此问题，但我想知道其他用户是否也遇到了同样的问题。
2个背靠背命令：
Marcels-iMac:~ marcel$ dig @68.94.157.9 bagtheweb.com
; <<>> DiG 9.9.7-P3 <<>> @68.94.157.9 bagtheweb.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58515
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bagtheweb.com. IN A
;; Query time: 131 msec
;; SERVER: 68.94.157.9#53(68.94.157.9)
;; WHEN: Fri Mar 02 12:01:07 CST 2018
;; MSG SIZE rcvd: 42
Marcels-iMac:~ marcel$ dig @68.94.157.9 bagtheweb.com
; <<>> DiG 9.9.7-P3 <<>> @68.94.157.9 bagtheweb.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31350
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;bagtheweb.com. IN A
;; ANSWER SECTION:
bagtheweb.com. 60 IN A 184.73.200.185
bagtheweb.com. 60 IN A 23.23.171.5
bagtheweb.com. 60 IN A 50.17.234.140
bagtheweb.com. 60 IN A 174.129.203.239
bagtheweb.com. 60 IN A 204.236.236.192
bagtheweb.com. 60 IN A 107.22.233.200
bagtheweb.com. 60 IN A 23.21.55.239
bagtheweb.com. 60 IN A 23.23.215.144
;; Query time: 54 msec
;; SERVER: 68.94.157.9#53(68.94.157.9)
;; WHEN: Fri Mar 02 12:01:09 CST 2018
;; MSG SIZE rcvd: 170
答案1
我还能做些什么来调查或强制更新吗（除了打电话给 AT&T 并浪费我 4 个小时的时间）？
不。您已完成自己的任务，与提供商设置了记录，并且提供商执行了请求的区域传输。
在区域传输之前我可以做些什么来消除这个问题？
可能是你可能已经能够设置一个非常低的 TTL，比如 5 分钟，但即使这样也必须在整个 DNS 基础设施中复制才能真正发挥作用。
AT&T 太烂了
更具体地说，大多数 ISP 托管的 DNS 通常都是垃圾。它们不是为了提高速度而构建的，而是为了帮助消除通过其他网络进行不必要的数据传输（这通常需要花钱）；这意味着非常大且繁重的缓存。他们还可以更轻松地托管自己的 DNS 并通过 DHCP 将这些值提供给他们的客户。这是意料之中的事。
我想知道其他用户是否也遇到了同样的问题
这可能是 AT&T DNS 基础设施特有的问题，我敢打赌，在他们的 DNS 服务器完成刷新后，一切就会正常。
我知道我可以使用 Google 的 DNS 自行解决这个问题，但是
您可能已经这样做了。顺便说一句，IBM 的新 DNS 服务通常非常快：9.9.9.9