冗長性と遅延を削減するためにDNSプライマリ/セカンダリ/…を設定する正しい方法？

冗長性を目的としたDNSプライマリ/セカンダリは簡単だと思いました。私の理解では、プライマリとセカンダリが少なくとも1つ必要であり、セカンダリは地理的に異なる場所に設定する必要がありますが、別のルーターの背後にも設定する必要があります（たとえば、https：//serverfault.com/questions/48087を参照）。 / why-are-there-several-nameservers-for-my-domain）

現在、メインデータセンターには2つのネームサーバーがあります。最近、さまざまな理由でいくつかの機能停止が発生し、両方のネームサーバーが使用できなくなったため、DNSを数時間使用しなかったため、私たちとお客様の両方が離れました。私のシステム管理者チームに、別のデータセンターでのDNSサーバーのセットアップを完了し、セカンダリネームサーバーとして構成するように依頼しました。

ただし、私たちのシステム管理者は、他のデータセンターが少なくともプライマリデータセンターほど信頼できない場合、これはあまり役に立たないと主張しています。彼らは、プライマリデータセンターがダウンしても、ほとんどのクライアントは適切に検索できないか、タイムアウトが長すぎると主張しています。

個人的には、この種の問題を抱えているのは私たちだけではなく、すでに解決済みの問題である可能性が高いと私は確信しています。これらのインターネット会社すべてが私たちの種類の問題の影響を受けているとは想像できません。しかし、失敗した場合に何が起こるか（たとえば、クライアントのタイムアウト）とそれらを回避する方法を説明する適切なオンラインドキュメントが見つかりません。

私たちのシステム管理者の推論に穴をあけるためにどのような議論を使うことができますか？彼らが存在すると主張する問題をよりよく理解するために私が相談できるオンラインリソースはありますか？

返信を読んだ後のいくつかの追加メモ：

• 私たちはLinux上にいます
• さらに複雑なDNSニーズがあります。私たちのDNSエントリは、いくつかのカスタムソフトウェアによって管理されており、BINDは現在Twisted DNSの実装に依存しており、いくつかのビューも混在しています。ただし、別のデータセンターに独自のDNSサーバーを設定することは完全に可能です。
• ローカルクライアントの再帰的なDNSサーバーではなく、部外者がサーバーを見つけるための信頼できるDNSについて話しています。

非常に技術的ではありますが、システム管理者との闘いに役立つと思われる非常に優れた「ベストプラクティス」ドキュメントがあります。 http://www.cisco.com/web/about/security/intelligence/dns-bcp.html

彼/彼女がシスコによって書かれた記事の正当性を認識していない場合は、システム管理者との議論をやめることもできます-管理のレベルを上げる。

他の多くの「ベストプラクティス」ドキュメントでは、プライマリネームサーバーとセカンダリネームサーバーをIPブロックだけでなく、物理的な場所で分離することを推奨しています。実際、RFC 2182では、セカンダリDNSサービスを地理的に分離することを推奨しています。多くの企業にとって、これは別のデータセンターでサーバーをレンタルするか、ZoneEditやUltraDNSなどのホステッドDNSプロバイダーに加入することを意味します。

ただし、私たちのシステム管理者は、他のデータセンターが少なくとも プライマリデータセンターほど信頼できない場合、これはあまり役に立たないと主張しています。彼らは、プライマリデータセンターがダウンしても、ほとんどのクライアントは適切に検索できないか、タイムアウトが長すぎると主張しています。

ああ、焦点は信頼できる。セカンダリDNSを設定するのではなく、外部へのリンクを妨害しているようです。すべて同じように、セカンダリDNSを設定し、そこから続行します。それは負荷を助け、ピンチで物事を支えます...しかし、彼らが他の場所が信頼できないと思う理由について彼らに尋ねてください。

個人的には、この種の問題を抱えているのは私たちだけではなく、すでに解決済みの問題である可能性が高いと私は確信しています。これらのインターネット会社すべてが私たちの種類の問題の影響を受けているとは想像できません。

あなたは唯一の会社ではありません。これはおそらく世界中の会社で100万回リハッシュされています。

しかし、失敗した場合に何が起こるか（たとえば、クライアントのタイムアウト）とそれらを回避する方法を説明する適切なオンラインドキュメントが見つかりません。

私たちのシステム管理者の推論に穴をあけるためにどのような議論を使うことができますか？彼らが存在すると主張する問題をよりよく理解するために私が相談できるオンラインリソースはありますか？

• ローカルクライアントの再帰的なDNSサーバーではなく、部外者がサーバーを見つけるための信頼できるDNSについて話しています。

ゾーンの権限として登録されている外部DNSサービスの設定を含め、あらゆる種類のことを実行できますが、（外部の）権限のあるサーバーを自分の（内部の）DNSサーバーのセカンダリにします。 この構成は恐ろしく、間違っており、私が本当に悪質なシステム管理者であり、私が推奨するたびに子猫が死ぬことを示しています。 しかし、次の2つのことを行います。

• DNSサービスを利用して負荷の大きな部分を処理し、独自の（内部）DNSの容量に関する質問を無効にします。
• 社内DNSサーバーがダウンしている間もDNSサービスが稼働し続けるため、リンクの信頼性は問題ではありません。重要なのは、DNSサービスプロバイダーの信頼性です。

これが間違っている理由：

• 「ステルスネームサーバー」と呼ばれるものをセットアップします。ゾーンレコードに表示され、サーバーの名前をIPに照会することはできますが、外部からアクセスされることはありません。クライアントのクエリが到達することはありません。
• DNSは引き続き正常に動作しますが（ホストされたサービスが問題に対処するため）、インターネット接続がダウンした場合に使用できるWebサイトがあるということではありません。つまり、問題の半分しか解決されません。管理者が懸念している他の問題があるようです。

残念ながら、Linux DNSリゾルバーは、DNSサーバーのフェイルオーバーの検出と実行を直接サポートしているようには見えません。プライマリ解決ネームサーバーにリクエストを送り続け、設定されたタイムアウトを待ち、再試行などを行います。

これは多くの場合、すべてのリクエストで最大30秒の遅延を意味します。プライマリがダウンしている限り、最初にセカンダリを試行することなく。

私たちのAmazon EC2解決ネームサーバーが多くの従業員に到達できないため、私はこれを解決したかったのです。これにより、プロセスに大きな遅延が生じ、場合によっては解決に依存しているためにダウンタイムが発生することもあります。Amazonが再びダウンした場合に備えて、Google / Level3ネームサーバーへの適切なフェイルオーバーが必要でした。そして、できるだけ早くフォールバックします。それは、Amazonがホスト名をローカルアドレスに解決し、インスタンス間通信のレイテンシを短縮するためです。

しかし、どのようなユースケースでも、フェイルオーバーを改善する必要があります。これを解決したかった。プロキシ処理のデーモンやサービスなどに近づかないようにしたいと思っていました。そのため、単一障害点が増えるだけです。できるだけ古くて堅牢なテクノロジーを使いたかったのです。

私はcrontabとbashを使用することに決め、nsfailover.shと書きました。お役に立てれば。

問題は、クライアント（だれでもどこでも可能）が2つのDNSサーバーを参照していて、1つが失敗した場合、セカンダリサーバーにフェールオーバーしないか、タイムアウトするまでに長いタイムアウトがあることです。

プライマリDNSサーバーとセカンダリDNSサーバーを別の施設に配置することをベストプラクティスとして同意しますが、それによってこの特定の問題がどのように解決されるかはわかりません。

クライアントが特定のIPアドレスのクエリを要求し、セカンダリのIPアドレスを無視する（またはタイムアウトするのにしばらく時間がかかる）場合は、たとえそのIPアドレスが機能し続けていても、そのIPアドレスを維持し続けるソリューションを考え出す必要があります。プライマリサーバーがダウンしています。

探求するいくつかの方向は、単一のIPアドレスのトラフィックを異なるデータセンターの複数のサーバーにリダイレクトできるロードバランサーです。またはおそらくエニーキャストルーティング。

各データセンターが異なる回路上にある限り（理想的には、クラウドまでのアップストリームプロバイダーが異なる場合）、2つのデータセンターだけで非常に信頼性の高いDNSをセットアップできます。選択したレジストラが適切なグルーレコードを空の大きなサーバーに入力することを確認するだけです。

私たちのセットアップは：

• 2つの物理データセンター（個別の回線、ISP、および上流プロバイダー）
• 各施設のSLBの背後にあるクラスター内の2つの物理クエリサーバー
• 2つのデータセット間のバランスを管理する特定のレコードを提供する2つの負荷分散デバイス
• 両方のサーバークラスターから内部的にアクセス可能な隠しマスター（セキュリティのための隠しマスターの設定は非常に重要であると信じています）

このセットアップは、更新などのサーバーのダウンタイムが時々発生する場合でも、過去6年間または7年間でおよそ5秒間のアップタイムを与えるのに十分効果的です。 ultradnsのような誰かとのゾーンのホスティング...

KPWINCが言及したロードカンバセーションに関しては、100％正しいです。最小のデータセンターが負荷の100％を処理できない場合は、少なくとも必要なときに停止が発生するため、とにかく骨が折れる可能性があります=）

私はすべてのエッジルーターから最大負荷を取得し、それらをすべて追加してから0.65で割ります...これは、各データセンターで必要な最小帯域幅です。私はそのルールを5年ほど前に導入しました。CCOやインターネットについて収集した、それを正当化するためのいくつかの文書があり、私たちが失敗したことはありません。ただし、これらの統計は少なくとも四半期ごとに確認する必要があります。昨年の11月から2月のトラフィックは3倍近く増加しましたが、その準備ができていませんでした。その明るい面は、WAN回線の負荷が72％になるとパケットをドロップし始めるという非常に明確なハードデータを生成できる状況でした。帯域幅を増やすために、これ以上の正当化の必要はありません。

説明を読んだところ、部外者がサーバーを見つけるための信頼できるDNSなのか、それともローカルクライアント用の再帰的なDNSサーバーなのかが明確ではないことに気付きました。これら2つの動作は大きく異なります。

信頼できるDNSサーバーの場合、「クライアント」は、キャッシングと十分なインテリジェンスを備えた他のDNSサーバーになります。最初のサーバーがまったく遅い場合は、一度に複数のサーバーを試す傾向があり、応答が速いサーバーを優先する傾向があります。その場合の1つのデータセンターのダウンタイムは、パフォーマンスに非常にわずかな影響を与えます。

再帰的なDNSサーバーの場合、クライアントは、おそらくDHCPにDNSサーバーがリストされているローカルクライアントです。彼らは、最初のサーバーから2番目のサーバーに移動する前に、非常に長い（数秒）タイムアウトで、リストされた順序でサーバーを毎回試します。

プライマリデータセンターがダウンしている場合、いずれのユーザーもこれらのサーバーに到達できなくなりますが、そのサーバーからのエラーは、到達不能なDNSサーバーからのエラーよりもわかりやすくなります。「サーバーが見つかりませんでした」または「そのようなサーバーはありません」ではなく、「サーバーに接続できませんでした」または「接続がタイムアウトしました」。たとえば、ほとんどのSMTPサーバーは、DNSでサーバーを見つけたが到達できない場合、メールを1週間待ちます。DNSでまったく見つからない場合は、すぐにドメインへの配信を拒否する可能性もあります。

セカンダリDNSを地理的に分離し、ネットワークで分離することは良いことです。あなたは友好的な会社と二次DNSを取引することができるかもしれません、そしてあなたのためにそれをするためにあなたが支払うことができるたくさんのDNSプロバイダーがあります。一部のレジストラは、サービスとしてセカンダリDNSも持っています。

トーマス、

更新を読んだ後、私の投稿を改訂しました（以前の投稿はWindowsソフトウェアに関するものでした）。

sysadminがフルロケーションを処理するために必要なハードウェアがセカンダリの場所にないことを言っているように、私にはほとんど聞こえますか？

「こんにちは。プライマリロケーション（プライマリDNSを含む）がダウンした場合、COLO1がダウンしているとCOLO2がロードを処理できないので、DNSは最も心配ではありません。」と言っているように聞こえます。

それが事実である場合、私はあなたがあなたのインフラストラクチャを見て、より良いデザインを考え出すことを試みることを勧めます。これは言うより簡単です、特に今は本番環境に住んでいるためです。

それを除けば、完璧な世界では、COLO1とCOLO2は独立して負荷を処理できます。

いったんそれが整ったら... DNSは実際には十分な速さのリフレッシュを備えた十分なDNSサーバーを持つことであり、一方が失敗した場合、稼働中のサーバーを指すようにDNSを書き換えることができます。

私はこの方法を小規模から妥当なサイズの環境で使用してきました。通常、フェイルオーバーには10分もかかりません。

DNSサーバーが短いTTL（存続時間）の余分な負荷を処理できることを確認する必要があります。

お役に立てれば。

あなたのシステム管理者は（ほとんど）間違っています。

権限のあるサーバーにクエリを実行する再帰サーバーは、どちらかのサイトが応答しない場合、非常に迅速に通知されます。

はい。停電時にクライアントでDNS解決の遅延がごくわずかに発生する可能性がありますが、わずか1〜2秒で、クライアントの独自のDNSサーバーがサーバーの1つがダウンしていることを知ると、サーバーが使用するようになります障害が発生したサーバーよりも優先される残りのサーバー。

必要に応じて（sysadminsを緩和するため）、プライマリデータセンターで2つのサーバーを実行し続けますが、少なくとももう1台は外部に配置します。

セカンダリDNSサーバーは、ホストされている場所に応じて、機能を損なうことはありません。

プライマリホストに障害が発生した場合、セカンダリホストがその隣にあるかリモートロケーションにあるかに関係なく、セカンダリホストが引き継ぐことができます。ただし、データセンターのアップリンクが失敗した場合でも、別のデータセンターのサーバーからDNS応答が返される可能性がありますが、サーバーにアクセスできなくなります。そのため、エンドユーザーがリモートロケーションのセカンダリDNSを直接利用することはありません。

さまざまなクライアントは、DNSサーバーが利用できないことに対して他の方法で反応するため、タイムアウトするクライアントにはいくつかの真実がありますが、すべてではありません。

ただし、リモートデータセンターのセカンダリDNSは、到達するサーバーのIPアドレスを解決できるため、ルーティングをデバッグして、いつ再起動するかを確認できます。また、セカンダリMXサーバーを正しく設定していれば、メールを失うことすらありません。