Diff: rfc9471.original.xml

	rfc9471.original.xml	rfc9471.xml

	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="UTF-8"?>

		<!DOCTYPE rfc [
		<!ENTITY nbsp " ">
		<!ENTITY zwsp "">
		<!ENTITY nbhy "‑">
		<!ENTITY wj "⁠">
		]>

	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process or - mmark.miek.nl" -->	<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Process or - mmark.miek.nl" -->

	<rfc version="3" ipr="trust200902" docName="draft-ietf-dnsop-glue-is-not-optiona
	l-09" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3	<rfc version="3" ipr="trust200902" docName="draft-ietf-dnsop-glue-is-not-optiona
	.org/2001/XInclude" updates="1034" indexInclude="false" consensus="true">	l-09" number="9471" submissionType="IETF" category="std" consensus="true" xml:la
		ng="en" xmlns:xi="http://www.w3.org/2001/XInclude"
		tocInclude="true" symRefs="true" sortRefs="true" updates="1034" obsoletes="">

	<front>	<front>

	<title>DNS Glue Requirements in Referral Responses</title><seriesInfo value="dra	<title abbrev="DNS Glue Requirements">DNS Glue Requirements in Referral Respon
	ft-ietf-dnsop-glue-is-not-optional-09" stream="IETF" status="standard" name="Int	ses</title>
	ernet-Draft"></seriesInfo>
	<author initials="M." surname="Andrews" fullname="M. Andrews"><organization>ISC<	<seriesInfo name="RFC" value="9471"/>
	/organization><address><postal><street></street>	<author initials="M." surname="Andrews" fullname="M. Andrews">
	</postal><email>marka@isc.org</email>	<organization>ISC</organization>
	</address></author><author initials="S." surname="Huque" fullname="Shumon Huque"	<address><postal><street></street>
	><organization>Salesforce</organization><address><postal><street></street>	</postal>
	</postal><email>shuque@gmail.com</email>	<email>marka@isc.org</email>
	</address></author><author initials="P." surname="Wouters" fullname="Paul Wouter	</address>
	s"><organization>Aiven</organization><address><postal><street></street>	</author>
	</postal><email>paul.wouters@aiven.io</email>	<author initials="S." surname="Huque" fullname="Shumon Huque">
	</address></author><author initials="D." surname="Wessels" fullname="Duane Wesse	<organization>Salesforce</organization>
	ls"><organization>Verisign</organization><address><postal><street></street>	<address><postal><street></street>
	</postal><email>dwessels@verisign.com</email>	</postal>
	</address></author><date/>	<email>shuque@gmail.com</email>
	<area>Operations</area>	</address>
	<workgroup>DNSOP</workgroup>	</author><author initials="P." surname="Wouters" fullname="Paul Wouters">
		<organization>Aiven</organization>
		<address><postal><street></street>
		</postal>
		<email>paul.wouters@aiven.io</email>
		</address>
		</author><author initials="D." surname="Wessels" fullname="Duane Wessels">
		<organization>Verisign</organization>
		<address><postal><street></street>
		</postal>
		<email>dwessels@verisign.com</email>
		</address>
		</author>
		<date year="2023" month="September" />
		<area>ops</area>
		<workgroup>dnsop</workgroup>

		<keyword>Glue Record</keyword>
		<keyword>In-Domain Name Server</keyword>
		<keyword>Sibling Domain Name Server</keyword>

	<abstract>	<abstract>
	<t>The DNS uses glue records to allow iterative clients to find the	<t>The DNS uses glue records to allow iterative clients to find the
	addresses of name servers that are contained within a delegated zone.	addresses of name servers that are contained within a delegated zone.

	Authoritative Servers are expected to return all available glue records for i n-domain name servers	Authoritative servers are expected to return all available glue records for i n-domain name servers
	in a referral response. If message size constraints prevent the inclusion of all	in a referral response. If message size constraints prevent the inclusion of all

	glue records for in-domain name servers, the server must set the TC flag to	glue records for in-domain name servers, the server must set the TC (Truncate
	inform the client that the response is incomplete, and that the client	d) flag to
		inform the client that the response is incomplete and that the client
	should use another transport to retrieve the full response.	should use another transport to retrieve the full response.
	This document updates RFC 1034 to clarify correct server behavior.</t>	This document updates RFC 1034 to clarify correct server behavior.</t>
	</abstract>	</abstract>

	</front>	</front>

	<middle>	<middle>

	<section anchor="introduction"><name>Introduction</name>	<section anchor="introduction"><name>Introduction</name>

	<t>The Domain Name System (DNS) <xref target="RFC1034"></xref>, <xref target="RF C1035"></xref> uses glue records	<t>The Domain Name System (DNS) <xref target="RFC1034"></xref> <xref target="RFC 1035"></xref> uses glue records
	to allow iterative clients to find the addresses of name servers that are	to allow iterative clients to find the addresses of name servers that are
	contained within a delegated zone. Glue records are added to the parent	contained within a delegated zone. Glue records are added to the parent

	zone as part of the delegation process and returned in referral responses,	zone as part of the delegation process and returned in referral responses;
	otherwise a resolver following the referral has no way of finding these	otherwise, a resolver following the referral has no way of finding these
	addresses. Authoritative servers are expected to return all available	addresses. Authoritative servers are expected to return all available
	glue records for in-domain name servers in a referral response. If message si ze constraints prevent the	glue records for in-domain name servers in a referral response. If message si ze constraints prevent the

	inclusion of all glue records for in-domain name servers over the chosen tran	inclusion of all glue records for in-domain name servers over the chosen tran
	sport, the server MUST set the	sport, the server <bcp14>MUST</bcp14> set the
	TC (Truncated) flag to inform the client that the response is incomplete,	TC (Truncated) flag to inform the client that the response is incomplete
	and that the client SHOULD use another transport to retrieve the full respons	and that the client <bcp14>SHOULD</bcp14> use another transport to retrieve t
	e. This	he full response. This
	document clarifies that expectation.</t>	document clarifies that expectation.</t>
	<t>DNS responses sometimes contain optional data in the additional	<t>DNS responses sometimes contain optional data in the additional
	section. In-domain glue records, however, are not optional. Several other	section. In-domain glue records, however, are not optional. Several other
	protocol extensions, when used, are also not optional. This	protocol extensions, when used, are also not optional. This
	includes TSIG <xref target="RFC8945"></xref>, OPT <xref target="RFC6891"></xr ef>, and SIG(0) <xref target="RFC2931"></xref>.</t>	includes TSIG <xref target="RFC8945"></xref>, OPT <xref target="RFC6891"></xr ef>, and SIG(0) <xref target="RFC2931"></xref>.</t>
	<t>At the time of this writing, addresses (A or AAAA records) for	<t>At the time of this writing, addresses (A or AAAA records) for
	a delegation's authoritative name servers are the only type of	a delegation's authoritative name servers are the only type of
	glue defined for the DNS.</t>	glue defined for the DNS.</t>

	<t>Note that this document only clarifies requirements of name server	<t>Note that this document only clarifies requirements for name server
	software implementations. It does not introduce or change any requirements o	software implementations. It does not introduce or change any requirements r
	n	egarding data placed in DNS zones or registries.
	data placed in DNS zones or registries.	In other words, this document only makes requirements regarding "availab
	In other words, this document only makes requirements on "available	le
	glue records" (i.e., those given in a zone), but does not make	glue records" (i.e., those given in a zone) but does not make
	requirements regarding their presence in a zone.	requirements regarding their presence in a zone.
	If some glue records are absent from a given zone, an authoritative	If some glue records are absent from a given zone, an authoritative
	name server may be unable to return a useful referral response for	name server may be unable to return a useful referral response for
	the corresponding domain. The IETF may want to consider a separate	the corresponding domain. The IETF may want to consider a separate
	update to the requirements for including glue in zone data, beyond	update to the requirements for including glue in zone data, beyond
	those given in <xref target="RFC1034"></xref> and <xref target="RFC1035"></xr ef>.</t>	those given in <xref target="RFC1034"></xref> and <xref target="RFC1035"></xr ef>.</t>
	<t>This document assumes a reasonable level of familiarity with DNS	<t>This document assumes a reasonable level of familiarity with DNS
	operations and protocol terms. Much of the terminology is explained	operations and protocol terms. Much of the terminology is explained

	in further detail in "DNS Terminology" <xref target="RFC8499"></xre f>.</t>	in further detail in "<xref target="RFC8499" format="title"/>" <xref target=" RFC8499" format="default"/>.</t>


	<section anchor="reserved-words"><name>Reserved Words</name>	<section anchor="requirements-language"><name>Requirements Language</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", &	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	quot;SHALL", "SHALL NOT",	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NO	"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	T RECOMMENDED", "MAY",	"<bcp14>SHOULD NOT</bcp14>",
	and "OPTIONAL" in this document are to be interpreted as described	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when,	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	and only when, they	are to be interpreted as described in BCP 14
	appear in all capitals, as shown here.</t>	<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
		when, they appear in all capitals, as shown here.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="types-of-glue-in-referral-responses"><name>Types of Glue in Ref erral Responses</name>	<section anchor="types-of-glue-in-referral-responses"><name>Types of Glue in Ref erral Responses</name>
	<t>This section describes different types of glue that may be found in	<t>This section describes different types of glue that may be found in
	DNS referral responses. Note that the type of glue depends on	DNS referral responses. Note that the type of glue depends on
	the QNAME. A particular name server (and its corresponding glue record) can be in-domain for one response	the QNAME. A particular name server (and its corresponding glue record) can be in-domain for one response
	and in a sibling domain for another.</t>	and in a sibling domain for another.</t>

	<section anchor="indomainglue"><name>Glue for In-Domain Name Servers</name>	<section anchor="indomainglue"><name>Glue for In-Domain Name Servers</name>

	skipping to change at line 112 ¶	skipping to change at line 149 ¶
	foo.test. 86400 IN NS ns2.foo.test.	foo.test. 86400 IN NS ns2.foo.test.

	;; ADDITIONAL SECTION:	;; ADDITIONAL SECTION:
	ns1.foo.test. 86400 IN A 192.0.2.1	ns1.foo.test. 86400 IN A 192.0.2.1
	ns2.foo.test. 86400 IN AAAA 2001:db8::2:2	ns2.foo.test. 86400 IN AAAA 2001:db8::2:2
	</artwork>	</artwork>
	</section>	</section>

	<section anchor="siblingglue"><name>Glue for Sibling Domain Name Servers</name>	<section anchor="siblingglue"><name>Glue for Sibling Domain Name Servers</name>
	<t>Sibling domain name servers are NS records that are not contained in the dele gated	<t>Sibling domain name servers are NS records that are not contained in the dele gated

	zone itself, but in another zone delegated from the same parent. In many	zone itself but rather are contained in another zone delegated from the same
	cases, glue for sibling domain name servers are not strictly required for res	parent. In many
	olution, since the resolver	cases, glue for sibling domain name servers is not strictly required for reso
		lution, since the resolver
	can make follow-on queries to the sibling zone to resolve the name server	can make follow-on queries to the sibling zone to resolve the name server
	addresses (after following the referral to the sibling zone). However,	addresses (after following the referral to the sibling zone). However,
	most name server implementations today provide them as an optimization	most name server implementations today provide them as an optimization
	to obviate the need for extra traffic from iterative resolvers.</t>	to obviate the need for extra traffic from iterative resolvers.</t>

	<t>Here the delegating zone "test" contains two delegations for the	<t>Here, the delegating zone "test" contains two delegations for the
	child zones "bar.test" and "foo.test":</t>	child zones "bar.test" and "foo.test":</t>

	<artwork> bar.test. 86400 IN NS ns1.bar.test.	<artwork> bar.test. 86400 IN NS ns1.bar.test.
	bar.test. 86400 IN NS ns2.bar.test.	bar.test. 86400 IN NS ns2.bar.test.
	ns1.bar.test. 86400 IN A 192.0.2.1	ns1.bar.test. 86400 IN A 192.0.2.1
	ns2.bar.test. 86400 IN AAAA 2001:db8::2:2	ns2.bar.test. 86400 IN AAAA 2001:db8::2:2

	foo.test. 86400 IN NS ns1.bar.test.	foo.test. 86400 IN NS ns1.bar.test.
	foo.test. 86400 IN NS ns2.bar.test.	foo.test. 86400 IN NS ns2.bar.test.
	</artwork>	</artwork>

	skipping to change at line 151 ¶	skipping to change at line 188 ¶
	ns2.bar.test. 86400 IN AAAA 2001:db8::2:2	ns2.bar.test. 86400 IN AAAA 2001:db8::2:2
	</artwork>	</artwork>
	</section>	</section>

	<section anchor="siblingcyclicglue"><name>Glue for Cyclic Sibling Domain Name Se rvers</name>	<section anchor="siblingcyclicglue"><name>Glue for Cyclic Sibling Domain Name Se rvers</name>
	<t>The use of sibling domain name servers can introduce cyclic dependencies. Th is	<t>The use of sibling domain name servers can introduce cyclic dependencies. Th is
	happens when one domain specifies name servers from a sibling domain,	happens when one domain specifies name servers from a sibling domain,
	and vice versa. This type of cyclic dependency can only be	and vice versa. This type of cyclic dependency can only be
	broken when the delegating name server includes glue for the sibling	broken when the delegating name server includes glue for the sibling
	domain in a referral response.</t>	domain in a referral response.</t>

	<t>Here the delegating zone "test" contains two delegations for the	<t>Here, the delegating zone "test" contains two delegations for the
	child zones "bar.test" and "foo.test", and each use name	child zones "bar.test" and "foo.test", and each uses name
	servers under	servers under
	the other:</t>	the other:</t>

	<artwork> bar.test. 86400 IN NS ns1.foo.test.	<artwork> bar.test. 86400 IN NS ns1.foo.test.
	bar.test. 86400 IN NS ns2.foo.test.	bar.test. 86400 IN NS ns2.foo.test.
	ns1.bar.test. 86400 IN A 192.0.2.1	ns1.bar.test. 86400 IN A 192.0.2.1
	ns2.bar.test. 86400 IN AAAA 2001:db8::2:2	ns2.bar.test. 86400 IN AAAA 2001:db8::2:2

	foo.test. 86400 IN NS ns1.bar.test.	foo.test. 86400 IN NS ns1.bar.test.
	foo.test. 86400 IN NS ns2.bar.test.	foo.test. 86400 IN NS ns2.bar.test.
	ns1.foo.test. 86400 IN A 192.0.2.3	ns1.foo.test. 86400 IN A 192.0.2.3

	skipping to change at line 179 ¶	skipping to change at line 216 ¶
	;www.bar.test. IN A	;www.bar.test. IN A

	;; AUTHORITY SECTION:	;; AUTHORITY SECTION:
	bar.test. 86400 IN NS ns1.foo.test.	bar.test. 86400 IN NS ns1.foo.test.
	bar.test. 86400 IN NS ns2.foo.test.	bar.test. 86400 IN NS ns2.foo.test.

	;; ADDITIONAL SECTION:	;; ADDITIONAL SECTION:
	ns1.foo.test. 86400 IN A 192.0.2.3	ns1.foo.test. 86400 IN A 192.0.2.3
	ns2.foo.test. 86400 IN AAAA 2001:db8::2:4	ns2.foo.test. 86400 IN AAAA 2001:db8::2:4
	</artwork>	</artwork>

	<t>In late 2021 the authors analyzed zone file data available from ICANN's	<t>In late 2021, the authors analyzed zone file data available from ICANN's
	Centralized Zone Data Service <xref target="CZDS"></xref> and found 222 out o f approximately	Centralized Zone Data Service <xref target="CZDS"></xref> and found 222 out o f approximately

	209,000,000 total delegations that had only sibling domain NS RRs in a cyclic	209,000,000 total delegations that had only sibling domain NS Resource Record s (RRs) in a cyclic
	dependency as above.</t>	dependency as above.</t>
	</section>	</section>

	<section anchor="missing-glue"><name>Missing Glue</name>	<section anchor="missing-glue"><name>Missing Glue</name>

	<t>An example of missing glue is included here, even though it can not be consid ered	<t>An example of missing glue is included here, even though it cannot be conside red
	as a type of glue. While not common, real examples of responses	as a type of glue. While not common, real examples of responses
	that lack required glue, and with TC=0, have been shown to occur and	that lack required glue, and with TC=0, have been shown to occur and
	cause resolution failures.</t>	cause resolution failures.</t>
	<t>The example below, from the dig command <xref target="DIG"></xref>, is based on a response observed in June 2020. The names have	<t>The example below, from the dig command <xref target="DIG"></xref>, is based on a response observed in June 2020. The names have
	been altered to fall under documentation domains. It shows a case where none of	been altered to fall under documentation domains. It shows a case where none of
	the glue records present in the zone fit into the available space of the UDP response, and	the glue records present in the zone fit into the available space of the UDP response, and
	the TC flag was not set. While this example shows a referral with DNSSEC rec ords	the TC flag was not set. While this example shows a referral with DNSSEC rec ords

	<xref target="RFC4033"></xref>, <xref target="RFC4034"></xref>, <xref target= "RFC4035"></xref>, this behavior has	<xref target="RFC4033"></xref> <xref target="RFC4034"></xref> <xref target="R FC4035"></xref>, this behavior has
	been seen with plain DNS responses as well. Some records have	been seen with plain DNS responses as well. Some records have
	been truncated for display purposes. Note that at the time of this	been truncated for display purposes. Note that at the time of this
	writing, the servers originally responsible for this example have been update d and now correctly	writing, the servers originally responsible for this example have been update d and now correctly
	set the TC flag.</t>	set the TC flag.</t>

	<artwork> % dig +norec +dnssec +bufsize=512 +ignore @ns.example.net \	<artwork> % dig +norec +dnssec +bufsize=512 +ignore @ns.example.net \
	rh202ns2.355.foo.example	rh202ns2.355.foo.example

	; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignor e \	; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignor e \
	@ns.example.net rh202ns2.355.foo.example	@ns.example.net rh202ns2.355.foo.example

	skipping to change at line 235 ¶	skipping to change at line 272 ¶
	foo.example. 3600 IN RRSIG DS 8 2 3600 ...	foo.example. 3600 IN RRSIG DS 8 2 3600 ...
	</artwork>	</artwork>
	</section>	</section>
	</section>	</section>

	<section anchor="requirements"><name>Requirements</name>	<section anchor="requirements"><name>Requirements</name>
	<t>This section describes updated requirements for including glue in DNS referra l responses.</t>	<t>This section describes updated requirements for including glue in DNS referra l responses.</t>

	<section anchor="glue-for-in-domain-name-servers"><name>Glue for In-Domain Name Servers</name>	<section anchor="glue-for-in-domain-name-servers"><name>Glue for In-Domain Name Servers</name>
	<t>This document clarifies that when a name server generates a referral	<t>This document clarifies that when a name server generates a referral

	response, it MUST include all available glue records for in-domain name serve	response, it <bcp14>MUST</bcp14> include all available glue records for in-do
	rs in the	main name servers in the
	additional section, or MUST set TC=1 if constrained by message size.</t>	additional section or <bcp14>MUST</bcp14> set TC=1 if constrained by message
	<t>At the time of writing, most iterative clients send initial queries	size.</t>
		<t>At the time of this writing, most iterative clients send initial queries
	over UDP and retry over TCP upon receiving a response with the TC	over UDP and retry over TCP upon receiving a response with the TC
	flag set. UDP responses are generally limited to between 1232 and 4096	flag set. UDP responses are generally limited to between 1232 and 4096
	bytes, due to values commonly used for the EDNS0 UDP Message Size field	bytes, due to values commonly used for the EDNS0 UDP Message Size field

	<xref target="RFC6891"></xref>, <xref target="FLAGDAY2020"></xref>. TCP resp onses are limited to 65,535 bytes.</t>	<xref target="RFC6891"></xref> <xref target="FLAGDAY2020"></xref>. TCP respo nses are limited to 65,535 bytes.</t>
	</section>	</section>

	<section anchor="glue-for-sibling-domain-name-servers"><name>Glue for Sibling Do main Name Servers</name>	<section anchor="glue-for-sibling-domain-name-servers"><name>Glue for Sibling Do main Name Servers</name>
	<t>This document clarifies that when a name server generates a referral	<t>This document clarifies that when a name server generates a referral

	response, it SHOULD include all available glue records in the	response, it <bcp14>SHOULD</bcp14> include all available glue records in the
	additional section. If, after adding glue for all in-domain name servers, th e glue for all sibling domain name servers does not fit due to message size cons traints,	additional section. If, after adding glue for all in-domain name servers, th e glue for all sibling domain name servers does not fit due to message size cons traints,

	the name server MAY set TC=1 but is not obligated to do so.</t>	the name server <bcp14>MAY</bcp14> set TC=1 but is not obligated to do so.</t
	<t>Note that users may experience resolution failures for domains with cyclicall	>
	y-dependent sibling name servers	<t>Note that users may experience resolution failures for domains with cyclicall
		y dependent sibling name servers
	when the delegating name server chooses to omit the corresponding glue in a r eferral response. As described in	when the delegating name server chooses to omit the corresponding glue in a r eferral response. As described in
	<xref target="siblingcyclicglue"></xref>, such domains are rare.</t>	<xref target="siblingcyclicglue"></xref>, such domains are rare.</t>
	</section>	</section>


	<section anchor="updates-to-rfc-1034"><name>Updates to RFC 1034</name>	<section anchor="update-to-rfc-1034"><name>Update to RFC 1034</name>
	<t>Replace</t>
	<t>"Copy the NS RRs for the subzone into the authority section of the	<t>OLD:</t>

		<blockquote><t>Copy the NS RRs for the subzone into the authority section of the
	reply. Put whatever addresses are available into the additional	reply. Put whatever addresses are available into the additional
	section, using glue RRs if the addresses are not available from	section, using glue RRs if the addresses are not available from

	authoritative data or the cache. Go to step 4."</t>	authoritative data or the cache. Go to step 4.</t></blockquote>
	<t>with</t>	<t>NEW:</t>
	<t>"Copy the NS RRs for the subzone into the authority section of the	<blockquote><t>Copy the NS RRs for the subzone into the authority section of the
	reply. Put whatever NS addresses are available into the additional	reply. Put whatever NS addresses are available into the additional
	section, using glue RRs if the addresses are not available from	section, using glue RRs if the addresses are not available from
	authoritative data or the cache. If all glue RRs for in-domain name servers do not fit, set TC=1 in	authoritative data or the cache. If all glue RRs for in-domain name servers do not fit, set TC=1 in

	the header. Go to step 4."</t>	the header. Go to step 4.</t></blockquote>
	</section>	</section>
	</section>	</section>

	<section anchor="security-considerations"><name>Security Considerations</name>	<section anchor="security-considerations"><name>Security Considerations</name>
	<t>This document clarifies correct DNS server behavior and does not introduce	<t>This document clarifies correct DNS server behavior and does not introduce
	any changes or new security considerations.</t>	any changes or new security considerations.</t>
	</section>	</section>

	<section anchor="operational-considerations"><name>Operational Considerations</n ame>	<section anchor="operational-considerations"><name>Operational Considerations</n ame>
	<t>At the time of this writing, the behavior of most DNS server	<t>At the time of this writing, the behavior of most DNS server
	implementations is to set the TC flag only if none of the available	implementations is to set the TC flag only if none of the available
	glue records fit in a response over UDP transport. The updated	glue records fit in a response over UDP transport. The updated
	requirements in this document might lead to an increase in the fraction	requirements in this document might lead to an increase in the fraction

	of UDP responses with the TC flag set, and consequently an increase	of UDP responses with the TC flag set and, consequently, an increase
	in the number of queries received over TCP transport.</t>	in the number of queries received over TCP transport.</t>
	</section>	</section>

	<section anchor="iana-considerations"><name>IANA Considerations</name>	<section anchor="iana-considerations"><name>IANA Considerations</name>

	<t>There are no actions for IANA.</t>	<t>This document has no IANA actions.</t>
	</section>

	<section anchor="acknowledgements"><name>Acknowledgements</name>
	<t>The authors wish to thank
	Joe Abley,
	David Blacka,
	Brian Dickson,
	Kazunori Fujiwara,
	Paul Hoffman,
	Geoff Huston,
	Jared Mauch,
	George Michaelson,
	Yasuhiro Orange Morishita,
	Benno Overeinder,
	John R Levine,
	Hugo Salgado,
	Shinta Sato,
	Puneet Sood,
	Petr Spacek,
	Ralf Weber,
	Tim Wicinski,
	Suzanne Woolf,
	and other members of the DNSOP working group
	for their input.</t>
	</section>

	<section anchor="changes"><name>Changes</name>
	<t>RFC Editor: Please remove this section before publication.</t>
	<t>This section lists substantial changes to the document as it is being worked
	on.</t>
	<t>From -01 to -02:</t>

	<ul>
	<li>Clarified that "servers" means "authoritative servers".<
	/li>
	<li>Clarified that "available glue" means "all available glue&quo
	t;.</li>
	<li>Updated examples and placed before RFC 1034 update.</li>
	</ul>
	<t>From -02 to -03:</t>

	<ul>
	<li>Clarified scope to focus only on name server responses, and not zone/registr
	y data.</li>
	<li>Reorganized with section 2 as Types of Glue and section 3 as Requirements.</
	li>
	<li>Removed any discussion of promoted / orphan glue.</li>
	<li>Use appropriate documentation addresses and domain names.</li>
	<li>Added Sibling Cyclic Glue example.</li>
	</ul>
	<t>From -03 to -04:</t>

	<ul>
	<li>Use "referral glue" on the assumption that other types of glue may
	be defined in the future.</li>
	<li>Added Operational Considerations section.</li>
	<li>Note many current implementations set TC=1 only when no glue RRs fit. New r
	equirements may lead to more truncation and TCP.</li>
	<li>Sibling glue can be optional. Only require TC=1 when all in-domain glue RRs
	don't fit.</li>
	<li>Avoid talking about requirements for UDP/TCP specifically, and talk more gen
	erically about message size constraints regardless of transport.</li>
	</ul>
	<t>From -04 to -05:</t>

	<ul>
	<li>Reverting the -04 change to use the phrase "referral glue".</li>
	<li>Rephrase "in-domain glue" as "glue for in-domain name servers
	".</li>
	<li>Rephrase "sibling glue" as "glue for sibling domain name serv
	ers".</li>
	<li>Expand paragraph noting this document does not make requirements about prese
	nce of glue in zones.</li>
	</ul>
	<t>From -05 to -06:</t>

	<ul>
	<li>More instances of rephrasing "in-domain glue" as "glue for in
	-domain name servers" (and for sibling glue).</li>
	</ul>
	<t>From -06 to -07:</t>

	<ul>
	<li>Change "NOT REQUIRED to set TC=1" to "MAY set TC=1 but is not
	obligated to do so."</li>
	</ul>
	<t>From -07 to -08:</t>

	<ul>
	<li>Update TSIG reference to RFC8945.</li>
	</ul>
	<t>From -08 to -09:</t>

	<ul>
	<li>Lowercase RFC2119 keywords in abstract</li>
	<li>Add informative reference to DNS terminology RFC</li>
	<li>Add informative reference to dig</li>
	</ul>
	</section>	</section>


	</middle>	</middle>

	<back>	<back>

		<references>
		<name>References</name>
	<references><name>Normative References</name>	<references><name>Normative References</name>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
	xml"/>	/>
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
	xml"/>	/>
	</references>	</references>
	<references><name>Informative References</name>	<references><name>Informative References</name>


	<reference anchor="CZDS" target="https://czds.icann.org/">	<reference anchor="CZDS" target="https://czds.icann.org/">
	<front>	<front>
	<title>Centralized Zone Data Service</title>	<title>Centralized Zone Data Service</title>
	<author>	<author>
	<organization>ICANN</organization>	<organization>ICANN</organization>
	</author>	</author>

	<date year="2022" month="January"></date>	<date/>
	</front>	</front>

	<refcontent></refcontent>
	</reference>	</reference>


	<reference anchor="DIG" target="https://en.wikipedia.org/wiki/Dig_(command)">	<reference anchor="DIG" target="https://en.wikipedia.org/wiki/Dig_(command)">
	<front>	<front>
	<title>dig (command)</title>	<title>dig (command)</title>
	<author>	<author>
	<organization>Wikipedia</organization>	<organization>Wikipedia</organization>
	</author>	</author>

	<date year="2023" month="June"></date>	<date year="2023" month="September"></date>
	</front>	</front>

	<refcontent></refcontent>
	</reference>	</reference>


	<reference anchor="FLAGDAY2020" target="https://dnsflagday.net/2020/">	<reference anchor="FLAGDAY2020" target="https://dnsflagday.net/2020/">
	<front>	<front>
	<title>DNS Flag Day 2020</title>	<title>DNS Flag Day 2020</title>
	<author>	<author>
	<organization>Various DNS software and service providers</organization>	<organization>Various DNS software and service providers</organization>
	</author>	</author>

	<date year="2020" month="Oct"></date>	<date year="2020" month="October"></date>
	</front>	</front>

	<refcontent></refcontent>
	</reference>	</reference>

	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2931.
	xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4033.	/>
	xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4034.	/>
	xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4035.	/>
	xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6891.	/>
	xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8499.	/>
	xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"
	<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8945.	/>
	xml"/>	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8945.xml"
		/>
		</references>
	</references>	</references>


		<section anchor="acknowledgements" numbered="false">
		<name>Acknowledgements</name>
		<t>The authors wish to thank
		<contact fullname="Joe Abley"/>,
		<contact fullname="David Blacka"/>,
		<contact fullname="Brian Dickson"/>,
		<contact fullname="Kazunori Fujiwara"/>,
		<contact fullname="Paul Hoffman"/>,
		<contact fullname="Geoff Huston"/>,
		<contact fullname="John R. Levine"/>,
		<contact fullname="Jared Mauch"/>,
		<contact fullname="George Michaelson"/>,
		<contact fullname="Yasuhiro Orange Morishita"/>,
		<contact fullname="Benno Overeinder"/>,
		<contact fullname="Hugo Salgado"/>,
		<contact fullname="Shinta Sato"/>,
		<contact fullname="Puneet Sood"/>,
		<contact fullname="Petr Spacek"/>,
		<contact fullname="Ralf Weber"/>,
		<contact fullname="Tim Wicinski"/>,
		<contact fullname="Suzanne Woolf"/>,
		and other members of the DNSOP Working Group
		for their input.</t>
		</section>
	</back>	</back>


	</rfc>	</rfc>

End of changes. 42 change blocks.
	206 lines changed or deleted	170 lines changed or added
This html diff was produced by rfcdiff 1.48.