メインコンテンツまでスキップ

7. DNS ステートフル操作の基本 TLV

このセクションでは、DNS ステートフル操作の 3 つの基本 TLV である、Keepalive、Retry Delay、および Encryption Padding について説明します。

7.1. Keepalive TLV​

Keepalive TLV (DSO-TYPE=1) は 2 つの機能を実行します。主に、セッションタイムアウトの値を確立します。ちなみに、DSO セッションのキープアライブタイマーもリセットします。つまり、セッションを存続させる目的で一種の「no-op」メッセージとして使用できます。クライアントは希望するセッションタイムアウト値を要求し、サーバーはクライアントに使用を要求する応答値で確認応答します。

Keepalive TLV をプライマリ TLV として持つ DSO メッセージは、早期データ (early data) に現れる場合があります。

Keepalive TLV の DSO-DATA は次のとおりです。

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 INACTIVITY TIMEOUT (32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 KEEPALIVE INTERVAL (32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • INACTIVITY TIMEOUT: 現在の DSO セッションの非アクティブタイムアウト。32 ビットの符号なし整数として指定され、ネットワーク（ビッグエンディアン）バイト順で、単位はミリ秒です。これは、クライアントが非アクティブな DSO セッションを閉じ始めなければならないタイムアウトです。非アクティブタイムアウトは、サーバーが選択した任意の値にすることができます。クライアントが非アクティブな DSO セッションを正常に閉じない場合、5 秒またはこの間隔の 2 倍のいずれか大きい方の後、サーバーは接続を強制的に中止します。

  • KEEPALIVE INTERVAL: 現在の DSO セッションのキープアライブ間隔。32 ビットの符号なし整数として指定され、ネットワーク（ビッグエンディアン）バイト順で、単位はミリ秒です。これは、接続状態を維持するためにクライアントが DSO キープアライブトラフィックを生成しなければならない間隔です。キープアライブ間隔は 10 秒未満であってはなりません。クライアントが義務付けられた DSO キープアライブトラフィックを生成しない場合、この間隔の 2 倍の後、サーバーは接続を強制的に中止します。許可される最小キープアライブ間隔は 10 秒であるため、義務付けられた DSO キープアライブトラフィックの生成に失敗したためにサーバーがクライアントを強制的に切断する最小時間は 20 秒です。

DSO Keepalive メッセージ（つまり、Keepalive TLV が最初の TLV であるメッセージ）の送信または受信は、キープアライブタイマーのみをリセットし、非アクティブタイマーはリセットしません。その理由は、定期的な DSO Keepalive メッセージは、DSO セッションに現在または最近の非メンテナンスアクティビティがあり、その DSO セッションを維持する価値がある場合にのみ、DSO セッションを維持する目的で送信されるためです。DSO キープアライブトラフィック自体の送信は、クライアントアクティビティとは見なされません。他のクライアントアクティビティのサービスで実行されるメンテナンスアクティビティと見なされます。DSO キープアライブトラフィック自体が非アクティブタイマーをリセットする場合、DSO セッションを維持するためにキープアライブトラフィックが無期限に送信される循環ライブロックが作成されます。このシナリオでは、その DSO セッションでの唯一のアクティビティは、さらなるキープアライブトラフィックを送信できるように DSO セッションを維持するキープアライブトラフィックです。DSO セッションがアクティブであると見なされるには、キープアライブトラフィック以上のものを伝送している必要があります。これが、単に DSO Keepalive メッセージを送信または受信しても非アクティブタイマーがリセットされない理由です。

クライアントによって送信される場合、DSO Keepalive 要求メッセージは、ゼロ以外の MESSAGE ID を持つ DSO 要求メッセージとして送信されなければなりません (MUST)。サーバーが MESSAGE ID がゼロの DSO Keepalive メッセージを受信した場合、これは致命的なエラーであり、サーバーはすぐに接続を強制的に中止しなければなりません (MUST)。DSO Keepalive 要求メッセージは、DSO セッションのキープアライブタイマーをリセットし、同時に、クライアントの要求されたセッションタイムアウト値をサーバーに伝達します。クライアント主導の DSO Keepalive 要求メッセージに対するサーバー応答では、セッションタイムアウトには、DSO セッションのこの時点以降のサーバーが選択した値が含まれており、クライアントはこれを尊重しなければなりません (MUST)。これは DHCP プロトコルをモデルにしており、クライアントは DHCP オプション 51 [RFC2132] を使用して特定のリース期間を要求しますが、実際に付与されるリース期間を決定する最終的な権限はサーバーにあります。

クライアントが 2 回目以降の DSO Keepalive 要求メッセージをサーバーに送信する場合、クライアントは毎回優先値を要求し続けるべきです (SHOULD)。これにより、DSO セッションの存続期間中に条件が変化した場合に、サーバーがクライアントのニーズによりよく適合するように応答を適応させることができる柔軟性が得られます。

DSO セッションが進行中 (セクション 5.1) になると、サーバーによって DSO Keepalive メッセージが開始される場合があります (MAY)。サーバーによって送信される場合、DSO Keepalive メッセージは、MESSAGE ID がゼロに設定された DSO 一方向メッセージとして送信されなければなりません (MUST)。クライアントは、サーバー主導の DSO Keepalive メッセージに対する応答を生成してはなりません (MUST NOT)。クライアントがゼロ以外の MESSAGE ID を持つ DSO Keepalive 要求メッセージを受信した場合、これは致命的なエラーであり、クライアントはすぐに接続を強制的に中止しなければなりません (MUST)。サーバーからの DSO Keepalive 一方向メッセージは、DSO セッションのキープアライブタイマーをリセットし、同時に、この DSO セッションでこの時点以降使用する新しいセッションタイムアウト値をクライアントに一方的に通知します。この一方的な宣言に対するクライアントの DSO 応答は必要なく、許可もされません。

DSO Keepalive 応答メッセージでは、Keepalive TLV のインスタンスが 1 つだけ存在しなければならず (MUST)、クライアントからの DSO Keepalive 要求メッセージへの返信として送信される応答プライマリ TLV としてのみ使用されます。Keepalive TLV を応答追加 TLV として他の応答に追加してはなりません (MUST NOT)。サーバーがクライアントからの DSO Keepalive 要求メッセージへの応答以外でクライアントのセッションタイムアウト値を更新したい場合は、上記のように独自の DSO Keepalive 一方向メッセージを送信することによって行います。

Keepalive TLV をすべての DSO セッションで使用する必要はありません。多くの DSO 操作は長寿命セッション状態と組み合わせて使用されますが、すべての DSO 操作が長寿命セッション状態を必要とするわけではなく、場合によっては、非アクティブタイムアウトとキープアライブ間隔の両方でデフォルトの 15 秒の値が完全に適切である可能性があります。ただし、このドキュメントで定義されている DSO-TYPE のみを実装するクライアントの場合、DSO Keepalive 要求メッセージがクライアントが DSO セッションを開始する唯一の方法であることに注意してください。

7.1.1. 受信したセッションタイムアウト値のクライアント処理​

クライアントが、クライアント主導の DSO Keepalive 要求メッセージに対する応答を受信するか、サーバー主導の DSO Keepalive 一方向メッセージを受信すると、クライアントはサーバーによって指示されたセッションタイムアウト値を受信します。サーバーからの Keepalive TLV に含まれる 2 つのタイムアウト値は、それぞれ、クライアントが以前にこの DSO セッションに対して持っていたそれぞれのセッションタイムアウト値よりも高い、低い、または同じである可能性があります。

キープアライブタイマーの場合、受信した値の処理は簡単です。DSO Keepalive TLV を含むメッセージを受信する行為自体がキープアライブタイマーをリセットし、DSO セッションのキープアライブ間隔を更新します。新しいキープアライブ間隔は、DSO セッションを存続させる場合、この DSO セッションで別のメッセージを送信または受信しなければならないまでの最大経過可能時間を示します。

非アクティブタイムアウトの場合、受信した値の処理は少し微妙ですが、非アクティブタイムアウトの意味は指定されたままです。つまり、DSO セッションで有用なアクティビティがない状態で許容される最大時間を示します。Keepalive TLV を含むメッセージを受信する行為自体は、非アクティブタイマーをリセットしません。この DSO セッションでの最後の有用なアクティビティからの経過時間は、DSO Keepalive メッセージの交換の影響を受けません。受信したメッセージの Keepalive TLV 内の新しい非アクティブタイムアウト値は、実行中の非アクティブタイマーに関連付けられたタイムアウトを更新します。それが、DSO セッションでアクティビティがない場合の新しい最大許容時間になります。

  • 現在の非アクティブタイマー値が新しい非アクティブタイムアウトよりも小さい場合、DSO セッションは今のところ開いたままにすることができます。非アクティブタイマー値が新しい非アクティブタイムアウトに達すると、クライアントは上記のように DSO セッションを閉じ始めなければなりません (MUST)。

  • 現在の非アクティブタイマー値が新しい非アクティブタイムアウトと等しい場合、この DSO セッションはサーバーが許可する時間とまったく同じ時間非アクティブであったため、クライアントはすぐにこの DSO セッションを閉じ始めなければなりません (MUST)。

  • 現在の非アクティブタイマー値がすでに新しい非アクティブタイムアウトよりも大きい場合、この DSO セッションはサーバーが許可するよりも長く非アクティブであったため、クライアントはすぐにこの DSO セッションを閉じ始めなければなりません (MUST)。

  • 現在の非アクティブタイマー値がすでに新しい非アクティブタイムアウトの 2 倍を超えている場合、クライアントはすぐに滞納していると見なされ (この DSO セッションはすぐにサーバーによって強制的に終了される資格があります)、クライアントはすぐにこの DSO セッションを閉じ始めなければなりません (MUST)。ただし、サーバーがこのように非アクティブタイムアウトを突然短縮した場合、サーバーが強制的に中止する前にクライアントが接続を正常に閉じる時間を与えるために、サーバーはクライアントに 5 秒または新しい非アクティブタイムアウトの 4 分の 1 のいずれか大きい方の追加の猶予期間を与えるべきです (SHOULD)。

7.1.2. edns-tcp-keepalive EDNS(0) オプションとの関係​

Keepalive TLV (DSO-TYPE=1) の非アクティブタイムアウト値は、edns-tcp-keepalive EDNS(0) オプション [RFC7828] と同様の意図を持っています。DSO をサポートするクライアント/サーバーペアは、DSO セッションが確立された後のいかなるメッセージ内でも edns-tcp-keepalive EDNS(0) オプションを使用してはなりません (MUST NOT)。セッションを確立するために DSO メッセージを送信したクライアントは、この時点から edns-tcp-keepalive EDNS(0) オプションを送信してはなりません (MUST NOT)。DSO セッションが確立されると、クライアントまたはサーバーが DSO セッションを介して edns-tcp-keepalive EDNS(0) オプションを含む DNS メッセージを受信した場合、これは致命的なエラーであり、edns-tcp-keepalive EDNS(0) オプションの受信者はすぐに接続を強制的に中止しなければなりません (MUST)。

7.2. Retry Delay TLV​

Retry Delay TLV (DSO-TYPE=2) は、サーバーからクライアントへのメッセージ (一方向) のプライマリ TLV として、または任意の方向の応答追加 TLV として使用できます。リレー遅延 (Relay Delay) TLV をプライマリ TLV とする DSO メッセージは、早期データ (early data) では許可されません。

Retry Delay TLV の DSO-DATA は次のとおりです。

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     RETRY DELAY (32 bits)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • RETRY DELAY: 32 ビットの符号なし整数として指定され、ネットワーク（ビッグエンディアン）バイト順で、単位はミリ秒の時間値。この時間内にイニシエーターはこの操作を再試行したり、このサーバーへの接続を再試行したりしてはなりません (MUST NOT)。RETRY DELAY 値の推奨事項は、セクション 6.6.1 に記載されています。

7.2.1. プライマリ TLV として使用される Retry Delay TLV​

DSO 一方向メッセージのプライマリ TLV として使用される場合、Retry Delay TLV はサーバーからクライアントに送信されます。これは、クライアントに DSO セッションと基盤となる接続を閉じ、指定された時間間隔の間再接続しないように指示するためにサーバーによって使用されます。

この場合、それは DSO セッション全体に適用され、クライアントはセクション 6.6.1 で説明されているように DSO セッションを閉じ始めなければなりません (MUST)。メッセージヘッダーの RCODE は、終了の主な理由を示すべきです (SHOULD)。

  • NOERROR は、定期的なシャットダウンまたは再起動を示します。

  • FORMERR は、クライアント DSO 要求がひどく不正な形式であったため、セッションを続行できないことを示します。

  • SERVFAIL は、リソースの枯渇によりサーバーが過負荷になっており、負荷を軽減する必要があることを示します。

  • REFUSED は、サーバーが再構成されており、現時点で、以前にこの DSO セッションで実行されていた 1 つ以上の長寿命クライアント操作を実行できないことを示します。

  • NOTAUTH は、サーバーが再構成されており、現時点で、問題の名前に対する権限がないため、以前にこの DSO セッションで実行されていた 1 つ以上の長寿命クライアント操作を実行できないことを示します (たとえば、DNS プッシュ通知サーバーが再構成され、現在サブスクライブされている 1 つ以上の名前に対する DNS プッシュ通知要求を受け入れなくなる可能性があります)。

このドキュメントでは、DSO リトライ遅延メッセージに対してこれらの RCODE 値のみを指定しています。DSO リトライ遅延メッセージを送信するサーバーは、これらの値のいずれかを使用すべきです (SHOULD)。ただし、将来の状況により、DSO リトライ遅延メッセージで他の RCODE 値が適切になる状況が生じる可能性があるため、クライアントは任意の RCODE 値を持つ DSO リトライ遅延メッセージを受け入れる準備をしておく必要があります (MUST)。

場合によっては、サーバーが DSO リトライ遅延一方向メッセージをクライアントに送信するときに、サーバーがセッションを終了したい理由が複数ある場合があります。おそらく、構成が変更され、ポリシー (REFUSED) により一部の長寿命クライアント操作を継続できなくなり、サーバーがそれらの名前に対して権限を持たなくなった (NOTAUTH) ために他の長寿命クライアント操作を実行できなくなった可能性があります。そのような場合、サーバーは該当する RCODE 値のいずれか、または RCODE=NOERROR (定期的なシャットダウンまたは再起動) を使用できます (MAY)。

DSO リトライ遅延メッセージでの RCODE 値の選択は重要ではないことに注意してください。RCODE 値は通常、切断の性質に関する将来の人間による分析のためにログファイルに書き込むなど、情報提供の目的でのみ使用されるためです。通常、クライアントは RCODE 値に応じて動作を変更しません。メッセージ内の RETRY DELAY は、このサービスインスタンスへの接続を試みる前にどれくらい待つべきかをクライアントに伝えます。

RCODE 値に応じて何らかの方法で動作を変更するクライアントの場合、不明な RCODE 値を RCODE=NOERROR (定期的なシャットダウンまたは再起動) と同じように扱うべきです (SHOULD)。

サーバーからクライアントへの DSO リトライ遅延メッセージ (プライマリ TLV が Retry Delay である DSO メッセージ) は DSO 一方向メッセージです。送信メッセージでは MESSAGE ID をゼロに設定しなければならず (MUST)、クライアントは応答を送信してはなりません (MUST NOT)。

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

7.2.2. 応答追加 TLV として使用される Retry Delay TLV​

ゼロ以外の RCODE 値をもたらす DSO 要求メッセージの場合、レスポンダーは応答に Retry Delay TLV を追加して (MAY)、イニシエーターがこの操作を再度試行すべきではない時間間隔を示すことができます (SHOULD NOT)。

イニシエーターが再試行すべきではない示された時間間隔は、DSO セッション全体ではなく、失敗した操作にのみ適用されます。

特定の DSO 要求メッセージのレスポンダーの役割を果たしているクライアントまたはサーバーのいずれかが、送信するエラー応答に Retry Delay TLV を追加できます (MAY)。

7.3. Encryption Padding TLV​

Encryption Padding TLV (DSO-TYPE=3) は、追加または応答追加 TLV としてのみ使用できます。DSO トランスポート層が TLS などの暗号化を使用する場合にのみ適用されます。

Padding TLV の DSO-DATA はオプションであり、指定されていない値を含む可変長フィールドです。DSO-LENGTH が 0 の場合、基本的に 4 バイトのパディング (最小量) が提供されます。

                                             1   1   1   1   1   1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                                                               |
   /              PADDING -- VARIABLE NUMBER OF BYTES              /
   /                                                               /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

EDNS(0) Padding オプション [RFC7830] で指定されているように、PADDING バイトは 0x00 に設定すべきです (SHOULD)。たとえば、暗号化の前にパディングされたメッセージが圧縮される可能性があるという懸念がある場合など、他の値を使用できます (MAY)。任意の値の PADDING バイトは、受信したメッセージで受け入れられなければなりません (MUST)。

Encryption Padding TLV は、DSO 要求メッセージ、応答、またはその両方に含めることができます。EDNS(0) Padding オプション [RFC7830] で指定されているように、Encryption Padding TLV を含む DSO 要求メッセージを受信した場合、DSO 応答にも Encryption Padding TLV を含めなければなりません (MUST)。

パディングの長さは、このドキュメントでは意図的に指定されておらず、先行する TLV のデータのタイプと長さに関する現在のベストプラクティスの関数です [RFC8467]。

に最終更新