9. 追加の考慮事項

9.1. サービスインスタンス

我々は「サービスインスタンス」という用語を、あるセットの { IP アドレス, ポート } タプルで接続を受け入れることができるホスト上で実行されているソフトウェアを指すために使用します。ソフトウェアをインスタンスにするのは、クライアントがこれらのタプルのどれを使用して接続しても、クライアントは同じ論理ノード（セクション 9.2 参照）上で実行されている同じソフトウェアに接続され、同じ回答と同じキーイング情報を受け取るということです。

サービスインスタンスはクライアントの視点から識別されます。クライアントが { IP アドレス, ポート } タプルで構成されている場合、あるタプルで提供されるサービスが別のタプルでリッスンしているのと同じサーバーであるかどうかを判断する方法はありません。したがって、この場合、クライアントはそれぞれ異なるタプルを異なるサービスインスタンスを参照しているかのように扱います。

場合によっては、クライアントはホスト名とポート番号で構成されます。ポート番号はホスト名とともに明示的に与えられる場合があります。ポート番号は省略され、何らかのデフォルト値を持つと想定される場合があります。DNS SRV レコードの場合のように、ホスト名とポート番号がネットワークから学習される場合があります。これらの場合、{ ホスト名, ポート } タプルは、通常のケースインセンシティブな DNS 名の比較 [RFC1034] に従って、サービスインスタンスを一意に識別します。

2つのホスト名がいくつかの共通の IP アドレスを指す可能性があります。これは、クライアントが検出する義務のない構成上の異常です。これの影響として、切断するように指示された後、クライアントは異なるサービスインスタンスとして表されているため、同じサーバーに再接続する可能性があります。

実装は、2つのエンティティが「同じサービスインスタンス」であると判断されるべきかどうかを評価するために、ホスト名を解決してから IP アドレスを照合するプロセスを実行すべきではありません（SHOULD NOT）。

9.2. エニーキャストの考慮事項

エニーキャストサービスが特定の IP アドレスとポートで構成されている場合、その IP アドレスで応答する物理サーバーが複数あるとしても、そのような各サーバーは同等として扱える必要があります。ここで言う「同等」とは、接続を確立する際に、両方のサーバーが同じサービスを提供でき、必要に応じて PKI 証明書などの同じ認証情報を提供できることを意味します。

ネットワークトポロジの変更により、特定の TCP 接続内のパケットがその接続について知らないエニーキャストサーバーインスタンスに送信された場合、新しいサーバーはその接続の記録がないため、TCP リセットで自動的に接続を終了します。その後、クライアントは必要に応じて再接続するか、接続の使用を停止できます。

接続が再確立された後、同じインスタンスに接続されているというクライアントの仮定が何らかの方法で違反された場合、それはこのコンテキストでは誤った動作と見なされます。ただし、この点に関して具体的な推奨事項を作成することは、本仕様の可能な範囲外です。それは、DNS ステートフル操作の具体的な使用法を説明する後続のドキュメントに委ねられます。

9.3. 接続共有

DNS-over-TCP [RFC7766] で以前に規定されたように：

意図しないサーバーの過負荷のリスクを軽減するために、DNS クライアントは、個々のサーバーに対して行われる同時 TCP 接続の数を最小限に抑えるように注意しなければなりません（MUST）。任意の特定のクライアント/サーバー対話について、通常のクエリ用に1つの接続、ゾーン転送用に1つの接続、および TCP 上で使用されている各プロトコル（たとえば、リゾルバが TLS を使用していた場合）用に1つの接続を超えないようにすることが推奨されます（RECOMMENDED）。ただし、多くのビジーなゾーンを持つ特定のプライマリ/セカンダリ構成では、運用上の理由（たとえば、複数のゾーンの同時転送をサポートするため）でゾーン転送に複数の TCP 接続を使用する必要がある場合があることに注意してください。

単一のサーバーは、1つ以上の DNS ゾーンに対して、DNS 更新 [RFC2136]、DNS プッシュ通知 [Push]、およびその他のサービスを含む複数のサービスをサポートする場合があります。クライアントが、いくつかの異なる操作のターゲットサーバーが同じサービスインスタンス（セクション 9.1 参照）であることを発見した場合、クライアントはそれらすべての操作に対して単一の共有 DSO セッションを使用すべきです（SHOULD）。

この要件には2つの利点があります。第一に、DNS サーバーへの不必要な接続負荷を軽減します。第二に、同じ DNS サーバーへの新しい追加接続を確立するために費やされる接続開始時間を回避します。

ただし、サーバーの実装者と運用者は、すべてのケースで接続共有が可能であるとは限らないことに注意する必要があります。単一のホストデバイスは、互いに調整しない複数の独立したクライアントソフトウェアインスタンスのホームである場合があります。同様に、同じ NAT ゲートウェイの背後にある複数の独立したクライアントデバイスも、通常、同じクライアント IP アドレス上の異なるソースポートとして DNS サーバーに表示されます。これらの制約のため、DNS サーバーは、同じクライアント IP アドレス上の異なるソースポートからの複数の接続を受け入れる準備ができていなければなりません（MUST）。

9.4. ミドルボックスの運用上の考慮事項

アプリケーション層のミドルボックス（DNS プロキシ、フォワーダー、またはセッションマルチプレクサなど）がパス内にある場合、DSO トラフィックが誤って処理される構成を避けるように注意する必要があります。このような問題を回避する最も簡単な方法は、ミドルボックスの使用を避けることです。これが不可能な場合、ミドルボックスが正しく動作することを確認するために評価する必要があります。

ミドルボックスの正しい動作は、以下のいずれかで構成されます：

• ミドルボックスは DSO メッセージを転送せず、NOERROR または DSOTYPENI 以外の応答コードで DSO メッセージに応答します。

• ミドルボックスは DSO サーバーとして機能し、接続を確立する際に本仕様に従います。

• 着信接続と発信接続の間に 1:1 の対応があり、ミドルボックスへの接続が確立されると、ミドルボックスからある DNS リゾルバへの対応する接続が正確に1つ確立されることが保証され、すべての着信メッセージは変更または並べ替えなしで転送されます。これの例としては、NAT フォワーダーや TCP 接続オプティマイザー（たとえば、静止衛星リンクなどの高遅延接続用）があります。

上記の基準のいずれかを満たさないミドルボックスは、予期しない、診断が困難な方法で失敗する可能性が非常に高いです。たとえば、DNS ロードバランサーは、着信 TCP ストリームから DNS メッセージをバンドル解除し、ストリームからの各メッセージを異なる DNS サーバーに転送する場合があります。このようなロードバランサーが使用されており、それが指す DNS サーバーが DSO を実装し、DSO を有効にするように構成されている場合、DSO セッションの確立は成功しますが、クライアントとサーバーの間に一貫したセッションは存在しません。このようなロードバランサーが DSO を実装していないか、DSO を許可しないように構成されている DNS サーバーを指している場合、そのような問題は存在しませんが、DSO を実装する新しいサーバーソフトウェアがインストールされた場合、そのような構成は予期しない失敗のリスクがあります。

もちろん、DSO を適切にサポートするミドルボックスを実装することは可能です。長寿命の操作で DSO を実装するものを実装することさえ可能です。これは、上記のように着信接続と発信接続の間の 1:1 の対応を維持するか、ミドルボックスで着信セッションを終了し、要求された長寿命の操作に関する状態をミドルボックスで維持することによって行うことができます。これを詳細に規定することは、本文書の範囲外です。

9.5. TCP 遅延確認応答の考慮事項

伝送制御プロトコル (TCP) の最新の実装のほとんどには、「遅延確認応答 (Delayed Acknowledgement)」[RFC1122] と呼ばれる機能が含まれています。

この機能がないと、TCP はネットワーク上で非常に無駄になる可能性があります。説明のために、遅延 ack を欠く非常に単純な TCP 実装を使用したリモートログインのような単純な例を考えてみましょう。ユーザーがキーストロークを入力すると、データパケットが送信されます。データパケットがサーバーに到着すると、単純な TCP 実装は即時の確認応答を送信します。ほんの数ミリ秒後、サーバープロセスはキーストロークデータの1バイトを読み取り、その結果、単純な TCP 実装は即時のウィンドウ更新を送信します。ほんの数ミリ秒後、サーバープロセスは文字エコーを生成し、このデータパケットもすぐに送信します。単純な TCP 実装は、このデータパケットもすぐに送信します。この場合、この単純な TCP 実装は、ほぼ瞬時に3つのパケットのバースト（ack、ウィンドウ更新、データ）を送信します。

TCP 実装が3つの別々のパケットを1つに結合すれば、明らかに効率的であり、これが遅延 ack 機能が可能にするものです。

遅延 ack を使用すると、TCP 実装はデータパケットを受信した後に（通常は 200 ミリ秒）待機し、(a) さらにデータパケットが到着する、(b) 受信プロセスが何らかの応答データを生成する、または (c) 上記のいずれも発生せずに 200 ミリ秒が経過する場合、ack を送信します。

遅延 ack を使用すると、リモートログインははるかに効率的になり、各文字エコーに対して3つではなく1つのパケットのみを生成します。

遅延 ack のロジックは、200 ミリ秒の遅延が重大な害を及ぼすことはないというものです。反対側の何かが何かを待っている場合、受信プロセスは反対側のものが待っている応答を生成するはずであり、TCP はその応答（ack およびウィンドウ更新と組み合わせて）を直ちに送信します。そして、受信プロセスが実際にこの特定のメッセージに対して応答を生成しない場合、定義上、反対側のものは何も待っていないことになります。したがって、200 ミリ秒の遅延は無害です。

送信者が Nagle アルゴリズム（同様の効率化機能であり、多数の急速な小さな書き込みを連続して実行する不十分に記述されたクライアントソフトウェアからネットワークを保護するために作成された）を使用していない限り、この仮定は正しいかもしれません。Nagle アルゴリズムを使用すると、これらの小さな書き込みを、より大きく無駄の少ないパケットにまとめることができます。

残念ながら、Nagle アルゴリズムと遅延 ack という2つの貴重な効率化機能は、一緒に使用すると相互に悪影響を及ぼす可能性があります [NagleDA]。

DSO 要求メッセージは応答を引き出します。DSO 一方向メッセージと DSO 応答メッセージは応答を引き出しません。

応答を引き出す DSO 要求メッセージの場合、Nagle アルゴリズムと遅延 ack は意図したとおりに機能します。

応答を引き出さない DSO メッセージの場合、遅延 ack メカニズムにより、ack が 200 ミリ秒遅延します。ack の 200 ミリ秒の遅延により、今度は Nagle アルゴリズムが、待機中の ack が到着するまで 200 ミリ秒間、送信者がそれ以上のデータを送信するのを防ぐ可能性があります。サブミリ秒のラウンドトリップ時間を持つエンタープライズギガビットイーサネット (GigE) バックボーンでは、200 ミリ秒の遅延はそれに比べて膨大です。

この問題が提起されると、通常2つの解決策が提示されますが、どちらも理想的ではありません：

1. 遅延 ack を無効にする。応答を引き出さない DSO メッセージの場合、遅延 ack を削除すると、不要な 200 ミリ秒の遅延が回避され、次のパケットを送信する許可を送信者に直ちに与えるべきであることを Nagle アルゴリズムに伝える即時 ack が返送されます。残念ながら、応答を 引き出す DSO メッセージの場合、遅延 ack を削除すると、ack とデータを組み合わせる効率の向上がなくなり、レスポンダーは1つではなく2つまたは3つのパケットを送信するようになります。

2. Nagle アルゴリズムを無効にする。ack が遅延 ack アルゴリズムによって遅延している場合、Nagle アルゴリズムを削除すると、送信者が次の小さなパケットをすぐに送信するのをブロックされるのを防ぎます。残念ながら、ラウンドトリップ時間が長いネットワークでは、Nagle アルゴリズムを削除すると、複数の小さなパケットをより少ない大きなパケットに結合する効率の向上がなくなり、一度に転送中の小さなパケットの数を制限するという目標が失われます。

ここでの問題は、応答を引き出さない DSO メッセージの場合、TCP 実装は待機状態で動けなくなり、応答が生成されようとしているのか、それとも TCP 実装が先に進んで ack とウィンドウ更新を送信すべきかどうかがわからないことです。

解決策は、受信メッセージが読み取られ、処理され、このメッセージに対する応答が生成されないことを受信者が TCP 実装に通知できるようにするネットワーク API です。TCP は、決して来ない応答を待つのをやめ、すぐに先に進んで ack とウィンドウ更新を送信できます。

DSO の実装では、ネットワークに害を及ぼす可能性があるため、遅延 ack を無効にすることは推奨されません（NOT RECOMMENDED）。

DSO の実装では、ネットワークに害を及ぼす可能性があるため、Nagle アルゴリズムを無効にすることは推奨されません（NOT RECOMMENDED）。

本文書が公開の準備をしている時点で、少なくとも1つの TCP 実装が、TCP メッセージの受信者が応答を送信しないことを通知する機能を提供し、それによって遅延 ack メカニズムが待機を停止できることが知られています。この機能が利用可能なオペレーティングシステム上の実装は、それを利用すべきです（SHOULD）。