idnits 2.17.1 draft-klh-dnsop-rfc8109bis-01.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 date (16 November 2020) is 1250 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) == Unused Reference: 'RSSAC023v2' is defined on line 398, but no explicit reference was found in the text ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Obsoletes: 8109 (if approved) M. Larson 5 Intended status: Best Current Practice P. Hoffman 6 Expires: 20 May 2021 ICANN 7 16 November 2020 9 Initializing a DNS Resolver with Priming Queries 10 draft-klh-dnsop-rfc8109bis-01 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 Resource Record Set (RRset) for the root zone and the 17 necessary address information for reaching the root servers. 19 This document, when published, obsoletes RFC 8109. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 20 May 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Changes from RFC 8109 . . . . . . . . . . . . . . . . . . 3 56 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Description of Priming . . . . . . . . . . . . . . . . . . . 4 58 2.1. Content of Priming Information . . . . . . . . . . . . . 4 59 3. Priming Queries . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Repeating Priming Queries . . . . . . . . . . . . . . . . 5 61 3.2. Target Selection . . . . . . . . . . . . . . . . . . . . 5 62 3.3. DNSSEC with Priming Queries . . . . . . . . . . . . . . . 6 63 4. Priming Responses . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Expected Properties of the Priming Response . . . . . . . 7 65 4.2. Completeness of the Response . . . . . . . . . . . . . . 7 66 5. Post-Priming Strategies . . . . . . . . . . . . . . . . . . . 7 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 71 8.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Recursive DNS resolvers need a starting point to resolve queries. 78 [RFC1034] describes a common scenario for recursive resolvers: they 79 begin with an empty cache and some configuration for finding the 80 names and addresses of the DNS root servers. [RFC1034] describes 81 that configuration as a list of servers that will give authoritative 82 answers to queries about the root. This has become a common 83 implementation choice for recursive resolvers, and is the topic of 84 this document. 86 This document describes the steps needed for this common 87 implementation choice. Note that this is not the only way to start a 88 recursive name server with an empty cache, but it is the only one 89 described in [RFC1034]. Some implementers have chosen other 90 directions, some of which work well and others of which fail 91 (sometimes disastrously) under different conditions. For example, an 92 implementation that only gets the addresses of the root name servers 93 from configuration, not from the DNS as described in this document, 94 will have stale data that could cause slower resolution. 96 This document only deals with recursive name servers (recursive 97 resolvers, resolvers) for the IN class. 99 1.1. Changes from RFC 8109 101 This document obsoletes [RFC8109]. The significant changes from RFC 102 8109 are: 104 * Added section on the content of priming information. 106 * Added paragraph about no expectation that the TC bit in responses 107 will be set. 109 * Changed "man-in-the-middle" to "machine-in-the-middle" to be both 110 less sexist and more technically accurate. 112 * Clarified that there are other effects of machine-in-the-middle 113 attacks. 115 * Clarified language for root server domain names as "root server 116 identifiers". 118 * Added informative references to RSSAC documents. 120 * Added short discussion about this document and private DNS. 122 * Future changes noted in the current text with [[ text like this 123 ]]. 125 1.2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 See [RSSAC026v2] for terminology that relates to the root server 134 system. 136 2. Description of Priming 138 Priming is the act of finding the list of root servers from a 139 configuration that lists some or all of the purported IP addresses of 140 some or all of those root servers. In priming, a recursive resolver 141 starts with no cached information about the root servers, and 142 finishes with a full list of their names and their addresses in its 143 cache. 145 Priming is described in Sections 5.3.2 and 5.3.3 of [RFC1034]. The 146 scenario used in that description, that of a recursive server that is 147 also authoritative, is no longer as common. 149 The configured list of IP addresses for the root servers usually 150 comes from the vendor or distributor of the recursive server 151 software. This list is usually correct and complete when shipped, 152 but may become out of date over time. 154 The domain names for the root servers are called the "root server 155 identifiers". This list has been stable since 1997, but the IPv4 and 156 IPv6 addresses for the root server identifiers sometimes change, 157 Research shows that after those addresses change, some resolvers 158 never get the new addresses. Therefore, it is important that 159 resolvers be able to cope with change, even without relying upon 160 configuration updates to be applied by their operator. Root server 161 identifier and address changes are the main reasons that resolvers 162 need to do priming instead of just going from a configured list to 163 get a full and accurate list of root servers. 165 See [RSSAC023v2]for a history of the root server system. 167 Although this document is targeted at the global DNS, it also could 168 apply to a private DNS as well. These terms are defined in 169 [RFC8499]. 171 2.1. Content of Priming Information 173 As described above, the configuration for priming is a list of IP 174 addresses. The priming information in software may be in any format 175 that gives he software the addresses associated with at least some of 176 the root server identifiers. 178 Some software has configuration that also contains the root server 179 identifiers, sometimes as comments and sometimes as data consumed by 180 the software. For example, IANA's "Root Hints File" at 181 is derived directly from 182 the root zone and contains all of the addresses of the root server 183 identifiers found in the root zone, It is in DNS master file format, 184 and includes the root server identifiers. Although there is no harm 185 to adding such information, it is not useful in the root priming 186 process. 188 3. Priming Queries 190 A priming query is a DNS query used to get the root server 191 information in a resolver. It has a QNAME of ".", a QTYPE of NS, and 192 a QCLASS of IN; it is sent to one of the addresses in the 193 configuration for the recursive resolver. The priming query can be 194 sent over either UDP or TCP. If the query is sent over UDP, the 195 source port SHOULD be randomly selected (see [RFC5452]). The 196 Recursion Desired (RD) bit MAY be set to 0 or 1, although the meaning 197 of it being set to 1 is undefined for priming queries. 199 The recursive resolver SHOULD use EDNS0 [RFC6891] for priming queries 200 and SHOULD announce and handle a reassembly size of at least 1024 201 octets [RFC3226]. Doing so allows responses that cover the size of a 202 full priming response (see Section 4.2) for the current set of root 203 servers. See Section 3.3 for discussion of setting the DNSSEC OK 204 (DO) bit (defined in [RFC4033]). 206 3.1. Repeating Priming Queries 208 The recursive resolver SHOULD send a priming query only when it is 209 needed, such as when the resolver starts with an empty cache and when 210 the NS RRset for the root zone has expired. Because the NS records 211 for the root are not special, the recursive resolver expires those NS 212 records according to their TTL values. (Note that a recursive 213 resolver MAY pre-fetch the NS RRset before it expires.) 215 [[ Need to discuss: when pre-fetching, does the resolver send the 216 queries to the addresses associated with the . / NS RRset in the 217 cache, or does the resolver go back to the addresses in the 218 configuration? ]] 220 If a priming query does not get a response, the recursive resolver 221 needs to retry the query with a different target address from the 222 configuration. 224 3.2. Target Selection 226 In order to spread the load across all the root server identifiers, 227 the recursive resolver SHOULD select the target for a priming query 228 randomly from the list of addresses. The recursive resolver might 229 choose either IPv4 or IPv6 addresses based on its knowledge of 230 whether the system on which it is running has adequate connectivity 231 on either type of address. 233 Note that this recommended method is not the only way to choose from 234 the list in a recursive resolver's configuration. Two other common 235 methods include picking the first from the list, and remembering 236 which address in the list gave the fastest response earlier and using 237 that one. There are probably other methods in use today. However, 238 the random method listed above SHOULD be used for priming. 240 3.3. DNSSEC with Priming Queries 242 [[ This section talks about sending the DO bit, but does not actually 243 talk about validating the response to the priming query. This became 244 important after the root KSK rollover in 2018 because some resolvers 245 apparently were validating and only had the old KSK, but were still 246 sending RFC 8145 telemetry even after failing to validate their 247 priming response. ]] 249 The resolver MAY set the DNSSEC OK (DO) bit. At the time of 250 publication, there is little use to performing DNSSEC validation on 251 the priming query. Currently, all root name server names end in 252 "root-servers.net" and the AAAA and A RRsets for the root server 253 names reside in the "root-servers.net" zone. All root servers are 254 also authoritative for this zone, allowing priming responses to 255 include the appropriate root name server A and AAAA RRsets. But, 256 because the "root-servers.net" zone is not currently signed, these 257 RRsets cannot be validated. 259 A machine-in-the-middle attack on the priming query could direct a 260 resolver to a rogue root name server. Note, however, that a 261 validating resolver will not accept responses from rogue root name 262 servers if they are different from the real responses because the 263 resolver has a trust anchor for the root and the answers from the 264 root are signed. Thus, if there is a machine-in-the-middle attack on 265 the priming query, the results for a validating resolver could be a 266 denial of service, or the attacker seeing queries while returning 267 good answers, but not the resolver's accepting the bad responses. 269 If the "root-servers.net" zone is later signed, or if the root 270 servers are named in a different zone and that zone is signed, having 271 DNSSEC validation for the priming queries might be valuable. 273 4. Priming Responses 275 A priming query is a normal DNS query. Thus, a root name server 276 cannot distinguish a priming query from any other query for the root 277 NS RRset. Thus, the root server's response will also be a normal DNS 278 response. 280 4.1. Expected Properties of the Priming Response 282 The priming response is expected to have an RCODE of NOERROR, and to 283 have the Authoritative Answer (AA) bit set. Also, it is expected to 284 have an NS RRset in the Answer section (because the NS RRset 285 originates from the root zone), and an empty Authority section 286 (because the NS RRset already appears in the Answer section). There 287 will also be an Additional section with A and/or AAAA RRsets for the 288 root name servers pointed at by the NS RRset. 290 Resolver software SHOULD treat the response to the priming query as a 291 normal DNS response, just as it would use any other data fed to its 292 cache. Resolver software SHOULD NOT expect exactly 13 NS RRs 293 because, historically, some root servers have returned fewer. 295 4.2. Completeness of the Response 297 There are currently 13 root servers. All have one IPv4 address and 298 one IPv6 address. Not even counting the NS RRset, the combined size 299 of all the A and AAAA RRsets exceeds the original 512-octet payload 300 limit from [RFC1035]. 302 In the event of a response where the Additional section omits certain 303 root server address information, re-issuing of the priming query does 304 not help with those root name servers that respond with a fixed order 305 of addresses in the Additional section. Instead, the recursive 306 resolver needs to issue direct queries for A and AAAA RRsets for the 307 remaining names. Currently, these RRsets would be authoritatively 308 available from the root name servers. 310 If the Additional section is truncated, there is no expectation that 311 the TC bit in the response will be set to 1. At the time that this 312 document is written, many of the root servers are not setting the TC 313 bit on responses with a truncated Additional section. 315 5. Post-Priming Strategies 317 [[ Describe some common post-priming strategies for picking which RSI 318 to use for queries sent to the root, such as "always use the 319 fastest", "create buckets of fastness and pick randomly in the 320 buckets", and others. ]] 322 6. Security Considerations 324 Spoofing a response to a priming query can be used to redirect all of 325 the queries originating from a victim recursive resolver to one or 326 more servers for the attacker. Until the responses to priming 327 queries are protected with DNSSEC, there is no definitive way to 328 prevent such redirection. 330 An on-path attacker who sees a priming query coming from a resolver 331 can inject false answers before a root server can give correct 332 answers. If the attacker's answers are accepted, this can set up the 333 ability to give further false answers for future queries to the 334 resolver. False answers for root servers are more dangerous than, 335 say, false answers for Top-Level Domains (TLDs), because the root is 336 the highest node of the DNS. See Section 3.3 for more discussion. 338 In both of the scenarios above, a validating resolver will be able to 339 detect the attack if its chain of queries comes to a zone that is 340 signed, but not for those that are unsigned. 342 7. IANA Considerations 344 This document does not require any IANA actions. 346 8. References 348 8.1. Normative References 350 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 351 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 352 . 354 [RFC1035] Mockapetris, P., "Domain names - implementation and 355 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 356 November 1987, . 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, 360 DOI 10.17487/RFC2119, March 1997, 361 . 363 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 364 message size requirements", RFC 3226, 365 DOI 10.17487/RFC3226, December 2001, 366 . 368 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 369 Rose, "DNS Security Introduction and Requirements", 370 RFC 4033, DOI 10.17487/RFC4033, March 2005, 371 . 373 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 374 Resilient against Forged Answers", RFC 5452, 375 DOI 10.17487/RFC5452, January 2009, 376 . 378 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 379 for DNS (EDNS(0))", STD 75, RFC 6891, 380 DOI 10.17487/RFC6891, April 2013, 381 . 383 [RFC8109] Koch, P., Larson, M., and P. Hoffman, "Initializing a DNS 384 Resolver with Priming Queries", BCP 209, RFC 8109, 385 DOI 10.17487/RFC8109, March 2017, 386 . 388 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 389 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 390 May 2017, . 392 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 393 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 394 January 2019, . 396 8.2. Informative References 398 [RSSAC023v2] 399 "History of the Root Server System", 2016, 400 . 403 [RSSAC026v2] 404 "RSSAC Lexicon", 2020, 405 . 408 Appendix A. Acknowledgements 410 RFC 8109 was the product of the DNSOP WG and benefitted from the 411 reviews done there. 413 Authors' Addresses 414 Peter Koch 415 DENIC eG 416 Kaiserstrasse 75-77 417 60329 Frankfurt 418 Germany 420 Phone: +49 69 27235 0 421 Email: pk@DENIC.DE 423 Matt Larson 424 ICANN 426 Email: matt.larson@icann.org 428 Paul Hoffman 429 ICANN 431 Email: paul.hoffman@icann.org