Internet Engineering Task Force (IETF) H. Salgado
Request for Comments: 9660 NIC Chile
Category: Standards Track M. Vergara
ISSN: 2070-1721 DigitalOcean
D. Wessels
Verisign
October 2024
The DNS ZONEVERSION option is a way for DNS clients to request, and for authoritative DNS servers to provide, information regarding the version of the zone from which a response is generated. The SERIAL field from the Start of Authority (SOA) resource record (RR) is a good example of a zone's version, and it is the only one defined by this specification. Additional version types may be defined by future specifications.
DNSゾーンバージョンオプションは、DNSクライアントが応答を生成するゾーンのバージョンに関する情報を要求し、権威あるDNSサーバーを提供する方法です。オーソリティの開始（SOA）リソースレコード（RR）のシリアルフィールドは、ゾーンのバージョンの良い例であり、この仕様で定義されている唯一のものです。追加のバージョンタイプは、将来の仕様によって定義できます。
Including zone version data in a response simplifies and improves the quality of debugging and diagnostics since the version and the DNS answer are provided atomically. This can be especially useful for zones and DNS providers that leverage IP anycast or multiple backend systems. It functions similarly to the DNS Name Server Identifier (NSID) option described in RFC 5001.
応答にゾーンバージョンデータを含めると、バージョンとDNSの回答が原子的に提供されるため、デバッグと診断の品質が簡素化され、向上します。これは、IP Anycastまたは複数のバックエンドシステムを活用するゾーンやDNSプロバイダーにとって特に役立ちます。これは、RFC 5001で説明されているDNS Name Server Identifier（NSID）オプションと同様に機能します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9660.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9660で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
1.2. Terminology
2. The ZONEVERSION Option
2.1. Wire Format
2.2. Presentation Format
3. ZONEVERSION Processing
3.1. Initiators
3.2. Responders
3.2.1. Responding to Invalid ZONEVERSION Queries
3.2.2. ZONEVERSION Is Not Transitive
4. The SOA-SERIAL ZONEVERSION Type
4.1. Type SOA-SERIAL Presentation Format
5. Example Usage
6. IANA Considerations
6.1. DNS EDNS(0) Option Code Registration
6.2. ZONEVERSION TYPE Values Registry
6.2.1. Designated Expert Review Directives
7. Security Considerations
8. Normative References
9. Informative References
Appendix A. Implementation Considerations
Appendix B. Implementation References
Acknowledgements
Authors' Addresses
The ZONEVERSION option allows DNS queriers to request, and authoritative DNS servers to provide, a token representing the version of the zone from which a DNS response was generated. It is similar to the NSID option [RFC5001], which can be used to convey the identification of a name server that generates a response.
ゾーンバージョンオプションにより、DNSクエリエは、DNS応答が生成されたゾーンのバージョンを表すトークンを提供するDNSクエリエが要求します。これは、NSIDオプション[RFC5001]に似ています。これは、応答を生成する名前サーバーの識別を伝えるために使用できます。
The Domain Name System allows data to be loosely coherent [RFC3254], because synchronization can never be instantaneous, and some uses of DNS do not require strong coherency anyway. This means that a record obtained by one response could be out of sync with other authoritative sources of the same data at the same point in time. This can make it difficult to debug some problems when there is a need to couple the data with the version of the zone it came from. Furthermore, in today's Internet, it is common for high volume and important DNS zones to utilize IP anycast (Section 4.9 of [RFC4786]) and/or load-balanced backend servers. In general, there is no way to ensure that two separate queries are delivered to the same server. The ZONEVERSION option both simplifies and improves DNS monitoring and debugging by directly associating the data and the version together in a single response.
ドメイン名システムを使用すると、データはゆるくコヒーレント[RFC3254]を使用できます。同期は瞬時になることはなく、DNSの一部の使用にはとにかく強力な一貫性が必要ないためです。これは、1つの応答によって得られたレコードが、同じ時点で同じデータの他の権威あるソースと同期しない可能性があることを意味します。これにより、データをそれが生まれたゾーンのバージョンと結合する必要がある場合に、いくつかの問題をデバッグすることが難しくなる可能性があります。さらに、今日のインターネットでは、大量および重要なDNSゾーンがIP Anycast（[RFC4786]のセクション4.9）および/またはロードバランスのバックエンドサーバーを利用することが一般的です。一般に、2つの個別のクエリが同じサーバーに配信されるようにする方法はありません。ゾーンバージョンオプションは、データとバージョンを単一の応答で直接関連付けることにより、DNSの監視とデバッグを簡素化および改善します。
The SOA SERIAL field (Section 4.3.5 of [RFC1034]) is one example of zone versioning. Its purpose is to facilitate the distribution of zone data between primary and secondary name servers. It is also often useful in DNS monitoring and debugging. This document specifies the SOA SERIAL as one type of ZONEVERSION data.
SOAシリアルフィールド（[RFC1034]のセクション4.3.5）は、ゾーンバージョンの1つの例です。その目的は、プライマリとセカンダリネームサーバー間のゾーンデータの分布を促進することです。また、DNSの監視とデバッグにも役立つことがよくあります。このドキュメントは、SOAシリアルを1つのタイプのゾーンバージョンデータとして指定します。
Some DNS zones may use other distribution and synchronization mechanisms that are not based on the SOA SERIAL number, such as relational databases or other proprietary methods. In those cases, the SOA SERIAL field may not be relevant with respect to the versioning of its content. To accommodate these use cases, new ZONEVERSION types could be defined in future specifications. Alternatively, zone operators may use one of the Private Use ZONEVERSION code points allocated by this specification.
一部のDNSゾーンは、リレーショナルデータベースやその他の独自の方法など、SOAシリアル番号に基づいていない他の分布および同期メカニズムを使用する場合があります。そのような場合、SOAシリアルフィールドは、そのコンテンツのバージョンに関して関連性がない場合があります。これらのユースケースに対応するために、将来の仕様で新しいゾーンバージョンタイプを定義できます。または、ゾーン演算子は、この仕様によって割り当てられたプライベート使用ゾーンバージョンコードポイントの1つを使用する場合があります。
The ZONEVERSION option is OPTIONAL to implement by DNS clients and name servers. It is designed for use only when a name server provides authoritative response data. It is intended only for hop-to-hop communication and is not transitive.
ゾーンバージョンオプションは、DNSクライアントと名前サーバーによって実装するためにオプションです。名前サーバーが権威ある応答データを提供する場合にのみ使用するように設計されています。ホップツーホップ通信のみを目的としており、推移的ではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
In this document, "original QNAME" is used to mean what the DNS terminology document [RFC9499] calls "QNAME (original)":
このドキュメントでは、「Original QName」は、DNS用語ドキュメント[RFC9499]が「QName（Original）」と呼ぶものを意味するために使用されます。
The name actually sent in the Question section in the original query, which is always echoed in the (final) reply in the Question section when the QR bit is set to 1.
QRビットが1に設定されている場合の質問セクションの（最終）回答（最終）の回答に常に反映される元のクエリの質問セクションで実際に送信された名前。
In this document, an "enclosing zone" of a domain name means a zone in which the domain name is present as an owner name or any parent of that zone. For example, if B.C.EXAMPLE and EXAMPLE are zones but C.EXAMPLE is not, the domain name A.B.C.EXAMPLE has B.C.EXAMPLE, EXAMPLE, and the root as enclosing zones.
このドキュメントでは、ドメイン名の「囲まれたゾーン」とは、ドメイン名が所有者名またはそのゾーンの親として存在するゾーンを意味します。たとえば、B.C。exampleと例がゾーンであるが、C.exampleがそうではない場合、ドメイン名A.B.C.Exampleにはb.c.example、例、およびrootがゾーンを囲みます。
This document specifies a new EDNS(0) [RFC6891] option, ZONEVERSION, which can be used by DNS clients and servers to provide information regarding the version of the zone from which a response is generated.
このドキュメントは、新しいEDNS（0）[RFC6891]オプションであるゾーンバージョンを指定します。これは、DNSクライアントとサーバーが使用して、応答が生成されるゾーンのバージョンに関する情報を提供できます。
The ZONEVERSION option is encoded as follows:
ゾーンバージョンオプションは次のようにエンコードされます。
OPTION-CODE for the ZONEVERSION option is 19.
ゾーンバージョンオプションのオプションコードは19です。
OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for queries and MUST have the value of the length (in octets) of the OPTION-DATA for responses.
ゾーンバージョンオプションのオプション長は、クエリの値が0である必要があり、応答のオプションデータの長さ（オクテット内）の値が必要です。
OPTION-DATA for the ZONEVERSION option is omitted in queries. For responses, it is composed of three fields:
ゾーンバージョンオプションのオプションデータは、クエリで省略されています。応答については、3つのフィールドで構成されています。
* an unsigned 1-octet Label Count (LABELCOUNT) indicating the number of labels for the name of the zone that VERSION value refers to
* バージョン値が指すゾーンの名前のラベルの数を示す、署名されていない1-OCTETラベルカウント（LabelCount）
* an unsigned 1-octet type number (TYPE) distinguishing the format and meaning of VERSION
* バージョンの形式と意味を区別する符号なしの1-OCTETタイプ番号（タイプ）
* an opaque octet string conveying the zone version data (VERSION)
* ゾーンバージョンデータを運ぶ不透明なオクテット弦（バージョン）
+0 (MSB) +1 (LSB)
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: | LABELCOUNT | TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: | VERSION |
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: Diagram with the OPTION-DATA Format for the ZONEVERSION Option
図1：ゾーンバージョンオプションのオプションデータ形式の図
The LABELCOUNT field indicates the name of the zone that the ZONEVERSION option refers to, by means of taking the last LABELCOUNT labels of the original QNAME. For example, an answer with QNAME "a.b.c.example.com" and a ZONEVERSION option with a LABELCOUNT of value 2 indicates that the zone name in which this ZONEVERSION refers to is "example.com.".
ラベルカウントフィールドは、元のQNameの最後のラベルカウントラベルを取得することにより、ゾーンバージョンオプションが指すゾーンの名前を示します。たとえば、QName「A.B.C.Example.com」を使用した回答と値2のラベルカウントを備えたゾーンバージョンオプションは、このゾーンバージョンが言及するゾーン名が「Example.com」です。
In the case of a downward referral response, the LABELCOUNT number helps to differentiate between the parent and child zones, where the parent is authoritative for some portion of the QNAME above a zone cut. Also, if the ANSWER section has more than one RR set with different zones (like a CNAME and a target name in another zone), the number of labels in the QNAME disambiguates such a situation.
下向きの紹介応答の場合、ラベルカウント番号は、親がゾーンカットの上のQNAMEの一部で権威ある親と子ゾーンを区別するのに役立ちます。また、回答セクションに異なるゾーン（CNAMEや別のゾーンのターゲット名など）を備えた複数のRRセットがある場合、QNAMEのラベルの数はそのような状況を明らかにします。
The value of the LABELCOUNT field MUST NOT count the null (root) label that terminates the original QNAME. The value of the LABELCOUNT field MUST be less than or equal to the number of labels in the original QNAME. The Root zone (".") has a LABELCOUNT field value of 0.
LabelCountフィールドの値は、元のQNAMEを終了するNULL（root）ラベルをカウントしてはなりません。LabelCountフィールドの値は、元のQNAMEのラベルの数よりも低くなければなりません。ルートゾーン（ "。"）のラベルカウントフィールド値は0です。
The presentation format of the ZONEVERSION option is as follows:
ゾーンバージョンオプションのプレゼンテーション形式は次のとおりです。
The OPTION-CODE field MUST be represented as the mnemonic value ZONEVERSION.
オプションコードフィールドは、ニーモニック値ゾーンバージョンとして表す必要があります。
The OPTION-LENGTH field MAY be omitted, but if present, it MUST be represented as an unsigned decimal integer.
オプションの長さのフィールドは省略される場合がありますが、存在する場合は、署名されていない小数整数として表す必要があります。
The LABELCOUNT value of the OPTION-DATA field MAY be omitted, but if present, it MUST be represented as an unsigned decimal integer. The corresponding zone name SHOULD be displayed (i.e., LABELCOUNT labels of the original QNAME) for easier human consumption.
オプションデータフィールドのラベルカウント値は省略できますが、存在する場合は、署名されていない小数整数として表す必要があります。対応するゾーン名を表示する必要があります（つまり、元のQNAMEのラベルカウントラベル）。
The TYPE and VERSION fields of the option SHOULD be represented according to each specific TYPE.
オプションのタイプとバージョンのフィールドは、各特定のタイプに従って表現する必要があります。
A DNS client MAY signal its support and desire for zone version information by including an empty ZONEVERSION option in the EDNS(0) OPT pseudo-RR of a query to an authoritative name server. An empty ZONEVERSION option has OPTION-LENGTH set to zero.
DNSクライアントは、eDNS（0）クエリのopt pseudo-rrに、権威ある名前サーバーにopt pseudo-rrに空のゾーンバージョンオプションを含めることにより、ゾーンバージョン情報のサポートと欲求を信号することができます。空のゾーンバージョンオプションには、オプションの長さがゼロに設定されています。
A DNS client SHOULD NOT send the ZONEVERSION option to non-authoritative name servers.
DNSクライアントは、ゾーンバージョンオプションを非著作的な名前サーバーに送信しないでください。
A DNS client MUST NOT include more than one ZONEVERSION option in the OPT pseudo-RR of a DNS query.
DNSクライアントは、DNSクエリのOPT擬似RRに複数のゾーンバージョンオプションを含めてはなりません。
A name server that (a) understands the ZONEVERSION option, (b) receives a query with the ZONEVERSION option, (c) is authoritative for one or more enclosing zones of the original QNAME, and (d) chooses to honor a particular ZONEVERSION request responds by including a TYPE and corresponding VERSION value in a ZONEVERSION option in an EDNS(0) OPT pseudo-RR in the response message.
（a）ゾーンバージョンオプションを理解し、（b）ゾーンバージョンオプションでクエリを受信し、（c）元のQNameのゾーンを1つ以上囲むことを許可し、（d）特定のゾーンバージョンリクエストを尊重することを選択します。ゾーンバージョン値をゾーンバージョンオプションにEDNS（0）に含めることにより、応答メッセージにopt擬似RRを含めることにより応答します。
Otherwise, a server MUST NOT include a ZONEVERSION option in the response.
それ以外の場合、サーバーは応答にゾーンバージョンオプションを含めてはなりません。
A name server MAY include more than one ZONEVERSION option in the response if it supports multiple TYPEs. A name server MAY also include more than one ZONEVERSION option in the response if it is authoritative for more than one enclosing zone of the original QNAME. A name server MUST NOT include more than one ZONEVERSION option for a given TYPE and LABELCOUNT.
名前サーバーには、複数のタイプをサポートする場合、応答に複数のゾーンバージョンオプションを含めることができます。名前サーバーには、元のQNAMEの複数の囲まれたゾーンに対して権威ある場合、応答に複数のゾーンバージョンオプションを含めることもできます。名前サーバーには、特定のタイプとラベルカウントに複数のゾーンバージョンオプションを含めてはなりません。
Note: the ZONEVERSION option should be included for any response satisfying the criteria above including, but not limited to, the following:
注：ゾーンバージョンオプションは、以下を含むがこれらに限定されない基準を満たす応答に含める必要があります。
* Downward referral (see "Referrals" in Section 4 of [RFC9499]), even though the response's Authoritative Answer bit is not set. In this case, the ZONEVERSION data MUST correspond to the version of the referring zone.
* 応答の権威ある回答ビットが設定されていない場合でも、下向きの紹介（[RFC9499]のセクション4の「紹介」を参照）。この場合、ゾーンバージョンデータは参照ゾーンのバージョンに対応する必要があります。
* Name error (NXDOMAIN), even though the response does not include any Answer section RRs.
* 応答には回答セクションRRSが含まれていない場合でも、名前エラー（nxDomain）。
* NODATA (Section 3 of [RFC9499]), even though the response does not include any Answer section RRs.
* Nodata（[RFC9499]のセクション3）、応答には回答セクションRRSが含まれていない場合でも。
* Server failure (SERVFAIL) when the server is authoritative for the original QNAME.
* サーバーが元のQNAMEに対して信頼できる場合のサーバー障害（サーブファイル）。
A name server that understands the ZONEVERSION option MUST return a FORMERR response when:
ゾーンバージョンオプションを理解している名前サーバーは、次の場合にformerr応答を返す必要があります。
* The ZONEVERSION OPTION-LENGTH is not zero.
* ゾーンバージョンオプション長はゼロではありません。
* More than one ZONEVERSION option is present.
* 複数のゾーンバージョンオプションが存在します。
The ZONEVERSION option is not transitive. A name server (recursive or otherwise) MUST NOT blindly copy the ZONEVERSION option from a query it receives into a subsequent query that it sends onward to another server. A name server MUST NOT send a ZONEVERSION option back to a client that did not request it.
ゾーンバージョンオプションは推移的ではありません。名前サーバー（再帰的またはその他）は、受信したクエリからゾーンバージョンオプションを盲目的にコピーして、他のサーバーに向かって送信する後続のクエリにコピーしてはなりません。名前サーバーは、ゾーンバージョンオプションをリクエストしなかったクライアントに送信してはなりません。
The first and only ZONEVERSION option TYPE defined in this document is a zone's serial number as found in the Start of Authority (SOA) RR.
このドキュメントで定義されている最初と唯一のゾーンバージョンオプションタイプは、権限の開始（SOA）RRに見られるゾーンのシリアル番号です。
As mentioned previously, some DNS zones may use alternative distribution and synchronization mechanisms that are not based on the SOA SERIAL number, and the SERIAL field may not be relevant with respect to the versioning of zone content. In those cases, a name server SHOULD NOT include a ZONEVERSION option with type SOA-SERIAL in a reply.
前述のように、一部のDNSゾーンは、SOAシリアル番号に基づいていない代替分布および同期メカニズムを使用する場合があり、シリアルフィールドはゾーンコンテンツのバージョン化に関して関連しない場合があります。そのような場合、名前サーバーには、返信にタイプSOAシリアルを備えたゾーンバージョンオプションを含めるべきではありません。
The value for this type is "0".
このタイプの値は「0」です。
The mnemonic for this type is "SOA-SERIAL".
このタイプのニーモニックは「SOA-SERIAL」です。
The EDNS(0) OPTION-LENGTH for this type MUST be set to "6" in responses.
このタイプのEDNS（0）オプション長は、応答で「6」に設定する必要があります。
The VERSION value for the SOA-SERIAL type MUST be a copy of the unsigned 32-bit SERIAL field of the SOA RR, as defined in Section 3.3.13 of [RFC1035].
SOAシリアルタイプのバージョン値は、[RFC1035]のセクション3.3.13で定義されているように、SOA RRの32ビットシリアルフィールドのコピーでなければなりません。
The presentation format of this type content is as follows:
このタイプコンテンツのプレゼンテーション形式は次のとおりです。
The TYPE field MUST be represented as the mnemonic value "SOA-SERIAL".
タイプフィールドは、ニーモニック値「SOA-SERIAL」として表現する必要があります。
The VERSION field MUST be represented as an unsigned decimal integer.
バージョンフィールドは、署名のない小数整数として表す必要があります。
A name server that (a) implements this specification, (b) receives a query with the ZONEVERSION option, (c) is authoritative for the zone of the original QNAME, and (d) utilizes the SOA SERIAL field for versioning of said zone should include a ZONEVERSION option in its response. In the response's ZONEVERSION option, the EDNS(0) OPTION-LENGTH would be set to 6 and the OPTION-DATA would consist of the 1-octet LABELCOUNT, the 1-octet TYPE with value 0, and the 4-octet SOA-SERIAL value.
（a）この仕様を実装する名前サーバー、（b）ゾーンバージョンオプションでクエリを受信し、（c）元のQNameのゾーンに対して権威あるものであり、（d）は、ゾーンのバージョンにSOAシリアルフィールドを利用する必要があります。その応答にゾーンバージョンオプションを含めます。応答のゾーンバージョンオプションでは、EDNS（0）オプション長が6に設定され、オプションデータは1-OCTETラベルカウント、値0の1-OCTETタイプ、および4オクテットのSOA-SERIALで構成されます。価値。
The example below demonstrates expected output of a diagnostic tool that implements the ZONEVERSION option, displaying a response from a compliant authoritative DNS server:
以下の例は、ゾーンバージョンオプションを実装する診断ツールの予想される出力を示しており、準拠した権威あるDNSサーバーからの応答を表示します。
$ dig @ns.example.com www.example.com aaaa +zoneversion \
+norecurse +nocmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 \
; (example.com.)")
;; QUESTION SECTION:
;www.example.com. IN AAAA
;; ANSWER SECTION:
www.example.com. 43200 IN AAAA 2001:db8::80
;; AUTHORITY SECTION:
example.com. 43200 IN NS ns.example.com.
;; ADDITIONAL SECTION:
ns.example.com. 43200 IN AAAA 2001:db8::53
;; Query time: 15 msec
;; SERVER: 2001:db8::53#53(2001:db8::53) (UDP)
;; WHEN: dom jul 30 19:51:04 -04 2023
;; MSG SIZE rcvd: 129
Figure 2: Example Usage and Dig Output
図2：使用の例とDIG出力
This document defines a new EDNS(0) option, entitled "ZONEVERSION" (see Section 2), with the assigned value of 19 from the "DNS EDNS0 Option Codes (OPT)" registry:
このドキュメントでは、「ゾーンバージョン」というタイトルの新しいEDNS（0）オプション（セクション2を参照）を定義します。
+=======+=============+==========+===========+
| Value | Name | Status | Reference |
+=======+=============+==========+===========+
| 19 | ZONEVERSION | Standard | RFC 9660 |
+=======+=============+==========+===========+
Table 1: DNS EDNS0 Option Codes (OPT) Registry
表1：DNS EDNS0オプションコード（OPT）レジストリ
IANA has created and will maintain a new registry called "ZONEVERSION TYPE Values" in the "Domain Name System (DNS) Parameters" registry group as follows:
IANAは、「ドメイン名システム（DNS）パラメーター」レジストリグループに「ゾーンバージョンタイプ値」と呼ばれる新しいレジストリを作成し、維持します。
+=========+=========================+
| Range | Registration Procedures |
+=========+=========================+
| 0-245 | Specification Required |
+=========+=========================+
| 246-254 | Private Use |
+=========+=========================+
| 255 | Reserved |
+=========+=========================+
Table 2: Registration Procedures for the ZONEVERSION TYPE Values Registry
表2：ゾーンバージョンタイプ値レジストリの登録手順
Initial values for the "ZONEVERSION TYPE Values" registry are given below; future assignments in the 1-245 values range are to be made through Specification Required [RFC8126]. Assignments consist of a TYPE value as an unsigned 8-bit integer recorded in decimal, a Mnemonic name as an uppercase ASCII string with a maximum length of 15 characters, and the required document reference.
「ゾーンバージョンタイプ値」レジストリの初期値を以下に示します。1-245値範囲の将来の割り当ては、必要な仕様[RFC8126]を通じて行われます。割り当ては、10進数で記録された署名されていない8ビット整数としてのタイプ値、最大長さ15文字の大文字のASCII文字列としてのニーモニック名、および必要なドキュメントリファレンスで構成されています。
+==================+==========================+===========+
| ZONEVERSION TYPE | Mnemonic | Reference |
+==================+==========================+===========+
| 0 | SOA-SERIAL | RFC 9660 |
+==================+==========================+===========+
| 1-245 | Unassigned | |
+==================+==========================+===========+
| 246-254 | Reserved for Private Use | RFC 9660 |
+==================+==========================+===========+
| 255 | Reserved | RFC 9660 |
+==================+==========================+===========+
Table 3: ZONEVERSION TYPE Values Registry
表3：ゾーンバージョンタイプ値レジストリ
The change controller for this registry is IETF.
このレジストリの変更コントローラーはIETFです。
The allocation procedure for new code points in the "ZONEVERSION TYPE Values" registry is Specification Required, thus review is required by a designated expert as stated in [RFC8126].
「ゾーンバージョンタイプ値」レジストリの新しいコードポイントの割り当て手順は、[RFC8126]に記載されているように、指定された専門家がレビューを必要とします。
When evaluating requests, the expert should consider the following:
リクエストを評価するとき、専門家は次のことを考慮する必要があります。
* Duplication of code point allocations should be avoided.
* コードポイント割り当ての複製は避ける必要があります。
* A Presentation Format section should be provided with a clear code point mnemonic.
* プレゼンテーション形式のセクションには、クリアコードポイントMNEMONINで提供する必要があります。
* The referenced document and stated use of the new code point should be appropriate for the intended use of a ZONEVERSION TYPE assignment. In particular, the reference should state clear instructions for implementers about the syntax and semantic of the data. Also, the length of the data must have proper limits.
* 参照されたドキュメントと新しいコードポイントの使用は、ゾーンバージョンタイプの割り当ての意図された使用に適している必要があります。特に、参照は、データの構文とセマンティックに関する実装者の明確な指示を明確に述べる必要があります。また、データの長さには適切な制限が必要です。
The expert reviewing the request MUST respond within 10 business days.
リクエストをレビューする専門家は、10営業日以内に応答する必要があります。
The EDNS extension data is not covered by RRSIG records, so there's no way to verify its authenticity nor integrity using DNSSEC, and it could theoretically be tampered with by a person in the middle if the transport is made by insecure means. Caution should be taken to use the EDNS ZONEVERSION data for any means besides troubleshooting and debugging.
EDNS拡張データはRRSIGレコードではカバーされていないため、DNSSECを使用してその信ity性や整合性を検証する方法はなく、輸送が安全でない手段で作られている場合、真ん中の人が理論的に改ざんすることができます。トラブルシューティングとデバッグ以外に、EDNSゾーンバージョンデータを使用するように注意する必要があります。
If there's a need to certify the trustworthiness of ZONEVERSION, it will be necessary to use an encrypted and authenticated DNS transport, a transaction signature (TSIG) [RFC8945], or SIG(0) [RFC2931].
ゾーンバージョンの信頼性を証明する必要がある場合は、暗号化され、認証されたDNSトランスポート、トランザクション署名（TSIG）[RFC8945]、またはSIG（0）[RFC2931]を使用する必要があります。
If there's a need to authenticate the data origin for the ZONEVERSION value, an answer with the SOA-SERIAL type as defined above could be compared to a separate regular SOA query with a DO flag, whose answer shall be DNSSEC signed. Since these are separate queries, the caveats about loose coherency already stated in the Introduction (Section 1) would apply.
ゾーンバージョン値のデータ原点を認証する必要がある場合、上記のSOAシリアルタイプの回答は、DOフラグを使用した別の通常のSOAクエリと比較できます。これらは別々のクエリであるため、導入部（セクション1）に既に記載されているゆるい一貫性に関する警告が適用されます。
With the SOA-SERIAL type defined above, there's no risk on disclosure of private information, as the SERIAL of the SOA record is already publicly available.
上記で定義されたSOAシリアルタイプでは、SOAレコードのシリアルがすでに公開されているため、個人情報の開示にリスクはありません。
Please note that the ZONEVERSION option cannot be used for checking the correctness of an entire zone in a server. For such cases, the ZONEMD record [RFC8976] might be better suited for such a task. ZONEVERSION can help identify and correlate a specific answer with a version of a zone, but it has no special integrity or verification function besides a normal field value inside a zone, as stated above.
サーバー内のゾーン全体の正しさを確認するために、ゾーンバージョンオプションを使用できないことに注意してください。このような場合、ZoneMDレコード[RFC8976]は、そのようなタスクに適している可能性があります。ゾーンバージョンは、特定の答えをゾーンのバージョンと特定して相関させるのに役立ちますが、上記のように、ゾーン内の通常のフィールド値以外に特別な完全性または検証機能はありません。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[ImplRef] "Zoneversion Implementations", commit f5f68a0, August
2023, <https://github.com/huguei/rrserial>.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
2000, <https://www.rfc-editor.org/info/rfc2931>.
[RFC3254] Alvestrand, H., "Definitions for talking about
directories", RFC 3254, DOI 10.17487/RFC3254, April 2002,
<https://www.rfc-editor.org/info/rfc3254>.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC5001] Austein, R., "DNS Name Server Identifier (NSID) Option",
RFC 5001, DOI 10.17487/RFC5001, August 2007,
<https://www.rfc-editor.org/info/rfc5001>.
[RFC8945] Dupont, F., Morris, S., Vixie, P., Eastlake 3rd, D.,
Gudmundsson, O., and B. Wellington, "Secret Key
Transaction Authentication for DNS (TSIG)", STD 93,
RFC 8945, DOI 10.17487/RFC8945, November 2020,
<https://www.rfc-editor.org/info/rfc8945>.
[RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
Hardaker, "Message Digest for DNS Zones", RFC 8976,
DOI 10.17487/RFC8976, February 2021,
<https://www.rfc-editor.org/info/rfc8976>.
[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
RFC 9499, DOI 10.17487/RFC9499, March 2024,
<https://www.rfc-editor.org/info/rfc9499>.
With very few exceptions, EDNS(0) option values in a response are independent of the queried name. This is not the case for ZONEVERSION, so its implementation may be more or less difficult, depending on how EDNS(0) options are handled in the name server.
例外はほとんどありませんが、応答のEDN（0）オプション値は、クエリ名とは無関係です。これはゾーンバージョンの場合ではないため、EDN（0）オプションが名前サーバーで処理される方法に応じて、その実装は多かれ少なかれ難しい場合があります。
There is a patched NSD server (version 4.7.0) with support for ZONEVERSION as well as live test servers installed for compliance tests. Also, there is a client command "dig" with added zoneversion support, along with test libraries in Perl, Python, and Go. See [ImplRef] for more information.
ゾーンバージョンをサポートするパッチ付きNSDサーバー（バージョン4.7.0）と、コンプライアンステスト用にインストールされたライブテストサーバーがあります。また、Perl、Python、およびGoのテストライブラリとともに、ゾーンバージョンサポートを追加したクライアントコマンド「DIG」があります。詳細については、[Implef]を参照してください。
The authors are thankful for all the support and comments made in the DNSOP Working Group mailing list, chats, and discussions. A special thanks for suggestions to generalize the option using a registry of types from Petr Špaček and Florian Obser, suggestions for implementation from Stéphane Bortzmeyer, clarifications on security from George Michaelson, zone name disambiguation from Joe Abley and Brian Dickson, and reviews from Tim Wicinski and Peter Thomassen.
著者は、DNSOPワーキンググループのメーリングリスト、チャット、ディスカッションで行われたすべてのサポートとコメントに感謝しています。ペトルシュパチェクとフロリアンオブザーターからのタイプのレジストリを使用してオプションを一般化するための提案、ステファンボルツマイヤーからの実装の提案、ジョージマイケルソンからのセキュリティに関する説明、ジョーエイベリーとブライアンディクソンからのゾーン名の乱学、ティムウィシンスキーのレビューのレビューそしてピーター・トマセン。
Hugo Salgado
NIC Chile
Miraflores 222, piso 14
CP 8320198 Santiago
Chile
Phone: +56 2 29407700
Email: hsalgado@nic.cl
Mauricio Vergara Ereche
DigitalOcean
101 6th Ave
New York, NY 10013
United States of America
Email: mvergara@digitalocean.com
Duane Wessels
Verisign
12061 Bluemont Way
Reston, VA 20190
United States of America
Phone: +1 703 948-3200
Email: dwessels@verisign.com
URI: https://verisign.com