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

5. プロトコルの詳細 (Protocol Details)

DNS Stateful Operations (DNSステートフル操作) の全体的な流れは、一連のフェーズを経ます:

接続確立 (Connection Establishment): クライアントがサーバーへの接続を確立します (セクション 4.2)。

接続済みだがセッションレス (Connected but Sessionless): 接続は存在するが、DSOセッションは確立されていません。クライアントからサーバーへDNSメッセージを送信でき、サーバーからクライアントへDNS応答を送信できます。この状態では、DSOを使用したいクライアントはDSOセッションの確立を試みることができます (セクション 5.1)。標準のDNS-over-TCP非アクティブタイムアウト処理が有効です [RFC7766] (本文書のセクション 7.1.2 を参照)。

DSOセッション確立中 (DSO Session Establishment in Progress): クライアントが過去30秒以内にDSO要求を送信したが、その要求に対するDSO応答をまだ受信していません。このフェーズでは、クライアントはさらにDSO要求およびDNS要求を送信できますが、DSO単方向メッセージを送信してはなりません (MUST NOT) (セクション 5.1)。

DSOセッション確立タイムアウト: クライアントがDSO要求を送信し、30秒後もその要求に対するDSO応答を受信していません。これは、サーバーが現在不確定な状態にあることを意味します。クライアントは接続を強制的に中断します。クライアントは、適切な場合、DSOを使用せずに再接続してもかまいません (MAY)。

DSOセッション確立失敗 (DSO Session Establishment Failed): クライアントがDSO要求を送信し、ゼロでないRCODEを持つ対応するDSO応答を受信しました。これは、DSOセッションを確立する試みが成功しなかったことを意味します。この時点で、クライアントはDSOセッションなし (接続済みだがセッションレス) で動作を続けることが許可されますが、それ以上のDSOメッセージは送信しません (セクション 5.1)。

DSOセッション確立済み (DSO Session Established): クライアントがDSO要求を送信し、RCODEがNOERROR (0) に設定された対応するDSO応答を受信しました。DSOセッションが正常に確立されました。クライアントとサーバーの両方がDSOメッセージとDNSメッセージを送信でき、両方が受信したメッセージに応答して応答を送信できます (セクション 5.2)。非アクティブタイマー (セクション 6.4) がアクティブです; キープアライブタイマー (セクション 6.5) がアクティブです。標準のDNS-over-TCP非アクティブタイムアウト処理はもはや有効ではありません [RFC7766] (本文書のセクション 7.1.2 を参照)。

サーバーシャットダウン (Server Shutdown): サーバーがセッションを正常に終了することを決定し、クライアントにRetry Delayメッセージを送信しました (セクション 6.6.1)。クライアントからの未処理メッセージがまだ存在する可能性がありますが、サーバーはそれらを無視します。サーバーはクライアントにこれ以上メッセージを送信しません (セクション 6.6.1.1)。

クライアントシャットダウン (Client Shutdown): クライアントが切断を決定しました。これは、サービスが不要になったため、接続が非アクティブであるため (セクション 6.4.1)、またはサーバーからRetry Delayメッセージを受信したため (セクション 6.6.1) です。クライアントは接続を正常に閉じます (セクション 5.3)。

再接続 (Reconnect): クライアントがサーバーシャットダウンの結果として切断されました。クライアントは、サーバーが指定したRetry Delayの期限切れを待つ (セクション 6.6.3) か、別のサーバーインスタンスに接続します。クライアントがサービスを必要としなくなった場合、再接続しません。

強制中断 (Forcibly Abort): クライアントまたはサーバーがプロトコルエラーを検出し、さらなる通信は未定義の動作になります。クライアントまたはサーバーが接続を強制的に中断します (セクション 5.3)。

中断後再接続待機 (Abort Reconnect Wait): クライアントが接続を強制的に中断したが、まだサービスが必要です。または、サーバーが接続を強制的に中断したが、クライアントはまだサービスが必要です。クライアントは別のサービスインスタンスに接続する (セクション 9.1) か、再接続を待ちます (セクション 6.6.3.1)。

5.1. DSOセッション確立 (DSO Session Establishment)​

クライアントとサーバー間でセッションを確立するには、クライアントはまず適用可能なトランスポートを使用してサーバーへの接続を確立する必要があります (セクション 4.2 を参照)。

一部の環境では、クライアントとサーバーの両方がDSOをサポートすることが外部手段によって事前に知られている可能性があり、これらの場合、クライアントまたはサーバーのいずれかがいつでもDSOメッセージを開始できます。この場合、セッションは接続が確立されるとすぐに確立されます。これは暗黙的なDSOセッション確立と呼ばれます。

ただし、一般的なケースでは、サーバーはクライアントがDSOをサポートするかどうかを事前に知りません。したがって、一般的には、クライアントがDSOをサポートすることが他の手段によって事前に知られていない限り、サーバーは、以下で説明するように、クライアントによって開始された少なくとも1つの成功したDSO要求/応答交換によってDSOセッションが相互に確立されるまで、DSO要求メッセージまたはDSO単方向メッセージを開始してはなりません (MUST NOT)。これは明示的なDSOセッション確立と呼ばれます。

DSOセッションが暗黙的または明示的に確立されるまで、クライアントはDSO単方向メッセージを開始してはなりません (MUST NOT)。

DSOセッションは、クライアントがDSO Keepalive要求メッセージ (セクション 7.1) などのDSO要求メッセージを送信し、一致するMESSAGE IDを持ち、RCODEがNOERROR (0) に設定された応答を受信することで、接続上に確立されます。これは、DSO要求が成功したことを示します。

一部のDSOメッセージは早期データとして許可されています (セクション 11.1)。他のものは許可されていません。単方向メッセージは、暗黙的なDSOセッションが存在しない限り、早期データとして決して許可されません。

サーバーが早期データ内で主要TLVが早期データに現れることが許可されていないDSOメッセージを受信した場合、サーバーは接続を強制的に中断しなければなりません (MUST)。クライアントが早期データ内でDSOメッセージを受信し、暗黙的なDSOセッションが存在しない場合、クライアントは接続を強制的に中断しなければなりません (MUST)。これはTLS接続でのみ強制できます。したがって、サーバーはTLSを必要としない接続を待機するときにTCP Fast Open (TFO) を有効にしてはなりません (MUST NOT)。

5.1.1. DSOセッション確立の失敗​

応答RCODEがNOTIMP (4) に設定されている場合、または実際にはNOERROR (0) またはDSOTYPENI (以下で定義) 以外の値に設定されている場合、クライアントはサーバーがDSOを全く実装していないと仮定しなければなりません (MUST)。この場合、クライアントはその接続でDNSメッセージを送信し続けることが許可されますが、その接続でさらにDSOメッセージを発行してはなりません (MUST NOT)。

応答のRCODEがDSOTYPENI ("DSO-TYPE Not Implemented"; RCODE 11) に設定されている場合、これはサーバーがDSOをサポートしているが、このDSO要求メッセージの主要TLVのDSO-TYPEを実装していないことを示します。DSOを実装するサーバーは、DSO Keepalive要求メッセージに対してDSOTYPENIを返してはなりません (MUST NOT)。Keepalive TLVは実装が必須であるためです。しかし、将来、クライアントがサーバーが理解しない新しく定義されたDSO-TYPEを使用する応答が必要なDSO要求メッセージを使用してDSOセッションを確立しようとした場合、それはDSOTYPENI応答になります。サーバーがDSOTYPENIを返す場合、DSOセッションは確立されたとは見なされません。ただし、クライアントは接続でDNSメッセージを送信し続けることが許可されており、DSO Keepaliveなどの他のDSOメッセージを含め、それが成功したNOERROR応答をもたらし、DSOセッションの確立を生じさせる可能性があります。

DSO OPCODEを認識しない既存のDNSサーバーによってDSOメッセージが受信されると、他に2つの可能な結果が存在します:サーバーがDSOメッセージに応答を送信しない可能性がある、またはサーバーが接続を切断する可能性があります。

サーバーがDSOメッセージに応答を送信しない場合、クライアントは30秒待つべきです (SHOULD)。その後、サーバーがDSOをサポートしていないと仮定されます。サーバーが30秒以内に応答しない場合、応答しないと仮定できます。これにより、サーバーは不特定の状態になります:未知のメッセージに応答を送信することを要求する仕様はありませんが、応答が送信されない場合にサーバーがどの状態にあるかを述べる仕様もありません。したがって、クライアントはサーバーへの接続を強制的に中断しなければなりません (MUST)。クライアントは、適切な場合、DSOを使用せずに再接続してもかまいません (MAY) (セクション 6.6.3.1)。切断して再接続することにより、クライアントは後続の要求を送信する前にサーバーが既知の状態にあることを保証します。

サーバーが接続を切断する場合、クライアントはそのサービスインスタンスをDSOをサポートしていないとしてマークし、失敗した試行後一定期間 (少なくとも1時間) DSO接続を試みないべきです (SHOULD)。クライアントは、適切な場合、DSOを使用せずに再接続してもかまいません (MAY) (セクション 6.6.3.2)。

5.1.2. DSOセッション確立の成功​

サーバーがクライアントからDSO要求メッセージを受信し、その要求に対して成功したNOERROR応答を送信すると、サーバーはDSOセッションが確立されたと見なします。

クライアントがそのDSO要求メッセージに対するサーバーのNOERROR応答を受信すると、クライアントはDSOセッションが確立されたと見なします。

DSOセッションが確立されると、いずれかの端はいつでも一方的に適切なDSOメッセージを送信でき、したがってクライアントまたはサーバーのいずれかがメッセージの開始者になることができます。

5.2. DSOセッション確立後の操作 (Operations after DSO Session Establishment)​

DSOセッションが確立されると、クライアントとサーバーは、非アクティブタイムアウトとセッション終了に関して、以前にDNS-over-TCPの以前の仕様で規定されていたようにではなく、この仕様で説明されているように動作すべきです [RFC7766]。

DNS Stateful Operationsをサポートするサーバーは、Keepalive TLV DSO要求メッセージを受信したときに "NOERROR" のRCODEを返さなければならない (MUST) ため、Keepalive TLVはDSOセッションを確立する際に使用する理想的な候補です。目的のタイプのサーバーに送信された場合にのみ成功できる他のオプションも、DSOセッションを確立する際に使用する良い候補です。この基本仕様で定義されたDSO-TYPEのみを実装するクライアントの場合、Keepalive TLVを送信することがDSOセッションを開始するために利用可能な唯一のDSO要求メッセージです。他の将来のDSO-TYPEを実装するクライアントであっても、簡単にするために、DSOセッションを開始する方法として常に初期DSO Keepalive要求メッセージを送信することを選択してもかまいません (MAY)。新しい応答が必要なDSO-TYPEの将来の定義は、実装者が希望する場合にその新しいDSO-TYPEを使用するオプションを提供しますが、Keepalive TLVを送信することがDSOセッションを開始する有効な方法であり続けるという事実は変わりません。

5.3. DSOセッション終了 (DSO Session Termination)​

DSOセッションは、基礎となる接続が閉じられると終了します。DSOセッションは、サーバーが過負荷であるためDSOセッションを閉じる、クライアントが完了したためDSOセッションを閉じる、またはクライアントが非アクティブであるためDSOセッションを閉じる結果として "正常に閉じられ" ます。DSOセッションは、クライアントまたはサーバーがプロトコルエラーのために接続を閉じるときに "強制的に中断" されます。

  • この仕様が "正常に閉じる" と言う場合、TLS close_notify (TLSが使用されている場合) の送信、続いてTCP FIN、または他のプロトコルの同等のものを意味します。この仕様が接続を正常に閉じることを要求する場合、その正常な閉鎖を開始する要件はクライアントに課せられ、TCPのTIME-WAIT状態の負担をサーバーではなくクライアントに置きます。

  • この仕様が "強制的に中断" と言う場合、TCP RSTまたは他のプロトコルの同等のものを送信することを意味します。BSD Sockets APIでは、これはソケットを閉じる前にSO_LINGERオプションをゼロに設定することによって達成されます。

5.3.1. プロトコルエラーの処理 (Handling Protocol Errors)​

プロトコル実装では、一般的にソフトウェア開発者が対処しなければならない2種類のエラーがあります。最初のものは、一時的な接続喪失など、環境の要因によって生じる状況です。望ましくないものの、これらの状況はソフトウェアの欠陥を示すものではなく、ソフトウェアが一般的に回復できるはずの状況です。

2番目は、準拠したDSO実装と通信するときに決して発生すべきではない状況です。それらが発生する場合、ソフトウェアが回復することが合理的に期待されるものを超えて、プロトコル実装の深刻な欠陥を示します。この文書は、このタイプのエラー条件を "致命的エラー" として説明し、致命的エラー条件に遭遇した実装は "直ちに接続を強制的に中断しなければならない (MUST)" と規定しています。

5.4. メッセージフォーマット (Message Format)​

DSOメッセージは、OPCODEフィールドがDSO OPCODE (6) に設定された標準の12バイトDNSメッセージヘッダー [RFC1035] で始まります。ただし、標準のDNSメッセージとは異なり、質問セクション、回答セクション、権威レコードセクション、および追加レコードセクションは存在しません。対応するカウントフィールド (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) は、送信時にゼロに設定されなければなりません (MUST)。

いずれかのカウントフィールドがゼロでないDSOメッセージが受信された場合、FORMERRを返さなければなりません (MUST)。

                                             1   1   1   1   1   1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                          MESSAGE ID                           |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |QR |  OPCODE (6)   |            Z              |     RCODE     |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                     QDCOUNT (MUST be zero)                    |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                     ANCOUNT (MUST be zero)                    |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                     NSCOUNT (MUST be zero)                    |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                     ARCOUNT (MUST be zero)                    |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                                                               |
   /                           DSO Data                            /
   /                                                               /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

5.4.1. DSOメッセージのDNSヘッダーフィールド (DNS Header Fields in DSO Messages)​

DSO単方向メッセージでは、MESSAGE IDフィールドをゼロに設定しなければなりません (MUST)。DSO要求メッセージでは、MESSAGE IDフィールドを、開始者がこの接続で現在他のアクティブな操作に使用していない一意の非ゼロ値に設定しなければなりません (MUST)。ここでの目的のために、MESSAGE IDは、開始者がまだ応答を待っているDSO要求メッセージで使用した場合、またはクライアントがまだキャンセルされていない長期操作を設定するために使用した場合、このDSOセッションで使用中です。たとえば、長期操作はプッシュ通知サブスクリプション [Push] またはDiscovery Relayインターフェイスサブスクリプション [Relay] である可能性があります。

メッセージがDSO要求メッセージであるかDSO単方向メッセージであるかは、主要TLVの仕様によってのみ決定されます。主要TLVに従って単方向であることが要求されるメッセージに非ゼロのMESSAGE IDを含めることによって確認応答を要求することはできません。主要TLVに従ってDSO要求メッセージであることが要求されるメッセージにゼロのMESSAGE IDを送信することによって確認応答を防ぐこともできません。そのような不正なメッセージを受信したレスポンダーは、それを致命的エラーとして扱い、直ちに接続を強制的に中断しなければなりません (MUST)。

DSO要求メッセージまたはDSO単方向メッセージでは、DNSヘッダーのQuery/Response (QR) ビットはゼロでなければなりません (MUST) (QR=0)。QRビットがゼロでない場合、メッセージはDSO要求またはDSO単方向メッセージではありません。

DSO応答メッセージでは、DNSヘッダーのQRビットは1でなければなりません (MUST) (QR=1)。QRビットが1でない場合、メッセージはDSO応答メッセージではありません。

DSO応答メッセージ (QR=1) では、MESSAGE IDフィールドはゼロであってはならず (MUST NOT)、応答されているDSO要求メッセージの (非ゼロの) MESSAGE IDフィールドの値のコピーを含まなければなりません (MUST)。MESSAGE IDがゼロであるDSO応答メッセージ (QR=1) が受信された場合、これは致命的エラーであり、受信者は直ちに接続を強制的に中断しなければなりません (MUST)。

DNSヘッダーのOPCODEフィールドはDSO OPCODE値 (6) を保持します。

Zビットは現在DSOメッセージでは未使用です。DSO要求メッセージとDSO応答の両方で、Zビットは送信時にゼロ (0) に設定されなければならず (MUST)、受信時に無視されなければなりません (MUST)。

DSO要求メッセージ (QR=0) では、RCODEは要求の定義に従って設定されます。たとえば、Retry Delayメッセージ (セクション 6.6.1) では、RCODEは終了の理由を示します。ただし、ほとんどのDSO要求メッセージ (QR=0) では、明確に別途指定されていない限り、RCODEは送信時にゼロに設定され、受信時に黙って無視されます。

応答メッセージ (QR=1) のRCODE値は、次の値のいずれかになります:

コードニーモニック説明
0NOERROR操作が正常に処理されました
1FORMERRフォーマットエラー
2SERVFAILサーバーがサーバーの問題によりDSO要求メッセージを処理できませんでした
4NOTIMPDSOはサポートされていません
5REFUSEDポリシー上の理由で操作が拒否されました
11DSOTYPENI主要TLVのDSO-Typeは実装されていません

上記のRCODEの使用はDSOで一般的である可能性が高いですが、DSOを使用する将来の文書で他のコードの定義と使用を妨げるものではありません。

新しいDSO-TYPEを定義するドキュメントがここで定義されていない応答コードを使用する場合、そのドキュメントはその新しいDSO TLVのコンテキストでそれらのRCODE値の特定の解釈を指定しなければなりません (MUST)。

RCODEフィールドの後には、4つのゼロ値のカウントフィールドが続き、その後にDSOデータが続きます。

5.4.2. DSOデータ (DSO Data)​

ゼロ値のカウントフィールドを持つ標準の12バイトDNSメッセージヘッダーの後に、セクション 5.4.4 で説明されているTLV構文を使用して表現されたDSOデータが続きます。

DSO要求メッセージまたはDSO単方向メッセージには、少なくとも1つのTLVを含まなければなりません (MUST)。DSO要求メッセージまたはDSO単方向メッセージの最初のTLVは "主要TLV" と呼ばれ、実行される操作の性質を決定します。これには、それがDSO要求であるか単方向DSO操作であるかが含まれます。場合によっては、DSO Encryption Padding TLV (セクション 7.3) など、DSO要求メッセージまたはDSO単方向メッセージに他のTLVを含めることが適切な場合があります。追加のTLVは主要TLVの後に続きます。追加のTLVはこの文書で定義されているものに限定されません。新しい追加TLVは将来定義される可能性があります。それらの定義は、その使用が適切である場合を説明します。

認識されない主要TLVは、DSOTYPENIエラー応答をもたらします。認識されない追加TLVは、セクション 5.4.5 および 8.2 で説明されているように、黙って無視されます。

DSO応答メッセージにはTLVが含まれない場合もあれば、通信される情報に適した1つ以上のTLVが含まれる場合もあります。

対応するDSO要求メッセージの主要TLVと同じDSO-TYPEを持つTLVは応答主要TLVであり、DSO応答メッセージで最初に現れなければなりません (MUST)。DSO応答メッセージには、複数の応答主要TLV、単一の応答主要TLV、または場合によっては応答主要TLVが含まれない場合があります。応答主要TLVは必須ではありません。ほとんどのDSO操作では、DNSメッセージヘッダーのMESSAGE IDフィールドは、特定の応答メッセージが関連するDSO要求メッセージを識別するのに十分です。

DSO応答メッセージの他のTLVは、DSO Encryption Padding TLV (セクション 7.3) などの応答追加TLVです。応答追加TLVは、存在する場合、応答主要TLVの後に続きます。応答追加TLVはこの文書で定義されているものに限定されません。新しい応答追加TLVは将来定義される可能性があります。それらの定義は、その使用が適切である場合を説明します。認識されない応答追加TLVは、セクション 5.4.5 および 8.2 で説明されているように、黙って無視されます。

各DSO TLVの仕様は、そのTLVを使用するDSO要求メッセージへの応答に必要なTLVを決定します。仕様が応答に特定のTLVまたはTLVを運ぶことを要求する操作に対してDSO応答が受信され、必要なTLVが存在しない場合、これは致命的エラーであり、欠陥のある応答メッセージの受信者は直ちに接続を強制的に中断しなければなりません (MUST)。同様に、指定された数以上の特定のTLVのインスタンスが存在する場合、これは致命的エラーであり、欠陥のある応答メッセージの受信者は直ちに接続を強制的に中断しなければなりません (MUST)。

5.4.3. DSO単方向メッセージ (DSO Unidirectional Messages)​

ほとんどのDSO操作は、対応するDSO応答を生成するDSO要求メッセージを使用するように指定されることが予想されます。一部の特殊な高トラフィックの使用例では、DSO単方向メッセージを指定することが適切な場合があります。DSO単方向メッセージは、対応する応答メッセージのストリームを生成しないため、ネットワーク上でより効率的です。DSO単方向メッセージの使用は、開始者が気にしない応答を受信するのを待つ間に状態を維持する必要性を排除することで、場合によってはソフトウェアを簡素化することもできます。発信DSO要求メッセージ (すなわち、QR=0) の主要TLV (すなわち、最初) として使用される特定のTLVの仕様が、メッセージが単方向であるべきであると述べている場合、MESSAGE IDフィールドをゼロに設定しなければならず (MUST)、受信者はそのDSO単方向メッセージに対応する応答メッセージを生成してはなりません (MUST NOT)。

受信者がDSO単方向メッセージに対する応答を生成してはならない (MUST NOT) という前述の点は、エラーの場合でも適用されます。

QRビットとMESSAGE IDフィールドの両方がゼロであるDSOメッセージが受信された場合、受信者は応答を生成してはなりません (MUST NOT)。たとえば、主要TLVのDSO-TYPEが認識されない場合、DSOTYPENIエラーを返してはなりません (MUST NOT)。代わりに、受信者は直ちに接続を強制的に中断しなければなりません (MUST)。

DSO単方向メッセージは、送信者が受信者がメッセージの主要TLVをサポートするかどうかを知らない場合に "投機的に" 使用してはなりません (MUST NOT)。成功または失敗を示す応答を受信する方法がないためです。DSO単方向メッセージは、送信者が受信者がこれらのメッセージをサポートし、受信したいと既に知っている場合にのみ適切です。

たとえば、クライアントがプッシュ通知 [Push] をサブスクライブした後、その後のイベント通知はDSO単方向メッセージとして送信されます。これは、クライアントがプッシュ通知サブスクリプションによってメッセージストリームを開始したため、プッシュ通知のサポートとそれらの通知を受信したいという意思を示しているため、適切です。

同様に、Discovery RelayクライアントがDiscovery Relayから着信マルチキャストDNS (mDNS) [RFC6762] トラフィックを受信するようにサブスクライブした後、受信したパケットの後続のストリームはDSO単方向メッセージを使用して送信されます。これは、クライアントがDiscovery Relayリンクサブスクリプションによってメッセージストリームを開始したため、Discovery RelayのサポートとそのDSOセッション [Relay] で着信mDNSパケットを受信したいという意思を示しているため、適切です。

5.4.4. TLV構文 (TLV Syntax)​

すべてのTLVは、"主要"、"追加"、"応答主要"、または "応答追加" として使用されるかどうかにかかわらず、同じエンコーディング構文を使用します。

新しいTLVを定義する仕様は、DSO-TYPEを主要TLVとして使用できるかどうか、およびDSO-TYPEを追加TLVとして使用できるかどうかを指定する必要があります。一部のDSO-TYPEは二重目的であり、一部のメッセージでは主要TLVとして使用でき、他のメッセージでは追加TLVとして使用できます。DSO-TYPEの仕様は、DSOメッセージ (すなわち、QR=0) の主要 (すなわち、最初) TLVとして使用される場合、そのDSOメッセージが単方向であるか、応答を必要とするDSO要求メッセージであるかも述べる必要があります。

DSO要求メッセージが応答を必要とする場合、仕様は応答に含めるべきTLV (ある場合) と、各TLVの許可されるインスタンス数も述べる必要があります。主要TLVは、そのTLVに指定されているものに応じて、応答に含まれる場合と含まれない場合があります。主要TLVの複数のインスタンスが許可される場合、仕様はそれらをどのように処理すべきかを明確に説明する必要があります。

                                             1   1   1   1   1   1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                           DSO-TYPE                            |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                          DSO-LENGTH                           |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                                                               |
   /                           DSO-DATA                            /
   /                                                               /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

DSO-TYPE: IANAの "DSO Type Codes" レジストリに従って現在のDSO TLVのDSO-TYPEを提供する、ネットワーク (ビッグエンディアン) バイトオーダーの16ビット符号なし整数。

DSO-LENGTH: DSO-DATAのバイト単位のサイズを提供する、ネットワーク (ビッグエンディアン) バイトオーダーの16ビット符号なし整数。

DSO-DATA: タイプコード固有のフォーマット。汎用DSOメカニズムは、DSO-DATAを解釈しようとせずに不透明な "ブロブ" として扱います。特定のDSO-TYPEのDSO-DATAの意味の解釈は、そのDSO-TYPEを実装するソフトウェアの責任です。

5.4.5. 認識されないTLV (Unrecognized TLVs)​

認識されない主要TLVを含み、非ゼロのMESSAGE ID (応答が期待されることを示す) を持つDSO要求メッセージが受信された場合、受信者は一致するMESSAGE IDとRCODE DSOTYPENIを持つエラー応答を送信しなければなりません (MUST)。エラー応答には、認識されない主要TLVのコピーを含めてはなりません (MUST NOT)。

認識されない主要TLVとゼロのMESSAGE ID (応答が期待されないことを示す) の両方を含むDSO単方向メッセージが受信された場合、これは致命的エラーであり、受信者は直ちに接続を強制的に中断しなければなりません (MUST)。

主要TLVが認識され、1つ以上の認識されない追加TLVを含むDSO要求メッセージまたはDSO単方向メッセージが受信された場合、認識されない追加TLVは黙って無視されなければならず (MUST)、メッセージの残りの部分は認識されない部分が存在しないかのように解釈および処理されます。

同様に、1つ以上の認識されないTLVを含むDSO応答メッセージが受信された場合、認識されないTLVは黙って無視されなければならず (MUST)、メッセージの残りの部分は認識されない部分が存在しないかのように解釈および処理されます。

5.4.6. EDNS(0) と TSIG​

ARCOUNTフィールドはゼロでなければならない (MUST) ため、DSOメッセージには追加レコードセクションに有効なEDNS(0) オプションを含めることができません。DSOメッセージに現在または将来のEDNS(0) オプションによって提供される機能が必要な場合、必要な情報を運ぶために1つ以上の新しいDSO TLVを定義する必要があります。

たとえば、セキュリティ目的で使用されるEDNS(0) Padding Option [RFC7830] はDSOメッセージでは許可されていないため、DSOメッセージにメッセージパディングが必要な場合は、セクション 7.3 で説明されているDSO Encryption Padding TLVを使用しなければなりません (MUST)。

DSOメッセージにはTSIGレコードを含めることができません。TSIGレコードはメッセージの追加セクションに含まれるためです。つまり、ARCOUNTがゼロより大きくなります。DSOメッセージはARCOUNTがゼロである必要があります。したがって、将来DSOメッセージで署名の使用が必要になった場合、この機能を実行するために新しいDSO TLVを定義する必要があります。

ただし、DSO メッセージ にはEDNS(0) またはTSIGレコードを含めることができませんが、DSO セッション は通常、DSOメッセージやQuery [RFC1034] [RFC1035] およびUpdate [RFC2136] などの他のDNSメッセージタイプを含むさまざまな種類のDNSメッセージ全体を運ぶために使用されます。これらのメッセージにはEDNS(0) およびTSIGレコードを含めることができます。

メッセージには適切な他のEDNS(0) オプションを含めることができますが、この仕様はDSOセッションで送信される すべての メッセージでのedns-tcp-keepalive EDNS(0) Option [RFC7828] の使用を明示的に禁止しています (DSO Keepalive操作によって提供される機能によって廃止されているため)。DSOセッションで送信されたメッセージにedns-tcp-keepalive EDNS(0) Optionが含まれている場合、これは致命的エラーであり、欠陥のあるメッセージの受信者は直ちに接続を強制的に中断しなければなりません (MUST)。

5.5. メッセージ処理 (Message Handling)​

セクション 5.4.1 で説明されているように、DNSヘッダーのQRビットがゼロに設定された発信DSOメッセージがDSO要求であるかDSO単方向メッセージであるかは、主要TLVの仕様によって決定され、それによってその発信メッセージのMESSAGE IDフィールドがゼロか非ゼロかが決定されます。

DNSヘッダーのQRビットがゼロに設定され、MESSAGE IDフィールドが非ゼロであるすべてのDSOメッセージはDSO要求メッセージであり、対応する応答を引き出さなければならず (MUST)、DNSヘッダーのQRビットが1に設定され、MESSAGE IDフィールドが対応するDSO要求メッセージで指定された値に設定されます。

クライアントによって送信された非ゼロのMESSAGE IDフィールドを持つ有効なDSO要求メッセージはサーバーからの応答を引き出し、サーバーによって送信された非ゼロのMESSAGE IDフィールドを持つ有効なDSO要求メッセージはクライアントからの応答を引き出します。

DNSヘッダーのQRビットとMESSAGE IDフィールドの両方がゼロに設定されたすべてのDSOメッセージはDSO単方向メッセージであり、応答を引き出してはなりません (MUST NOT)。

5.5.1. 遅延確認応答管理 (Delayed Acknowledgement Management)​

一般的に、ほとんどの優れたTCP実装は、ネットワークのより効率的な使用とより良いパフォーマンスを提供するために遅延確認応答タイマーを使用します。

DSO要求メッセージなどのTCP上の双方向交換では、オペレーティングシステムのTCP実装は、アプリケーション層クライアントソフトウェアが対応するDSO応答メッセージを生成するのを待ちます。TCP実装は、TCP確認応答、TCPウィンドウ更新、およびアプリケーションが生成したDSO応答メッセージを含む単一の結合パケットを送信できます。これは、DSO要求を含むTCPパケットが直ちに確認応答された場合に発生するであろう3つの別個のパケットを送信するよりも効率的です。

DSO単方向メッセージまたはDSO応答メッセージでは、対応するアプリケーションが生成したDSO応答メッセージがなく、したがって、トランスポートプロトコルに確認応答とウィンドウ更新をいつ送信すべきかについてのヒントがありません。

一部のネットワーキングAPIは、アプリケーション層クライアントソフトウェアが応答が来ないことをトランスポートプロトコルに通知できるメカニズムを提供します (実際には、ゼロ長の "空の" 書き込みと考えることができます)。使用されるネットワーキングAPIで利用可能な場合、DSO単方向メッセージまたはDSO応答メッセージの受信者は、メッセージを解析および解釈した後、このメッセージに対する応答が来ないことを通知するために、ネットワーキングAPIによって提供されるこのメカニズムを使用すべきです (SHOULD)。TCP実装は、それ以上遅延することなく確認応答とウィンドウ更新を送信できます。これが重要である理由のさらなる議論については、セクション 9.5 を参照してください。

5.5.2. MESSAGE ID名前空間 (MESSAGE ID Namespaces)​

16ビットMESSAGE IDの名前空間は各方向で独立しています。これは、クライアントとサーバーが同時に、異なる方向で同じMESSAGE IDを使用してDSO要求メッセージを送信することはエラーで ない ことを意味します。この簡略化は、プロトコルが実装可能であるために必要です。クライアントとサーバーが新しい一意のMESSAGE IDの割り当てに関して互いに調整することを要求することは実行不可能です。クライアントとサーバーが新しい一意のMESSAGE IDの割り当てに関して互いに調整することを要求する必要もありません。16ビットMESSAGE IDの値と開始者 (クライアントまたはサーバー) の識別の組み合わせは、問題の操作を明確に識別するのに十分です。これは、クライアントからサーバーへのDSO要求メッセージに0x00001-0x0FFFFのメッセージ識別子を使用し、サーバーからクライアントへのDSO要求メッセージに0x10001-0x1FFFFを使用する17ビットメッセージ識別子空間と考えることができます。最下位16ビットはDSOメッセージのMESSAGE IDフィールドに明示的に格納され、最上位ビットはメッセージの方向から暗黙的です。

セクション 5.4.1 で説明されているように、開始者は、未解決のDSO要求メッセージ (問題のDSO-TYPEの関連する仕様で別途指定されない限り) に既に使用しているMESSAGE IDを再利用してはなりません (MUST NOT)。少なくとも、これは、開始者がそのDSOセッションでそのMESSAGE IDを使用する以前のDSO要求メッセージへの応答を待っている間 (問題のDSO-TYPEの関連する仕様で別途指定されない限り)、特定の方向の特定のDSOセッションでMESSAGE IDを再利用できないことを意味し、長期操作の場合、その操作がアクティブのままである間、操作のMESSAGE IDを再利用できません。

クライアントまたはサーバーが、MESSAGE IDがゼロである、または未解決の操作のいずれのMESSAGE IDとも一致しない他の値である応答 (QR=1) を受信した場合、これは致命的エラーであり、受信者は直ちに接続を強制的に中断しなければなりません (MUST)。

レスポンダーが、MESSAGE IDがゼロでないDSO要求メッセージ (QR=0) を受信し、レスポンダーが要求MESSAGE IDを追跡し、MESSAGE IDがまだ応答が送信されていない受信したDSO要求メッセージのMESSAGE IDと一致する場合、直ちに接続を強制的に中断しなければなりません (MUST)。この動作は、この場合の未定義の動作を利用する仮想的な攻撃を防ぐために必要です。ただし、レスポンダーがこのようにMESSAGE IDを追跡しない場合、そのようなリスクは存在しません。したがって、この健全性チェックを実装するためだけにMESSAGE IDを追跡することは必須ではありません。

5.5.3. エラー応答 (Error Responses)​

DSO要求メッセージが何らかの理由で失敗した場合、レスポンダーは開始者にエラーコードを返します。

失敗したDSO要求メッセージに応答してサーバーがクライアントにエラーコードを返す場合、サーバーはDSOセッションを終了することを選択してもかまいません (MAY) し、DSOセッションを開いたままにすることを選択してもかまいません (MAY)。問題の単一の操作のみに影響するエラー条件の場合、サーバーはクライアントにエラー応答を返し、さらなる操作のためにDSOセッションを開いたままにすべきです (SHOULD)。

すべての操作が近い将来に失敗する可能性が高いエラー条件の場合、サーバーはクライアントにエラー応答を返し、セクション 6.6.1 で説明されているようにRetry Delayメッセージを送信してDSOセッションを終了すべきです (SHOULD)。

サーバーからエラー応答を受信した後、クライアントは自動的にDSOセッションを閉じるべきではありません (SHOULD NOT)。DSOセッションの特定の操作に関するエラーは、そのDSOセッションの他のすべての操作も失敗したこと、または将来の操作が失敗することを必ずしも意味しません。クライアントは、サーバーがエラー条件がこの特定の操作に関係するか、後続の操作に関係するかの決定に基づいてDSOセッションを終了するかどうかについて独自の決定を行うと仮定すべきです。サーバーがクライアントにRetry Delayメッセージを送信してDSOセッションを終了しない場合 (セクション 6.6.1)、クライアントは後続の操作のためにそのDSOセッションを使用し続けるべきです (SHOULD)。

DSO単方向メッセージタイプが受信された場合 (MESSAGE IDフィールドがゼロ)、受信者はこのDSOメッセージタイプを既に期待しているはずです。セクション 5.4.5 は未知のDSOメッセージタイプの処理を説明しています。予期しないタイプのDSO単方向メッセージが受信された場合、受信者は接続を強制的に中断すべきです (SHOULD)。DSO単方向メッセージの処理中の他の内部エラーのために接続を強制的に中断すべきかどうかは、エラーの重大度に応じて実装に依存します。

5.6. レスポンダーが開始した操作のキャンセル (Responder-Initiated Operation Cancellation)​

この文書、DNS Stateful Operationsの基本仕様は、それ自体では長期操作を定義しませんが、プッシュ通知サブスクリプション [Push] やDiscovery Relayインターフェイスサブスクリプション [Relay] などの長期操作をサポートするためのフレームワークを定義します。

長期操作は、成功した場合、開始者が操作を終了するまでアクティブのままです。

ただし、長期操作が開始された時点では有効であった可能性がありますが、その後の状況の変化によってその操作が無効になる可能性があります。たとえば、長期クライアント操作は、サーバーが権威を持つ名前に関係する可能性がありますが、その後サーバー構成が変更され、その名前に対して権威を持たなくなる可能性があります。

このような場合、セッション全体を終了する代わりに、レスポンダーが無効になった操作のみを選択的にキャンセルできることが望ましい場合があります。

レスポンダーは、終了すべき長期操作のMESSAGE ID (以前にNOERROR RCODEで確認応答したもの) を含むMESSAGE IDフィールドと、キャンセルの理由を示す新しいDSO応答メッセージのRCODEフィールドを持つ新しいDSO応答メッセージを送信することによって、この選択的キャンセルを実行します。

非ゼロRCODEを持つDSO応答メッセージが送信された後、その操作はレスポンダーの観点から終了しており、レスポンダーはその操作に関してこれ以上メッセージを送信しません。

非ゼロRCODEを持つDSO応答メッセージが開始者によって受信された後、その操作は開始者の観点から終了しており、キャンセルされた操作のMESSAGE IDは再利用可能になります。

に最終更新