summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8109.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8109.txt')
-rw-r--r--doc/rfc/rfc8109.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc8109.txt b/doc/rfc/rfc8109.txt
new file mode 100644
index 0000000..3af133b
--- /dev/null
+++ b/doc/rfc/rfc8109.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Koch
+Request for Comments: 8109 DENIC eG
+BCP: 209 M. Larson
+Category: Best Current Practice P. Hoffman
+ISSN: 2070-1721 ICANN
+ March 2017
+
+
+ Initializing a DNS Resolver with Priming Queries
+
+Abstract
+
+ This document describes the queries that a DNS resolver should emit
+ 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
+ necessary address information for reaching the root servers.
+
+Status of This Memo
+
+ This memo documents an Internet Best Current Practice.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ BCPs is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8109.
+
+Copyright Notice
+
+ Copyright (c) 2017 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Koch et al. Best Current Practice [Page 1]
+
+RFC 8109 DNS Priming Queries March 2017
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Description of Priming ..........................................3
+ 3. Priming Queries .................................................3
+ 3.1. Repeating Priming Queries ..................................4
+ 3.2. Target Selection ...........................................4
+ 3.3. DNSSEC with Priming Queries ................................4
+ 4. Priming Responses ...............................................5
+ 4.1. Expected Properties of the Priming Response ................5
+ 4.2. Completeness of the Response ...............................5
+ 5. Security Considerations .........................................6
+ 6. IANA Considerations .............................................6
+ 7. Normative References ............................................6
+ Acknowledgements ...................................................7
+ Authors' Addresses .................................................7
+
+1. Introduction
+
+ Recursive DNS resolvers need a starting point to resolve queries.
+ [RFC1034] describes a common scenario for recursive resolvers: they
+ begin with an empty cache and some configuration for finding the
+ names and addresses of the DNS root servers. [RFC1034] describes
+ that configuration as a list of servers that will give authoritative
+ answers to queries about the root. This has become a common
+ implementation choice for recursive resolvers, and is the topic of
+ this document.
+
+ This document describes the steps needed for this common
+ 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
+ described in [RFC1034]. Some implementers have chosen other
+ directions, some of which work well and others of which fail
+ (sometimes disastrously) under different conditions. For example, an
+ implementation that only gets the addresses of the root name servers
+ from configuration, not from the DNS as described in this document,
+ will have stale data that could cause slower resolution.
+
+ 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].
+
+ This document only deals with recursive name servers (recursive
+ resolvers, resolvers) for the IN class.
+
+
+
+
+
+
+
+Koch et al. Best Current Practice [Page 2]
+
+RFC 8109 DNS Priming Queries March 2017
+
+
+2. Description of Priming
+
+ Priming is the act of finding the list of root servers from a
+ configuration that lists some or all of the purported IP addresses of
+ some or all of those root servers. A recursive resolver starts with
+ no information about the root servers, and ends up with a list of
+ their names and their addresses.
+
+ Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The
+ scenario used in that description, that of a recursive server that is
+ also authoritative, is no longer as common.
+
+ The configured list of IP addresses for the root servers usually
+ comes from the vendor or distributor of the recursive server
+ software. This list is usually correct and complete when shipped,
+ but may become out of date over time.
+
+ The list of root server operators and the domain name associated with
+ each one has been stable since 1997. However, there are address
+ changes for the root server domain names, both for IPv4 and IPv6
+ addresses. However, research shows that after those addresses
+ change, some resolvers never get the new addresses. Therefore, it is
+ important that resolvers be able to cope with change, even without
+ relying upon configuration updates to be applied by their operator.
+ Root server change is the main reason that resolvers need to do
+ priming instead of just going from a configured list to get a full
+ and accurate list of root servers.
+
+3. Priming Queries
+
+ A priming query is a DNS query used to get the root server
+ information in a resolver. It has a QNAME of "." and a QTYPE of NS,
+ and is sent to one of the addresses in the configuration for the
+ recursive resolver. The priming query can be sent over either UDP or
+ TCP. If the query is sent over UDP, the source port SHOULD be
+ randomly selected (see [RFC5452]). The Recursion Desired (RD) bit
+ MAY be set to 0 or 1, although the meaning of it being set to 1 is
+ undefined for priming queries.
+
+ The recursive resolver SHOULD use EDNS(0) [RFC6891] for priming
+ queries and SHOULD announce and handle a reassembly size of at least
+ 1024 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 servers. See Section 3.3 for discussion of setting the DNSSEC
+ OK (DO) bit (defined in [RFC4033]).
+
+
+
+
+
+
+Koch et al. Best Current Practice [Page 3]
+
+RFC 8109 DNS Priming Queries March 2017
+
+
+3.1. Repeating Priming Queries
+
+ The recursive resolver SHOULD send a priming query only when it is
+ needed, such as when the resolver starts with an empty cache and when
+ the NS RRset for the root zone has expired. Because the NS records
+ for the root are not special, the recursive resolver expires those NS
+ records according to their TTL values. (Note that a recursive
+ resolver MAY pre-fetch the NS RRset before it expires.)
+
+ If a priming query does not get a response, the recursive resolver
+ needs to retry the query with a different target address from the
+ configuration.
+
+3.2. Target Selection
+
+ In order to spread the load across all the root server domain names,
+ the recursive resolver SHOULD select the target for a priming query
+ randomly from the list of addresses. The recursive resolver might
+ choose either IPv4 or IPv6 addresses based on its knowledge of
+ whether the system on which it is running has adequate connectivity
+ on either type of address.
+
+ Note that this recommended method is not the only way to choose from
+ the list in a recursive resolver's configuration. Two other common
+ methods include picking the first from the list, and remembering
+ which address in the list gave the fastest response earlier and using
+ that one. There are probably other methods in use today. However,
+ the random method listed above SHOULD be used for priming.
+
+3.3. DNSSEC with Priming Queries
+
+ The resolver MAY set the DNSSEC OK (DO) bit. At the time of
+ publication, there is little use to performing DNSSEC validation on
+ the priming query. Currently, all root name server names end in
+ "root-servers.net" and the AAAA and A RRsets for the root server
+ names reside in the "root-servers.net" zone. All root servers are
+ also authoritative for this zone, allowing priming responses to
+ include the appropriate root name server A and AAAA RRsets. But,
+ because the "root-servers.net" zone is not currently signed, these
+ RRsets cannot be validated.
+
+ A man-in-the-middle attack on the priming query could direct a
+ resolver to a rogue root name server. Note, however, that a
+ validating resolver will not accept responses from rogue root name
+ servers if they are different from the real responses because the
+
+
+
+
+
+
+Koch et al. Best Current Practice [Page 4]
+
+RFC 8109 DNS Priming Queries March 2017
+
+
+ resolver has a trust anchor for the root and the answers from the
+ root are signed. Thus, if there is a man-in-the-middle attack on the
+ priming query, the only result for a validating resolver will be a
+ denial of service, not the resolver's accepting the bad responses.
+
+ If the "root-servers.net" zone is later signed, or if the root
+ servers are named in a different zone and that zone is signed, having
+ DNSSEC validation for the priming queries might be valuable.
+
+4. Priming Responses
+
+ A priming query is a normal DNS query. Thus, a root name server
+ cannot distinguish a priming query from any other query for the root
+ NS RRset. Thus, the root server's response will also be a normal DNS
+ response.
+
+4.1. Expected Properties of the Priming Response
+
+ The priming response is expected to have an RCODE of NOERROR, and to
+ have the Authoritative Answer (AA) bit set. Also, it is expected to
+ have an NS RRset in the Answer section (because the NS RRset
+ originates from the root zone), and an empty Authority section
+ (because the NS RRset already appears in the Answer section). There
+ will also be an Additional section with A and/or AAAA RRsets for the
+ root name servers pointed at by the NS RRset.
+
+ 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
+ cache. Resolver software SHOULD NOT expect exactly 13 NS RRs
+ because, historically, some root servers have returned fewer.
+
+4.2. Completeness of the Response
+
+ There are currently 13 root servers. All have one IPv4 address and
+ one IPv6 address. Not even counting the NS RRset, the combined size
+ of all the A and AAAA RRsets exceeds the original 512-octet payload
+ limit from [RFC1035].
+
+ In the event of a response where the Additional section omits certain
+ root server address information, re-issuing of the priming query does
+ not help with those root name servers that respond with a fixed order
+ of addresses in the Additional section. Instead, the recursive
+ resolver needs to issue direct queries for A and AAAA RRsets for the
+ remaining names. Currently, these RRsets would be authoritatively
+ available from the root name servers.
+
+
+
+
+
+
+Koch et al. Best Current Practice [Page 5]
+
+RFC 8109 DNS Priming Queries March 2017
+
+
+5. Security Considerations
+
+ Spoofing a response to a priming query can be used to redirect all of
+ the queries originating from a victim recursive resolver to one or
+ more servers for the attacker. Until the responses to priming
+ queries are protected with DNSSEC, there is no definitive way to
+ prevent such redirection.
+
+ An on-path attacker who sees a priming query coming from a resolver
+ can inject false answers before a root server can give correct
+ answers. If the attacker's answers are accepted, this can set up the
+ ability to give further false answers for future queries to the
+ resolver. False answers for root servers are more dangerous than,
+ say, false answers for Top-Level Domains (TLDs), because the root is
+ the highest node of the DNS. See Section 3.3 for more discussion.
+
+ In both of the scenarios above, a validating resolver will be able to
+ detect the attack if its chain of queries comes to a zone that is
+ signed, but not for those that are unsigned.
+
+6. IANA Considerations
+
+ This document does not require any IANA actions.
+
+7. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034,
+ November 1987, <http://www.rfc-editor.org/info/rfc1034>.
+
+ [RFC1035] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+ November 1987, <http://www.rfc-editor.org/info/rfc1035>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware
+ server/resolver message size requirements", RFC 3226,
+ DOI 10.17487/RFC3226, December 2001,
+ <http://www.rfc-editor.org/info/rfc3226>.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, DOI 10.17487/RFC4033, March 2005,
+ <http://www.rfc-editor.org/info/rfc4033>.
+
+
+
+Koch et al. Best Current Practice [Page 6]
+
+RFC 8109 DNS Priming Queries March 2017
+
+
+ [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More
+ Resilient against Forged Answers", RFC 5452,
+ DOI 10.17487/RFC5452, January 2009,
+ <http://www.rfc-editor.org/info/rfc5452>.
+
+ [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+ for DNS (EDNS(0))", STD 75, RFC 6891,
+ DOI 10.17487/RFC6891, April 2013,
+ <http://www.rfc-editor.org/info/rfc6891>.
+
+Acknowledgements
+
+ This document is the product of the DNSOP WG and benefitted from the
+ reviews done there.
+
+Authors' Addresses
+
+ Peter Koch
+ DENIC eG
+ Kaiserstrasse 75-77
+ Frankfurt 60329
+ Germany
+
+ Phone: +49 69 27235 0
+ Email: pk@DENIC.DE
+
+ Matt Larson
+ ICANN
+
+ Email: matt.larson@icann.org
+
+ Paul Hoffman
+ ICANN
+
+ Email: paul.hoffman@icann.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch et al. Best Current Practice [Page 7]
+