draft-ietf-dnsop-zoneversion-02.txt		draft-ietf-dnsop-zoneversion-09.txt
	Internet Engineering Task Force H. Salgado		Internet Engineering Task Force H. Salgado
	Internet-Draft NIC Chile		Internet-Draft NIC Chile
	Intended status: Informational M. Vergara		Intended status: Standards Track M. Vergara
	Expires: 25 August 2023 DigitalOcean		Expires: 2 January 2025 DigitalOcean
	21 February 2023		D. Wessels
			Verisign
			1 July 2024
	The "ZONEVERSION" EDNS option for the version token of a RR's zone		The DNS Zone Version (ZONEVERSION) Option
	draft-ietf-dnsop-zoneversion-02		draft-ietf-dnsop-zoneversion-09
	Abstract		Abstract
	The "ZONEVERSION" EDNS option allows a DNS querier to request a DNS		The DNS ZONEVERSION option is a way for DNS clients to request, and
	authoritative server to add an EDNS option in the answer of such		for authoritative DNS servers to provide, information regarding the
	query with a token field representing the version of the zone which		version of the zone from which a response is generated. The Serial
	contains the answered Resource Record, such as the SOA serial field		field from the Start Of Authority (SOA) resource record is a good
	in zones when this number corresponds to the zone version.		example of a zone's version, and the only one defined by this
			specification. Additional version types may be defined by future
			specifications.
	This "ZONEVERSION" data allows to debug and diagnose problems by		Including zone version data in a response simplifies and improves the
	helping to recognize the data source of an answer in an atomic single		quality of debugging and diagnostics since the version and the DNS
	query, by associating the response with a respective zone version.		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 [RFC5001].
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on 25 August 2023.		This Internet-Draft will expire on 2 January 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2023 IETF Trust and the persons identified as the		Copyright (c) 2024 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Revised BSD License text as		extracted from this document must include Revised BSD License text as
	described in Section 4.e of the Trust Legal Provisions and are		described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Revised BSD License.		provided without warranty as described in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2. The ZONEVERSION Option . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. The ZONEVERSION Option Presentation Format . . . . . . . 4		2. The ZONEVERSION Option . . . . . . . . . . . . . . . . . . . 4
	3. ZONEVERSION Processing . . . . . . . . . . . . . . . . . . . 4		2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Initiator . . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Presentation Format . . . . . . . . . . . . . . . . . . . 5
	3.2. Responder . . . . . . . . . . . . . . . . . . . . . . . . 4		3. ZONEVERSION Processing . . . . . . . . . . . . . . . . . . . 5
	4. Flag Definition for SOA-SERIAL . . . . . . . . . . . . . . . 4		3.1. Initiators . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Flag SOA-SERIAL Presentation Format . . . . . . . . . . . 5		3.2. Responders . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Example usage . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2.1. ZONEVERSION Is Not Transitive . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6		4. The SOA-SERIAL ZONEVERSION Type . . . . . . . . . . . . . . . 7
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4.1. Type SOA-SERIAL Presentation Format . . . . . . . . . . . 7
	7.1. DNS EDNS0 Option Code Registration . . . . . . . . . . . 6		5. Example usage . . . . . . . . . . . . . . . . . . . . . . . . 7
	7.2. ZONEVERSION Registry . . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	7.2.1. Expert Review Directives . . . . . . . . . . . . . . 7		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7.1. DNS EDNS0 Option Code Registration . . . . . . . . . . . 9
	9. Normative References . . . . . . . . . . . . . . . . . . . . 8		7.2. ZONEVERSION Registry . . . . . . . . . . . . . . . . . . 9
	10. Informative References . . . . . . . . . . . . . . . . . . . 9		7.2.1. Expert Review Directives . . . . . . . . . . . . . . 10
	Appendix A. Implementation Considerations . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	Appendix B. Implementation References . . . . . . . . . . . . . 9		9. Normative References . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		10. Informative References . . . . . . . . . . . . . . . . . . . 11
			Appendix A. Implementation Considerations . . . . . . . . . . . 12
			Appendix B. Implementation References . . . . . . . . . . . . . 12
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The "ZONEVERSION" EDNS option [RFC6891] allows a DNS querier to		The ZONEVERSION option allows DNS queriers to request, and
	request to a DNS authoritative server to add an EDNS option in the		authoritative DNS servers to provide, a token representing the
	answer of such query with a token field representing the version of		version of the zone from which a DNS response was generated. It is
	the zone associated to the answered Resource Record, such as the SOA		similar to the NSID option [RFC5001], which can be used to convey the
	serial field in zones when this number corresponds to the zone		identification of a name server that generates a response.
	version.
	This "ZONEVERSION" data allows to help debug by recognizing the data
	source of an answer, associating this answer with a respective zone
	version.
	DNS data is of loose coherent nature, meaning that a record obtained		The Domain Name System allows data to be loosely coherent [RFC3254],
	by a response could be out-of-sync with other authoritative sources		because synchronization can never be instantaneous, and some uses of
	of the same data. This makes it difficult to debug responses,		DNS do not require strong coherency anyway. This means that a record
	because you'd need to couple an answer with the same version of the		obtained by one response could be out-of-sync with other
	zone used to obtain such data. Even when in zones where the SOA		authoritative sources of the same data at the same point in time.
	serial field have the meaning of zone version you could use a		This can make it difficult to debug some problems when there is a
	separate query to ask for the SOA RR of the zone and therefore know		need to couple the data with the version of the zone it came from.
	its SOA serial, such separate query is performed in a different time		Furthermore, in today's Internet, it is common for high volume and
	and could arrive from another authoritative source (for example, in		important DNS zones to utilize IP anycast Section 4.9 of [RFC4786]
	the case the server is anycasted as described in Section 4.9 of		and/or load-balanced backend servers. In general, there is no way to
	[RFC4786]), so it's not directly correlated with the original query.		ensure that two separate queries are delivered to the same server.
			The ZONEVERSION option both simplifies and improves the DNS
			monitoring and debugging by directly associating the data and the
			version together in a single response.
	This EDNS option is aimed to be used only on authoritative servers		The SOA Serial field (Section 4.3.5 of [RFC1034]) is one example of
	for a zone. It's intended for hop-to-hop communication (not		zone versioning. Its purpose is to facilitate the distribution of
	transitive). Resolver and forwarder behavior is undefined.		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.
	The ZONEVERSION EDNS extension can have different meaning depending		Some DNS zones may use other distribution and synchronization
	on the semantics of the zone maintainer and implementation of		mechanisms not based on the SOA Serial number, such as relational
	nameservers. This document defines one possible value, when the zone		databases or other proprietary methods. In those cases the SOA
	version corresponds to the serial field of the SOA Resource Record of		Serial field may not be relevant with respect to the versioning of
	the zone, a classic behaviour defined in Section 4.3.5 of [RFC1034].		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.
	As the writing of this document, we recognize there are cases where		The ZONEVERSION option is OPTIONAL to implement by DNS clients and
	nameservers use different backends for its data sources (like		name servers. It is designed for use only when a name server
	relational databases or by using a different off-DNS synchronicity		provides authoritative response data. It is intended only for hop-
	among others) therefore, the SOA version field doesn't offer much		to-hop communication and is not transitive.
	relevance as a versioning to its content, and in those cases the
	ZONEVERSION EDNS extension SHOULD be extended with a different flag
	and have an opaque value for its data token.
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[BCP14] (RFC2119, RFC8174) when, and only when, they appear in all
			capitals, as shown here.
			1.2. Terminology
			In this document "original QNAME" is used to mean what the DNS
			terminology document [RFC8499] calls "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.
	2. The ZONEVERSION Option		2. The ZONEVERSION Option
	The variable part of RDATA in the OPT RR Section 6.1.2 of [RFC6891]		This document specifies a new EDNS(0) (Section 6.1.2 of [RFC6891])
	for ZONEVERSION is defined as follows:		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.
	* The OPTION-CODE for the ZONEVERSION option is <TBD>.		2.1. Wire Format
	* The OPTION-LENGTH for the ZONEVERSION option MUST have a value of		The ZONEVERSION option is encoded as follows:
	0 for queries, and MUST have the value of length in octets for the
	next OPTION-DATA for responses.
	* The OPTION-DATA for the ZONEVERSION option is composed of the		OPTION-CODE for the ZONEVERSION option is <TBD>.
	concatenation of an unsigned 1 byte Flag number (FLAG-NUMBER), an
	unsigned 2 bytes number with the Length of the next field in bytes
	(FLAG-LENGTH), and the final Data value of the ZONEVERSION field
	as an opaque bit value, with the previous specified length (FLAG-
	DATA).
	[RFC Editor: change <TBD> to the proper code when assigned by IANA.]		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.
	2.1. The ZONEVERSION Option Presentation Format		OPTION-DATA for the ZONEVERSION option is omitted in queries. For
			responses it is composed of three fields:
	The presentation format of the RDATA portion is as follows:		* An unsigned 1-octet Label Count (LABELCOUNT) indicating the number
			of labels for the name of the zone that VERSION value refers to.
			* An unsigned 1-octet type number (TYPE) that distinguishes the
			format and meaning of VERSION.
			* 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 ZONEVERSION option
			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 that this ZONEVERSION refers is
			"example.com.".
			The LABELCOUNT number helps to differentiate in the case of a
			downward referral response, where the parent server is authoritative
			for some portion of the QNAME that differs from a child server that
			is below the 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.
			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.
			2.2. Presentation Format
			The presentation format of the ZONEVERSION option is as follows:
	The OPTION-CODE field MUST be represented as the mnemonic value		The OPTION-CODE field MUST be represented as the mnemonic value
	"ZONEVERSION".		ZONEVERSION.
	The OPTION-LENGTH field could be omitted in presentation format, but		The OPTION-LENGTH field MAY be omitted, but if present it MUST be
	if is used, MUST be represented as an unsigned decimal integer.		represented as an unsigned decimal integer.
	The OPTION-DATA field MUST be represented following its own format,		The LABELCOUNT value of OPTION-DATA field MAY be omitted, but if
	as specified in the corresponding Flag's specification.		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.
			The TYPE and VERSION fields of the option SHOULD be represented
			according to each specific TYPE.
	3. ZONEVERSION Processing		3. ZONEVERSION Processing
	3.1. Initiator		3.1. Initiators
	The EDNS ZONEVERSION option MAY be included on any QUERY, by adding a		A DNS client MAY signal its support and desire for zone version
	zero-length EDNS ZONEVERSION option to the options field of the OPT		information by including an empty ZONEVERSION option in the EDNS(0)
	record when the query is made.		OPT pseudo-RR of a query to an authoritative name server. An empty
			ZONEVERSION option has OPTION-LENGTH set to zero.
	3.2. Responder		A DNS client SHOULD NOT send the ZONEVERSION option to non-
			authoritative name servers.
	If an EDNS ZONEVERSION option is sent to a server that is		A DNS client MUST NOT include more than one ZONEVERSION option in the
	Authoritative for the zone, then a name server that understands the		OPT RR of a DNS query.
	ZONEVERSION option and chooses to honor a particular ZONEVERSION
	request, MUST put in the OPTION-DATA a flag, length and value that
	corresponds to the properly semantic of such flag number, and
	corresponds to a zone versioning value of the zone that holds the
	original QNAME of the reply (as per Section 4 of [RFC8499]).
	Otherwise, the answer MUST NOT add an EDNS ZONEVERSION option to the		3.2. Responders
			A name server that (a) understands the ZONEVERSION option, (b)
			receives a query with the ZONEVERSION option, (c) is authoritative
			for the zone 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.
			Otherwise, a server MUST NOT include a ZONEVERSION option in the
	response.		response.
	4. Flag Definition for SOA-SERIAL		A name server MUST ignore invalid ZONEVERSION options present in the
			query message.
	The first and only ZONEVERSION Flag defined in this document for the		A name server MAY include more than one ZONEVERSION option in the
	ZONEVERSION Option has the FLAG-NUMBER of 0, a FLAG-LENGTH field of		response if it supports multiple TYPEs. A name server MAY also
	value 4, and its corresponding FLAG-DATA MUST be a copy of the		include more than one ZONEVERSION option in the response if it is
	unsigned 32 bit version number as defined in the SERIAL field of the		authoritative for more than one zone of the corresponding QNAME. A
	"SOA RDATA Format" in Section 3.3.13 of [RFC1035].		name server MUST NOT include more than one ZONEVERSION option for a
			given TYPE and LABELCOUNT.
	The FLAG-LENGTH for this ZONEVERSION Option MUST have a value of 7		A name server SHOULD include zone version information in a name error
	for responses.		(NXDOMAIN) response, even though the response does not include any
			Answer section RRs.
	The mnemonic of this flag is SOA-SERIAL.		A name server SHOULD include zone version information for downward
			referral responses (see "Referrals" in Section 4 of [RFC8499]). Even
			though the response's Authoritative Answer bit is not set, the name
			server is authoritative for the zone from which the referral was
			generated. In this case, the ZONEVERSION data MUST correspond to the
			version of the referring zone.
	Note that in this case a NXDOMAIN RCODE already includes the complete		A name server SHOULD include zone version information in a server
	SOA Resource Record in the AUTHORITY section, so the inclusion of a		failure (SERVFAIL) response when it is authoritative for the original
	ZONEVERSION EDNS Option in the answer is superfluous and can be		QNAME.
	omitted. In the case of a SERVFAIL RCODE the responder MAY include
	the ZONEVERSION EDNS Option if the QNAME still belongs to an
	authoritative zone of the server, in which case that value MUST be
	the one included in the answer.
	Note that a NODATA response code as defined in Section 3 of [RFC8499]		A name server SHOULD include zone version information in a NODATA
	MUST also include the ZONEVERSION answer even when there's no ANSWER		response (Section 3 of [RFC8499]). Even though the NODATA response
	data for the QNAME, since the RCODE is NOERROR.		does not include any Answer section RRs, the RCODE is NOERROR and the
			name server is still authoritative for the zone.
	4.1. Flag SOA-SERIAL Presentation Format		3.2.1. ZONEVERSION Is Not Transitive
	The presentation format of this flag content is as follows:		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 subsquent query that it sends onward to
			another server. A name server MUST NOT send a ZONEVERSION option
			back to a client which did not request it.
	The FLAG-NUMBER field MUST be represented as the mnemonic value "SOA-		4. The SOA-SERIAL ZONEVERSION Type
	SERIAL".
	The FLAG-LENGTH field could be omitted in presentation format, but if		The first and only ZONEVERSION option TYPE defined in this document
	is used, MUST be represented as an unsigned decimal integer.		is a zone's serial number as found in the Start of Authority (SOA)
			RR.
	The FLAG-DATA field MUST be represented as an unsigned decimal		The value for this type is: 0
	integer.
			The mnemonic of this type is: SOA-SERIAL.
			The EDNS(0) OPTION-LENGTH for this type MUST be set to 6 in
			responses.
			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].
			4.1. Type SOA-SERIAL Presentation Format
			The presentation format of this type content is as follows:
			The TYPE field MUST be represented as the mnemonic value "SOA-
			SERIAL".
			The VERSION field MUST be represented as an unsigned decimal integer.
	5. Example usage		5. Example usage
	A zone which utilizes the serial field of the SOA Resource Record as		A name server which (a) implements this specification, (b) receives a
	a number of the zone version release, should answer a ZONEVERSION		query with the ZONEVERSION option, (c) is authoritative for the zone
	request with an EDNS option code ZONEVERSION, an OPTION-DATA with a		of the original QNAME, and (d) utilizes the SOA serial field for
	Flag byte with value 0, Length value 4 and a copy of the unsigned 32		versioning of said zone should include a ZONEVERSION option in its
	bit version number of the SERIAL field of its SOA zone Resourse		response. In the response's ZONEVERSION option the EDNS(0) OPTION-
	Record, and an OPTION-LENGTH with value 7.		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 4-octet SOA
			SERIAL value.
	An example of a proper diagnostic tool that implements ZONEVERSION		The example below demonstrates expected output of a diagnostic tool
	EDNS extension towards a compliant authoritative DNS server could be:		that implements the ZONEVERSION option, displaying a response from a
			compliant authoritative DNS server:
	$ dig @ns.example.com www.example.com AAAA +zoneversion +norec +cmd		$ dig @ns.example.com www.example.com aaaa +zoneversion +norecurse
	; (1 server found)		; <<>> DiG 9.17.14-patched <<>> @ns.example.com www.example.com aaaa +zoneversion
	;; global options: +cmd		; (1 server found)
	;; Got answer:		;; global options: +cmd
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16429		;; Got answer:
	;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0		;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
			;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
	;; OPT PSEUDOSECTION:		;; OPT PSEUDOSECTION:
	; EDNS: version: 0, flags:; udp: 4096		; EDNS: version: 0, flags:; udp: 1232
	; ZONEVERSION: 2019073001 (SOA-SERIAL)		; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 (example.com.)")
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;www.example.com. IN AAAA		;www.example.com. IN AAAA
	;; ANSWER SECTION:		;; ANSWER SECTION:
	www.example.com. 900 IN AAAA		www.example.com. 43200 IN AAAA 2001:db8::80
	;; Query time: 53 msec		;; AUTHORITY SECTION:
	;; SERVER: ns.example.com#53(2001:DB8::53)		example.com. 43200 IN NS ns.example.com.
	;; WHEN: Tue Aug 07 16:54:05 -04 2018
	;; MSG SIZE rcvd: 71
	Figure 1		;; 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
	6. Acknowledgements		6. Acknowledgements
	The authors thanks all the comments and support made in the DNSOP		The authors thanks all the comments and support made in the DNSOP
	mailing list, chats and discussions. In special for the suggestions		mailing list, chats and discussions. Special thanks for the
	to generalize the option using a registry of flags from Petr Špaček,		suggestions to generalize the option using a registry of types from
	and suggestions for implementation from Stéphane Bortzmeyer.		Petr Špaček and Florian Obser, suggestions for implementation from
			Stéphane Bortzmeyer, security clarifications from George Michaelson,
			zone name disambiguation from Joe Abley and Brian Dickson, and
			reviews from Tim Wicinski and Peter Thomassen.
	7. IANA Considerations		7. IANA Considerations
	7.1. DNS EDNS0 Option Code Registration		7.1. DNS EDNS0 Option Code Registration
	This document defines a new EDNS0 option, entitled "ZONEVERSION" (see		This document defines a new EDNS0 option, entitled ZONEVERSION (see
	Section 2), and assigns a value of <TBD> from the DNS EDNS0 Option		Section 2), and assigns a value of <TBD> from the DNS EDNS0 Option
	Codes (OPT) Option space:		Codes (OPT) Option space:
	+=======+=============+==========+=================+		+=======+=============+==========+=================+
	| Value | Name | Status | Reference |		| Value | Name | Status | Reference |
	+=======+=============+==========+=================+		+=======+=============+==========+=================+
	| <TBD> | ZONEVERSION | Standard | [this document] |		| <TBD> | ZONEVERSION | Standard | [this document] |
	+=======+=============+==========+=================+		+=======+=============+==========+=================+
	Table 1		Table 1: DNS EDNS0 Option code
	[RFC Editor: change <TBD> to the proper code when assigned by IANA.]
	[RFC Editor: change "this document" with the proper RFC number for
	this document when assigned by IANA.]
	7.2. ZONEVERSION Registry		7.2. ZONEVERSION Registry
	The ZONEVERSION option also defines a 8-bit Flag field, for which		The ZONEVERSION option also defines a 8-bit TYPE field, for which
	IANA is to create and maintain a new registry entitled "DNS EDNS0		IANA is requested to create and maintain a new registry entitled
	ZONEVERSION Flags values" (abbreviation "ZONEVERSION") used by the		"ZONEVERSION TYPE Values" (abbreviation ZONEVERSION) used by the
	ZONEVERSION option, inside the "Domain Name System (DNS) Parameters"		ZONEVERSION option, inside the "Domain Name System (DNS) Parameters"
	group. Initial values for the DNS EDNS0 ZONEVERSION Flags values		group. Initial values for the ZONEVERSION TYPE values registry are
	registry are given below; future assignments in the 1-245 values are		given below; future assignments in the 1-245 values are to be made
	to be made through Specification Required Review [BCP26].		through Specification Required Review [BCP26]. Assignments consist
	Assignments consist of a Flag value as an unsigned 8-bit integer		of a TYPE value as an unsigned 8-bit integer recorded in decimal, a
	recorded in decimal, a Mnemonic name as an uppercase ASCII string		Mnemonic name as an uppercase ASCII string with maximum length of 15
	with maximum length of 15 characters, and the required document		characters, and the required document reference.
	reference.
	+==================+=====================+=================+
	| ZONEVERSION Flag | Mnemonic | Reference |
	+==================+=====================+=================+
	| 0 | SOA-SERIAL | [this document] |
	+==================+=====================+=================+
	| 1-245 | Unassigned | |
	+==================+=====================+=================+
	| 246-254 | Reserved for Local/ | [this document] |
	| | Experimental Use | |
	+==================+=====================+=================+
	| 255 | Reserved for future | [this document] |
	| | expansion | |
	+==================+=====================+=================+
	Table 2		+==================+==================+=================+
			| ZONEVERSION TYPE | Mnemonic | Reference |
			+==================+==================+=================+
			| 0 | SOA-SERIAL | [this document] |
			+==================+==================+=================+
			| 1-245 | Unassigned | |
			+==================+==================+=================+
			| 246-254 | Private Use | [this document] |
			+==================+==================+=================+
			| 255 | Reserved for | [this document] |
			| | future expansion | |
			+==================+==================+=================+
	[RFC Editor: change "this document" with the proper RFC number for		Table 2: ZONEVERSION Registry
	this document when assigned by IANA.]
	The change control for this registry should be my means of an		The change control for this registry should be by means of an
	Standard action.		Standard action.
	7.2.1. Expert Review Directives		7.2.1. Expert Review Directives
	Allocation procedures for new code points in the ZONEVERSION Flag		Allocation procedures for new code points in the ZONEVERSION TYPE
	registry require Specification Required review, and so it requires		registry require Specification Required review, and so it requires
	Expert Reviews as stated in [BCP26].		Expert Reviews as stated in [BCP26].
	The expert should consider the following points:		The expert should consider the following points:
	* Duplication of code point allocations should be avoided.		* Duplication of code point allocations should be avoided.
	* A Presentation Format section should be provided, with a clear		* A Presentation Format section should be provided, with a clear
	code point mnemonic.		code point mnemonic.
	* The referenced document and stated use of the new code point		* The referenced document and stated use of the new code point
	should be appropriate for the intended use of a ZONEVERSION Flag		should be appropriate for the intended use of a ZONEVERSION TYPE
	assignment. In particular the reference should state clear		assignment. In particular the reference should state clear
	instructions for implementers about the syntax and semantic of the		instructions for implementers about the syntax and semantic of the
	data. Also the Length of the Data must have proper limits.		data. Also the Length of the Data must have proper limits.
	The expert reviewing the request MUST approve or disapprove the		The expert reviewing the request MUST approve or disapprove the
	request within 10 business days from when he or she received the		request within 10 business days from when she or he received the
	expert review request.		expert review request.
	8. Security Considerations		8. Security Considerations
	The EDNS extension data it's not covered by RRSIG records, so there's		The EDNS extension data it's not covered by RRSIG records, so there's
	no way to verify its authenticity nor integrity using DNSSEC and		no way to verify its authenticity nor integrity using DNSSEC and
	could theoretically be tampered by a person-in-the-middle if the		could theoretically be tampered by a person-in-the-middle if the
	transport is made by insecure means. Caution should be taken to use		transport is made by insecure means. Caution should be taken to use
	the EDNS ZONEVERSION data for any means besides troubleshooting and		the EDNS ZONEVERSION data for any means besides troubleshooting and
	debugging.		debugging.
	If there's a need to certify the ZONEVERSION trustworthiness, it will		If there's a need to certify the ZONEVERSION trustworthiness, it will
	be necessary to use an encrypted and authenticated DNS transport.		be necessary to use an encrypted and authenticated DNS transport,
			TSIG [RFC8945], or SIG(0) [RFC2931].
	If there's a need to authenticate data origin for the ZONEVERSION		If there's a need to authenticate data origin for the ZONEVERSION
	value, an answer with the SOA-SERIAL flag as defined above could be		value, an answer with the SOA-SERIAL type as defined above could be
	compared to a separate regular SOA query with DO flag, whose answer		compared to a separate regular SOA query with DO flag, whose answer
	shall be DNSSEC signed, with the cautions about Anycast and others as		shall be DNSSEC signed, with the cautions about Anycast and others as
	already stated in Introduction.		already stated in Introduction.
	With the SOA-SERIAL flag defined above, there's no risk on disclosure		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		of private information, as the SERIAL of the SOA record is already
	publicly available.		publicly available.
			Please note that the ZONEVERSION option can not be used for checking
			the correctness of an entire zone in a server. For such cases, the
			ZONEMD record [RFC8976] might be better suited at such a task.
			ZONEVERSION can help identify and correlate a certain 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.
	9. Normative References		9. Normative References
	[BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<https://www.rfc-editor.org/info/rfc1034>.		<https://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <https://www.rfc-editor.org/info/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		[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
	for DNS (EDNS(0))", STD 75, RFC 6891,		for DNS (EDNS(0))", STD 75, RFC 6891,
	DOI 10.17487/RFC6891, April 2013,		DOI 10.17487/RFC6891, April 2013,
	<https://www.rfc-editor.org/info/rfc6891>.		<https://www.rfc-editor.org/info/rfc6891>.
	10. Informative References		10. Informative References
			[BCP14] Best Current Practice 14,
			<https://www.rfc-editor.org/info/bcp14>.
			At the time of writing, this BCP comprises the following:
			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>.
			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] Salgado, H., "Zoneversion Implementations", 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		[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
	Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,		Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
	December 2006, <https://www.rfc-editor.org/info/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>.
	[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,		Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
	January 2019, <https://www.rfc-editor.org/info/rfc8499>.		January 2019, <https://www.rfc-editor.org/info/rfc8499>.
			[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>.
	Appendix A. Implementation Considerations		Appendix A. Implementation Considerations
	With very few exceptions, EDNS options which elicit an EDNS option in		With very few exceptions, EDNS options which elicit an EDNS option in
	the response are independent of the QNAME. This is not the case of		the response are independent of the queried name. This is not the
	ZONEVERSION, so its implementation may be more or less difficult		case of ZONEVERSION, so its implementation may be more or less
	depending on how EDNS options are handled in the name server.		difficult depending on how EDNS options are handled in the name
			server.
	Appendix B. Implementation References		Appendix B. Implementation References
	There's a patched NSD server version 4.3.7 with support for		There's a patched NSD server version 4.7.0 with support for
	ZONEVERSION with the experimental opcode 65024 maintained in		ZONEVERSION with an experimental opcode, with live test servers
	https://github.com/huguei/nsd/tree/rrserial with SOA-SERIAL flag		installed for compliance tests. Also there is a client command "dig"
	support, and installed for live testing in 200.1.122.30 address with		with added zoneversion support, along with test libraries in Perl,
	configured zones dateserial.example.com. and incserial.example.com.;		Python and Go. More information in the working document [ImplRef].
	with MX, TXT and AAAA apex records.
	Authors' Addresses		Authors' Addresses
	Hugo Salgado		Hugo Salgado
	NIC Chile		NIC Chile
	Miraflores 222, piso 14		Miraflores 222, piso 14
	CP 8320198 Santiago		CP 8320198 Santiago
	Chile		Chile
	Phone: +56 2 29407700		Phone: +56 2 29407700
	Email: hsalgado@nic.cl		Email: hsalgado@nic.cl
	Mauricio Vergara Ereche		Mauricio Vergara Ereche
	DigitalOcean		DigitalOcean
	101 6th Ave		101 6th Ave
	New York, NY 10013		New York, NY 10013
	United States of America		United States of America
	Email: mvergara@digitalocean.com		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
End of changes. 70 change blocks.
	217 lines changed or deleted		359 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/