DNSサーバーに障害が発生した場合のDNSタイムアウトの回避

3つの内部DNSサーバー（バインド9）を指す約100のホストを持つ小さなデータセンターがあります。問題は、内部DNSサーバーの1つが使用できなくなったときに発生します。その時点で、そのサーバーを指すすべてのクライアントの実行が非常に遅くなります。

問題は、標準のLinuxリゾルバには、実際には別のDNSサーバーへの「フェイルオーバー」という概念がないということです。使用するタイムアウトと再試行回数を調整できます（そして、リストで機能するように回転を設定します）が、プライマリDNSサーバーが使用できなくなった場合、サービスを使用する設定がどれほど遅くなるかは関係ありません。現時点では、これは私たちにとって最大のサービス中断の原因の1つです。

私の理想的な答えは、「RTFM：tweak /etc/resolv.conf like this ...」のようなものですが、それがオプションである場合は見ていません。

私は他の人々がこの問題をどのように扱っているのだろうと思っていましたか？

私は3つの可能なタイプのソリューションを見ることができます：

• linux-ha / PacemakerとフェイルオーバーIPを使用します（DNS IP VIPは「常に」利用可能です）。残念ながら、優れたフェンシングインフラストラクチャがなく、フェンシングなしではペースメーカーはあまりうまく機能しません（私の経験では、Pacemakerはフェンシングなしで可用性を低下させます）。

• 各ノードでローカルDNSサーバーを実行し、resolv.confがlocalhostを指すようにします。これは機能しますが、監視および管理するためのより多くのサービスを提供します。

• 各ノードでローカルキャッシュを実行します。人々はnscdが「壊れている」と考えているように見えますが、dnrdには適切な機能セットがあるようです。つまり、dnsサーバーをupまたはdownとしてマークし、「down」dnsサーバーを使用しません。

エニーキャスティングは、IPルーティングレベルでのみ機能するようであり、サーバー障害のルート更新に依存します。マルチキャスティングは完璧な答えのように見えましたが、バインドはブロードキャストまたはマルチキャスティングをサポートしていないため、マルチキャストdnsは通常のdns解決ではなく、サービス検出と自動構成を目的としていることがわかります。

明らかな解決策がありませんか？

いくつかのオプション。どちらもDNSサーバー全体にDNS負荷を分散します。

• options rotateresolv.confで使用してみてください。これにより、プライマリサーバーがダウンする影響を最小限に抑えることができます。他のサーバーの1つがダウンすると、アクションが遅くなります。
• 異なるクライアントで異なるネームサーバーの順序を使用します。これにより、プライマリDNSサーバーがダウンしている場合に一部のクライアントが正常に実行できるようになります。これにより、アウトオブサービスDNSサーバーの影響が広がります。

これらのオプションはと組み合わせることができますoptions timeout:1 attempts:5。タイムアウトを減らす場合は、低速の外部サーバーを処理できるように試行回数を増やします。

ルーターの構成によっては、プライマリDNSサーバーのIPアドレスがダウンしたときに引き継ぐようにDNSサーバーを構成できる場合があります。これは上記の手法と組み合わせることができます。

注：予定外のDNS停止なしで何年も実行しています。他の人が指摘したように、DNSサーバーが失敗する原因となる問題の解決に取り組みます。上記の手順は、到達不能なネームサーバーを指定することにより、DNSサーバーの構成が誤っている場合にも役立ちます。

「man resolv.conf」を確認してください。resolv.confにタイムアウトオプションを追加できます。デフォルトは5ですが、resolv.confに次を追加すると1秒になります。

オプションタイムアウト：1

ここでは、ハートビートやペースメーカー/コロシンクなどのクラスタリングソフトウェアがあなたの友人です。例として、ペースメーカー/コロシンクを次のように設定しました。

• すべてのサーバーを別のサーバーとペアリングします
• ペアごとに2つのdns vipsがあり、通常はそれぞれに1つ
• バインドまたはサーバーが失敗した場合、vipはミリ秒以内に他のサーバーに移動します

生産時間は24時間365日ですが、お客様に影響を与えることなくすべてのサーバーに障害が発生する可能性があると強く考えています。オプションrotateは単なる回避策であり、私はそれをしません。

各ノードでローカルDNSサーバーを実行し、resolv.confがlocalhostを指すようにします。これは機能しますが、監視および管理するためのより多くのサービスを提供します。

FWIW、これは私がこの問題のために見つけた唯一の実行可能なソリューションです。localhostでのみリッスンするようにサーバーを制限する必要がありますが、この環境ではDNSの停止に気づくユーザーを完全に排除しました。

興味深い副作用の1つは、何らかの理由でlocalhostサーバーがダウンした場合、標準のリゾルバーライブラリが次のサーバーへのフェールオーバーを標準の場合よりもはるかに高速に処理するように見えることです。

約3年前からこれを行ってきましたが、localhostで実行されているDNSサーバーの障害/停止に関連する可能性のある単一の問題を見たことはありません。

ネームサーバーがメンテナンスのためにダウンしている場合、メンテナンスが発生したときに変更（メンテナンス前にNSレコードを削除し、メンテナンス後にそれらを戻すなど）するために、そのドメインのSOAのタイムアウトを事前に減らすのが通常の手順です）迅速に伝播します。これはサーバー側のアプローチであることに注意してください-リゾルバを変更することはクライアント側のアプローチであり、クライアントのそれぞれと話をしてマシンでこの調整を行うようにしない限り...適切なアプローチ。さて、内部DNSサーバーを使用するデータセンター内の100のクライアントのみを言ったと思いますが、ゾーンを変更するだけで100のクライアントの構成を変更したいのですか？

SOAのどの値を調整するかを説明しますが、この質問に出くわしたときに、その正確な情報を見つけるためにWebを閲覧していました。

おそらく、DNSサーバーをロードバランサーの背後に配置できますか？どうやらLVSはUDPのバランスを取ることができます。明らかにLBの可用性を高めて、単一障害点ではないようにします。

これは些細に聞こえるかもしれませんが、問題の永続的な解決策として、より安定した、信頼性の高いDNSインフラストラクチャを構築する方法はどうでしょうか。

よりネットワーク中心のソリューションでは、同じ（専用の）IPおよびエニーキャストルーティングを備えた2つのDNSサーバーを使用します。（私はこれまでこのスレッドでこの答えに気づいていませんでしたが、それがここで使用されているものです。）

両方が稼働している限り、最も近いサーバーが使用されます。1つがダウンすると、そのIPのトラフィックは、再びアップするまで他のノードにルーティングされます。これは、2つ以上の場所またはデータセンターがある場合に特に意味があります。