draft-ietf-dnsop-zoneversion-08.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: 14 December 2024 DigitalOcean		Expires: 2 January 2025 DigitalOcean
	D. Wessels		D. Wessels
	Verisign		Verisign
	12 June 2024		1 July 2024
	The DNS Zone Version (ZONEVERSION) Option		The DNS Zone Version (ZONEVERSION) Option
	draft-ietf-dnsop-zoneversion-08		draft-ietf-dnsop-zoneversion-09
	Abstract		Abstract
	The DNS ZONEVERSION option is a way for DNS clients to request, and		The DNS ZONEVERSION option is a way for DNS clients to request, and
	for authoritative DNS servers to provide, information regarding the		for authoritative DNS servers to provide, information regarding the
	version of the zone from which a response is generated. The Serial		version of the zone from which a response is generated. The Serial
	field from the Start Of Authority (SOA) resource record is a good		field from the Start Of Authority (SOA) resource record is a good
	example of a zone's version, and the only one defined by this		example of a zone's version, and the only one defined by this
	specification. Additional version types may be defined by future		specification. Additional version types may be defined by future
	specifications.		specifications.
	Including zone version data in a response simplifies and improves the		Including zone version data in a response simplifies and improves the
	quality of debugging and diagnostics since the version and the data		quality of debugging and diagnostics since the version and the DNS
	are provided atomically. This can be especially useful for zones and		answer are provided atomically. This can be especially useful for
	DNS providers that leverage IP anycast or multiple backend systems.		zones and DNS providers that leverage IP anycast or multiple backend
	It functions similarly to the DNS Name Server Identifier (NSID)		systems. It functions similarly to the DNS Name Server Identifier
	option [RFC5001].		(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 14 December 2024.		This Internet-Draft will expire on 2 January 2025.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 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
	skipping to change at page 2, line 30 ¶		skipping to change at page 2, line 30 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. The ZONEVERSION Option . . . . . . . . . . . . . . . . . . . 4		2. The ZONEVERSION Option . . . . . . . . . . . . . . . . . . . 4
	2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Presentation Format . . . . . . . . . . . . . . . . . . . 5		2.2. Presentation Format . . . . . . . . . . . . . . . . . . . 5
	3. ZONEVERSION Processing . . . . . . . . . . . . . . . . . . . 5		3. ZONEVERSION Processing . . . . . . . . . . . . . . . . . . . 5
	3.1. Initiators . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Initiators . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Responders . . . . . . . . . . . . . . . . . . . . . . . 6		3.2. Responders . . . . . . . . . . . . . . . . . . . . . . . 6
	4. The SOA-SERIAL ZONEVERSION Type . . . . . . . . . . . . . . . 6		3.2.1. ZONEVERSION Is Not Transitive . . . . . . . . . . . . 7
			4. The SOA-SERIAL ZONEVERSION Type . . . . . . . . . . . . . . . 7
	4.1. Type SOA-SERIAL Presentation Format . . . . . . . . . . . 7		4.1. Type SOA-SERIAL Presentation Format . . . . . . . . . . . 7
	5. Example usage . . . . . . . . . . . . . . . . . . . . . . . . 7		5. Example usage . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7.1. DNS EDNS0 Option Code Registration . . . . . . . . . . . 9		7.1. DNS EDNS0 Option Code Registration . . . . . . . . . . . 9
	7.2. ZONEVERSION Registry . . . . . . . . . . . . . . . . . . 9		7.2. ZONEVERSION Registry . . . . . . . . . . . . . . . . . . 9
	7.2.1. Expert Review Directives . . . . . . . . . . . . . . 10		7.2.1. Expert Review Directives . . . . . . . . . . . . . . 10
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. Normative References . . . . . . . . . . . . . . . . . . . . 11		9. Normative References . . . . . . . . . . . . . . . . . . . . 11
	10. Informative References . . . . . . . . . . . . . . . . . . . 11		10. Informative References . . . . . . . . . . . . . . . . . . . 11
	Appendix A. Implementation Considerations . . . . . . . . . . . 12		Appendix A. Implementation Considerations . . . . . . . . . . . 12
	Appendix B. Implementation References . . . . . . . . . . . . . 12		Appendix B. Implementation References . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The ZONEVERSION option allows DNS queriers to request, and		The ZONEVERSION option allows DNS queriers to request, and
	authoritative DNS severs to provide, a token representing the version		authoritative DNS servers to provide, a token representing the
	of the zone from which a DNS response was generated. It is similar		version of the zone from which a DNS response was generated. It is
	to the NSID option, which can be used to convey the identification of		similar to the NSID option [RFC5001], which can be used to convey the
	a name server that generates a response.		identification of a name server that generates a response.
	The Domain Name System allows data to be loosely coherent [RFC3254],		The Domain Name System allows data to be loosely coherent [RFC3254],
	because synchronization can never be instantaneous, and some uses of		because synchronization can never be instantaneous, and some uses of
	DNS do not require strong coherency anyway. This means that a record		DNS do not require strong coherency anyway. This means that a record
	obtained by one response could be out-of-sync with other		obtained by one response could be out-of-sync with other
	authoritative sources of the same data at the same point in time.		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		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.		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		Furthermore, in today's Internet, it is common for high volume and
	important DNS zones to utilize IP anycast Section 4.9 of [RFC4786]		important DNS zones to utilize IP anycast Section 4.9 of [RFC4786]
	skipping to change at page 3, line 26 ¶		skipping to change at page 3, line 26 ¶
	The ZONEVERSION option both simplifies and improves the DNS		The ZONEVERSION option both simplifies and improves the DNS
	monitoring and debugging by directly associating the data and the		monitoring and debugging by directly associating the data and the
	version together in a single response.		version together in a single response.
	The SOA Serial field (Section 4.3.5 of [RFC1034]) is one example of		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 versioning. Its purpose is to facilitate the distribution of
	zone data between primary and secondary name servers. It is also		zone data between primary and secondary name servers. It is also
	often useful in DNS monitoring and debugging. This document		often useful in DNS monitoring and debugging. This document
	specifies the SOA Serial as one type of ZONEVERSION data.		specifies the SOA Serial as one type of ZONEVERSION data.
	Some DNS zones may use other distrubtion and synchronization		Some DNS zones may use other distribution and synchronization
	mechanisms not based on the SOA Serial number, such as relational		mechanisms not based on the SOA Serial number, such as relational
	databases or other proprietary methods. In those cases the SOA		databases or other proprietary methods. In those cases the SOA
	Serial field may not be relevant with respect to the versioning of		Serial field may not be relevant with respect to the versioning of
	its content. To accomodate these use cases, new ZONEVERSION types		its content. To accommodate these use cases, new ZONEVERSION types
	should be defined in future specifications. Alternatively, zone		could be defined in future specifications. Alternatively, zone
	operators may use one of the private use ZONEVERSION code points		operators may use one of the private use ZONEVERSION code points
	allocated by this specification.		allocated by this specification.
	The ZONEVERSION option is OPTIONAL to implement by DNS clients and		The ZONEVERSION option is OPTIONAL to implement by DNS clients and
	name servers. It is designed for use only when a name server		name servers. It is designed for use only when a name server
	provides authoritative response data. It is intended only for hop-		provides authoritative response data. It is intended only for hop-
	to-hop communication and is not transitive.		to-hop communication and is not transitive.
	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		1.2. Terminology
	In this document "original QNAME" is used to mean what the DNS		In this document "original QNAME" is used to mean what the DNS
	terminology document [RFC8499] calls "QNAME (original)":		terminology document [RFC8499] calls "QNAME (original)":
	| The name actually sent in the Question section in the original		| The name actually sent in the Question section in the original
	| query, which is always echoed in the (final) reply in the Question		| query, which is always echoed in the (final) reply in the Question
	| section when the QR bit is set to 1.		| section when the QR bit is set to 1.
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	OPTION-CODE for the ZONEVERSION option is <TBD>.		OPTION-CODE for the ZONEVERSION option is <TBD>.
	OPTION-LENGTH for the ZONEVERSION option MUST have a value of 0 for		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		queries, and MUST have the value of the length (in octets) of the
	OPTION-DATA for responses.		OPTION-DATA for responses.
	OPTION-DATA for the ZONEVERSION option is omitted in queries. For		OPTION-DATA for the ZONEVERSION option is omitted in queries. For
	responses it is composed of three fields:		responses it is composed of three fields:
	* An unsigned 1 octet Label Count (LABELCOUNT) indicating the number		* An unsigned 1-octet Label Count (LABELCOUNT) indicating the number
	of labels for the name of the zone that VERSION value refers to.		of labels for the name of the zone that VERSION value refers to.
	* An unsigned 1 octet type number (TYPE) that distinguishes the		* An unsigned 1-octet type number (TYPE) that distinguishes the
	format and meaning of VERSION.		format and meaning of VERSION.
	* An opaque octet string conveying the zone version data (VERSION).		* An opaque octet string conveying the zone version data (VERSION).
	+0 (MSB) +1 (LSB)		+0 (MSB) +1 (LSB)
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	0: | LABELCOUNT | TYPE |		0: | LABELCOUNT | TYPE |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	2: | VERSION |		2: | VERSION |
	/ /		/ /
	skipping to change at page 6, line 7 ¶		skipping to change at page 6, line 7 ¶
	ZONEVERSION option has OPTION-LENGTH set to zero.		ZONEVERSION option has OPTION-LENGTH set to zero.
	A DNS client SHOULD NOT send the ZONEVERSION option to non-		A DNS client SHOULD NOT send the ZONEVERSION option to non-
	authoritative name servers.		authoritative name servers.
	A DNS client MUST NOT include more than one ZONEVERSION option in the		A DNS client MUST NOT include more than one ZONEVERSION option in the
	OPT RR of a DNS query.		OPT RR of a DNS query.
	3.2. Responders		3.2. Responders
	A name server that (a) understands the ZONEVERSION option, (b) is		A name server that (a) understands the ZONEVERSION option, (b)
	authoritative for the original QNAME, and (c) chooses to honor a		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		particular ZONEVERSION request responds by including a TYPE and
	corresponding VERSION value in a ZONEVERSION option in an EDNS(0) OPT		corresponding VERSION value in a ZONEVERSION option in an EDNS(0) OPT
	pseudo-RR in the response message.		pseudo-RR in the response message.
	Otherwise, a server MUST NOT include a ZONEVERSION option in the		Otherwise, a server MUST NOT include a ZONEVERSION option in the
	response.		response.
	A name server MUST ignore invalid ZONEVERSION options present in the		A name server MUST ignore invalid ZONEVERSION options present in the
	query message.		query message.
	A name server MAY include more than one ZONEVERSION option in the		A name server MAY include more than one ZONEVERSION option in the
	response if it supports multiple TYPEs. A name server MUST NOT		response if it supports multiple TYPEs. A name server MAY also
	include more than one ZONEVERSION option for a given TYPE.		include more than one ZONEVERSION option in the response if it is
			authoritative for more than one zone of the corresponding QNAME. A
			name server MUST NOT include more than one ZONEVERSION option for a
			given TYPE and LABELCOUNT.
			A name server SHOULD include zone version information in a name error
			(NXDOMAIN) response, even though the response does not include any
			Answer section RRs.
	A name server SHOULD include zone version information for downward		A name server SHOULD include zone version information for downward
	referral responses (see "Referrals" in Section 4 of [RFC8499]). Even		referral responses (see "Referrals" in Section 4 of [RFC8499]). Even
	though the response's Authoritative Answer bit is not set, the name		though the response's Authoritative Answer bit is not set, the name
	server is authoritative for the zone from which the referral was		server is authoritative for the zone from which the referral was
	generated. In this case, the ZONEVERSION data MUST correspond to the		generated. In this case, the ZONEVERSION data MUST correspond to the
	version of the referring zone.		version of the referring zone.
	A name server SHOULD include zone version information in a server		A name server SHOULD include zone version information in a server
	failure (SERVFAIL) response when it is authoritative for the original		failure (SERVFAIL) response when it is authoritative for the original
	QNAME.		QNAME.
	A name server SHOULD include zone version information in a NODATA		A name server SHOULD include zone version information in a NODATA
	response (Section 3 of [RFC8499]). Even though the NODATA response		response (Section 3 of [RFC8499]). Even though the NODATA response
	does not include any Answer section RRs, the RCODE is NOERROR and the		does not include any Answer section RRs, the RCODE is NOERROR and the
	name server is still authoritative for the zone.		name server is still authoritative for the zone.
			3.2.1. ZONEVERSION Is Not Transitive
			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.
	4. The SOA-SERIAL ZONEVERSION Type		4. The SOA-SERIAL ZONEVERSION Type
	The first and only ZONEVERSION option TYPE defined in this document		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)		is a zone's serial number as found in the Start of Authority (SOA)
	RR.		RR.
	The value for this type is: 0		The value for this type is: 0
	The mnemonic of this type is: SOA-SERIAL.		The mnemonic of this type is: SOA-SERIAL.
	The OPTION-LENGTH for this type MUST be set to 6 in responses.		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		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		unsigned 32-bit SERIAL field of the SOA RR, as defined in
	Section 3.3.13 of [RFC1035].		Section 3.3.13 of [RFC1035].
	4.1. Type SOA-SERIAL Presentation Format		4.1. Type SOA-SERIAL Presentation Format
	The presentation format of this type content is as follows:		The presentation format of this type content is as follows:
	The TYPE field MUST be represented as the mnemonic value "SOA-		The TYPE field MUST be represented as the mnemonic value "SOA-
	SERIAL".		SERIAL".
	The VERSION field MUST be represented as an unsigned decimal integer.		The VERSION field MUST be represented as an unsigned decimal integer.
	5. Example usage		5. Example usage
	A name server which (a) implements this specification, (b) receives a		A name server which (a) implements this specification, (b) receives a
	query with the ZONEVERSION option, (c) is authoritative for the		query with the ZONEVERSION option, (c) is authoritative for the zone
	original QNAME, and (d) utilizes the SOA serial field for versioning		of the original QNAME, and (d) utilizes the SOA serial field for
	of said zone should include a ZONEVERSION option in its response. In		versioning of said zone should include a ZONEVERSION option in its
	the response's ZONEVERSION option the OPTION-LENGTH would be set to 6		response. In the response's ZONEVERSION option the EDNS(0) OPTION-
	and the OPTION-DATA would consist of the 1-octet LABELCOUNT, the		LENGTH would be set to 6 and the OPTION-DATA would consist of the
	1-octet TYPE with value 0, and 4-octet SOA SERIAL value.		1-octet LABELCOUNT, the 1-octet TYPE with value 0, and 4-octet SOA
			SERIAL value.
	The example below demonstrates expected output of a diagnostic tool		The example below demonstrates expected output of a diagnostic tool
	that implements the ZONEVERSION option, displaying a response from a		that implements the ZONEVERSION option, displaying a response from a
	compliant authoritative DNS server:		compliant authoritative DNS server:
	$ dig @ns.example.com www.example.com aaaa +zoneversion		$ dig @ns.example.com www.example.com aaaa +zoneversion +norecurse
	; <<>> DiG 9.17.14-patched <<>> @ns.example.com www.example.com aaaa +zoneversion		; <<>> DiG 9.17.14-patched <<>> @ns.example.com www.example.com aaaa +zoneversion
	; (1 server found)		; (1 server found)
	;; global options: +cmd		;; global options: +cmd
	;; Got answer:		;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077		;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
	;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2		;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
	;; OPT PSEUDOSECTION:		;; OPT PSEUDOSECTION:
	; EDNS: version: 0, flags:; udp: 1232		; EDNS: version: 0, flags:; udp: 1232
	skipping to change at page 9, line 31 ¶		skipping to change at page 9, line 31 ¶
	IANA is requested to create and maintain a new registry entitled		IANA is requested to create and maintain a new registry entitled
	"ZONEVERSION TYPE 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 ZONEVERSION TYPE values registry are		group. Initial values for the ZONEVERSION TYPE values registry are
	given below; future assignments in the 1-245 values are to be made		given below; future assignments in the 1-245 values are to be made
	through Specification Required Review [BCP26]. Assignments consist		through Specification Required Review [BCP26]. Assignments consist
	of a TYPE value as an unsigned 8-bit integer recorded in decimal, a		of a TYPE value as an unsigned 8-bit integer recorded in decimal, a
	Mnemonic name as an uppercase ASCII string with maximum length of 15		Mnemonic name as an uppercase ASCII string with maximum length of 15
	characters, and the required document reference.		characters, and the required document reference.
	+==================+=====================+=================+		+==================+==================+=================+
	| ZONEVERSION TYPE | Mnemonic | Reference |		| ZONEVERSION TYPE | Mnemonic | Reference |
	+==================+=====================+=================+		+==================+==================+=================+
	| 0 | SOA-SERIAL | [this document] |		| 0 | SOA-SERIAL | [this document] |
	+==================+=====================+=================+		+==================+==================+=================+
	| 1-245 | Unassigned | |		| 1-245 | Unassigned | |
	+==================+=====================+=================+		+==================+==================+=================+
	| 246-254 | Reserved for Local/ | [this document] |		| 246-254 | Private Use | [this document] |
	| | Experimental Use | |		+==================+==================+=================+
	+==================+=====================+=================+		| 255 | Reserved for | [this document] |
	| 255 | Reserved for future | [this document] |		| | future expansion | |
	| | expansion | |		+==================+==================+=================+
	+==================+=====================+=================+
	Table 2: ZONEVERSION Registry		Table 2: ZONEVERSION Registry
	The change control for this registry should be by 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 TYPE		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].
	skipping to change at page 11, line 28 ¶		skipping to change at page 11, line 28 ¶
	<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,		[ImplRef] Salgado, H., "Zoneversion Implementations", 2023,
	<https://github.com/huguei/rrserial>.		<https://github.com/huguei/rrserial>.
	[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures		[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
	( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September		( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September
	2000, <https://www.rfc-editor.org/info/rfc2931>.		2000, <https://www.rfc-editor.org/info/rfc2931>.
	[RFC3254] Alvestrand, H., "Definitions for talking about		[RFC3254] Alvestrand, H., "Definitions for talking about
	directories", RFC 3254, DOI 10.17487/RFC3254, April 2002,		directories", RFC 3254, DOI 10.17487/RFC3254, April 2002,
	<https://www.rfc-editor.org/info/rfc3254>.		<https://www.rfc-editor.org/info/rfc3254>.
End of changes. 23 change blocks.
	54 lines changed or deleted		82 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/