idnits 2.17.1 draft-ietf-dnsop-resolver-priming-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 24, 2016) is 2673 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Koch 3 Internet-Draft DENIC eG 4 Intended status: Best Current Practice M. Larson 5 Expires: June 27, 2017 P. Hoffman 6 ICANN 7 December 24, 2016 9 Initializing a DNS Resolver with Priming Queries 10 draft-ietf-dnsop-resolver-priming-11 12 Abstract 14 This document describes the queries that a DNS resolver should emit 15 to initialize its cache. The result is that the resolver gets both a 16 current NS RRSet for the root zone and the necessary address 17 information for reaching the root servers. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 27, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 Recursive DNS resolvers need a starting point to resolve queries. 54 [RFC1034] describes a common scenario for recursive resolvers: they 55 begin with an empty cache and some configuration for finding the 56 names and addresses of the DNS root servers. [RFC1034] describes 57 that configuration as a list of servers that will give authoritative 58 answers to queries about the root. This has become a common 59 implementation choice for recursive resolvers, and is the topic of 60 this document. 62 This document describes the steps needed for this common 63 implementation choice. Note that this is not the only way to start a 64 recursive name server with an empty cache, but it is the only one 65 described in [RFC1034]. Some implementers have chosen other 66 directions, some of which work well and others of which fail 67 (sometimes disastrously) under different conditions. For example, an 68 implementation that only gets the addresses of the root name servers 69 from configuration, not from the DNS as described in this document, 70 will have stale data that could cause slower resolution. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 This document only deals with recursive name servers (recursive 77 resolvers, resolvers) for the IN class. 79 2. Description of Priming 81 Priming is the act of finding the list of root servers from a 82 configuration that lists some or all of the purported IP addresses of 83 some or all of those root servers. A recursive resolver starts with 84 no information about the root servers, and ends up with a list of 85 their names and their addresses. 87 Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The 88 scenario used in that description, that of a recursive server that is 89 also authoritative, is no longer as common. 91 The configured list of IP addresses for the root servers usually 92 comes from the vendor or distributor of the recursive server 93 software. This list is usually correct and complete when shipped, 94 but may become out of date over time. 96 The list of root server operators and the domain name associated with 97 each one has been stable since 1997. However, there are address 98 changes for the root server domain names, both for IPv4 and IPv6 99 addresses. However, research shows that after those addresses 100 change, some resolvers never get the new addresses. Therefore, it is 101 important that resolvers be able to cope with change, even without 102 relying upon configuration updates to be applied by their operator. 103 Root server change is the main reason that resolvers need to do 104 priming instead of just going from a configured list to get a full 105 and accurate list of root servers. 107 3. Priming Queries 109 A priming query is a DNS query used to get the root server 110 information in a resolver. It has a QNAME of "." and a QTYPE of NS, 111 and is sent to one of the addresses in the configuration for the 112 recursive resolver. The priming query can be sent over either UDP or 113 TCP. If the query is sent over UDP, the source port SHOULD be 114 randomly selected (see [RFC5452]). The RD bit MAY be set to 0 or 1, 115 although the meaning of it being set to 1 is undefined for priming 116 queries. 118 The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries 119 and SHOULD announce and handle a reassembly size of at least 1024 120 octets [RFC3226]. Doing so allows responses that cover the size of a 121 full priming response (see Section 4.2) for the current set of root 122 servers. See Section 3.3 for discussion of setting the DNSSEC OK 123 (DO) bit (defined in [RFC4033]). 125 3.1. Repeating Priming Queries 127 The recursive resolver SHOULD send a priming query only when it is 128 needed, such as when the resolver starts with an empty cache and when 129 the NS RRset for the root zone has expired. Because the NS records 130 for the root are not special, the recursive resolver expires those NS 131 records according to their TTL values. (Note that a recursive 132 resolver MAY pre-fetch the NS RRset before it expires.) 134 If a priming query does not get a response, the recursive resolver 135 needs to retry the query with a different target address from the 136 configuration. 138 3.2. Target Selection 140 In order to spread the load across all the root server domain names, 141 the recursive resolver SHOULD select the target for a priming query 142 randomly from the list of addresses. The recursive resolver might 143 choose either IPv4 and IPv6 addresses based on its knowledge of 144 whether the system on which it is running has adequate connectivity 145 on either type of address. 147 Note that this recommended method is not the only way to choose from 148 the list in a recursive resolver's configuration. Two other common 149 methods include picking the first from the list, and remembering 150 which address in the list gave the fastest response earlier and using 151 that one. There are probably other methods in use today. However, 152 the random method listed above SHOULD be used for priming. 154 3.3. DNSSEC with Priming Queries 156 The resolver MAY set the DNSSEC OK (DO) bit. At the time this 157 document is being published, there is little use to performing DNSSEC 158 validation on the priming query. Currently all root name server 159 names end in "root-servers.net" and the AAAA and A RRsets for the 160 root server names reside in the "root-servers.net" zone. All root 161 servers are also authoritative for this zone, allowing priming 162 responses to include the appropriate root name server A and AAAA 163 RRsets. But because the "root-servers.net" zone is not currently 164 signed, these RRsets cannot be validated. 166 A man-in-the-middle attack on the priming query could direct a 167 resolver to a rogue root name server. Note, however, that a 168 validating resolver will not accept responses from rogue root name 169 servers if they are different from the real responses because the 170 resolver has a trust anchor for the root and the answers from the 171 root are signed. Thus, if there is a man-in-the-middle attack on the 172 priming query, the only result for a validating resolver will be a 173 denial of service, not the resolver's accepting the bad responses. 175 If the "root-servers.net" zone is later signed, or if the root 176 servers are named in a different zone and that zone is signed, having 177 DNSSEC validation for the priming queries might be valuable. 179 4. Priming Responses 181 A priming query is a normal DNS query. Thus, a root name server 182 cannot distinguish a priming query from any other query for the root 183 NS RRSet. Thus, the root server's response will also be a normal DNS 184 response. 186 4.1. Expected Properties of the Priming Response 188 The priming response is expected to have an RCODE of NOERROR, and to 189 have the AA bit set. Also, it is expected to have an NS RRSet in the 190 Answer section (because the NS RRSet originates from the root zone), 191 and an empty Authority section (because the NS RRSet already appears 192 in the Answer section). There will also be an Additional section 193 with A and/or AAAA RRSets for the root name servers pointed at by the 194 NS RRSet. 196 Resolver software SHOULD treat the response to the priming query as a 197 normal DNS response, just as it would use any other data fed to its 198 cache. Resolver software SHOULD NOT expect exactly 13 NS RRs because 199 historically some root servers have returned fewer. 201 4.2. Completeness of the Response 203 There are currently 13 root servers. All have one IPv4 address and 204 one IPv6 address. Not even counting the NS RRSet, the combined size 205 of all the A and AAAA RRSets exceeds the original 512 octet payload 206 limit from [RFC1035]. 208 In the event of a response where the Additional section omits certain 209 root server address information, re-issuing of the priming query does 210 not help with those root name servers that respond with a fixed order 211 of addresses in the Additional section. Instead, the recursive 212 resolver needs to issue direct queries for A and AAAA RRSets for the 213 remaining names. Currently, these RRSets would be authoritatively 214 available from the root name servers. 216 5. Security Considerations 218 Spoofing a response to a priming query can be used to redirect all of 219 the queries originating from a victim recursive resolver to one or 220 more servers for the attacker. Until the responses to priming 221 queries are protected with DNSSEC, there is no definitive way to 222 prevent such redirection. 224 An on-path attacker who sees a priming query coming from a resolver 225 can inject false answers before a root server can give correct 226 answers. If the attacker's answers are accepted, this can set up the 227 ability to give further false answers for future queries to the 228 resolver. False answers for root servers are more dangerous than, 229 say, false answers for TLDs, because the root is the highest node of 230 the DNS. See Section 3.3 for more discussion. 232 In both of the scenarios above, a validating resolver will be able to 233 detect the attack if its chain of queries comes to a zone that is 234 signed, but not for those that are unsigned. 236 6. IANA Considerations 238 None. 240 7. Normative References 242 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 243 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 244 . 246 [RFC1035] Mockapetris, P., "Domain names - implementation and 247 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 248 November 1987, . 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 256 message size requirements", RFC 3226, 257 DOI 10.17487/RFC3226, December 2001, 258 . 260 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 261 Rose, "DNS Security Introduction and Requirements", 262 RFC 4033, DOI 10.17487/RFC4033, March 2005, 263 . 265 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 266 Resilient against Forged Answers", RFC 5452, 267 DOI 10.17487/RFC5452, January 2009, 268 . 270 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 271 for DNS (EDNS(0))", STD 75, RFC 6891, 272 DOI 10.17487/RFC6891, April 2013, 273 . 275 Appendix A. Acknowledgements 277 This document is the product of the DNSOP WG and benefitted from the 278 reviews done there. 280 Authors' Addresses 282 Peter Koch 283 DENIC eG 284 Kaiserstrasse 75-77 285 Frankfurt 60329 286 DE 288 Phone: +49 69 27235 0 289 Email: pk@DENIC.DE 291 Matt Larson 292 ICANN 294 Email: matt.larson@icann.org 296 Paul Hoffman 297 ICANN 299 Email: paul.hoffman@icann.org