systemd-resolvedがオフラインDNSサーバーを使用しないようにする方法は？
DHCPサーバーを構成して、冗長性のために2つのネームサーバーを提供しました。これにより、一方がオフラインの場合でも、もう一方を使用できます。
私はsystemd-resolvedを使用してPCを構成し、resolvectl statusに従ってすべてのDNSサーバー（両方のIPv4アドレスとIPv6アドレス）を取得し、1つを現在のサーバーとして使用しています。
ただし、DNSサーバーがオフラインになると、systemd-resolvedは次のサーバーに切り替えず、オフラインサーバーへの接続を試行し続けるため、キャッシュされていないすべての名前解決が失敗します。
systemctl restart systemd-resolvedを実行すると、別のサーバーに切り替わり、作業は続行されますが、しばらくするとランダムにオフラインサーバーに戻り、名前解決が再び失敗します。
オフラインDNSサーバーの使用を停止し、それが認識している他のサーバーにすばやく切り替えるようにsystemd-resolvedに指示するにはどうすればよいですか？
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に応答しません。
DNSの専門家は、ネットワークでDNSサービスの復元力が必要な場合は、クライアントの実装にその決定を任せないことを長い間知っていました。
クライアントのリゾルバー実装に任せるのはあまりにも重要な決定です。
理論的には、クライアントは1番目の障害時に2番目のDNSにフォールバックする必要がありますが、多くの場合これは起こりません。私の経歴の何年にもわたって、クライアントオペレーティングシステムのリゾルバーが十分にスマートであることを頼りにして、実装する人々の完全なネットワークに大きな障害が発生しました。
通常行うことは、実際にはルートネームサーバーが実行していることです。これは、DNSクラスターを作成してDNSサーバーの仮想IPアドレスを引き継ぐことです。そのために最も使用されているテクノロジーはDNSエニーキャストです。 keepdalivedを使用するなど、より単純なアーキテクチャを試すこともできます。
しかし、あなたが何をするにせよ、私はその決定をクライアントに任せないことを強調します。
LinuxおよびQuaggaでのIPv4エニーキャストを参照してください
従来の安全策は、特定のサイトに複数のDNSサーバーを確立することです。ネットワーク上の各DNSクライアントは、それらの各サーバーのIPアドレスで構成されます。これらのサーバーすべてが壊滅的な方法で失敗する可能性はかなり低いので、安全に余裕があります。
一方、多くのスタブリゾルバーは2つのDNSサーバーしか使用しないため、DNSトポロジに地理的な意味のある分散を持たせることはほぼ不可能です。 DNSスタブリゾルバーは、通常、構成された2つのDNSサーバーのうち最初のサーバーのみを排他的に使用します。その結果、1つのサーバーがクエリの負荷全体と1つのアイドリングを受け取り、障害を待機することになります。最適ではありませんが、それは冗長性の代償です...である必要はありません。
DNSの冗長性とフェイルオーバーは、エニーキャストの典型的な使用例です。エニーキャストは、1つのIPアドレスを取得して、それぞれが他のサーバーを認識しない複数のサーバー間で共有するという概念です。 DNSルートネームサーバーはエニーキャストを広範囲に使用します。
PS。私は、過去に2つのISPと1つの大学でiBGPとOSPFを使用してエニーキャストDNSを実装し、DNSサービスの稼働時間の可用性を劇的に改善しました。