From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8109.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc8109.txt (limited to 'doc/rfc/rfc8109.txt') 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, . + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware + server/resolver message size requirements", RFC 3226, + DOI 10.17487/RFC3226, December 2001, + . + + [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, + . + + + +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, + . + + [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms + for DNS (EDNS(0))", STD 75, RFC 6891, + DOI 10.17487/RFC6891, April 2013, + . + +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] + -- cgit v1.2.3