オフラインDNSサーバーの使用を停止するためにsystemd-resolveを取得するにはどうすればよいですか?

オフラインDNSサーバーの使用を停止するためにsystemd-resolveを取得するにはどうすればよいですか?

一方がオフラインになると、他のものを使用できるように冗長性のために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サービスの稼働時間の可用性を大幅に向上させました。

答え2

DHCPを介して複数のネームサーバーを使用することは、冗長性ではなく復元力のためです。複数のネームサーバーを使用したいようです。各クライアントは、ネームサーバーが応答しないかどうかを追跡して使用を中止するためです。この種の動作/設計が本当に必要な場合は、DNSサーバー自体を使用する必要があります。これは通常DNSクライアントでは不可能です。ここでよく見られるアプローチは、DNSサーバーが確認するアップストリームDNSサーバーに基づいてDNSサーバー高可用性(HA)を作成することです。

/etc/resolv.confこれがうまくいかない理由を知るには、このファイルがどのように機能するかを見てください。 DHCPに複数のネームサーバーを追加すると、各/etc/resolv.confクライアントはそのファイルに2つのエントリを提供します。このファイルは、複数のネームサーバーを処理するための次のメカニズムのみを提供できます。

.confを手動で解析する
  nameserver Name server IP address

          Internet address of a name server that the resolver should query, either 
          an IPv4 address (in dot notation), or an IPv6 address in colon (and 
          possibly dot) notation as per RFC  2373. Up  to MAXNS (currently 3, see 
          <resolv.h>) name servers may be listed, one per keyword.  If there are 
          multiple servers, the resolver library queries them in the order listed.  
          If no nameserver entries are present, the default is to use the name 
          server on the local machine.  (The algorithm used is to try a name server, 
          and if the query times out, try  the  next, until out of name servers, 
          then repeat trying all the name servers until a maximum number of retries 
          are made.)

この文は次のように言います。

複数のサーバーがある場合、パーサーライブラリはリストされた順序で照会します。

パーサーはこのリストを管理するために何もしません。最初の項目から始めて、2番目の項目などを使用して盲目的にリストを使用し続けます。それを制御するために行うことができる唯一のことは変更timeoutです。retriesrotate

タイムアウト:n

別のネームサーバーを介してクエリを再試行する前に、リゾルバがリモートネームサーバーからの応答を待つ時間を設定します。秒単位で測定され、
デフォルトはRES_TIMEOUT(現在5、以下を参照)です。このオプションの値はデフォルトで30に制限されます。

試行回数:n

呼び出しアプリケーションを放棄してエラーを返す前にリゾルバーがネームサーバーにクエリを送信する回数を設定します。デフォルトはRES_DFLRETRY(現在2、以下を参照)です。このオプションの値はデフォルトで 5 に制限されます。

回転する

_res.options で RES_ROTATE を設定すると、リストされたネームサーバーのラウンドロビン選択が発生します。これは
、すべてのクライアントが最初にリストされたサーバーを最初に試みるのではなく、リストされているすべてのサーバーにクエリー負荷を分散させる効果があります。

引用する

関連情報