6. DSO セッションのライフサイクルとタイマー

6.1. DSO セッションの開始

DSO セッションは、セクション 5.1 で説明されているように開始されます。

DSO セッションが作成されると、クライアントまたはサーバーは、DSO セッションを使用して任意の数の DNS 操作を開始できます。

イニシエーターに送信するメッセージが複数ある場合、次のメッセージを送信する前に各応答を待つべきではありません (SHOULD NOT)。

レスポンダーは、受信した順序でメッセージを処理しなければならず (MUST)、利用可能になった時点で要求メッセージへの応答を返すべきです (SHOULD)。レスポンダーは、対応する要求が受信されたのと同じ順序で応答を配信する目的で、応答の送信を遅らせるべきではありません (SHOULD NOT)。

DNS-over-TCP 仕様 [RFC7766] のセクション 6.2.1.1 では、これについて詳しく規定しています。

6.2. DSO セッションのタイムアウト

DSO セッションには、非アクティブタイムアウトとキープアライブ間隔の 2 つのタイムアウト値が関連付けられています。両方の値は、同じ TLV、Keepalive TLV (セクション 7.1) で伝達されます。

最初のタイムアウト値である非アクティブタイムアウトは、クライアントがそのサーバーに送信する将来の要求があるかもしれないと期待して、非アクティブな DSO セッションを投機的に開いたままにすることができる最大時間です。

2 番目のタイムアウト値であるキープアライブ間隔は、クライアントが DSO セッションを維持したい場合に、メッセージ間で許可される最大間隔です。

2 つのタイムアウト値は独立しています。非アクティブタイムアウトは、キープアライブ間隔より短いか、同じか、長い場合がありますが、ほとんどの場合、非アクティブタイムアウトはキープアライブ間隔より短いと予想されます。

短い非アクティブタイムアウトと長いキープアライブ間隔は、理由もなく非アクティブな DSO セッションを長く開いたままにするべきではないが、DSO セッションを開いたままにするアクティブな理由がある場合、そのセッションを維持するために攻撃的なレベルの DSO キープアライブトラフィックを送信する必要はないことをクライアントに通知します。これの例は、DNS プッシュ通知を購読しているクライアントです。この場合、クライアントはサーバーにトラフィックを送信していませんが、プッシュ通知を受信するためのサーバーへのアクティブな要求があるため、セッションは非アクティブではありません。

長い非アクティブタイムアウトと短いキープアライブ間隔は、非アクティブな DSO セッションを長時間投機的に開いたままにすることができるが、その非アクティブな DSO セッションを維持するには、多くの DSO キープアライブトラフィックを送信する必要があることをクライアントに通知します。この構成はあまり一般的ではないと予想されます。

非アクティブタイムアウトがキープアライブ間隔よりも短い通常の場合、クライアントが長寿命で低トラフィックの操作を行っている場合にのみ、NAT とファイアウォールの状態を維持し、クライアントとサーバーが互いに接続されていることを保証するのに十分な残留トラフィックが生成されるようにするために、キープアライブ間隔が機能します。

新しい DSO セッションでは、明示的な DSO Keepalive メッセージ交換が行われていない場合、両方のタイムアウトのデフォルト値は 15 秒です。

両方のタイムアウトについて、タイムアウトの値が低いと、ネットワークトラフィックが増加し、サーバーの CPU 負荷が高くなります。

6.3. 非アクティブな DSO セッション

サーバーとクライアントの両方で、完全な DNS メッセージ (DNS 要求、応答、更新、DSO メッセージなどを含む) の生成または受信は、その DSO セッションの両方のタイマーをリセットします。唯一の例外は、DSO Keepalive メッセージがキープアライブタイマーのみをリセットし、非アクティブタイムアウトタイマーをリセットしないことです。

さらに、クライアントに未処理の操作が進行中である限り、非アクティブタイマーはクリアされたままであり、非アクティブタイムアウトは発生しません。

従来のクエリや更新のような短命の DNS 操作の場合、操作は要求と応答の間の時間、通常は最大で数百ミリ秒の間「進行中」と見なされます。クライアントでは、非アクティブタイマーは要求の送信時にクリアされ、対応する応答を受信するまでクリアされたままになります。サーバーでは、非アクティブタイマーは要求の受信時にクリアされ、対応する応答の送信までクリアされたままになります。

長寿命の DNS ステートフル操作 (プッシュ通知サブスクリプション [Push] やディスカバリリレーインターフェイスサブスクリプション [Relay] など) の場合、操作はアクティブである限り、つまりキャンセルされるまで「進行中」と見なされます。これは、アクティブな操作がある DSO セッションが存在し、どちらの方向にもメッセージが流れていない状態が、非アクティブタイムアウトよりもはるかに長く続く可能性があることを意味します。これはエラーではありません。これが、非アクティブタイムアウトとキープアライブ間隔の 2 つの別々のタイマーがある理由です。DSO セッションに長期間トラフィックがないからといって、イベントを待機しているアクティブな操作がある場合、その DSO セッションが自動的に「非アクティブ」になるわけではありません。

6.4. 非アクティブタイムアウト

非アクティブタイムアウトの目的は、サーバーが新しい DSO セッションを設定するコストと非アクティブな DSO セッションを維持するコストのトレードオフのバランスをとることです。DSO セッション容量が豊富なサーバーは、高い非アクティブタイムアウトを提供して、クライアントが投機的な DSO セッションを長時間開いたままにし、そのサーバーとの将来の通信のために新しい DSO セッションを確立するコストを節約できるようにすることができます。メモリリソースが不足しているサーバーは、低い非アクティブタイムアウトを提供して、クライアントがそのサーバーとの未処理の操作がない場合はすぐに DSO セッションを閉じ、必要になったときに後で新しい DSO セッションを作成するように促すことができます。

6.4.1. 非アクティブな DSO セッションを閉じる

接続の非アクティブタイムアウトに達すると、クライアントはアイドル接続を閉じ始めなければなりませんが (MUST)、クライアントは非アクティブタイムアウトに達するまでアイドル接続を開いたままにする必要はありません。クライアントは、クライアントの裁量でいつでも DSO セッションを閉じることができます (MAY)。クライアントが、現在非アクティブな DSO セッションに対して現在または合理的に予測される将来の必要性がないと判断した場合、クライアントはその接続を正常に閉じるべきです (SHOULD)。

DSO セッションの存続期間中のいつでも、DSO セッションでアクティブな操作がない状態で非アクティブタイムアウト値 (つまり、デフォルトで 15 秒) が経過した場合、クライアントは接続を正常に閉じなければなりません (MUST)。

DSO セッションの存続期間中のいつでも、DSO セッションでアクティブな操作がない状態で時間が経過しすぎた場合、サーバーはクライアントを滞納していると見なさなければならず (MUST)、DSO セッションを強制的に中止しなければなりません (MUST)。このコンテキストで「時間が経過しすぎた」と見なされるのは、5 秒または現在の非アクティブタイムアウト値の 2 倍のいずれか大きい方です。非アクティブタイムアウトがデフォルト値の 15 秒である場合、これは、クライアントが 30 秒間非アクティブになった後に接続を閉じていない場合、滞納していると見なされ、切断されることを意味します。

このコンテキストでは、DSO セッションでアクティブな操作には、応答を待機しているクエリ、応答を待機している更新、またはアクティブな長寿命操作が含まれますが、DSO Keepalive メッセージ交換自体は含まれません。DSO Keepalive メッセージ交換は、キープアライブ間隔タイマーのみをリセットし、非アクティブタイムアウトタイマーはリセットしません。

クライアントが非アクティブな DSO セッションをデフォルトの期間よりも長く開いたままにしたい場合は、セクション 7.1 で説明されているように、DSO Keepalive メッセージを使用してより長いタイムアウト値を要求します。

6.4.2. 非アクティブタイムアウトの値

非アクティブタイムアウト値の場合、値が低いほど、DSO セッションの切断と再確立が頻繁に行われます。値が高いほど、トラフィックが減り、サーバーの CPU 負荷が低くなりますが、非アクティブな DSO セッションの状態を維持するためのメモリ負担が高くなります。

サーバーは、非アクティブタイムアウトに対して選択した任意の値 (クライアント主導の要求への応答、またはサーバー主導のメッセージのいずれか) を指示できます。これには、1 秒未満の値やゼロも含まれます。

ゼロの非アクティブタイムアウトは、アイドル接続をまったく投機的に維持すべきではなく、クライアントがこのサーバーに関連する操作を完了したらすぐに、クライアントはこのセッションを閉じ始めるべきであることをクライアントに通知します。

サーバーは、5 秒または非アクティブタイムアウト値の 2 倍のいずれか大きい方の時間が経過した後、アイドル状態のクライアントセッションを強制的に中止します。ゼロの非アクティブタイムアウト値の場合、これは、クライアントがアイドル状態のクライアントセッションを閉じなかった場合、サーバーが 5 秒後にアイドル状態のセッションを強制的に中止することを意味します。

0xFFFFFFFF の非アクティブタイムアウトは「無限」を表し、クライアントが望む限りアイドル接続を開いたままにすることができることを通知します。このように無制限の非アクティブタイムアウトを許可した後、サーバーはいつでも、新しいセッションタイムアウト値をクライアントに指示する新しい DSO Keepalive メッセージを送信することにより、その非アクティブタイムアウトを変更できることに注意してください。

現在の Keepalive TLV でサポートされている最大の有限非アクティブタイムアウトは 0xFFFFFFFE (2^32-2 ミリ秒、約 49.7 日) です。

6.5. キープアライブ間隔

キープアライブ間隔の目的は、ミドルボックス (NAT ゲートウェイやファイアウォールなど) の状態を維持し、クライアントとサーバーが互いに接続されていることを定期的に確認するのに十分なメッセージの生成を管理することです。これにより、接続が失われたときに状態をクリーンアップし、必要に応じて新しいセッションを確立できます。

6.5.1. キープアライブ間隔の満了

DSO セッションの存続期間中のいつでも、DSO セッションで DNS メッセージが送信または受信されずにキープアライブ間隔値 (つまり、デフォルトで 15 秒) が経過した場合、クライアントは DSO Keepalive メッセージ (セクション 7.1) を送信して DSO セッションを維持するためのアクションを実行しなければなりません (MUST)。DSO Keepalive メッセージ交換は、キープアライブタイマーのみをリセットし、非アクティブタイマーはリセットしません。

クライアントが DSO セッションをきれいに閉じずに突然ネットワークから切断された場合 (おそらく長寿命の操作がキャンセルされないままになっている場合)、サーバーはそのクライアントから必要な DSO キープアライブトラフィックを受信できなかった後にこれを知ります。DSO セッションの存続期間中のいつでも、DSO セッションで DNS メッセージが送信または受信されずにキープアライブ間隔値の 2 倍 (つまり、デフォルトで 30 秒) が経過した場合、サーバーはクライアントを滞納していると見なすべきであり (SHOULD)、DSO セッションを強制的に中止すべきです (SHOULD)。

6.5.2. キープアライブ間隔の値

キープアライブ間隔値の場合、値が低いほど、DSO キープアライブトラフィックの量が多くなります。キープアライブ間隔の値が高いほど、トラフィックと CPU 負荷は減少しますが、必要な DSO キープアライブトラフィックのレベルに関係なく、クライアントは同じ期間 (非アクティブタイムアウトによって決定される) DSO セッションを開いたままにするため、サーバーのメモリ負担への影響は最小限です。

クライアントとサーバーが、使用しているネットワークの種類に応じて異なるキープアライブ間隔を選択することが適切な場合があります。

介在する NAT ゲートウェイやファイアウォールがなく、内部ネットワーク上のクライアントのみにサービスを提供していることを知っている企業 DNS サーバーは、頻繁な DSO キープアライブトラフィックが必要ないため、より長いキープアライブ間隔を課すことができます。

パス上に NAT ゲートウェイがある可能性が高い住宅用コンシューマークライアントに主にサービスを提供しているパブリック DNS サーバーは、より頻繁な DSO キープアライブトラフィックを生成するために、より短いキープアライブ間隔を課す場合があります。

スマートクライアントは環境に適応する場合があります。プライベート IPv4 アドレス [RFC1918] を使用して、その IPv4 プライベートアドレスブロック外のアドレスにある DNS サーバーと通信するクライアントは、パス上に NAT ゲートウェイがある可能性が高いと結論付け、それに応じてより短いキープアライブ間隔を要求する場合があります。

デフォルトでは、クライアントが 60 分のキープアライブ間隔を要求し、サーバーが許可することが推奨されます (RECOMMENDED)。このキープアライブ間隔は、クライアントがセッションをきれいに閉じずに突然切断した場合に、合理的にタイムリーな検出を提供します。また、ミドルボックスで使用される「確立された接続のアイドルタイムアウト」が少なくとも 2 時間 4 分であるという IETF 推奨の現在のベストプラクティスに従うファイアウォールと NAT ゲートウェイの状態を維持するのに十分です [RFC5382] [RFC7857]。

キープアライブ間隔の値が短いほど、クライアントとサーバーの負荷が高くなることに注意してください。さらに、トランスポートが再送信するのに必要な時間よりも短いキープアライブ値の場合、単一のパケットの損失により、サーバーが過度に熱心に接続を中止する可能性があります。たとえば、(仮定の非現実的な) 100 ミリ秒のキープアライブ間隔値は、DSO セッションを維持するために、両方向で毎秒 10 メッセージ以上の連続ストリーム (現在の輻輳制御ウィンドウで許可されている場合) になります。そして、この極端な例では、たとえば 100 ミリ秒の RTT を持つパスでの単一の再送信により、メッセージのストリームに一時的な停止が生じ、サーバーが接続を中止するのに十分な長さになります。

この懸念のため、サーバーは 10 秒未満のキープアライブ間隔値を持つ DSO Keepalive メッセージ (クライアント主導の DSO 要求に対する DSO 応答またはサーバー主導の DSO メッセージのいずれか) を送信してはなりません (MUST NOT)。クライアントが 10 秒未満のキープアライブ間隔値を指定する DSO Keepalive メッセージを受信した場合、これは致命的なエラーであり、クライアントはすぐに接続を強制的に中止しなければなりません (MUST)。

0xFFFFFFFF のキープアライブ間隔値は「無限」を表し、クライアントが DSO キープアライブトラフィックを生成すべきではないことを通知します。このようにクライアントが DSO キープアライブトラフィックを生成すべきではないことを通知した後、サーバーはいつでも、新しいセッションタイムアウト値をクライアントに指示する新しい DSO Keepalive メッセージを送信することにより、その DSO キープアライブトラフィック要件を変更できることに注意してください。

現在の Keepalive TLV でサポートされている最大の有限キープアライブ間隔は 0xFFFFFFFE (2^32-2 ミリ秒、約 49.7 日) です。

6.6. サーバー主導の DSO セッション終了

個々の長寿命操作を選択的にキャンセルすることに加えて (セクション 5.6)、サーバーが 1 つ以上の DSO セッション全体を終了する必要がある場合もあります。クライアントに何らかの欠陥がある場合、または DSO セッションを閉じずにネットワークから離脱した場合、DSO セッション全体を終了する必要がある場合があります。サーバーが過負荷になったり、再構成されたりして、どの操作をキャンセルする必要があるかを選択的に行う能力がない場合も、DSO セッションを終了する必要がある場合があります。

このセクションでは、DSO セッションが終了される可能性のあるさまざまな理由と、そのためのメカニズムについて説明します。

通常の操作では、DSO セッションを閉じるのはクライアントの責任です。クライアントは、自身のニーズとサーバーによって指示された非アクティブタイムアウト値の両方の評価に基づいて、DSO セッションをいつ閉じるかを決定します。サーバーは、以下に概説する例外的な状況でのみ、DSO セッションを終了させます。サーバーが DSO セッションを終了する可能性のある例外的な状況には、次のものがあります。

• サーバーアプリケーションソフトウェアまたは基盤となるオペレーティングシステムがシャットダウンまたは再起動している。

• サーバーアプリケーションソフトウェアが予期せず終了する (おそらくクラッシュを引き起こすバグが原因で、基盤となるオペレーティングシステムが TCP RST を送信する)。

• サーバーは再構成またはメンテナンス手順を実行しており、サーバーソフトウェアの実装方法により、クライアントを切断する必要があります。たとえば、一部のソフトウェアは起動時に構成ファイルを読み取るように実装されており、サーバーの構成を変更するには、構成ファイルを変更してからサーバーソフトウェアを強制終了して再起動する必要があり、通常はネットワーク接続が失われます。

• クライアントは、必要な DSO キープアライブトラフィックを生成するか、所定の時間 (5 秒またはサーバーによって指示された時間間隔の 2 倍のいずれか大きい方、セクション 6.2 で説明) までに非アクティブなセッションを閉じる義務を果たさない。

• クライアントは、深刻な欠陥のあるクライアント実装を示す、著しく無効または不正な形式の要求を送信する。

• サーバーの容量を超えており、負荷を軽減する必要がある。

6.6.1. サーバー主導のリトライ遅延メッセージ

サーバーが DSO セッションを終了することを選択する上記の場合、接続を強制的に中止するだけでそれを行うことができます。ただし、これを行った場合、クライアントの予想される動作は、単にこれをネットワーク障害として扱い、すぐに再接続することであり、サーバーにさらに負担をかける可能性があります。

したがって、この再接続の爆発を避けるために、サーバーは代わりに、DSO セッションを終了する必要がある理由をクライアントに通知する適切な RCODE 値を持つリトライ遅延メッセージを送信することにより、クライアントの負荷を軽減することを選択すべきです (SHOULD)。DSO Retry Delay TLV の形式とさまざまな RCODE 値の解釈については、セクション 7.2 で説明されています。DSO リトライ遅延メッセージを送信した後、サーバーはその DSO セッションでそれ以上のメッセージを送信してはなりません (MUST NOT)。

サーバーは、リトライ遅延をランダム化して、すべてのクライアントが一度に再接続しようとするのを避けることができます (MAY)。一般に、実装は、すべてのクライアントが指定された正確な時間に再接続を試みた場合に、多くのクライアントが同時に再接続する結果となるような方法で DSO リトライ遅延メッセージを使用することを避けるべきです。

サーバーから DSO リトライ遅延メッセージを受信すると、クライアントはこのサーバーの再接続遅延をメモし、すぐに接続を正常に閉じなければなりません (MUST)。

DSO リトライ遅延メッセージを送信した後、サーバーはクライアントが接続を閉じるために 5 秒間許可すべきであり (SHOULD)、クライアントが 5 秒後に接続を閉じていない場合、サーバーは接続を強制的に中止すべきです (SHOULD)。

DSO リトライ遅延メッセージは、クライアントによって開始されてはなりません (MUST NOT)。サーバーが DSO リトライ遅延メッセージを受信した場合、これは致命的なエラーであり、サーバーはすぐに接続を強制的に中止しなければなりません (MUST)。

6.6.1.1. 未処理の操作

サーバーが DSO リトライ遅延メッセージを開始することを選択した瞬間に、この DSO セッションでクライアントからサーバーへの DNS 要求がすでに送信されている可能性があり、DSO リトライ遅延メッセージが送信された後にサーバーに到着します。サーバーは、そのような着信要求を黙って無視しなければならず (MUST)、それらに対する応答メッセージを生成してはなりません (MUST NOT)。サーバーからの DSO リトライ遅延メッセージがクライアントに到着すると、クライアントは、この DSO セッションで以前に送信した応答をまだ受信していない DNS 要求は、確実に受信されなくなると判断します。

このような要求は失敗したと見なされ、必要に応じて後で再試行されるべきです。

DSO セッションの既存の操作の一部 (すべてではない) が無効になった場合 (おそらくサーバーが再構成され、一部の名前に対して権限がなくなったため)、サーバーが影響を受けるすべての DSO セッションに DSO リトライ遅延メッセージを送信して一括終了する場合、再接続遅延はゼロになる場合があり (MAY)、クライアントがすぐに操作の再確立を試みるべきであることを示します (SHOULD)。

再構成の性質によっては、試行の一部が成功し、一部が失敗する可能性があります。

サーバーが一度に多数の DSO セッションを終了している場合 (たとえば、システムが再起動している場合)、サーバーが同時の再試行の洪水に圧倒されたくない場合は、各クライアントに異なる再接続遅延値を送信すべきです (SHOULD)。これらの調整は、ランダム、疑似ランダム、または決定論的に選択される場合があります (MAY) (たとえば、連続する各クライアントの時間値を 10 分の 1 秒ずつ増やし、再起動後の再接続率を 1 秒あたり 10 クライアントにする)。

6.6.2. 不正な動作をするクライアント

サーバーは、クライアントがプロトコルに正しく従っていないと判断する場合があります。サーバーが DSO セッションを回復する方法がない場合があり、その場合、サーバーは接続を強制的に終了します。クライアントは接続が切断された理由を知らないため、すぐに再接続する可能性があります。サーバーがクライアントがプロトコルに正しく従っていないと判断した場合、DSO セッションが確立されるとすぐに終了し、クライアントがすぐに再接続しないように長いリトライ遅延を指定する場合があります (MAY)。

6.6.3. クライアントの再接続

サーバーによって DSO セッションが終了された後 (クライアントに DSO リトライ遅延メッセージを送信するか、基盤となるトランスポート接続を強制的に中止することによって)、クライアントはそのサービスインスタンス、または複数のサービスインスタンスが利用可能な場合は別の適切なサービスインスタンスに再接続を試みるべきです (SHOULD)。同じサービスインスタンスに再接続する場合、クライアントは、再接続を試みる前に、利用可能な場合は示された遅延を尊重しなければなりません (MUST)。クライアントは遅延をランダム化しようとすべきではありません (SHOULD NOT)。この動作が望ましい場合、サーバーは各クライアントに送信するリトライ遅延値をランダムにジッターさせます。

特定のサービスインスタンスが短いメンテナンス期間のみサービス停止する場合、予想されるメンテナンスウィンドウよりも少し長いリトライ遅延値を示すべきです。非常に大きな遅延値をデフォルトにすべきではありません。そうしないと、サービスが再開された後、クライアントがすぐに再接続を試みない可能性があります。

サービスインスタンスがクライアントに二度と再接続してほしくない場合 (おそらくサービスインスタンスが廃止されている場合)、リトライ遅延を最大値 0xFFFFFFFF (2^32-1 ミリ秒、約 49.7 日) に設定すべきです (SHOULD)。49.7 日以上離れるようにクライアントに指示することはできません。49.7 日後、DNS またはその他の構成情報が、これが特定のサービスの有効なサービスインスタンスであることを示している場合、クライアントは再接続を試みることができます (MAY)。実際には、クライアントが再起動したり、状態を失ったりした場合、DNS またはその他の構成情報がこれがクライアントが使用すべきサービスインスタンスであることを示し続けている限り、49.7 日が経過する前に再接続を試みる可能性があります。

6.6.3.1. 強制中止後の再接続

サーバーによる非準拠の動作により、クライアントによって接続が強制的に中止された場合、クライアントはそのサービスインスタンスを DSO をサポートしていないものとしてマークすべきです (SHOULD)。クライアントは再接続しても DSO を使用しようとしないか、該当する場合は別のサービスインスタンスに接続することができます (MAY)。

6.6.3.2. 原因不明の接続切断後の再接続

サーバーが接続を強制的に終了することも可能です。この場合、クライアントは終了がプロトコルエラーの結果なのかネットワーク停止の結果なのかわかりません。クライアントが接続が切断されたことに気付くと、すぐに再接続を試みることができます。ただし、クライアントがしようとしていることを正常に完了できずに接続が再度切断された場合、サーバーを DSO をサポートしていないものとしてマークすべきです。

6.6.3.3. 動作する DSO サポートのプローブ

サーバーがクライアントによって DSO をサポートしていないとマークされると、クライアントはしばらく時間が経過するまで、そのサーバーで DSO 操作を試みるべきではありません (SHOULD NOT)。妥当な最小値は 1 時間です。強制的に中止された接続はソフトウェアの障害の結果であるため、最初に遭遇してから最初の 1 時間以内に問題が解決される可能性は低いです。ただし、リトライ間隔を 1 時間に制限することで、クライアントはサーバーに過度の負担をかけることなく、問題がいつ修正されたかに気付くことができます。