rfc9609v1.txt		rfc9609.txt
	Internet Engineering Task Force (IETF) P. Koch		Internet Engineering Task Force (IETF) P. Koch
	Request for Comments: 9609 DENIC eG		Request for Comments: 9609 DENIC eG
	BCP: 209 M. Larson		BCP: 209 M. Larson
	Obsoletes: 8109 P. Hoffman		Obsoletes: 8109 P. Hoffman
	Category: Best Current Practice ICANN		Category: Best Current Practice ICANN
	ISSN: 2070-1721 November 2024		ISSN: 2070-1721 February 2025
	Initializing a DNS Resolver with Priming Queries		Initializing a DNS Resolver with Priming Queries
	Abstract		Abstract
	This document describes the queries that a DNS resolver should emit		This document describes the queries that a DNS resolver should emit
	to initialize its cache. The result is that the resolver gets both a		to initialize its cache. The result is that the resolver gets both a
	current NS resource record set (RRset) for the root zone and the		current NS resource record set (RRset) for the root zone and the
	necessary address information for reaching the root servers.		necessary address information for reaching the root servers.
	skipping to change at line 36 ¶		skipping to change at line 36 ¶
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	Internet Engineering Steering Group (IESG). Further information on		Internet Engineering Steering Group (IESG). Further information on
	BCPs is available in Section 2 of RFC 7841.		BCPs is available in Section 2 of RFC 7841.
	Information about the current status of this document, any errata,		Information about the current status of this document, any errata,
	and how to provide feedback on it may be obtained at		and how to provide feedback on it may be obtained at
	https://www.rfc-editor.org/info/rfc9609.		https://www.rfc-editor.org/info/rfc9609.
	Copyright Notice		Copyright Notice
	Copyright (c) 2024 IETF Trust and the persons identified as the		Copyright (c) 2025 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/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	skipping to change at line 93 ¶		skipping to change at line 93 ¶
	This document describes the steps needed for this common		This document describes the steps needed for this common
	implementation choice. Note that this is not the only way to start a		implementation choice. Note that this is not the only way to start a
	recursive name server with an empty cache, but it is the only one		recursive name server with an empty cache, but it is the only one
	described in [RFC1034]. Some implementers have chosen other		described in [RFC1034]. Some implementers have chosen other
	directions, some of which work well and others of which fail		directions, some of which work well and others of which fail
	(sometimes disastrously) under different conditions. For example, an		(sometimes disastrously) under different conditions. For example, an
	implementation that only gets the addresses of the root name servers		implementation that only gets the addresses of the root name servers
	from configuration, not from the DNS as described in this document,		from configuration, not from the DNS as described in this document,
	will have stale data that could cause slower resolution.		will have stale data that could cause slower resolution.
	This document only deals with recursive name servers (recursive		This document only deals with recursive name servers (also called
	resolvers, resolvers) for the IN class.		"recursive resolvers" and just "resolvers") for the IN class.
	See Appendix A for the list of changes from [RFC8109].		See Appendix A for the list of changes from [RFC8109].
	1.1. Terminology		1.1. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at line 177 ¶		skipping to change at line 177 ¶
	names, they are not useful in the priming process.		names, they are not useful in the priming process.
	3. Priming Queries		3. Priming Queries
	A priming query is a DNS query whose response provides root server		A priming query is a DNS query whose response provides root server
	identifiers and addresses. It has a QNAME of ".", a QTYPE of NS, and		identifiers and addresses. It has a QNAME of ".", a QTYPE of NS, and
	a QCLASS of IN; it is sent to one of the addresses in the		a QCLASS of IN; it is sent to one of the addresses in the
	configuration for the recursive resolver. The priming query can be		configuration for the recursive resolver. The priming query can be
	sent over either UDP or TCP. If the query is sent over UDP, the		sent over either UDP or TCP. If the query is sent over UDP, the
	source port SHOULD be randomly selected (see [RFC5452]) to hamper on-		source port SHOULD be randomly selected (see [RFC5452]) to hamper on-
	path attacks. DNS Cookies [RFC7873] can also be used to hamper on-		path attacks. DNS cookies [RFC7873] can also be used to hamper on-
	path attacks. The Recursion Desired (RD) bit SHOULD be set to 0.		path attacks. The Recursion Desired (RD) bit SHOULD be set to 0.
	The meaning when RD is set to 1 is undefined for priming queries and		The meaning when RD is set to 1 is undefined for priming queries and
	is outside the scope of this document.		is outside the scope of this document.
	The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries		The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries
	and SHOULD announce and handle a reassembly size of at least 1024		and SHOULD announce and handle a reassembly size of at least 1024
	octets [RFC3226]. Doing so allows responses that cover the size of a		octets [RFC3226]. Doing so allows responses that cover the size of a
	full priming response (see Section 4.2) for the current set of root		full priming response (see Section 4.2) for the current set of root
	servers. See Section 3.3 for discussion of setting the DNSSEC OK		servers. See Section 3.3 for discussion of setting the DNSSEC OK
	(DO) bit (defined in [RFC4033]).		(DO) bit (defined in [RFC4033]).
	skipping to change at line 225 ¶		skipping to change at line 225 ¶
	randomly from the list of addresses. The recursive resolver might		randomly from the list of addresses. The recursive resolver might
	choose either IPv4 or IPv6 addresses based on its knowledge of		choose either IPv4 or IPv6 addresses based on its knowledge of
	whether the system on which it is running has adequate connectivity		whether the system on which it is running has adequate connectivity
	on either type of address.		on either type of address.
	Note that this recommended method is not the only way to choose from		Note that this recommended method is not the only way to choose from
	the list in a recursive resolver's configuration. Two other common		the list in a recursive resolver's configuration. Two other common
	methods include picking the first from the list, and remembering		methods include picking the first from the list, and remembering
	which address in the list gave the fastest response earlier and using		which address in the list gave the fastest response earlier and using
	that one. There are probably other methods in use today. However,		that one. There are probably other methods in use today. However,
	the random method listed above SHOULD be used for priming.		the random method SHOULD be used for priming.
	3.3. DNSSEC with Priming Queries		3.3. DNSSEC with Priming Queries
	The root NS RRset is signed and can be validated by a DNSSEC		The root NS RRset is signed and can be validated by a DNSSEC
	validating resolver. At the time this document was published, the		validating resolver. At the time this document is published, the
	addresses for the names in the root NS RRset are in the "root-		addresses for the names in the root NS RRset are in the "root-
	servers.net" zone. All root servers are also authoritative for the		servers.net" zone. All root servers are also authoritative for the
	"root-servers.net" zone, which allows priming responses to include		"root-servers.net" zone, which allows priming responses to include
	the appropriate root name server A and AAAA RRsets. However, because		the appropriate root name server A and AAAA RRsets. However, because
	at the time this document was published the "root-servers.net" zone		at the time this document is published the "root-servers.net" zone is
	is not signed, the root name server A and AAAA RRsets cannot be		not signed, the root name server A and AAAA RRsets cannot be
	validated. An attacker that is able to provide a spoofed priming		validated. An attacker that is able to provide a spoofed priming
	response can provide alternative A and AAAA RRsets and thus fool a		response can provide alternative A and AAAA RRsets and thus fool a
	resolver into considering addresses under the control of the attacker		resolver into considering addresses under the control of the attacker
	to be authoritative for the root zone.		to be authoritative for the root zone.
	A rogue root name server can view all queries from the resolver to		A rogue root name server can view all queries from the resolver to
	the root and alter all unsigned parts of responses, such as the		the root and alter all unsigned parts of responses, such as the
	parent-side NS RRsets and glue in referral responses. A resolver can		parent-side NS RRsets and glue in referral responses. A resolver can
	be fooled into trusting child (Top-Level Domain (TLD)) NS addresses		be fooled into trusting child (Top-Level Domain (TLD)) NS addresses
	that are under the control of the attacker as being authoritative if		that are under the control of the attacker as being authoritative if
	the resolver:		the resolver:
	* follows referrals from a rogue root server,		* follows referrals from a rogue root server,
	* does not explicitly query the authoritative NS RRset at the apex		* and does not explicitly query the authoritative NS RRset at the
	of the child (TLD) zone, and		apex of the child (TLD) zone,
	* does not explicitly query for the authoritative A and AAAA RRsets		* and does not explicitly query for the authoritative A and AAAA
	for the child (TLD) NS RRsets.		RRsets for the child (TLD) NS RRsets.
	With such resolvers, an attacker that controls a rogue root server		With such resolvers, an attacker that controls a rogue root server
	effectively controls the entire domain name space and can view all		effectively controls the entire domain name space and can view all
	queries and alter all unsigned data undetected unless other		queries and alter all unsigned data undetected unless other
	protections are configured at the resolver.		protections are configured at the resolver.
	An attacker controlling a rogue root name server also has complete		An attacker controlling a rogue root name server also has complete
	control over all unsigned delegations and over the entire domain name		control over all unsigned delegations and over the entire domain name
	space in the case of non-DNSSEC validating resolvers.		space in the case of non-DNSSEC validating resolvers.
	skipping to change at line 296 ¶		skipping to change at line 296 ¶
	section with A and/or AAAA RRsets for the root servers pointed at by		section with A and/or AAAA RRsets for the root servers pointed at by
	the NS RRset.		the NS RRset.
	Resolver software SHOULD treat the response to the priming query as a		Resolver software SHOULD treat the response to the priming query as a
	normal DNS response, just as it would use any other data fed to its		normal DNS response, just as it would use any other data fed to its
	cache. Resolver software SHOULD NOT expect 13 NS RRs because,		cache. Resolver software SHOULD NOT expect 13 NS RRs because,
	historically, some root servers have returned fewer.		historically, some root servers have returned fewer.
	4.2. Completeness of the Response		4.2. Completeness of the Response
	At the time this document was published, there are 13 root server		At the time this document is published, there are 13 root server
	operators operating a total of more than 1500 root server instances.		operators operating a total of more than 1500 root server instances.
	Each instance has one IPv4 address and one IPv6 address. The		Each instance has one IPv4 address and one IPv6 address. The
	combined size of all the A and AAAA RRsets exceeds the original		combined size of all the A and AAAA RRsets exceeds the original
	512-octet payload limit specified in [RFC1035].		512-octet payload limit specified in [RFC1035].
	In the event of a response where the Additional section omits certain		In the event of a response where the Additional section omits certain
	root server address information, reissuing of the priming query does		root server address information, reissuing of the priming query does
	not help with those root name servers that respond with a fixed order		not help with those root name servers that respond with a fixed order
	of addresses in the Additional section. Instead, the recursive		of addresses in the Additional section. Instead, the recursive
	resolver needs to issue direct queries for A and AAAA RRsets for the		resolver needs to issue direct queries for A and AAAA RRsets for the
	remaining names. At the time this document was published, these		remaining names. At the time this document is published, these
	RRsets would be authoritatively available from the root name servers.		RRsets would be authoritatively available from the root name servers.
	If some root server addresses are omitted from the Additional		If some root server addresses are omitted from the Additional
	section, there is no expectation that the TC (Truncated) bit in the		section, there is no expectation that the TC bit in the response will
	response will be set to 1. At the time this document was published,		be set to 1. At the time this document is written, many of the root
	many of the root servers are not setting the TC bit when omitting		servers are not setting the TC bit when omitting addresses from the
	addresses from the Additional section.		Additional section.
	Note that [RFC9471] updates [RFC1035] with respect to the use of the		Note that [RFC9471] updates [RFC1034] with respect to the use of the
	TC bit. It says		TC bit. It says
	| If message size constraints prevent the inclusion of all glue		| If message size constraints prevent the inclusion of all glue
	| records for in-domain name servers, the server must set the TC		| records for in-domain name servers over the chosen transport, the
	| (Truncated) flag to inform the client that the response is		| server MUST set the TC (Truncated) flag to inform the client that
	| incomplete and that the client should use another transport to		| the response is incomplete and that the client SHOULD use another
	| retrieve the full response.		| transport to retrieve the full response.
	Because the priming response is not a referral, root server addresses		Because the priming response is not a referral, root server addresses
	in the priming response are not considered glue records. Thus,		in the priming response are not considered glue records. Thus,
	[RFC9471] does not apply to the priming response and root servers are		[RFC9471] does not apply to the priming response and root servers are
	not required to set the TC bit if not all root server addresses fit		not required to set the TC bit if not all root server addresses fit
	within message size constraints. There are no requirements on the		within message size constraints. There are no requirements on the
	number of root server addresses that a root server must include in a		number of root server addresses that a root server must include in a
	priming response.		priming response.
	5. Post-Priming Strategies		5. Post-Priming Strategies
	skipping to change at line 361 ¶		skipping to change at line 361 ¶
	prevent such redirection.		prevent such redirection.
	An on-path attacker who sees a priming query coming from a resolver		An on-path attacker who sees a priming query coming from a resolver
	can inject false answers before a root server can give correct		can inject false answers before a root server can give correct
	answers. If the attacker's answers are accepted, this can set up the		answers. If the attacker's answers are accepted, this can set up the
	ability to give further false answers for future queries to the		ability to give further false answers for future queries to the
	resolver. False answers for root servers are more dangerous than,		resolver. False answers for root servers are more dangerous than,
	say, false answers for TLDs, because the root is the highest node of		say, false answers for TLDs, because the root is the highest node of
	the DNS. See Section 3.3 for more discussion.		the DNS. See Section 3.3 for more discussion.
	In both of the scenarios above, a validating resolver will be able to		In both of the scenarios listed here, a validating resolver will be
	detect the attack if its chain of queries comes to a zone that is		able to detect the attack if its chain of queries comes for a zone
	signed, but not for those that are unsigned.		that is signed, but not for those that are unsigned.
	7. IANA Considerations		7. IANA Considerations
	This document has no IANA actions.		This document has no IANA actions.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	skipping to change at line 491 ¶		skipping to change at line 491 ¶
	* Clarified that machine-in-the-middle attacks could be successful		* Clarified that machine-in-the-middle attacks could be successful
	for non-signed TLDs.		for non-signed TLDs.
	* Added discussion of where resolvers that pre-fetch should get the		* Added discussion of where resolvers that pre-fetch should get the
	root NS addresses.		root NS addresses.
	* Elevated the expectations in Section 4.1 ("Expected Properties of		* Elevated the expectations in Section 4.1 ("Expected Properties of
	the Priming Response") to MUST-level.		the Priming Response") to MUST-level.
	* Clarified that "currently" means "at the time this document was		* Clarified that "currently" means "at the time this document is
	published".		published".
	* Added a note about priming and RFC 8806.		* Added a note about priming and RFC 8806.
	* Added a reference to research about discontinued root server		* Added a reference to research about discontinued root server
	addresses.		addresses.
	Acknowledgements		Acknowledgements
	RFC 8109 was the product of the DNSOP WG and benefited from the		RFC 8109 was the product of the DNSOP WG and benefited from the
	reviews done there. This document also benefited from review by		reviews done there. This document also benefited from review by
	Duane Wessels.		Duane Wessels.
	Authors' Addresses		Authors' Addresses
	Peter Koch		Peter Koch
	DENIC eG		DENIC eG
	Kaiserstrasse 75-77
	60329 Frankfurt
	Germany
	Phone: +49 69 27235 0
	Email: pk@DENIC.DE		Email: pk@DENIC.DE
	Matt Larson		Matt Larson
	ICANN		ICANN
	Email: matt.larson@icann.org		Email: matt.larson@icann.org
	Paul Hoffman		Paul Hoffman
	ICANN		ICANN
	Email: paul.hoffman@icann.org		Email: paul.hoffman@icann.org
End of changes. 17 change blocks.
	32 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.48.