< draft-ietf-dnsop-glue-is-not-optional-01.txt		draft-ietf-dnsop-glue-is-not-optional-02.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: 13 January 2022 P. Wouters		Expires: 27 January 2022 P. Wouters
	Aiven		Aiven
	D. Wessels		D. Wessels
	Verisign		Verisign
	12 July 2021		26 July 2021
	Glue In DNS Referral Responses Is Not Optional		Glue In DNS Referral Responses Is Not Optional
	draft-ietf-dnsop-glue-is-not-optional-01		draft-ietf-dnsop-glue-is-not-optional-02
	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.
	Servers are expected to return available glue records in referrals.		Authoritative Servers are expected to return all available glue
	If message size constraints prevent the inclusion of glue records in		records in referrals. If message size constraints prevent the
	a UDP response, the server MUST set the TC flag to inform the client		inclusion of all glue records in a UDP response, the server MUST set
	that the response is incomplete, and that the client SHOULD use TCP		the TC flag to inform the client that the response is incomplete, and
	to retrieve the full response.		that the client SHOULD use TCP to retrieve the full response.
	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 13 January 2022.		This Internet-Draft will expire on 27 January 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 . . . . . . . . . . . . . . . . . . . . . 2		1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 3
	2. Clarifying modifications to RFC1034 . . . . . . . . . . . . . 3		2. Glue record example . . . . . . . . . . . . . . . . . . . . . 3
	3. Why glue is required . . . . . . . . . . . . . . . . . . . . 3		2.1. Missing glue . . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Example one: Missing glue . . . . . . . . . . . . . . . . 3		3. Updates to RFC 1034 . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Example two: Sibling Glue from the same delegating		4. Sibling Glue . . . . . . . . . . . . . . . . . . . . . . . . 5
	zone . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4.1. Sibling Glue example . . . . . . . . . . . . . . . . . . 5
	3.3. Example three: Cross Zone Sibling Glue . . . . . . . . . 5		5. Promoted (or orphaned) glue . . . . . . . . . . . . . . . . . 6
	3.4. Promoted (or orphaned) glue . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		8. Normative References . . . . . . . . . . . . . . . . . . . . 6
	6. Normative References . . . . . . . . . . . . . . . . . . . . 6		9. Informative References . . . . . . . . . . . . . . . . . . . 6
	7. Informative References . . . . . . . . . . . . . . . . . . . 6
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	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. Servers are expected		parent zone as part of the delegation process and returned in
	to return available glue records in referrals. If message size		referral responses, otherwise a resolver following the referral has
	constraints prevent the inclusion of glue records in a UDP response,		no way of finding these addresses. Authoritative servers are
	the server MUST set the TC flag to inform the client that the		expected to return all available glue records in referrals. If
	response is incomplete, and that the client SHOULD use TCP to		message size constraints prevent the inclusion of all glue records in
	retrieve the full response. This document clarifies that		a UDP response, the server MUST set the TC (Truncated) flag to inform
	expectation.		the client that the response is incomplete, and that the client
			SHOULD use TCP to retrieve the full response. This document
			clarifies that expectation.
			DNS responses sometimes contain optional data in the additional
			section. Glue records however are not optional. Several other
			protocol extensions, when used, are also not optional. This includes
			TSIG [RFC2845], OPT [RFC6891], and SIG(0) [RFC2931].
	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. Clarifying modifications to RFC1034		2. Glue record example
	Replace		The following is a simple example of glue records present in the
			delegating zone "test" for the child zone "foo.test". The
			nameservers for foo.test (ns1.foo.test and ns2.foo.test) are both
			below the delegation point. They are configured as glue records in
			the "test" zone:
	"Copy the NS RRs for the subzone into the authority section of the		foo.test. 86400 IN NS ns1.foo.test.
	reply. Put whatever addresses are available into the additional		foo.test. 86400 IN NS ns2.foo.test.
	section, using glue RRs if the addresses are not available from		ns1.foo.test. 86400 IN A 192.0.1.1
	authoritative data or the cache. Go to step 4."		ns2.foo.test. 86400 IN A 192.0.1.2
	with		Referral responses from "test" for "foo.test" must include the glue
			records in the additional section (and set TC=1 if they do not fit):
	"Copy the NS RRs for the subzone into the authority section of the		;; QUESTION SECTION:
	reply. Put whatever addresses are available into the additional		;www.foo.test. IN A
	section, using glue RRs if the addresses are not available from
	authoritative data or the cache. If glue RRs do not fit, set TC=1 in
	the header. Go to step 4."
	3. Why glue is required		;; AUTHORITY SECTION:
			foo.test. 86400 IN NS ns1.foo.test.
			foo.test. 86400 IN NS ns2.foo.test.
			;; ADDITIONAL SECTION:
			ns1.foo.test. 86400 IN A 192.0.1.1
			ns2.foo.test. 86400 IN A 192.0.1.2
			2.1. Missing glue
	While not common, real life examples of servers that fail to set TC=1		While not common, real life examples of servers that fail to set TC=1
	when glue records are available exist and they do cause resolution		when glue records are available, exist and they do cause resolution
	failures.		failures.
	3.1. Example one: Missing glue
	The example below from June 2020 shows a case where none of the glue		The example below from June 2020 shows a case where none of the glue
	records, present in the zone, fitted into the available space and		records, present in the zone, fitted into the available space and
	TC=1 was not set in the response. While this example shows an DNSSEC		TC=1 was not set in the response. While this example shows an DNSSEC
	[RFC4033], [RFC4034], [RFC4035] referral response, this behaviour has		[RFC4033], [RFC4034], [RFC4035] referral response, this behaviour has
	also been seen with plain DNS responses as well. The records have		also been seen with plain DNS responses as well. The 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, this configuration has been corrected and the response		writing, this configuration has been corrected and the response
	correctly sets the TC=1 flag.		correctly sets the TC=1 flag.
	% dig +norec +dnssec +bufsize=512 +ignore @a.gov-servers.net \		% dig +norec +dnssec +bufsize=512 +ignore @a.gov-servers.net \
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	dhhs.gov. 86400 IN NS rh120ns2.368.dhhs.gov.		dhhs.gov. 86400 IN NS rh120ns2.368.dhhs.gov.
	dhhs.gov. 86400 IN NS rh202ns2.355.dhhs.gov.		dhhs.gov. 86400 IN NS rh202ns2.355.dhhs.gov.
	dhhs.gov. 86400 IN NS rh120ns1.368.dhhs.gov.		dhhs.gov. 86400 IN NS rh120ns1.368.dhhs.gov.
	dhhs.gov. 86400 IN NS rh202ns1.355.dhhs.gov.		dhhs.gov. 86400 IN NS rh202ns1.355.dhhs.gov.
	dhhs.gov. 3600 IN DS 51937 8 1 ...		dhhs.gov. 3600 IN DS 51937 8 1 ...
	dhhs.gov. 3600 IN DS 635 8 2 ...		dhhs.gov. 3600 IN DS 635 8 2 ...
	dhhs.gov. 3600 IN DS 51937 8 2 ...		dhhs.gov. 3600 IN DS 51937 8 2 ...
	dhhs.gov. 3600 IN DS 635 8 1 ...		dhhs.gov. 3600 IN DS 635 8 1 ...
	dhhs.gov. 3600 IN RRSIG DS 8 2 3600 ...		dhhs.gov. 3600 IN RRSIG DS 8 2 3600 ...
	;; Query time: 226 msec		3. Updates to RFC 1034
	;; SERVER: 69.36.157.30#53(69.36.157.30)
	;; WHEN: Wed Apr 15 13:34:43 AEST 2020
	;; MSG SIZE rcvd: 500
	%
	DNS responses sometimes contain optional data in the additional		Replace
	section. Glue records however are not optional. Several other
	protocol extensions, when used, are also not optional. This includes
	TSIG [RFC2845], OPT [RFC6891], and SIG(0) [RFC2931].
	3.2. Example two: Sibling Glue from the same delegating zone		"Copy the NS RRs for the subzone into the authority section of the
			reply. Put whatever addresses are available into the additional
			section, using glue RRs if the addresses are not available from
			authoritative data or the cache. Go to step 4."
	Sibling glue are glue records that are not contained in the		with
	delegating zone itself, but in another delegated zone. In 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 provide them as an
	optimization to obviate the need for extra traffic.
	Here the delegating zone "test" contains 2 delegations for the		"Copy the NS RRs for the subzone into the authority section of the
	subzones "bar.test" and "foo.test". The nameservers for "foo.test"		reply. Put whatever addresses are available into the additional
	consist of sibling glue for "bar.test" (ns1.bar.test and ns2.bar.test).		section, using glue RRs if the addresses are not available from
			authoritative data or the cache. If all glue RRs do not fit, set
			TC=1 in the header. Go to step 4."
	bar.test. 86400 IN NS ns1.bar.test.		4. Sibling Glue
	bar.test. 86400 IN NS ns2.bar.test.
	ns1.bar.test. 86400 IN A 192.0.1.1
	ns2.bar.test. 86400 IN A 192.0.1.2
	foo.test. 86400 IN NS ns1.bar.test.		Sibling glue are glue records that are not contained in the delegated
	foo.test. 86400 IN NS ns2.bar.test.		zone itself, but in another delegated zone from the same parent. In
			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.
	Referral responses from test for foo.test should include the sibling		This document clarifies that sibling glue (being part of all
	glue:		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.
	;; QUESTION SECTION:		4.1. Sibling Glue example
	;www.foo.test. IN A
	;; AUTHORITY SECTION:		Here the delegating zone "test" contains 2 sub-delegations for the
	foo.test. 86400 IN NS ns1.bar.test.		subzones "bar.test" and "foo.test".
	foo.test. 86400 IN NS ns2.bar.test.
	;; ADDITIONAL SECTION:		bar.test. 86400 IN NS ns1.bar.test.
	ns1.bar.test. 86400 IN A 192.0.1.1		bar.test. 86400 IN NS ns2.bar.test.
	ns2.bar.test. 86400 IN A 192.0.1.2		ns1.bar.test. 86400 IN A 192.0.1.1
			ns2.bar.test. 86400 IN A 192.0.1.2
	Question: if sibling glue from the same delegating zone does not fit		foo.test. 86400 IN NS ns1.bar.test.
	into the response, should we also recommend or require that TC=1 be		foo.test. 86400 IN NS ns2.bar.test.
	set?
	3.3. Example three: Cross Zone Sibling Glue		Referral responses from "test" for "foo.test" must include the
			sibling glue (and set TC=1 if they do not fit):
	Here is a more complex example of sibling glue that lives in another		;; QUESTION SECTION:
	zone, but is required to resolve a circular dependency in the zone		;www.foo.test. IN A
	configuration.
	example.com. 86400 IN NS ns1.example.net.		;; AUTHORITY SECTION:
	example.com. 86400 IN NS ns2.example.net.		foo.test. 86400 IN NS ns1.bar.test.
	ns1.example.com. 86400 IN A 192.0.1.1		foo.test. 86400 IN NS ns2.bar.test.
	ns2.example.com. 86400 IN A 192.0.1.2
	example.net. 86400 IN NS ns1.example.com.		;; ADDITIONAL SECTION:
	example.net. 86400 IN NS ns2.example.com.		ns1.bar.test. 86400 IN A 192.0.1.1
	ns1.example.net. 86400 IN A 198.51.100.1		ns2.bar.test. 86400 IN A 192.0.1.2
	ns2.example.net. 86400 IN A 198.51.100.2
	3.4. Promoted (or orphaned) glue		5. Promoted (or orphaned) glue
	When a zone is deleted but the parent notices that its NS glue		When a zone is deleted but the parent notices that its NS glue
	records are required for other zones, it MAY opt to take these (now		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		orphaned) glue records into its own zone to ensure that other zones
	depending on this glue are not broken. Technically, these NS records		depending on this glue are not broken. Technically, these address
	are no longer glue records, but authoritative data of the parent		records are no longer glue records, but authoritative data of the
	zone, and should be added to the DNS response similarly to regular		parent zone, and should be added to the DNS response similarly to
	glue records.		regular glue records.
	4. Security Considerations		6. Security Considerations
	This document clarifies correct DNS server behaviour and does not		This document clarifies correct DNS server behaviour and does not
	introduce any changes or new security considerations.		introduce any changes or new security considerations.
	5. IANA Considerations		7. IANA Considerations
	There are no actions for IANA.		There are no actions for IANA.
	6. 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>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	7. Informative References		9. Informative References
	[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.		[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
	Wellington, "Secret Key Transaction Authentication for DNS		Wellington, "Secret Key Transaction Authentication for DNS
	(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,		(TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
	<https://www.rfc-editor.org/info/rfc2845>.		<https://www.rfc-editor.org/info/rfc2845>.
	[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>.
End of changes. 37 change blocks.
	105 lines changed or deleted		111 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/