昨日、ドメイン bagtheweb.com の DNS ホスティングを Godaddy から CloudFlare に切り替えました。Cloudflare によると、転送は成功し、DNS 解決は私のオフィス以外ではどこでもうまく機能しています。うまくいくときもあれば、SERVFAIL 応答が返されるときもありますdig bagtheweb.com。
私のオフィスのコンピューターは DNS に AT&T ゲートウェイを使用しています。ゲートウェイのコントロール パネルを見ると、DNS に 68.94.156.9 と 68.94.157.9 が使用されていると表示されています。
私は、次の両方の 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 時間を無駄にする以外に)?
いいえ。プロバイダーにレコードを設定することであなたの役割は完了しており、プロバイダーは要求されたゾーン転送を実行しました。
この問題を解決するために、ゾーン転送の前に何かできることはありますか?
あなたかもしれませんかもしれない5 分のような非常に低い TTL を設定することはできますが、実際に効果が出る前に、その TTL を DNS インフラストラクチャ全体に複製する必要があります。
AT&Tは最悪だ
もっと具体的に言うと、ほとんどの ISP がホストする DNS は、一般的にひどいものです。速度を重視して構築されているのではなく、他のネットワークを介した不要なデータ転送 (通常はコストがかかります) をなくすために構築されています。つまり、非常に大規模で重いキャッシュです。また、ISP にとっては、独自の DNS をホストして、これらの値を DHCP 経由で顧客に提供する方が簡単です。当然のことです。
他のユーザーも同じ問題を経験しているのではないかと思います
これはおそらく AT&T の DNS インフラストラクチャに特有のものであり、DNS サーバーの更新が完了すれば、おそらく問題はなくなると思います。
GoogleのDNSを使えば自分で問題を解決できることは分かっていますが、
おそらくすでにこれを行う必要があります。ちなみに、IBM の新しい DNS サービスは通常非常に高速です。9.9.9.9