DNSが世界中に伝播しない

serverfault.comのDNSエントリに関連するものは何も変更していませんが、一部のユーザーはserverfault.com DNSが解決できないと今日報告していました。

私はジャストクエリを実行しましたが、これを確認することができます。serverfault.comの dnsは、特定の理由がない限り、いくつかの国では解決に失敗しているようです。（同様の方法で世界的なpingを行うWhat's My DNSでも確認されているため、2つの異なるソースによって問題として確認されています。）

• serverfault.comのDNSに触れていない場合、なぜこれが起こるのでしょうか？

• レジストラは（gag）GoDaddyであり、ほとんどの場合、デフォルトのDNS設定を問題なく使用しています。私は何か間違っていますか？DNSの神々は私を見捨てましたか？

• これを修正するためにできることはありますか？DNSをグースする方法、またはDNSを強制的に世界中に正しく伝播させる方法はありますか？

更新：月曜日の午前3時30分（PST）に、すべてが正しいように見えます。JustPingレポートサイトはすべての場所から到達可能です。非常に多くの有益な応答をありがとう、私は多くのことを学びました、そして、これが次に起こるとき、このQを参照します。

これは直接DNSの問題ではなく、インターネットの一部とserverfault.comのDNSサーバーとの間のネットワークルーティングの問題です。ネームサーバーに到達できないため、ドメインは解決を停止します。

私が知る限り、ルーティングの問題はIPアドレスを持つ（Global Crossing？）ルーターにあります204.245.39.50。

示すことによって@radius（で使用されるns52に、パケットstackoverflow.com）ここからに渡し208.109.115.121、正しくが仕事から。ただし、ns22へのパケットは代わりにに送られ208.109.115.201ます。

それらの2つのアドレスが両方とも同じで/24あり、対応するBGP発表も/24これが起こるべきでないので。

ネットワークを介してtracerouteを実行しましたが、最終的にはGlobal Crossingの代わりにMFN Above.netを使用してGoDaddyにアクセス/24します。レベル以下のルーティングトリックの兆候はありません。

このようなものを見たのは、Cisco Express Forwarding（CEF）が壊れていたときだけです。これは、パケットルーティングを高速化するために使用されるハードウェアレベルのキャッシュです。残念ながら、たまに実際のルーティングテーブルと同期しなくなり、間違ったインターフェイスを介してパケットを転送しようとします。CEFエントリは/32、基礎となるルーティングテーブルエントリが/24。この種の問題を見つけるのは難しいですが、一度特定すれば、通常は簡単に修正できます。

私はGCにメールを送って、彼らと話をしようとしましたが、彼らは非顧客向けのチケットを作成しません。あなたが GCの顧客である場合、これを試して報告してください...

10:38 UTCの更新 Jeffが指摘したように、問題は解決されました。上記の両方のサーバーへのトレースルートは、208.109.115.121次のホップを経由します。

serverfault.comのdnsサーバー[ns21.domaincontrol.com、ns22.domaincontrol.com。]は到達不能です。最後の〜20hの間、少なくともスウェーデンのカップルの主要なisps [ telia、tele2、bredband2 ]から。

同時に、stackoverflow.comおよびsuperuser.com [ns51.domaincontrol.com、ns52.domaincontrol.com]の「隣接」DNSサーバーに到達できます。

ns52.domaincontrol.comへのサンプルtraceroute：

 1. xxxxxxxxxxx
 2. 83.233.28.193           
 3. 83.233.79.81            
 4. 213.200.72.5            
 5. 64.208.110.129          
 6. 204.245.39.50           
 7. 208.109.115.121         
 8. 208.109.115.162         
 9. 208.109.113.62          
10. 208.109.255.26          

ns21.domaincontrol.comへ

 1. xxxxxxxxxxxx
 2. 83.233.28.193      
 3. 83.233.79.81       
 4. 213.200.72.5       
 5. 64.208.110.129     
 6. 204.245.39.50      
 7. 208.109.115.201    
 8. ???

多分フィルタリングを台無しにして/誰かがいくつかの不要なddos保護をトリガーし、インターネットのいくつかの部分をブラックリストに載せました。おそらくあなたはあなたのDNSサービスプロバイダーに連絡する必要があります-パパに行きます。

問題が[部分的に]解決されたかどうかを確認できます：

1. godaddyが反応してネームサーバーを変更したかどうかを確認します。たとえば、recortタイプを使用して、http：//www.squish.net/dnscheck/でserverfault.comを検索します。
2. 提供ネームサーバがpingに応答[ネームサーバが正常に動作し、まだICMPをブロックすることができるので、非常に科学的ではないが、この場合には、ICMPが他のサーバーに許可されているようです]経由テリアからかどうかを確認ガラスを探して。

編集：職場からのtraceroutes

ポーランド

 1. xxxxxxxxxxxxxxx
 2. 153.19.40.254               
 3. ???
 4. 153.19.254.236              
 5. 212.191.224.205             
 6. 213.248.83.129              
 7. 80.91.254.171               
 8. 80.91.249.105               
    80.91.251.230
    80.91.254.93
    80.91.251.52
 9. 213.248.89.182              
10. 204.245.39.50               
11. 208.109.115.121             
12. 208.109.115.162             
13. 208.109.113.62              
14. 208.109.255.26              

ドイツ

 1. xxxxxxxxxxxx
 2. 89.149.218.181       
 3. 89.149.218.2         
 4. 134.222.105.249      
 5. 134.222.231.205      
 6. 134.222.227.146      
 7. 80.81.194.26         
 8. 64.125.24.6          
 9. 64.125.31.249        
10. 64.125.27.165        
11. 64.125.26.178        
12. 64.125.26.242        
13. 209.249.175.170      
14. 208.109.113.58       
15. 208.109.255.26       

編集：実際にすべてが正常に動作します。

私の提案：Alnitakが説明したように、問題はDNSではなくルーティング（おそらくBGP）です。問題はDNSになかったため、DNSセットアップで何も変更されなかったという事実は正常です。

serverfault.comのDNS設定は今日非常に貧弱で、次のような重要なサイトには不十分です。

• 2つのネームサーバーのみ
• 同じバスケット内のすべての卵（両方とも同じAS内にあります）

結果を見たところです：一部のユーザー（国ではなく、オペレーターによって異なります）に対してserverfault.comが消えるには、ルーティングの不具合（インターネット上で非常に一般的なもの）で十分です。

他のASにあるネームサーバーを追加することをお勧めします。これにより、障害回復力が得られます。それらを民間企業にレンタルするか、serverfaultユーザーにセカンダリDNSホスティングの提供を依頼することができます（ユーザーの担当者が1000人を超えている場合のみ:-)

NS21.DOMAINCONTROL.COMとNS22.DOMAINCONTROL.COMもフランスのISP Free.frから到達できないことを確認します。
pQd tracerouteと同様に、私もns21とns22の両方で208.109.115.201の後に終了します。

traceroute to NS22.DOMAINCONTROL.COM (208.109.255.11), 64 hops max, 40 byte packets
 1  x.x.x.x (x.x.x.x)  2.526 ms  0.799 ms  0.798 ms
 2  78.224.126.254 (78.224.126.254)  6.313 ms  6.063 ms  6.589 ms
 3  213.228.5.254 (213.228.5.254)  6.099 ms  6.776 ms *
 4  212.27.50.170 (212.27.50.170)  6.943 ms  6.866 ms  6.842 ms
 5  212.27.50.190 (212.27.50.190)  8.308 ms  6.641 ms  6.866 ms
 6  212.27.38.226 (212.27.38.226)  68.660 ms  185.527 ms  14.123 ms
 7  204.245.39.50 (204.245.39.50)  48.544 ms  19.391 ms  19.753 ms
 8  208.109.115.201 (208.109.115.201)  19.315 ms  19.668 ms  34.110 ms
 9  * * *
10  * * *
11  * * *
12  * * *

ただし、ns52.domaincontrol.com（208.109.255.26）は機能し、ns22.domaincontrol.com（208.109.255.11）と同じサブネット内にあります

traceroute to ns52.domaincontrol.com (208.109.255.26), 64 hops max, 40 byte packets
 1  x.x.x.x (x.x.x.x)  1.229 ms  0.816 ms  0.808 ms
 2  78.224.126.254 (78.224.126.254)  12.127 ms  5.623 ms  6.068 ms
 3  * * *
 4  212.27.50.170 (212.27.50.170)  13.824 ms  6.683 ms  6.828 ms
 5  212.27.50.190 (212.27.50.190)  6.962 ms *  7.085 ms
 6  212.27.38.226 (212.27.38.226)  35.379 ms  7.105 ms  7.830 ms
 7  204.245.39.50 (204.245.39.50)  19.896 ms  19.426 ms  19.355 ms
 8  208.109.115.121 (208.109.115.121)  37.931 ms  19.665 ms  19.814 ms
 9  208.109.115.162 (208.109.115.162)  19.663 ms  19.395 ms  29.670 ms
10  208.109.113.62 (208.109.113.62)  19.398 ms  19.220 ms  19.158 ms
11  * * *
12  * * *
13  * * *

ご覧のとおり、今回は204.245.39.50の後、208.109.115.201ではなく208.109.115.121に移動します。また、pQdには同じtracerouteがあります。職場では、この204.245.39.50ルーター（グローバルクロッシング）を通過しませんでした。

作業場所と非作業場所からのtracerouteを増やすと役立ちますが、グローバルクロッシングには208.109.255.11/32および216.69.185.11/32の208.109.255.10、208.109.255.12、216.69.185.10、216.69のような偽のルーティングエントリがある可能性が高いです。 185.12はうまく機能しています。

ルーティングエントリが詰まっている理由を知るのは困難です。おそらく208.109.115.201（Go Daddy）は、208.109.255.11 / 32および216.69.185.11/32の非稼働ルートをアドバタイズしています。

編集：telnet route-server.eu.gblx.netを使用して、Global Crossingルートサーバーに接続し、Global Crossingネットワーク内からtracerouteを実行できます。

編集：数日前に同じ問題が他のNSで既に発生したようです。http：//www.newtondynamics.com/forum/viewtopic.php？ f = 9＆t = 5277＆start = 0を参照してください

便利なのは、障害が発生している場所から詳細な解決トレースを表示することです...障害が発生している解決パスのレイヤーを確認します。私はあなたが使用しているサービスに精通していませんが、おそらくどこかのオプションです。

それに失敗すると、ルートまたはTLDでの障害がより多くのドメインに影響を与えるため、問題がツリーの「下に」ある可能性が最も高くなります（希望）。レジリエンスを向上させるために、ドメイン制御のネットワークに問題がある場合、2番目のDNSサービスに委任して、解像度の冗長性を向上させることができます。

独自のDNSをホストしていないことに驚いています。そのようにすることの利点は、DNSに到達できる場合、そして（できれば）サイトにも到達できることです。

少なくともUPCから、権限のあるサーバー（ns21.domaincontrol.com）からAレコードを取得しようとすると、この反応を受け取ります。

; <<>> DiG 9.5.1-P2 <<>> @ns21.domaincontrol.com serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 38663
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.       IN  A

;; Query time: 23 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:09:40 2009
;; MSG SIZE  rcvd: 33

別のネットワーク（OVH）上のマシンから同じことを試みると、答えが返されます

; <<>> DiG 9.4.2-P2 <<>> @216.69.185.11 serverfault.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33998
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

;; QUESTION SECTION:
;serverfault.com.               IN      A

;; ANSWER SECTION:
serverfault.com.        3600    IN      A       69.59.196.212

;; AUTHORITY SECTION:
serverfault.com.        3600    IN      NS      ns21.domaincontrol.com.
serverfault.com.        3600    IN      NS      ns22.domaincontrol.com.

;; Query time: 83 msec
;; SERVER: 216.69.185.11#53(216.69.185.11)
;; WHEN: Sun Jul 19 12:11:05 2009
;; MSG SIZE  rcvd: 101

他のいくつかのドメインでも同様の動作が発生するため、UPCは（少なくとも）DNSクエリを独自のキャッシングネームサーバーにサイレントにリダイレクトし、応答を偽装していると想定しています。DNSが短時間誤動作した場合、UPCのネームサーバーがNXDOMAIN応答をキャッシュしている可能性があるため、これが原因である可能性があります。