< draft-ietf-dnsop-glue-is-not-optional-02.txt		draft-ietf-dnsop-glue-is-not-optional-03.txt >
	DNSOP M. Andrews		DNSOP M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Updates: 1034 (if approved) S. Huque		Updates: 1034 (if approved) S. Huque
	Intended status: Standards Track Salesforce		Intended status: Standards Track Salesforce
	Expires: 27 January 2022 P. Wouters		Expires: 14 April 2022 P. Wouters
	Aiven		Aiven
	D. Wessels		D. Wessels
	Verisign		Verisign
	26 July 2021		11 October 2021
	Glue In DNS Referral Responses Is Not Optional		Glue In DNS Referral Responses Is Not Optional
	draft-ietf-dnsop-glue-is-not-optional-02		draft-ietf-dnsop-glue-is-not-optional-03
	Abstract		Abstract
	The DNS uses glue records to allow iterative clients to find the		The DNS uses glue records to allow iterative clients to find the
	addresses of nameservers that are contained within a delegated zone.		addresses of nameservers that are contained within a delegated zone.
	Authoritative Servers are expected to return all available glue		Authoritative Servers are expected to return all available glue
	records in referrals. If message size constraints prevent the		records in referrals. If message size constraints prevent the
	inclusion of all glue records in a UDP response, the server MUST set		inclusion of all glue records in a UDP response, the server MUST set
	the TC flag to inform the client that the response is incomplete, and		the TC flag to inform the client that the response is incomplete, and
	that the client SHOULD use TCP to retrieve the full response.		that the client SHOULD use TCP to retrieve the full response. This
			document updates RFC 1034 to clarify correct server behavior.
	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 27 January 2022.		This Internet-Draft will expire on 14 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 3		1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 3
	2. Glue record example . . . . . . . . . . . . . . . . . . . . . 3		2. Types of Glue . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Missing glue . . . . . . . . . . . . . . . . . . . . . . 3		2.1. In-Domain Glue . . . . . . . . . . . . . . . . . . . . . 3
	3. Updates to RFC 1034 . . . . . . . . . . . . . . . . . . . . . 4		2.2. Sibling Glue . . . . . . . . . . . . . . . . . . . . . . 4
	4. Sibling Glue . . . . . . . . . . . . . . . . . . . . . . . . 5		2.3. Sibling Cyclic Glue . . . . . . . . . . . . . . . . . . . 4
	4.1. Sibling Glue example . . . . . . . . . . . . . . . . . . 5		2.4. Missing glue . . . . . . . . . . . . . . . . . . . . . . 5
	5. Promoted (or orphaned) glue . . . . . . . . . . . . . . . . . 6		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 6		3.1. In-Domain Glue . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		3.2. Sibling Glue . . . . . . . . . . . . . . . . . . . . . . 6
	8. Normative References . . . . . . . . . . . . . . . . . . . . 6		3.3. Updates to RFC 1034 . . . . . . . . . . . . . . . . . . . 6
	9. Informative References . . . . . . . . . . . . . . . . . . . 6		4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
			6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
			7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
			8. Normative References . . . . . . . . . . . . . . . . . . . . 8
			9. Informative References . . . . . . . . . . . . . . . . . . . 8
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	The Domain Name System (DNS) [RFC1034], [RFC1035] uses glue records		The Domain Name System (DNS) [RFC1034], [RFC1035] uses glue records
	to allow iterative clients to find the addresses of nameservers that		to allow iterative clients to find the addresses of nameservers that
	are contained within a delegated zone. Glue records are added to the		are contained within a delegated zone. Glue records are added to the
	parent zone as part of the delegation process and returned in		parent zone as part of the delegation process and returned in
	referral responses, otherwise a resolver following the referral has		referral responses, otherwise a resolver following the referral has
	no way of finding these addresses. Authoritative servers are		no way of finding these addresses. Authoritative servers are
	expected to return all available glue records in referrals. If		expected to return all available glue records in referrals. If
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 10 ¶
	a UDP response, the server MUST set the TC (Truncated) flag to inform		a UDP response, the server MUST set the TC (Truncated) flag to inform
	the client that the response is incomplete, and that the client		the client that the response is incomplete, and that the client
	SHOULD use TCP to retrieve the full response. This document		SHOULD use TCP to retrieve the full response. This document
	clarifies that expectation.		clarifies that expectation.
	DNS responses sometimes contain optional data in the additional		DNS responses sometimes contain optional data in the additional
	section. Glue records however are not optional. Several other		section. Glue records however are not optional. Several other
	protocol extensions, when used, are also not optional. This includes		protocol extensions, when used, are also not optional. This includes
	TSIG [RFC2845], OPT [RFC6891], and SIG(0) [RFC2931].		TSIG [RFC2845], OPT [RFC6891], and SIG(0) [RFC2931].
			Note that this document only clarifies requirements of name server
			software implementations. It does not place any requirements on data
			placed in DNS zones or registries.
	1.1. Reserved Words		1.1. Reserved Words
	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", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Glue record example		2. Types of Glue
			This section describes different types of glue that may be found in
			DNS referral responses. Note that the type of glue depends on the
			QNAME. A particular record can be in-domain glue for one response
			and sibling glue for another.
			2.1. In-Domain Glue
	The following is a simple example of glue records present in the		The following is a simple example of glue records present in the
	delegating zone "test" for the child zone "foo.test". The		delegating zone "test" for the child zone "foo.test". The
	nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both		nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both
	below the delegation point. They are configured as glue records in		below the delegation point. They are configured as glue records in
	the "test" zone:		the "test" zone:
	foo.test. 86400 IN NS ns1.foo.test.		foo.test. 86400 IN NS ns1.foo.test.
	foo.test. 86400 IN NS ns2.foo.test.		foo.test. 86400 IN NS ns2.foo.test.
	ns1.foo.test. 86400 IN A 192.0.1.1		ns1.foo.test. 86400 IN A 192.0.2.1
	ns2.foo.test. 86400 IN A 192.0.1.2		ns2.foo.test. 86400 IN AAAA 2001:db8::2:2
	Referral responses from "test" for "foo.test" must include the glue		A referral response from "test" for "foo.test" with in-domain glue
	records in the additional section (and set TC=1 if they do not fit):		looks like this:
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;www.foo.test. IN A		;www.foo.test. IN A
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	foo.test. 86400 IN NS ns1.foo.test.		foo.test. 86400 IN NS ns1.foo.test.
	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.1.1		ns1.foo.test. 86400 IN A 192.0.2.1
	ns2.foo.test. 86400 IN A 192.0.1.2		ns2.foo.test. 86400 IN AAAA 2001:db8::2:2
	2.1. Missing glue		2.2. Sibling Glue
	While not common, real life examples of servers that fail to set TC=1		Sibling glue are glue records that are not contained in the delegated
	when glue records are available, exist and they do cause resolution		zone itself, but in another delegated zone from the same parent. In
	failures.		many cases, these are not strictly required for resolution, since the
			resolver can make follow-on queries to the same zone to resolve the
			nameserver addresses after following the referral to the sibling
			zone. However, most nameserver implementations today provide them as
			an optimization to obviate the need for extra traffic from iterative
			resolvers.
	The example below from June 2020 shows a case where none of the glue		Here the delegating zone "test" contains 2 sub-delegations for the
	records, present in the zone, fitted into the available space and		subzones "bar.test" and "foo.test":
	TC=1 was not set in the response. While this example shows an DNSSEC
	[RFC4033], [RFC4034], [RFC4035] referral response, this behaviour has
	also been seen with plain DNS responses as well. The records have
	been truncated for display purposes. Note that at the time of this
	writing, this configuration has been corrected and the response
	correctly sets the TC=1 flag.
	% dig +norec +dnssec +bufsize=512 +ignore @a.gov-servers.net \		bar.test. 86400 IN NS ns1.bar.test.
	rh202ns2.355.dhhs.gov		bar.test. 86400 IN NS ns2.bar.test.
			ns1.bar.test. 86400 IN A 192.0.2.1
			ns2.bar.test. 86400 IN AAAA 2001:db8::2:2
			foo.test. 86400 IN NS ns1.bar.test.
			foo.test. 86400 IN NS ns2.bar.test.
			A referral response from "test" for "foo.test" with sibling glue
			looks like this:
			;; QUESTION SECTION:
			;www.foo.test. IN A
			;; AUTHORITY SECTION:
			foo.test. 86400 IN NS ns1.bar.test.
			foo.test. 86400 IN NS ns2.bar.test.
			;; ADDITIONAL SECTION:
			ns1.bar.test. 86400 IN A 192.0.2.1
			ns2.bar.test. 86400 IN AAAA 2001:db8::2:2
			2.3. Sibling Cyclic Glue
			The use of sibling glue can introduce cyclic dependencies. This
			happens when one domain specifies name servers from a sibling domain,
			and vice versa. This type of cyclic dependency can only be broken
			when the delegating name server includes the sibling glue in a
			referral response.
			Here the delegating zone "test" contains 2 sub-delegations for the
			subzones "bar.test" and "foo.test", and each use name servers under
			the other:
			bar.test. 86400 IN NS ns1.foo.test.
			bar.test. 86400 IN NS ns2.foo.test.
			ns1.bar.test. 86400 IN A 192.0.2.1
			ns2.bar.test. 86400 IN AAAA 2001:db8::2:2
			foo.test. 86400 IN NS ns1.bar.test.
			foo.test. 86400 IN NS ns2.bar.test.
			ns1.foo.test. 86400 IN A 192.0.2.3
			ns2.foo.test. 86400 IN AAAA 2001:db8::2:4
			A referral response from "test" for "bar.test" with sibling glue
			looks like this:
			;; QUESTION SECTION:
			;www.bar.test. IN A
			;; AUTHORITY SECTION:
			bar.test. 86400 IN NS ns1.foo.test.
			bar.test. 86400 IN NS ns2.foo.test.
			;; ADDITIONAL SECTION:
			ns1.foo.test. 86400 IN A 192.0.2.3
			ns2.foo.test. 86400 IN AAAA 2001:db8::2:4
			2.4. Missing glue
			An example of missing glue is included here, even though it is not
			really 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
			cause resolution failures.
			The example below 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 the glue records present in the zone fit
			into the available space of the UDP respose, and TC=1 was not set.
			While this example shows a referral with DNSSEC records [RFC4033],
			[RFC4034], [RFC4035], this behaviour has been seen with plain DNS
			responses as well. Some records have been truncated for display
			purposes. Note that at the time of this writing, the servers
			originally responsible for this example have been updated and now
			correctly set the TC=1 flag.
			% dig +norec +dnssec +bufsize=512 +ignore @ns.example.net \
			rh202ns2.355.foo.example
	; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignore \		; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignore \
	@a.gov-servers.net rh202ns2.355.dhhs.gov		@ns.example.net rh202ns2.355.foo.example
	; (2 servers found)		; (2 servers found)
	;; global options: +cmd		;; global options: +cmd
	;; Got answer:		;; Got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8798		;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8798
	;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1		;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
	;; OPT PSEUDOSECTION:		;; OPT PSEUDOSECTION:
	; EDNS: version: 0, flags: do; udp: 4096		; EDNS: version: 0, flags: do; udp: 4096
	;; QUESTION SECTION:		;; QUESTION SECTION:
	;rh202ns2.355.dhhs.gov. IN A		;rh202ns2.355.foo.example. IN A
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	dhhs.gov. 86400 IN NS rh120ns2.368.dhhs.gov.		foo.example. 86400 IN NS rh120ns2.368.foo.example.
	dhhs.gov. 86400 IN NS rh202ns2.355.dhhs.gov.		foo.example. 86400 IN NS rh202ns2.355.foo.example.
	dhhs.gov. 86400 IN NS rh120ns1.368.dhhs.gov.		foo.example. 86400 IN NS rh120ns1.368.foo.example.
	dhhs.gov. 86400 IN NS rh202ns1.355.dhhs.gov.		foo.example. 86400 IN NS rh202ns1.355.foo.example.
	dhhs.gov. 3600 IN DS 51937 8 1 ...		foo.example. 3600 IN DS 51937 8 1 ...
	dhhs.gov. 3600 IN DS 635 8 2 ...		foo.example. 3600 IN DS 635 8 2 ...
	dhhs.gov. 3600 IN DS 51937 8 2 ...		foo.example. 3600 IN DS 51937 8 2 ...
	dhhs.gov. 3600 IN DS 635 8 1 ...		foo.example. 3600 IN DS 635 8 1 ...
	dhhs.gov. 3600 IN RRSIG DS 8 2 3600 ...		foo.example. 3600 IN RRSIG DS 8 2 3600 ...
	3. Updates to RFC 1034		3. Requirements
	Replace		3.1. In-Domain Glue
			This document clarifies that when a name server generates a referral
			response, it MUST include all available in-domain glue records in the
			additional section. If all in-domain glue records do not fit in a
			UDP response, the name server MUST set TC=1.
			3.2. Sibling Glue
			This document clarifies that when a name server generates a referral
			response, it MUST [SHOULD] include available sibling glue records in
			the additional section. If all sibling glue records do not fit in a
			UDP response, the name server MUST [is NOT REQUIRED to] set TC=1.
			3.3. Updates to RFC 1034
			[this doesn't really account for SHOULD on sibling glue...]
			Replace
	"Copy the NS RRs for the subzone into the authority section of the		"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."		authoritative data or the cache. Go to step 4."
	with		with
	"Copy the NS RRs for the subzone into the authority section of the		"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. If all glue RRs do not fit, set		authoritative data or the cache. If all glue RRs do not fit, set
	TC=1 in the header. Go to step 4."		TC=1 in the header. Go to step 4."
	4. Sibling Glue		4. Security Considerations
	Sibling glue are glue records that are not contained in the delegated		This document clarifies correct DNS server behaviour and does not
	zone itself, but in another delegated zone from the same parent. In		introduce any changes or new security considerations.
	many cases, these are not strictly required for resolution, since the
	resolver can make follow-on queries to the same zone to resolve the
	nameserver addresses after following the referral to the sibling
	zone. However, most nameserver implementations today provide them as
	an optimization to obviate the need for extra traffic from iterative
	resolvers.
	This document clarifies that sibling glue (being part of all		5. IANA Considerations
	available glue records) MUST be returned in referral responses, and
	that the requirement to set TC=1 applies to sibling glue that cannot
	fit in the response too.
	4.1. Sibling Glue example		There are no actions for IANA.
	Here the delegating zone "test" contains 2 sub-delegations for the		6. Acknowledgements
	subzones "bar.test" and "foo.test".
	bar.test. 86400 IN NS ns1.bar.test.		The authors wish to thank Joe Abley, Brian Dickson, Geoff Huston,
	bar.test. 86400 IN NS ns2.bar.test.		Jared Mauch, George Michaelson, Benno Overeinder, John R Levine,
	ns1.bar.test. 86400 IN A 192.0.1.1		Shinta Sato, Puneet Sood, Ralf Weber, Tim Wicinski, Suzanne Woolf,
	ns2.bar.test. 86400 IN A 192.0.1.2		and other members of the DNSOP working group for their input.
	foo.test. 86400 IN NS ns1.bar.test.		7. Changes
	foo.test. 86400 IN NS ns2.bar.test.
	Referral responses from "test" for "foo.test" must include the		RFC Editor: Please remove this section before publication.
	sibling glue (and set TC=1 if they do not fit):
	;; QUESTION SECTION:		This section lists substantial changes to the document as it is being
	;www.foo.test. IN A		worked on.
	;; AUTHORITY SECTION:		From -01 to -02:
	foo.test. 86400 IN NS ns1.bar.test.
	foo.test. 86400 IN NS ns2.bar.test.
	;; ADDITIONAL SECTION:		* Clarified that "servers" means "authoritative servers".
	ns1.bar.test. 86400 IN A 192.0.1.1
	ns2.bar.test. 86400 IN A 192.0.1.2
	5. Promoted (or orphaned) glue		* Clarified that "available glue" means "all available glue".
	When a zone is deleted but the parent notices that its NS glue		* Updated examples and placed before RFC 1034 update.
	records are required for other zones, it MAY opt to take these (now
	orphaned) glue records into its own zone to ensure that other zones
	depending on this glue are not broken. Technically, these address
	records are no longer glue records, but authoritative data of the
	parent zone, and should be added to the DNS response similarly to
	regular glue records.
	6. Security Considerations		From -02 to -03:
	This document clarifies correct DNS server behaviour and does not		* Clarified scope to focus only on name server responses, and not
	introduce any changes or new security considerations.		zone/registry data.
	7. IANA Considerations		* Reorganized with section 2 as Types of Glue and section 3 as
			Requirements.
	There are no actions for IANA.		* Removed any discussion of promoted / orphan glue.
			* Use appropriate documentation addresses and domain names.
			* Added Sibling Cyclic Glue example.
	8. Normative References		8. Normative References
	[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>.
End of changes. 38 change blocks.
	97 lines changed or deleted		189 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/