rfc9660v2.txt		rfc9660.txt
	skipping to change at line 105 ¶		skipping to change at line 105 ¶
	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])
	and/or load-balanced backend servers. In general, there is no way to		and/or load-balanced backend servers. In general, there is no way to
	ensure that two separate queries are delivered to the same server.		ensure that two separate queries are delivered to the same server.
	The ZONEVERSION option both simplifies and improves the DNS		The ZONEVERSION option both simplifies and improves DNS monitoring
	monitoring and debugging by directly associating the data and the		and debugging by directly associating the data and the version
	version together in a single response.		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 distribution and synchronization		Some DNS zones may use other distribution and synchronization
	mechanisms that are not based on the SOA SERIAL number, such as		mechanisms that are not based on the SOA SERIAL number, such as
	relational databases or other proprietary methods. In those cases,		relational databases or other proprietary methods. In those cases,
	skipping to change at line 220 ¶		skipping to change at line 220 ¶
	2.2. Presentation Format		2.2. Presentation Format
	The presentation format of the ZONEVERSION option is as follows:		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 MAY be omitted, but if present, it MUST be		The OPTION-LENGTH field MAY be omitted, but if present, it MUST be
	represented as an unsigned decimal integer.		represented as an unsigned decimal integer.
	The LABELCOUNT value of OPTION-DATA field MAY be omitted, but if		The LABELCOUNT value of the OPTION-DATA field MAY be omitted, but if
	present, it MUST be represented as an unsigned decimal integer. The		present, it MUST be represented as an unsigned decimal integer. The
	corresponding zone name SHOULD be displayed (i.e., LABELCOUNT labels		corresponding zone name SHOULD be displayed (i.e., LABELCOUNT labels
	of the original QNAME) for easier human consumption.		of the original QNAME) for easier human consumption.
	The TYPE and VERSION fields of the option SHOULD be represented		The TYPE and VERSION fields of the option SHOULD be represented
	according to each specific TYPE.		according to each specific TYPE.
	3. ZONEVERSION Processing		3. ZONEVERSION Processing
	3.1. Initiators		3.1. Initiators
	skipping to change at line 349 ¶		skipping to change at line 349 ¶
	1-octet LABELCOUNT, the 1-octet TYPE with value 0, and the 4-octet		1-octet LABELCOUNT, the 1-octet TYPE with value 0, and the 4-octet
	SOA-SERIAL value.		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 +nocmd		+norecurse +nocmd
	; (1 server found)
	;; 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
	; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 \		; ZONEVERSION: 02 00 78 95 a4 e9 ("SOA-SERIAL: 2023073001 \
	; (example.com.)")		; (example.com.)")
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;www.example.com. IN AAAA		;www.example.com. IN AAAA
	skipping to change at line 558 ¶		skipping to change at line 556 ¶
	Hardaker, "Message Digest for DNS Zones", RFC 8976,		Hardaker, "Message Digest for DNS Zones", RFC 8976,
	DOI 10.17487/RFC8976, February 2021,		DOI 10.17487/RFC8976, February 2021,
	<https://www.rfc-editor.org/info/rfc8976>.		<https://www.rfc-editor.org/info/rfc8976>.
	[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,		[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
	RFC 9499, DOI 10.17487/RFC9499, March 2024,		RFC 9499, DOI 10.17487/RFC9499, March 2024,
	<https://www.rfc-editor.org/info/rfc9499>.		<https://www.rfc-editor.org/info/rfc9499>.
	Appendix A. Implementation Considerations		Appendix A. Implementation Considerations
	With very few exceptions, EDNS options that elicit an EDNS option in		With very few exceptions, EDNS(0) option values in a response are
	the response are independent of the queried name. This is not the		independent of the queried name. This is not the case for
	case for ZONEVERSION, so its implementation may be more or less		ZONEVERSION, so its implementation may be more or less difficult,
	difficult, depending on how EDNS options are handled in the name		depending on how EDNS(0) options are handled in the name server.
	server.
	Appendix B. Implementation References		Appendix B. Implementation References
	There is a patched NSD server (version 4.7.0) with support for		There is a patched NSD server (version 4.7.0) with support for
	ZONEVERSION with an experimental opcode as well as live test servers		ZONEVERSION as well as live test servers installed for compliance
	installed for compliance tests. Also, there is a client command		tests. Also, there is a client command "dig" with added zoneversion
	"dig" with added zoneversion support, along with test libraries in		support, along with test libraries in Perl, Python, and Go. See
	Perl, Python, and Go. See [ImplRef] for more information.		[ImplRef] for more information.
	Acknowledgements		Acknowledgements
	The authors are thankful for all the support and comments made in the		The authors are thankful for all the support and comments made in the
	DNSOP Working Group mailing list, chats, and discussions. A special		DNSOP Working Group mailing list, chats, and discussions. A special
	thanks for suggestions to generalize the option using a registry of		thanks for suggestions to generalize the option using a registry of
	types from Petr Špaček and Florian Obser, suggestions for		types from Petr Špaček and Florian Obser, suggestions for
	implementation from Stéphane Bortzmeyer, clarifications on security		implementation from Stéphane Bortzmeyer, clarifications on security
	from George Michaelson, zone name disambiguation from Joe Abley and		from George Michaelson, zone name disambiguation from Joe Abley and
	Brian Dickson, and reviews from Tim Wicinski and Peter Thomassen.		Brian Dickson, and reviews from Tim Wicinski and Peter Thomassen.
End of changes. 5 change blocks.
	15 lines changed or deleted		12 lines changed or added
This html diff was produced by rfcdiff 1.48.