< draft-ietf-dnsop-glue-is-not-optional-00.txt		draft-ietf-dnsop-glue-is-not-optional-01.txt >
	Network Working Group M. Andrews		DNSOP M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Updates: 1034 (if approved) June 3, 2020		Updates: 1034 (if approved) S. Huque
	Intended status: Standards Track		Intended status: Standards Track Salesforce
	Expires: December 5, 2020		Expires: 13 January 2022 P. Wouters
			Aiven
			D. Wessels
			Verisign
			12 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-00		draft-ietf-dnsop-glue-is-not-optional-01
	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 live within the delegated zone. Glue		addresses of nameservers that are contained within a delegated zone.
	records are expected to be returned as part of a referral and if they		Servers are expected to return available glue records in referrals.
	cannot be fitted into the UDP response, TC=1 MUST be set to inform		If message size constraints prevent the inclusion of glue records in
	the client that the response is incomplete and that TCP SHOULD be		a UDP response, the server MUST set the TC flag to inform the client
	used to retrieve the full response.		that the response is incomplete, and 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 December 5, 2020.		This Internet-Draft will expire on 13 January 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4		1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 2
	2. Modifications to RFC1034 . . . . . . . . . . . . . . . . . . 4		2. Clarifying modifications to RFC1034 . . . . . . . . . . . . . 3
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 4		3. Why glue is required . . . . . . . . . . . . . . . . . . . . 3
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4		3.1. Example one: Missing glue . . . . . . . . . . . . . . . . 3
	5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Example two: Sibling Glue from the same delegating
	5.1. Normative References . . . . . . . . . . . . . . . . . . 4		zone . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5.2. Informative References . . . . . . . . . . . . . . . . . 5		3.3. Example three: Cross Zone Sibling Glue . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5		3.4. Promoted (or orphaned) glue . . . . . . . . . . . . . . . 6
			4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
			5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
			6. Normative References . . . . . . . . . . . . . . . . . . . . 6
			7. Informative References . . . . . . . . . . . . . . . . . . . 6
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
	1. Introduction		1. Introduction
	The DNS [RFC1034], [RFC1035] uses glue records to allow iterative		The Domain Name System (DNS) [RFC1034], [RFC1035] uses glue records
	clients to find the addresses of nameservers that live within the		to allow iterative clients to find the addresses of nameservers that
	delegated zone. Glue records are expected to be returned as part of		are contained within a delegated zone. Glue records are added to the
	a referral and if they cannot be fitted into the UDP response, TC=1		parent zone as part of the delegation process. Servers are expected
	MUST be set to inform the client that the response is incomplete and		to return available glue records in referrals. If message size
	that TCP SHOULD be used to retrieve the full response.		constraints prevent the inclusion of glue records in a UDP response,
			the server MUST set the TC flag to inform the client that the
			response is incomplete, and that the client SHOULD use TCP to
			retrieve the full response. This document clarifies that
			expectation.
			1.1. Reserved Words
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
			2. Clarifying modifications to RFC1034
			Replace
			"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."
			with
			"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. If glue RRs do not fit, set TC=1 in
			the header. Go to step 4."
			3. Why glue is required
	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. The example below shows a case where none of the glue		failures.
			3.1. Example one: Missing 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.		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 \		% dig +norec +dnssec +bufsize=512 +ignore @a.gov-servers.net \
	rh202ns2.355.dhhs.gov		rh202ns2.355.dhhs.gov
	; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignore \		; <<>> DiG 9.15.4 <<>> +norec +dnssec +bufsize +ignore \
	@a.gov-servers.net rh202ns2.355.dhhs.gov		@a.gov-servers.net rh202ns2.355.dhhs.gov
	; (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.dhhs.gov. IN A
	;; AUTHORITY SECTION:		;; AUTHORITY SECTION:
	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		;; Query time: 226 msec
	;; SERVER: 69.36.157.30#53(69.36.157.30)		;; SERVER: 69.36.157.30#53(69.36.157.30)
	;; WHEN: Wed Apr 15 13:34:43 AEST 2020		;; WHEN: Wed Apr 15 13:34:43 AEST 2020
	;; MSG SIZE rcvd: 500		;; MSG SIZE rcvd: 500
	%		%
	This is almost certainly due a wide spread misbelief that all		DNS responses sometimes contain optional data in the additional
	additional section records are optional. This has never been the		section. Glue records however are not optional. Several other
	case with respect to glue records and later protocol extension have		protocol extensions, when used, are also not optional. This includes
	added more cases where records in the additional section are not		TSIG [RFC2845], OPT [RFC6891], and SIG(0) [RFC2931].
	optional in the response. This includes TSIG [RFC2845], OPT
	[RFC6891], and SIG(0) [RFC2931].
	Glue records are added to the parent zone as part of the delegation		3.2. Example two: Sibling Glue from the same delegating zone
	process. They are expected to be returned as part of a referral and
	if they can't fit in a UDP response TC=1 MUST be set to signal to the
	client to retry over TCP. This document reinforces that expectation.
	1.1. Reserved Words		Sibling glue are glue records that are not contained in the
			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.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		Here the delegating zone "test" contains 2 delegations for the
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		subzones "bar.test" and "foo.test". The nameservers for "foo.test"
	document are to be interpreted as described in [RFC2119].		consist of sibling glue for "bar.test" (ns1.bar.test and ns2.bar.test).
	2. Modifications to RFC1034		bar.test. 86400 IN NS ns1.bar.test.
			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
	Replace		foo.test. 86400 IN NS ns1.bar.test.
			foo.test. 86400 IN NS ns2.bar.test.
	"Copy the NS RRs for the subzone into the authority section of the		Referral responses from test for foo.test should include the sibling
	reply. Put whatever addresses are available into the additional		glue:
	section, using glue RRs if the addresses are not available from
	authoritative data or the cache. Go to step 4."
	with		;; QUESTION SECTION:
			;www.foo.test. IN A
	"Copy the NS RRs for the subzone into the authority section of the		;; AUTHORITY SECTION:
	reply. Put whatever addresses are available into the additional		foo.test. 86400 IN NS ns1.bar.test.
	section, using glue RRs if the addresses are not available from		foo.test. 86400 IN NS ns2.bar.test.
	authoritative data or the cache. If glue RRs do not fit set TC=1 in
	the header. Go to step 4."
	3. Security Considerations		;; ADDITIONAL SECTION:
			ns1.bar.test. 86400 IN A 192.0.1.1
			ns2.bar.test. 86400 IN A 192.0.1.2
	This document reinforces DNS server behaviour expectations and does		Question: if sibling glue from the same delegating zone does not fit
	not introduce new security considerations.		into the response, should we also recommend or require that TC=1 be
			set?
	4. IANA Considerations		3.3. Example three: Cross Zone Sibling Glue
	There are no actions for IANA.		Here is a more complex example of sibling glue that lives in another
			zone, but is required to resolve a circular dependency in the zone
			configuration.
	5. References		example.com. 86400 IN NS ns1.example.net.
			example.com. 86400 IN NS ns2.example.net.
			ns1.example.com. 86400 IN A 192.0.1.1
			ns2.example.com. 86400 IN A 192.0.1.2
	5.1. Normative References		example.net. 86400 IN NS ns1.example.com.
			example.net. 86400 IN NS ns2.example.com.
			ns1.example.net. 86400 IN A 198.51.100.1
			ns2.example.net. 86400 IN A 198.51.100.2
			3.4. Promoted (or orphaned) 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
			orphaned) glue records into its own zone to ensure that other zones
			depending on this glue are not broken. Technically, these NS 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.
			4. Security Considerations
			This document clarifies correct DNS server behaviour and does not
			introduce any changes or new security considerations.
			5. IANA Considerations
			There are no actions for IANA.
			6. 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>.
	5.2. Informative References		7. 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>.
	skipping to change at page 5, line 36 ¶		skipping to change at page 7, line 25 ¶
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<https://www.rfc-editor.org/info/rfc4035>.		<https://www.rfc-editor.org/info/rfc4035>.
	[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>.
	Author's Address		Authors' Addresses
	M. Andrews		M. Andrews
	Internet Systems Consortium		ISC
	PO Box 360
	Newmarket, NH 03857
	US
	Email: marka@isc.org		Email: marka@isc.org
			Shumon Huque
			Salesforce
			Email: shuque@gmail.com
			Paul Wouters
			Aiven
			Email: paul.wouters@aiven.io
			Duane Wessels
			Verisign
			Email: dwessels@verisign.com
End of changes. 36 change blocks.
	103 lines changed or deleted		178 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/