私は変わっていない何でもserverfault.com の DNS エントリに関連するしかし、一部のユーザーは今日、serverfault.com DNSが解決に失敗する。
私はジャストピングクエリそして、私はこれをある程度確認することができます。serverfault.com の DNS は、私が理解できる特別な理由もなく、いくつかの国で解決に失敗することのようです。（また、私のDNSは何ですかこれは同様の方法で世界規模で ping を実行するため、2 つの異なるソースによって問題として確認されています。
serverfault.com の DNS に触れていないのに、なぜこのようなことが起こるのでしょうか?
私たちのレジストラは（ゲッ）GoDaddy で、ほとんどの場合、デフォルトの DNS 設定を問題なく使用しています。私が何か間違っているのでしょうか？ DNS の神様は私を見捨てたのでしょうか？
これを修正するために何かできることはありますか? DNS を刺激したり、DNS が世界中に正しく伝播するように強制する方法はありますか?
更新: 月曜日午前 3:30 (太平洋標準時) の時点で、すべてが正しくなっているようです。JustPing は、サイトはどこからでもアクセスできると報告しています。非常に有益な回答を多数いただき、ありがとうございました。多くのことを学びました。次回このようなことが起こったときには、この質問を参考にします。
答え1
これは直接 DNS の問題ではなく、インターネットの一部と serverfault.com の DNS サーバー間のネットワーク ルーティングの問題です。ネームサーバーにアクセスできないため、ドメインの解決が停止します。
私の知る限り、ルーティングの問題は、IP アドレス の (Global Crossing?) ルーターにあります204.245.39.50。
として表示による@半径、パケットをns52（出典:) はここから へ、208.109.115.121そしてそこから へ正常に渡されます。ただし、ns22 へのパケットは ではなく へ行きます208.109.115.201。
これら2つのアドレスは両方とも同じであり/24、対応するBGPアナウンスも/24これに対するものであるため、起こるべきではない。
私は自分のネットワーク経由でトレースルートを実行しましたが、最終的には Global Crossing ではなく MFN Above.net を使用して GoDaddy に到達しましたが、その/24レベルより下のレベルでルーティングのトリックが行われた形跡はありません。両方のネーム サーバーはここから同一のトレースルートを持っています。
私がこのようなものを見たのは、壊れていたときだけですシスコエクスプレスフォワーディング(CEF)。これは、パケット ルーティングを高速化するために使用されるハードウェア レベルのキャッシュです。残念ながら、たまに実際のルーティング テーブルとの同期が取れなくなり、間違ったインターフェイス経由でパケットを転送しようとすることがあります。/32基礎となるルーティング テーブル エントリが の場合でも、CEF エントリは レベルまで下がることがあります/24。このような問題を見つけるのは難しいですが、いったん特定されれば、通常は簡単に修正できます。
GCにメールを送り、彼らと話をしようとしましたが、彼らは顧客以外の人のためにチケットを作成しませんでした。はGC の顧客の方は、ぜひこれを報告してください...
10:38 UTC に更新 Jeff が指摘したように、問題は解決しました。上記の両方のサーバーへのトレースルートは、現在、208.109.115.121次のホップを経由します。
答え2
serverfault.com の DNS サーバー [ ns21.domaincontrol.com、ns22.domaincontrol.com。 ] は、少なくともスウェーデンのいくつかの大手 ISP から、過去 20 時間ほどアクセス不能です [テリア、テレ2、ブレッドバンド2]。
同時に、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 サービス プロバイダーに問い合わせたほうがよいでしょう。
問題が[部分的に]解決されたかどうかを確認するには、次の操作を実行します。
- godaddyが反応してネームサーバーを変更したかどうかを確認する - 例えば、serverfault.comを検索するhttp://www.squish.net/dnscheck/レコードタイプを使用: ANY
- 指定されたネームサーバーがpingに応答するかどうかを確認します[ネームサーバーが正常に動作してもICMPをブロックできるため、あまり科学的ではありませんが、この場合はICMPが他のサーバーに許可されているようです] telia経由鏡。
編集: 職場からのトレースルート
ポーランド
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
編集: 今では確かにすべて正常に動作しています。
答え3
私の提案: Alnitak が説明したように、問題は DNS ではなくルーティング (おそらく BGP) です。DNS 設定で何も変更されていないのは、問題が DNS になかったため、正常です。
serverfault.com の DNS 設定は現在非常に貧弱で、次のような重要なサイトには明らかに不十分です。
- ネームサーバーは2つだけ
- すべての卵を同じバスケットに入れる（両方とも同じ AS 内）
その結果は、次のとおりです。ルーティングの不具合 (インターネットではよくあることです) により、一部のユーザー (国ではなく、オペレーターによって異なります) で serverfault.com が消えてしまうことがあります。
他の AS にあるネーム サーバーをさらに追加することをお勧めします。これにより、障害耐性が高まります。ネーム サーバーを民間企業に貸し出すか、serverfault ユーザーにセカンダリ DNS ホスティングを提供するよう依頼することができます (ユーザーのレピュテーションが 1000 を超える場合のみ)。
答え4
失敗している場所からの詳細な解決トレースを表示して、解決パスのどのレイヤーで失敗しているかを確認すると便利です。使用しているサービスについてはよくわかりませんが、どこかにオプションがあるかもしれません。
それができない場合、ルートまたは TLD の障害はより多くのドメインに影響するため (そう願うでしょう)、ツリーの「下の方」に問題がある可能性が最も高くなります。回復力を高めるには、domaincontrol のネットワークに問題がある場合、解決の冗長性を高めるために 2 番目の DNS サービスに委任することができます。