DNSサーバーに障害が発生した場合のDNSタイムアウトの回避
3つの内部DNSサーバー（バインド9）を指す約100のホストを持つ小さなデータセンターがあります。私たちの問題は、内部DNSサーバーの1つが利用できなくなったときに発生します。その時点で、そのサーバーを指すすべてのクライアントの実行が非常に遅くなります。
問題は、標準のLinuxリゾルバーが実際には別のDNSサーバーへの「フェイルオーバー」の概念を持っていないことです。使用するタイムアウトと再試行の数を調整できます（そして、リストを介して機能するように回転を設定します）。ただし、プライマリDNSサーバーが利用できなくなった場合、サービスをどの設定で使用しても、パフォーマンスが大幅に低下します。現在、これは私たちにとってサービス中断の最大の原因の1つです。
私の理想的な答えは「RTFM：/etc/resolv.confをこのように微調整する...」のようなものですが、それがオプションである場合、私はそれを見ていません。
他の人がこの問題をどのように処理したのだろうと思っていましたか？
私は3つの可能なタイプの解決策を見ることができます：
Linux-ha/PacemakerとフェイルオーバーIPを使用します（DNS IP VIPは「常に」使用可能です）。悲しいかな、私たちにはフェンシングインフラストラクチャがなく、フェンシングを行わないとペースメーカーがうまく機能しません（私の経験では、ペースメーカーはフェンシングなしで可用性を低下させます）。
各ノードでローカルDNSサーバーを実行し、resolv.confがlocalhostを指すようにします。これは機能しますが、監視および管理する多くのサービスを提供します。
各ノードでローカルキャッシュを実行します。人々はnscdが「壊れている」と考えているようですが、dnrdには正しい機能が設定されているようです。これは、DNSサーバーをアップまたはダウンとしてマークし、「ダウン」DNSサーバーを使用しません。
エニーキャスティングは、IPルーティングレベルでのみ機能するようで、サーバー障害のルートアップデートに依存しています。マルチキャストは完璧な答えのように見えましたが、bindはブロードキャストまたはマルチキャストをサポートしていません。また、見つけることができるドキュメントは、マルチキャストDNSは通常のDNS解決ではなく、サービス検出と自動設定を目的としているように思われます。
明らかな解決策がありませんか？
いくつかのオプション。どちらもDNS負荷をDNSサーバー全体に分散します。
- Resolv.confで
options rotateを使用してみてください。これにより、プライマリサーバーのダウンによる影響を最小限に抑えることができます。他のサーバーのいずれかがダウンしている場合、アクションが遅くなります。 - 異なるクライアントで異なるネームサーバーの順序を使用します。これにより、一部のクライアントは、プライマリDNSサーバーがダウンしている場合でも正常に実行できます。これにより、サービス停止中のDNSサーバーの影響が広がっています。
これらのオプションはoptions timeout:1 attempts:5と組み合わせることができます。タイムアウトを減らして低速の外部サーバーを処理できるようにするには、試行回数を増やします。
ルーターの構成によっては、DNSサーバーがダウンしたときにプライマリDNSサーバーのIPアドレスを引き継ぐようにDNSサーバーを構成できる場合があります。これは上記のテクニックと組み合わせることができます。
注：予定外のDNS停止なしで何年も実行しています。他の人が指摘したように、DNSサーバーの障害の原因となっている問題の解決に取り組みます。上記の手順は、到達不能なネームサーバーを指定して、DNSサーバーの設定を誤る場合にも役立ちます。
「man resolv.conf」をチェックしてください。 resolv.confにタイムアウトオプションを追加できます。デフォルトは5ですが、resolv.confに以下を追加すると、1秒になります。
オプションタイムアウト：1
ここでは、ハートビートやペースメーカー/コロシンクなどのクラスタリングソフトウェアが便利です。例として、私たちは次のようにペースメーカー/コロシンクを設定しました：
- すべてのサーバーを別のサーバーとペアリングする
- ペアごとに2つのDNS VIPがあり、通常はそれぞれに1つ
- バインドまたはサーバーに障害が発生した場合、vipはミリ秒以内に他のサーバーに移動します
本番稼働時間は24時間年中無休ですが、お客様に影響を与えることなく、すべてのサーバーで障害が発生する可能性があると強く信じています。オプション回転は単に回避策です、私はそれをしません。
各ノードでローカルDNSサーバーを実行し、resolv.confがlocalhostを指すようにします。これは機能しますが、監視および管理するための多くのサービスを提供します。
FWIW、これは私がこの問題に対して見つけた唯一の実行可能な解決策です。サーバーをlocalhostでのみリッスンするように制限する必要はありますが、環境でDNSの停止に気づくユーザーを完全に排除しました。
興味深い副作用の1つは、何らかの理由でlocalhostサーバーがダウンした場合、標準のリゾルバーライブラリが次のサーバーへのフェイルオーバーを標準の場合よりもはるかに速く処理するように見えることです。
私たちはこれを約3年間行っており、localhostで実行されているDNSサーバーの障害/停止に関連する単一の問題を見たことはありません。
ネームサーバーがメンテナンスのためにダウンしている場合、そのドメインのSOAのタイムアウトを前もって削減するのが通常の手順です。そうすることで、メンテナンスが発生すると、（NSメンテナンス前のレコードとメンテナンス後にそれらを戻す）は迅速に伝播します。これはサーバー側のアプローチです-リゾルバーの変更はクライアント側のアプローチであり、...そして、すべてのクライアントがそれらのマシンでこの調整を行うようにしてもらいます...正しいアプローチではないかもしれません。まあ、内部DNSサーバーを使用しているデータセンターのクライアントは100だけだと言っていましたが、実際にはゾーンを変更するだけで100のクライアントの構成を変更したいですか？
SOAのどの値を調整するかをお伝えしますが、この質問に出くわしたとき、正確な情報を見つけるためにウェブを閲覧していました。
おそらく、DNSサーバーをロードバランサーの背後に配置できますか？どうやらLVSはUDPのバランスをとることができます。明らかに、LBを高可用性にすることで、単一障害点ではなくなります。
これはささいなことのように聞こえるかもしれませんが、問題の永続的な解決策として、より安定した回復力のあるDNSインフラストラクチャを構築するのはどうでしょう。
よりネットワーク中心のソリューションは、同じ（専用）IPと Anycast ルーティングを持つ2つのDNSサーバーを使用することです。 （私はこれまでこのスレッドでこの答えに気づいていませんでしたが、ここではそれが使用されています。）
両方が稼働している限り、最も近いサーバーが使用されます。 1つがダウンすると、そのIPのトラフィックは、再びアップするまで他のノードにルーティングされます。これは、2つ以上の場所またはデータセンターがある場合に特に意味があります。