一方がオフラインになると、他のものを使用できるように冗長性のために2つのネームサーバーを提供するようにDHCPサーバーを構成しました。
私のコンピュータを設定し、systemd-resolvedすべてresolvectl statusのDNSサーバー（IPv4アドレスとIPv6アドレスの両方）を取得し、それらの1つを現在のサーバーとして使用することに基づいていました。
ただし、DNSサーバーがオフラインになると、systemd-resolved次のサーバーに切り替えるのではなくオフラインサーバーに接続しようとすると、キャッシュされていないすべての名前解決が失敗します。
を実行すると、systemctl restart systemd-resolved他のサーバーに切り替えて動作し続けますが、しばらくするとランダムにオフラインサーバーに戻り、名前解決が再び失敗します。
systemd-resolvedオフラインDNSサーバーの使用を中止し、そのサーバーが知っている他のサーバーの1つにすばやく切り替えるにはどうすればよいですか？
Journalctlは、オフラインサーバーの使用に切り替えたときにのみこの情報を表示します。
systemd-resolved[1985]: Using degraded feature set (UDP) for DNS server fdxx::x.
systemd-resolved[1985]: Using degraded feature set (TCP) for DNS server fdxx::x.
これが発生すると、サーバーは完全にオフラインになり、pingに応答しません。
ベストアンサー1
DNSの専門家は、ネットワークでDNSサービスの弾力性を望むなら、この決定をクライアントの実装に任せることができないことを長い間知っていました。
これは、顧客のパーサー実装では行うことができない非常に重要な決定です。
理論的には、最初のDNSが失敗した場合、クライアントは2番目のDNSに置き換える必要がありますが、多くの理由で通常これは発生しません。私のキャリアでは、長年にわたり、人々が物事を実装するのに十分なほど賢くなるように、クライアントOSパーサーに頼る完全なネットワークで大きな失敗を見てきました。
実際に一般的に実行するタスクは、ルートネームサーバーが実行するものです。つまり、DNSサーバーの仮想IPアドレスを引き継ぐDNSクラスタを作成します。最も一般的に使用される技術はDNSエニーキャストです。 keepdalivedを使用するなど、より単純なアーキテクチャを試してみることもできます。
しかし、何をしても決定を顧客に任せないことを強調します。
バラよりLinux および Quagga を使用した IPv4 Anycast
従来の保護措置は、特定のサイトに対して複数のDNSサーバーを設定することです。ネットワーク上のすべてのDNSクライアントは、各サーバーのIPアドレスで構成されています。これらすべてのサーバーで致命的なエラーが発生する可能性はかなり小さいため、ある程度の安全性があります。
一方、多くのスタブリゾルバには2つのDNSサーバーしか必要ないため、DNSトポロジでは意味のある地理的分散はほとんど不可能です。 DNSスタブリゾルバは通常、構成された2つのDNSサーバーのうち最初のサーバーのみを排他的に使用します。したがって、あるサーバーはクエリ全体のロードを担当し、他のサーバーはアイドル状態でエラーを待機します。最適ではありませんが、それは冗長性の対価です…そうでしょ？必ずしもそうではありません。
DNSの冗長性とフェイルオーバーは、エニーキャストの一般的なユースケースです。エニーキャストはIPアドレスを取得し、複数のサーバー間でそのアドレスを共有するという概念であり、各サーバーは他のサーバーを認識しません。 DNSルートネームサーバーは、エニーキャストを広く使用しています。
PS。過去には、ISP 2カ所と大学1カ所でiBGPとOSPFを使用してエニーキャストDNSを実装し、DNSサービスの稼働時間の可用性を大幅に向上させました。