DNS リゾルバと NS レコード TTL

Question

DNS リゾルバが権威ネームサーバーのドメイン/ゾーンを検索するとき、6 つのレコードすべてを取得して循環処理しますか?

はい、適切な再帰ネームサーバーはすべてのネームサーバーを考慮し、後で毎回最も高速なネームサーバーをクエリしようとします。

大まかなアルゴリズムは次のようになります。

コールドスタート（キャッシュなし）から、すべてをランダムに試し、応答速度を記録します（UDPの場合とTCPの場合を区別する必要があるかもしれません）
しばらくすると、以前の返信に基づいて最も速いものをより頻繁に使用し始めます
ただし、特定のネームサーバーに無期限に固執するのではなく、他のネームサーバーも「時々」試す必要があることに注意してください。なぜでしょうか? ネットワークトポロジーは変更される可能性があり、ネームサーバー自体も変更される可能性があるためです。ns3特定の観点からは、今日は最速のネームサーバーが最速かもしれませんが、明日はそうns5ではないかもしれません。したがって、最速のネームサーバーを使用する必要がありますが、常にそうする必要はありません。これは、現時点で最速と思われるネームサーバーよりも高速なネームサーバーを自動的に検出できるようにするためです。

リゾルバが1番目のNSサーバを使用する場合

ここで止まります。レコードはリストではなくセットで送られてきます。つまり、DNS には固有の順序はありません。もちろん、配線や表示表現には順序がありますが、それはプロトコルから来るものではありません。

レコードセットはバッグです。つまり、順序のないレコードが取得されます。実際、まったく同じクエリに対して、応答に複数のレコードがある場合、多くのネームサーバーは、クエリを実行するたびにレコードを異なる順序で並べ替えます。これは、最初の項目のみを考慮し、他の項目を無視するクライアントシステムに対抗するためです。

権威ネームサーバーが応答しない場合

上記のアルゴリズムを参照してください。セット内のネームサーバーの 1 つNSが応答しない場合は、「他のネームサーバーからの応答が最も遅い」のと同じと見なすことができます。クライアント DNS にはタイムアウトがあるため、無限に待機することはありませんが、この特定のネームサーバーは遅すぎるとマークされ、他のネームサーバーに切り替えられます。したがって、最初はシステムがそのネームサーバーに接続しようとし、少し待って (数秒)、再試行し、ある時点でそのネームサーバーの使用を停止する必要があるため、ペナルティが発生します。その後は、他のネームサーバーが使用され、処理が速くなります。ただし、特定のネームサーバーが遅い/応答していないことを実際に接続を試みることで初めて発見する必要があり、試してみなければ問題を推測することはできません。

つまり、NS レコードの TTL を短く設定する必要があるということですか?

おそらくそうでしょうが、ほとんどは無関係です。なぜでしょうか? NSDNS 委任を確実にするために、レコードはドメインの親ゾーンに公開されるからです。すべてのレコードには TTL が関連付けられているため、もちろん TTL 付きで公開されますが、自分が制御していないゾーンに公開されるため、TTL 値を選択することはできません。

NS(ここでは、親と子の 2 つの部分で存在するレコードについて複雑でまだ議論が終わっていません。「どちらが本当に信頼できるのか」という疑問があります。親のNSレコードの TTL が 1 週間で、ゾーン内の同じNSレコードの TTL が 1 秒の場合、再帰ネームサーバーは何をすべきでしょうか。通常は委任の子の部分が信頼できるため、ここでは 1 秒が有利であるという結論に達するかもしれません。実際には、複数の DNS 実装は「親中心」であり、親側のデータを使用するため、そこでは 1 週間が有利になります)

TTL は常にトレードオフです。これを知った一部の人々は、TTL が非常に低い方がうまくいくという結論にすぐに飛びつきます... これは、場合によっては当てはまりますが、他の場合には当てはまりません。キャッシュは便利です。キャッシュがなければ (つまり、十分な大きさの TTL を使用していないと)、小さな問題に対して耐性がなくなり、キャッシュによって名前がすでに期限切れになっているため、すべてが消えてしまいます。

また、TTL 値は、すべてのネームサーバーを巡回し、タイムアウトを試行して最も高速なネームサーバーに収束する上記のアルゴリズムにはまったく (またはほとんど) 影響を与えません。

したがって、TLD ネームサーバー (その TLD の下にあるすべてのドメインのレコードをホストするサーバー) またはさまざまな推奨事項で何が起こっているかを確認するとNS、TTL が 1 日または 2 日のレコードがよく見られますNS。

応答しない NS とその TTL でリゾルバ DNS がどのように動作するかについてアドバイスはありますか?

各リゾルバは独自の処理を行います :-) これはプロトコルで実際に指定されているわけではなく、実装の詳細です。インストールできるリゾルバのソースコードを調べることはできますが、大規模なパブリック再帰 DNS プロバイダーからその詳細を収集することはできないでしょう。

詳細は以下をご覧ください:

RFC 1034 §5.3.3 にもいくつかの情報が記載されています (忘れていたケースが 1 つ考慮されていることにも注意してください。特定のネームサーバーには複数の IP アドレスがある場合があります。今日でも、1 つの IPv4 と 1 つの IPv6 が常に存在するはずですが、それぞれで同じ時間内に結果が得られる保証はありません)。

サーバーの名前とアドレスに加えて、SLIST データ構造をソートして、最適なサーバーを最初に使用し、すべてのサーバーのすべてのアドレスがラウンドロビン方式で使用されるようにすることができます。ソートは、ローカルネットワーク上のアドレスを他のアドレスよりも優先するという単純な機能である場合もあれば、以前の応答時間や打率などの過去のイベントの統計情報を使用する場合もあります。

ステップ 3 では、応答が受信されるまでクエリを送信します。この戦略では、各送信の間にタイムアウトを設けて、すべてのサーバーのすべてのアドレスを循環します。実際には、マルチホームホストのすべてのアドレスを使用することが重要です。また、再送信ポリシーが強すぎると、同じネームサーバーを競合する複数のリゾルバーによって使用される場合や、場合によっては単一のリゾルバーに対して使用される場合に、応答が遅くなります。SLIST には通常、タイムアウトを制御し、以前の送信を追跡するためのデータ値が含まれています。

RFC 1035 §7.2 には次のように書かれています。

SLIST の初期化を完了するために、リゾルバは SLIST 内の各アドレスに、保持している履歴情報を添付します。これは通常、アドレスの応答時間の加重平均と、アドレスの打率 (つまり、アドレスが要求に応答した頻度) で構成されます。この情報は、ネームサーバーごとではなく、アドレスごとに保持する必要があることに注意してください。これは、特定のサーバーの応答時間と打率は、アドレスごとに大幅に異なる可能性があるためです。また、この情報は実際にはリゾルバアドレスとサーバーアドレスのペアに固有のものであるため、複数のアドレスを持つリゾルバでは、アドレスごとに個別の履歴を保持することを希望する場合があります。この手順の一部では、このような履歴を持たないアドレスを処理する必要があります。この場合、予想される往復時間は最悪の場合で 5 ～ 10 秒となり、同じローカルネットワークの場合はそれよりも低い推定値になります。

委任に従うたびに、リゾルバアルゴリズムによって SLIST が再初期化されることに注意してください。

この情報により、使用可能なネームサーバーアドレスの部分的なランキングが確立されます。アドレスが選択されるたびに、他のすべてのアドレスが試されるまで、そのアドレスが再度選択されないように状態を変更する必要があります。応答の変動を許容するために、各送信のタイムアウトは、平均予測値より 50 ～ 100% 大きくする必要があります。

最後に、これについてより具体的に説明します。

impervaのこの記事で説明されているように

あなたが参照しているこの記事では、障害が発生したときに Dyn ネームサーバーを使用しているユーザーに発生した問題について説明しています。そうすると、Dyn ネームサーバーのみを使用している場合は問題が発生します。ゾーンを変更して他のゾーンを使用するようにしたとしても、NSレコードの TTL により、変更はすぐには反映されません。しかし、実際には、これは TTL について多くを語っているわけではなく、DNS 管理について多くを語っているだけです。回復力を持たせたい場合は、重要なゾーンに対して単一の DNS プロバイダーではなく、複数のプロバイダーを使用してください (もちろん、プロバイダー間の調整が必須であり、プロバイダー X と Y を恣意的に組み合わせることはできません。DNSSEC を組み合わせるとさらに複雑になりますが、可能です)。このように、上で簡単に作成したアルゴリズムのおかげで、たとえば 5 つのネームサーバーのうち 2 つがこの特定のプロバイダーに問題があるために完全に応答しなくなったとしても、他のネームサーバーが負荷を引き受け、ドメインを機能させます。訪問者の新しいクエリごとに余分な遅延が発生する可能性があります (5 つのうち 2 つがダウンしているため、すべての再帰ネームサーバーが特定のネームサーバーに切り替える必要があることをすぐに理解できないため)。また、他の 3 つのネームサーバーが通常よりも多くのクエリで圧倒されるため (DNS はデフォルトで負荷分散されるため、理論上は各ネームサーバーがほぼ同じ量のクエリを受け取ります)、さらに遅延が発生する可能性がありますが、それでも応答は返されます。

PS: 求められてはいませんが、明確でない場合もあるため、特定のレコードセット内のすべてのレコードは同じ TTL を持つ必要があります。TTL はレコードごとにありますが、特定のレコードセット内で同じである必要があります。つまり、特定のタプル (名前、レコードタイプ) [およびクラス、ただしINクラス以外を使用する人はいません]に対して同じである必要があります。

Answer 1

DNS リゾルバが権威ネームサーバーのドメイン/ゾーンを検索するとき、6 つのレコードすべてを取得して循環処理しますか?

はい、適切な再帰ネームサーバーはすべてのネームサーバーを考慮し、後で毎回最も高速なネームサーバーをクエリしようとします。

大まかなアルゴリズムは次のようになります。

コールドスタート（キャッシュなし）から、すべてをランダムに試し、応答速度を記録します（UDPの場合とTCPの場合を区別する必要があるかもしれません）
しばらくすると、以前の返信に基づいて最も速いものをより頻繁に使用し始めます
ただし、特定のネームサーバーに無期限に固執するのではなく、他のネームサーバーも「時々」試す必要があることに注意してください。なぜでしょうか? ネットワークトポロジーは変更される可能性があり、ネームサーバー自体も変更される可能性があるためです。ns3特定の観点からは、今日は最速のネームサーバーが最速かもしれませんが、明日はそうns5ではないかもしれません。したがって、最速のネームサーバーを使用する必要がありますが、常にそうする必要はありません。これは、現時点で最速と思われるネームサーバーよりも高速なネームサーバーを自動的に検出できるようにするためです。

リゾルバが1番目のNSサーバを使用する場合

ここで止まります。レコードはリストではなくセットで送られてきます。つまり、DNS には固有の順序はありません。もちろん、配線や表示表現には順序がありますが、それはプロトコルから来るものではありません。

レコードセットはバッグです。つまり、順序のないレコードが取得されます。実際、まったく同じクエリに対して、応答に複数のレコードがある場合、多くのネームサーバーは、クエリを実行するたびにレコードを異なる順序で並べ替えます。これは、最初の項目のみを考慮し、他の項目を無視するクライアントシステムに対抗するためです。

権威ネームサーバーが応答しない場合

上記のアルゴリズムを参照してください。セット内のネームサーバーの 1 つNSが応答しない場合は、「他のネームサーバーからの応答が最も遅い」のと同じと見なすことができます。クライアント DNS にはタイムアウトがあるため、無限に待機することはありませんが、この特定のネームサーバーは遅すぎるとマークされ、他のネームサーバーに切り替えられます。したがって、最初はシステムがそのネームサーバーに接続しようとし、少し待って (数秒)、再試行し、ある時点でそのネームサーバーの使用を停止する必要があるため、ペナルティが発生します。その後は、他のネームサーバーが使用され、処理が速くなります。ただし、特定のネームサーバーが遅い/応答していないことを実際に接続を試みることで初めて発見する必要があり、試してみなければ問題を推測することはできません。

つまり、NS レコードの TTL を短く設定する必要があるということですか?

おそらくそうでしょうが、ほとんどは無関係です。なぜでしょうか? NSDNS 委任を確実にするために、レコードはドメインの親ゾーンに公開されるからです。すべてのレコードには TTL が関連付けられているため、もちろん TTL 付きで公開されますが、自分が制御していないゾーンに公開されるため、TTL 値を選択することはできません。

NS(ここでは、親と子の 2 つの部分で存在するレコードについて複雑でまだ議論が終わっていません。「どちらが本当に信頼できるのか」という疑問があります。親のNSレコードの TTL が 1 週間で、ゾーン内の同じNSレコードの TTL が 1 秒の場合、再帰ネームサーバーは何をすべきでしょうか。通常は委任の子の部分が信頼できるため、ここでは 1 秒が有利であるという結論に達するかもしれません。実際には、複数の DNS 実装は「親中心」であり、親側のデータを使用するため、そこでは 1 週間が有利になります)

TTL は常にトレードオフです。これを知った一部の人々は、TTL が非常に低い方がうまくいくという結論にすぐに飛びつきます... これは、場合によっては当てはまりますが、他の場合には当てはまりません。キャッシュは便利です。キャッシュがなければ (つまり、十分な大きさの TTL を使用していないと)、小さな問題に対して耐性がなくなり、キャッシュによって名前がすでに期限切れになっているため、すべてが消えてしまいます。

また、TTL 値は、すべてのネームサーバーを巡回し、タイムアウトを試行して最も高速なネームサーバーに収束する上記のアルゴリズムにはまったく (またはほとんど) 影響を与えません。

したがって、TLD ネームサーバー (その TLD の下にあるすべてのドメインのレコードをホストするサーバー) またはさまざまな推奨事項で何が起こっているかを確認するとNS、TTL が 1 日または 2 日のレコードがよく見られますNS。

応答しない NS とその TTL でリゾルバ DNS がどのように動作するかについてアドバイスはありますか?

各リゾルバは独自の処理を行います :-) これはプロトコルで実際に指定されているわけではなく、実装の詳細です。インストールできるリゾルバのソースコードを調べることはできますが、大規模なパブリック再帰 DNS プロバイダーからその詳細を収集することはできないでしょう。

詳細は以下をご覧ください:

RFC 1034 §5.3.3 にもいくつかの情報が記載されています (忘れていたケースが 1 つ考慮されていることにも注意してください。特定のネームサーバーには複数の IP アドレスがある場合があります。今日でも、1 つの IPv4 と 1 つの IPv6 が常に存在するはずですが、それぞれで同じ時間内に結果が得られる保証はありません)。

サーバーの名前とアドレスに加えて、SLIST データ構造をソートして、最適なサーバーを最初に使用し、すべてのサーバーのすべてのアドレスがラウンドロビン方式で使用されるようにすることができます。ソートは、ローカルネットワーク上のアドレスを他のアドレスよりも優先するという単純な機能である場合もあれば、以前の応答時間や打率などの過去のイベントの統計情報を使用する場合もあります。

ステップ 3 では、応答が受信されるまでクエリを送信します。この戦略では、各送信の間にタイムアウトを設けて、すべてのサーバーのすべてのアドレスを循環します。実際には、マルチホームホストのすべてのアドレスを使用することが重要です。また、再送信ポリシーが強すぎると、同じネームサーバーを競合する複数のリゾルバーによって使用される場合や、場合によっては単一のリゾルバーに対して使用される場合に、応答が遅くなります。SLIST には通常、タイムアウトを制御し、以前の送信を追跡するためのデータ値が含まれています。

RFC 1035 §7.2 には次のように書かれています。

SLIST の初期化を完了するために、リゾルバは SLIST 内の各アドレスに、保持している履歴情報を添付します。これは通常、アドレスの応答時間の加重平均と、アドレスの打率 (つまり、アドレスが要求に応答した頻度) で構成されます。この情報は、ネームサーバーごとではなく、アドレスごとに保持する必要があることに注意してください。これは、特定のサーバーの応答時間と打率は、アドレスごとに大幅に異なる可能性があるためです。また、この情報は実際にはリゾルバアドレスとサーバーアドレスのペアに固有のものであるため、複数のアドレスを持つリゾルバでは、アドレスごとに個別の履歴を保持することを希望する場合があります。この手順の一部では、このような履歴を持たないアドレスを処理する必要があります。この場合、予想される往復時間は最悪の場合で 5 ～ 10 秒となり、同じローカルネットワークの場合はそれよりも低い推定値になります。

委任に従うたびに、リゾルバアルゴリズムによって SLIST が再初期化されることに注意してください。

この情報により、使用可能なネームサーバーアドレスの部分的なランキングが確立されます。アドレスが選択されるたびに、他のすべてのアドレスが試されるまで、そのアドレスが再度選択されないように状態を変更する必要があります。応答の変動を許容するために、各送信のタイムアウトは、平均予測値より 50 ～ 100% 大きくする必要があります。

最後に、これについてより具体的に説明します。

impervaのこの記事で説明されているように

あなたが参照しているこの記事では、障害が発生したときに Dyn ネームサーバーを使用しているユーザーに発生した問題について説明しています。そうすると、Dyn ネームサーバーのみを使用している場合は問題が発生します。ゾーンを変更して他のゾーンを使用するようにしたとしても、NSレコードの TTL により、変更はすぐには反映されません。しかし、実際には、これは TTL について多くを語っているわけではなく、DNS 管理について多くを語っているだけです。回復力を持たせたい場合は、重要なゾーンに対して単一の DNS プロバイダーではなく、複数のプロバイダーを使用してください (もちろん、プロバイダー間の調整が必須であり、プロバイダー X と Y を恣意的に組み合わせることはできません。DNSSEC を組み合わせるとさらに複雑になりますが、可能です)。このように、上で簡単に作成したアルゴリズムのおかげで、たとえば 5 つのネームサーバーのうち 2 つがこの特定のプロバイダーに問題があるために完全に応答しなくなったとしても、他のネームサーバーが負荷を引き受け、ドメインを機能させます。訪問者の新しいクエリごとに余分な遅延が発生する可能性があります (5 つのうち 2 つがダウンしているため、すべての再帰ネームサーバーが特定のネームサーバーに切り替える必要があることをすぐに理解できないため)。また、他の 3 つのネームサーバーが通常よりも多くのクエリで圧倒されるため (DNS はデフォルトで負荷分散されるため、理論上は各ネームサーバーがほぼ同じ量のクエリを受け取ります)、さらに遅延が発生する可能性がありますが、それでも応答は返されます。

PS: 求められてはいませんが、明確でない場合もあるため、特定のレコードセット内のすべてのレコードは同じ TTL を持つ必要があります。TTL はレコードごとにありますが、特定のレコードセット内で同じである必要があります。つまり、特定のタプル (名前、レコードタイプ) [およびクラス、ただしINクラス以外を使用する人はいません]に対して同じである必要があります。

DNS リゾルバと NS レコード TTL

答え1

関連情報