2. 更新メッセージフォーマット

DNSメッセージフォーマットは[RFC1035 4.1]で定義されています。いくつかの拡張が必要であり(例えば、UPDATEではQUERYよりも多くのエラーコードが可能)、いくつかのフィールドはオーバーロードする必要があります(以下のCLASSフィールドの説明を参照)。

UPDATEメッセージの全体的なフォーマットは、[ibid]に従うと次のようになります:

+---------------------+
|        Header       |
+---------------------+
|         Zone        | 更新するゾーンを指定
+---------------------+
|     Prerequisite    | 存在する(しない)必要があるRRまたはRRset
+---------------------+
|        Update       | 追加または削除するRRまたはRRset
+---------------------+
|   Additional Data   | 追加データ
+---------------------+

Headerセクションは、このメッセージがUPDATEであることを指定し、他のセクションのサイズを記述します。Zoneセクションは、このメッセージによって更新されるゾーンを指定します。Prerequisiteセクションは、この更新に必要な開始不変条件(ゾーンコンテンツの観点から)を指定します。Updateセクションには、行われる編集が含まれ、Additional Dataセクションには、この更新を完了するために必要であるが、その一部ではないデータが含まれます。

2.1 トランスポートの問題

更新トランザクションは、リクエストが適合する場合はUDPデータグラムで、またはTCP接続で(リクエスタの裁量で)運ばれる可能性があります。TCPが使用される場合、メッセージは[RFC1035 4.2.2]で説明されているフォーマットになります。

2.2 メッセージヘッダー

DNSメッセージフォーマットのヘッダーは[RFC 1035 4.1]で定義されています。すべてのオペコードが同じフラグビットのセットを定義しているわけではありませんが、実際問題として、QUERY用に定義されたビットのほとんど([ibid]内)は、他のオペコードによって同一に定義されています。UPDATEは1つのフラグビット(QR)のみを使用します。

DNSメッセージフォーマットは、4つのセクション(Question、Answer、Authority、Additional)のレコード数を指定します。UPDATEは同じフィールドと同じセクションフォーマットを使用しますが、これらのセクションの命名と使用は、[RFC1035 4.1.1]の後の次の修正されたヘッダーに示されているように異なります:

                                  1  1  1  1  1  1
    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                      ID                       |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |QR|   Opcode  |          Z         |   RCODE   |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    ZOCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    PRCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    UPCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                    ADCOUNT                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

これらのフィールドは次のように使用されます:

ID
あらゆる種類のリクエストを生成するエンティティによって割り当てられる16ビットの識別子。この識別子は対応する応答にコピーされ、リクエスタが未処理のリクエストに応答を一致させるため、またはサーバーがあるリクエスタからの重複したリクエストを検出するために使用できます。

QR
このメッセージがリクエスト(0)であるか、応答(1)であるかを指定する1ビットのフィールド。

Opcode
このメッセージ内のリクエストの種類を指定する4ビットのフィールド。この値はリクエストの発信者によって設定され、応答にコピーされます。UPDATEメッセージを識別するOpcodeの値は5(5)です。

Z
将来の使用のために予約されています。すべてのリクエストと応答でゼロ(0)である必要があります。ゼロ以外のZフィールドは、この仕様の実装によって無視される必要があります。

RCODE
応答コード - この4ビットのフィールドはリクエストでは未定義で、応答で設定されます。応答内のこのフィールドの値と意味は次のとおりです:

ニーモニック	値	説明
NOERROR	0	エラー条件なし。
FORMERR	1	ネームサーバーがフォーマットエラーのためリクエストを解釈できませんでした。
SERVFAIL	2	ネームサーバーがこのリクエストの処理中に内部障害に遭遇しました。例えば、オペレーティングシステムエラーまたは転送タイムアウト。
NXDOMAIN	3	存在すべき名前が存在しません。
NOTIMP	4	ネームサーバーは指定されたOpcodeをサポートしていません。
REFUSED	5	ネームサーバーはポリシーまたはセキュリティ上の理由で指定された操作の実行を拒否します。
YXDOMAIN	6	存在すべきでない名前が存在します。
YXRRSET	7	存在すべきでないRRsetが存在します。
NXRRSET	8	存在すべきRRsetが存在しません。
NOTAUTH	9	サーバーはZoneセクションで指定されたゾーンに対して権威がありません。
NOTZONE	10	PrerequisiteまたはUpdateセクションで使用されている名前が、Zoneセクションで示されたゾーン内にありません。

ZOCOUNT
Zoneセクション内のRRの数。

PRCOUNT
Prerequisiteセクション内のRRの数。

UPCOUNT
Updateセクション内のRRの数。

ADCOUNT
Additional Dataセクション内のRRの数。

2.3 ゾーンセクション

Zoneセクションは、[RFC1035 4.1.2]で指定されたものと同じフォーマットを持ち、フィールドは次のように再定義されています:

                                  1  1  1  1  1  1
    0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                                               |
  /                     ZNAME                     /
  /                                               /
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     ZTYPE                     |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
  |                     ZCLASS                    |
  +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

UPDATEはこのセクションを使用して、更新されるレコードのゾーンを示します。更新されるすべてのレコードは同じゾーン内にある必要があるため、Zoneセクションには正確に1つのレコードのみを含めることができます。ZNAMEはゾーン名、ZTYPEはSOAである必要があり、ZCLASSはゾーンのクラスです。

2.4 前提条件セクション

このセクションには、UPDATEパケットがプライマリマスターサーバーによって受信された時点で満たされる必要があるRRset前提条件のセットが含まれています。このセクションのフォーマットは[RFC1035 4.1.3]で指定されたとおりです。ここで表現できるセマンティクスの可能な5つのセットがあり、次のように要約され、以下で説明されます。

RRsetが存在する(値非依存)。Zoneセクションで指定されたゾーンとクラス内に、指定されたNAMEとTYPEを持つ少なくとも1つのRRが存在する必要があります。
RRsetが存在する(値依存)。指定されたNAMEとTYPEを持つRRのセットが存在し、このセクションでここに指定されたRRsetと同じメンバーと同じRDATAを持ちます。
RRsetが存在しない。Zoneセクションで示されたゾーンとクラス内に、指定されたNAMEとTYPEを持つRRは存在できません。
名前が使用中である。Zoneセクションで指定されたゾーンとクラス内に、指定されたNAMEを持つ少なくとも1つのRRが存在する必要があります。この前提条件は空の非終端ノードでは満たされないことに注意してください。
名前が使用されていない。指定されたNAMEが所有するあらゆるタイプのRRは存在しません。この前提条件は空の非終端ノードで満たされることに注意してください。

これらの構文は次のとおりです:

2.4.1 - RRsetが存在する(値非依存)

Zoneセクションで指定されたゾーンとクラス内に、指定されたNAMEとTYPEを持つ少なくとも1つのRRが存在する必要があります。

この前提条件では、リクエスタは、存在が必要なゾーンRRsetのNAMEとTYPEに等しい単一のRRをセクションに追加します。RDLENGTHはゼロであり、したがってRDATAは空です。CLASSは、RDLENGTHが自然にゼロ(0)である実際のRR(例:NULL)の条件と区別するためにANYとして指定する必要があります。TTLはゼロ(0)として指定されます。

2.4.2 - RRsetが存在する(値依存)

指定されたNAMEとTYPEを持つRRのセットが存在し、このセクションでここに指定されたRRsetと同じメンバーと同じRDATAを持ちます。RRsetの順序は未定義であり、したがってこの比較には重要ではありませんが、セットはその範囲で同一である必要があります。

この前提条件では、リクエスタは、事前存在が必要な完全なRRsetをセクションに追加します。NAMEとTYPEは、示されているRRsetのものです。CLASSはゾーンのものです。TTLはゼロ(0)として指定する必要があり、同一性のためにRRsetを比較する際に無視されます。

2.4.3 - RRsetが存在しない

Zoneセクションで示されたゾーンとクラス内に、指定されたNAMEとTYPEを持つRRは存在できません。

この前提条件では、リクエスタは、非存在が必要なRRsetのNAMEとTYPEに等しい単一のRRをセクションに追加します。このレコードのRDLENGTHはゼロ(0)であり、したがってRDATAフィールドは空です。CLASSは、RDLENGTHが自然にゼロ(0)である有効なRR(例:NULL RR)と区別するためにNONEとして指定する必要があります。TTLはゼロ(0)として指定する必要があります。

2.4.4 - 名前が使用中

名前が使用中です。Zoneセクションで指定されたゾーンとクラス内に、指定されたNAMEを持つ少なくとも1つのRRが存在する必要があります。この前提条件は空の非終端ノードでは満たされないことに注意してください。

この前提条件では、リクエスタは、RRの所有が必要な名前に等しいNAMEを持つ単一のRRをセクションに追加します。RDLENGTHはゼロであり、したがってRDATAは空です。CLASSは、RDLENGTHが自然にゼロ(0)である実際のRR(例:NULL)の条件と区別するためにANYとして指定する必要があります。TYPEは、RRset存在テストのケースと区別するためにANYとして指定する必要があります。TTLはゼロ(0)として指定されます。

2.4.5 - 名前が使用されていない

名前が使用されていません。指定されたNAMEが所有するあらゆるタイプのRRは存在しません。この前提条件は空の非終端ノードで満たされることに注意してください。

この前提条件では、リクエスタは、あらゆるRRの非所有が必要な名前に等しいNAMEを持つ単一のRRをセクションに追加します。RDLENGTHはゼロであり、したがってRDATAは空です。CLASSはNONEとして指定する必要があります。TYPEはANYとして指定する必要があります。TTLはゼロ(0)として指定する必要があります。

2.5 更新セクション

このセクションには、ゾーンに追加または削除されるRRが含まれています。このセクションのフォーマットは[RFC1035 4.1.3]で指定されたとおりです。以下に要約され、詳細が続く4つの可能なセマンティクスのセットがあります。

RRsetにRRを追加する。
RRsetを削除する。
名前からすべてのRRsetを削除する。
RRsetからRRを削除する。

これらの構文は次のとおりです:

2.5.1 - RRsetに追加

NAME、TYPE、TTL、RDLENGTH、およびRDATAが追加されているもので、CLASSがゾーンクラスと同じであるRRがUpdateセクションに追加されます。重複するRRは、プライマリマスターによって黙って無視されます。

2.5.2 - RRsetを削除

削除されるRRsetのNAMEとTYPEを持つ1つのRRがUpdateセクションに追加されます。TTLはゼロ(0)として指定する必要があり、そうでなければプライマリマスターによって使用されません。CLASSはANYとして指定する必要があります。RDLENGTHはゼロ(0)である必要があり、したがってRDATAは空である必要があります。そのようなRRsetが存在しない場合、このUpdate RRはプライマリマスターによって黙って無視されます。

2.5.3 - 名前からすべてのRRsetを削除

RRsetをクリーンアップする名前のNAMEを持つ1つのRRがUpdateセクションに追加されます。TYPEはANYとして指定する必要があります。TTLはゼロ(0)として指定する必要があり、そうでなければプライマリマスターによって使用されません。CLASSはANYとして指定する必要があります。RDLENGTHはゼロ(0)である必要があり、したがってRDATAは空である必要があります。そのようなRRsetが存在しない場合、このUpdate RRはプライマリマスターによって黙って無視されます。

2.5.4 - RRsetからRRを削除

削除されるRRがUpdateセクションに追加されます。NAME、TYPE、RDLENGTH、およびRDATAは、削除されるRRと一致する必要があります。TTLはゼロ(0)として指定する必要があり、そうでなければプライマリマスターによって無視されます。CLASSは、RR追加と区別するためにNONEとして指定する必要があります。そのようなRRが存在しない場合、このUpdate RRはプライマリマスターによって黙って無視されます。

2.6 追加データセクション

このセクションには、更新自体、または更新によって追加される新しいRRに関連するRRが含まれています。例えば、ゾーン外のグルー(新しいNS RRによって参照されるA RR)をここに提示する必要があります。サーバーは、サーバー実装者の裁量で、ゾーン外のグルーを使用または無視できます。このセクションのフォーマットは[RFC1035 4.1.3]で指定されたとおりです。