idnits 2.17.1 draft-ietf-dnsop-resolver-priming-03.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 (July 15, 2013) is 3936 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) == Outdated reference: A later version (-05) exists of draft-koch-dns-glue-clarifications-04 -- Obsolete informational reference (is this intentional?): RFC 2870 (Obsoleted by RFC 7720) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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: January 16, 2014 Dyn, Inc. 6 July 15, 2013 8 Initializing a DNS Resolver with Priming Queries 9 draft-ietf-dnsop-resolver-priming-03 11 Abstract 13 This document describes the initial queries a DNS resolver is 14 supposed to emit to initialize its cache with a current NS RRSet for 15 the root zone as well as the necessary address information. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 16, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 Domain Name System (DNS) resolvers need a starting point to resolve 52 queries. [RFC1034], section 5.3.2, defines the SBELT structure in a 53 full resolver as: 55 ``a "safety belt" structure of the same form as SLIST, which is 56 initialized from a configuration file, and lists servers which 57 should be used when the resolver doesn't have any local 58 information to guide name server selection. The match count will 59 be -1 to indicate that no labels are known to match.'' 61 Section 5.3.3 of [RFC1034] adds 63 ``the usual choice is two of the root servers and two of the 64 servers for the host's domain'' 66 Today's practice generally seperates serving and resolving 67 functionality, so the servers ``for the host's domain'' might no 68 longer be an appropriate choice, even if they were only intended to 69 resolve ``local'' names, especially since the SBELT structure does 70 not distinguish between local and global information. In addition, 71 DNS server implementations have for a long time been seeded with not 72 only two but an exhaustive list of the root servers' addresses. This 73 list is either supplied as a configuration file (root "hints", an 74 excerpt of the DNS root zone) or even compiled into the software. 76 The list of root name servers has been rather stable over the last 77 fifteen years. After the last four servers had been added and moved 78 to their final (network) destinations in 1997, there have been only 79 five address changes affecting the L (twice), J, B, and D servers. 80 Research is available for B [Mann2006] and J [BLKT2004], which shows 81 that several months or even years after the change had become 82 effective, traffic is still received on the old addresses. 83 Therefore, it is important that resolvers be able to cope with 84 change, even without relying upon configuration updates to be applied 85 by their operator. 87 Work by the ICANN SSAC and RSSAC committees, [SSAC016] and [SSAC017], 88 aiming at adding AAAA RRs for the root name servers' names, deals 89 with priming queries and so does a draft on DNSSEC Trust Anchor 90 maintenance [I-D.ietf-dnsop-dnssec-trust-anchor]. However, it turned 91 out that despite having been practiced for a long time, priming 92 queries have not yet been documented as an important resolver 93 feature. 95 The following sections cover parameters of both the priming query and 96 the response to be sent by a root name server. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. Priming Queries 104 This document only deals with recursive name servers (recursive 105 resolvers, resolvers) for the IN CLASS. 107 2.1. Parameters of a Priming Query 109 A priming query SHOULD use a QNAME of "." and a QTYPE of NS. The 110 priming query MUST be sent over UDP (section 6.1.3.2 of [RFC1123]). 111 The UDP source port SHOULD be randomly selected [RFC5452]. The RD 112 bit MUST NOT be set. 114 The resolver SHOULD also use EDNS0 [RFC2671] and announce and handle 115 a reassembly size of at least 1024 octets [RFC3226]. This is to 116 cover the size of a full priming response (see Section 3.3). 118 2.2. Repeating Priming Queries 120 A resolver SHOULD NOT originate a priming query more often than once 121 per day (or whenever it starts). It SHOULD adhere to the TTL values 122 given in the priming response. To avoid amnesia, the resolver MAY 123 proactively re-prime before the old root NS RRSet expires from the 124 cache, but only after 75 percent of the NS RRSet's TTL (or of the A/ 125 AAAA RRSets' TTL, whichever is lower) have passed. 127 Should the priming query time out, the resolver SHOULD retry with a 128 different target address. 130 2.3. Target Selection 132 A resolver MUST select the target for a priming query randomly from 133 the list of addresses (IPv4 and IPv6) available in its SBELT 134 structure and it MUST ensure that all targets are selected with equal 135 probability even upon startup. For resending the priming query to a 136 different server the random selection SHOULD also be used. 138 2.4. DNSSEC with Priming Queries 140 The resolver SHOULD NOT set the DNSSEC OK [RFC4033] bit. 142 Discussion: Delegations in referral responses are not signed, so 143 consequently the priming response is not validated, either. For that 144 to work, the priming response would also have to be self-contained in 145 that it would allow the resolver to not only validate the NS RRSet 146 (with the root DNSKEY RRSet and the root NS RRSet's signature), but 147 also the A and AAAA RRSets. All this information cannot be 148 guaranteed to be either present at the root name servers or fit into 149 the priming reponse even with the largest feasible EDNS0 buffer size. 150 In fact, in today's Internet, with the root name servers' names under 151 "ROOT-SERVERS.NET.", this isn't even true for the top level domain 152 involved. So, even though a poisoned priming response could 153 drastically influence the resolver's operations, there is little a 154 DNSSEC enhanced priming response could achieve without the whole 155 validation chain. This would probably call for a different naming 156 scheme (see section 6.1 of [I-D.koch-dns-glue-clarifications]). 158 3. Priming Responses 160 A root name server cannot distinguish a priming query from any other 161 query for the root NS RRSet, except that QTYPE NS would not usually 162 be part of the DNS resolution process. 164 3.1. Expected Properties of the Priming Response 166 The priming response can be expected to have an RCODE of NOERROR and 167 the AA bit set. Also, there should be an NS RRSet in the answer 168 section (since the NS RRSet originates from the root zone), an empty 169 authority section (since the NS RRSet already appears in the answer 170 section) and an additional section with A and AAAA RRSets for the 171 root name servers pointed at by the NS RRSet. Resolver software 172 SHOULD NOT expect a fixed number of 13 NS RRs, since "internal" root 173 server setups in split DNS configurations might use a different 174 number of servers. Resolver software SHOULD warn the operator about 175 any change in the number or names of name servers or their addresses 176 compared to the SBELT information. 178 3.2. Use of the Priming Response 180 A resolver MAY use the priming response as it would use any other 181 data fed to its cache. However, it SHOULD NOT use the SBELT 182 information directly in any responses it hands out. 184 3.3. Completeness of the Response 186 Assuming an upper bound of thirteen root name servers and one address 187 each for IPv4 and IPv6, the combined size of all the A and AAAA 188 RRSets is 13 * (16 + 28) == 572, independent of the naming scheme. 189 Not even counting the NS RRSet, this value exceeds the original 512 190 octet payload limit. 192 For an EDNS response, a resolver SHOULD consider the address 193 information found in the additional section complete for any 194 particular server that appears at all. In other words: if the 195 additional section only has an A RRSet for a server, the resolver 196 SHOULD assume that no AAAA RRSet exists. This is to avoid repeated 197 unnecessary queries for names of name servers that do not or not yet 198 offer IPv6 service, or, in perspective, will have ceased IPv4 199 service. 201 If the resolver did not announce a reassembly size larger than 512 202 octets, this assumption is invalid. Simple re-issueing of the 203 priming query does not help with those root name servers that respond 204 with a fixed order of addresses in the additional section. Instead 205 the resolver ought to issue direct queries for A and AAAA RRSets for 206 the remaining names. In today's environment these RRSets would be 207 authoritatively available from the root name servers. 209 4. Requirements for Root Name Servers and the Root Zone 211 The operational requirements for root name servers are described in 212 [RFC2870]. This section specifies additional guidance for the 213 configuration of and software deployed at the root name servers. 215 All DNS root name servers need to be able to provide for all 216 addresses of all root name servers. This can easily achieved by 217 making all root name servers authoritative for the zone containing 218 the servers' names. 220 If the response packet does not provide for more than 512 octets due 221 to lack of EDNS0 support, A RRSets SHOULD be given preference over 222 AAAA RRSets when filling the additional section. 224 [[EDNS0 is used as an indication of AAAA understanding on the side of 225 the client. What to do with small payload sizes indicated by EDNS0 226 is open to discussion. At the time of writing, some root name 227 servers will fill the additional section with all available A RRSets, 228 only adding some AAAA RRSets, when queried over IPv4 without EDNS0. 229 Other servers will deliver more AAAA RRSets, therefore withholding 230 some A RRSets completely [RFC4472].]] 232 To ensure equal availability the A and AAAA RRSets for the rot name 233 servers' names SHOULD have identical TTL values at the authoritative 234 source. 236 [[Do the TTLs for the root NS RRSet and address RRSets in the root 237 and the ROOT-SERVERS.NET. zones need to be aligned? In real life 238 responses, the address RRSet's TTL values vary by name server 239 implementation.]] 241 5. Security Considerations 243 This document deals with priming a DNS resolver's cache. The usual 244 DNS caveats apply. Use of DNSSEC with priming queries is discussed 245 in section 2.4. 247 Spoofing a response to a priming query can be used to redirect all 248 queries originating from a victim resolver, therefore any difference 249 between the inital SBELT list and the priming response SHOULD be 250 brought to the operators' attention. There is also a chance that the 251 random target selection chooses the address of a retired root name 252 server. Operational measures to prevent reuse of these addresses are 253 out of the scope of this document. 255 6. IANA Considerations 257 This document does not propose any new IANA registry nor does it ask 258 for any allocation from an existing IANA registry. 260 However, this document deals with requirements for the root zone and 261 root server operations. 263 [[Any recommendation on the "." NS RRSet TTL or the TTLs of the 264 respective A and/or AAAA RRSets would go here.]] 266 7. References 268 7.1. Normative References 270 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 271 STD 13, RFC 1034, November 1987. 273 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 274 and Support", STD 3, RFC 1123, October 1989. 276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 280 2671, August 1999. 282 [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver 283 message size requirements", RFC 3226, December 2001. 285 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 286 Rose, "DNS Security Introduction and Requirements", RFC 287 4033, March 2005. 289 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 290 Resilient against Forged Answers", RFC 5452, January 2009. 292 7.2. Informative References 294 [BLKT2004] 295 Barber, P., Larson, M., Kosters, M., and P. Toscano, "Life 296 and Times of J-Root", NANOG 32, October 2004. 298 [I-D.ietf-dnsop-dnssec-trust-anchor] 299 Larson, M. and O. Gudmundsson, "DNSSEC Trust Anchor 300 Configuration and Maintenance", draft-ietf-dnsop-dnssec- 301 trust-anchor-04 (work in progress), October 2010. 303 [I-D.koch-dns-glue-clarifications] 304 Koch, P., "DNS Glue RR Survey and Terminology 305 Clarification", draft-koch-dns-glue-clarifications-04 306 (work in progress), July 2010. 308 [Mann2006] 309 Manning, B., "persistent queries and phantom nameservers", 310 WIDE/CAIDA Workshop , October 2006. 312 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 313 Name Server Operational Requirements", BCP 40, RFC 2870, 314 June 2000. 316 [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational 317 Considerations and Issues with IPv6 DNS", RFC 4472, April 318 2006. 320 [SSAC016] ICANN Security and Stability Advisory Committee, "Testing 321 Firewalls for IPv6 and EDNS0 Support", SSAC 016, January 322 2007. 324 [SSAC017] ICANN Security and Stability Advisory Committee, "Testing 325 Recursive Name Servers for IPv6 and EDNS0 Support", SSAC 326 017, February 2007. 328 Appendix A. Document Revision History 330 This section is to be removed should the draft be published. 332 $Id: draft-ietf-dnsop-resolver-priming.xml,v 1.6 2013/07/15 17:35:18 333 pk Exp $ 335 A.1. -03 WG Document 336 Revived. Resolved most open issues [[]] as per previous WG 337 discussion. Minor edits on history and wording. All root servers 338 authoritative for ROOT-SERVERS.NET. 340 A.2. -02 WG Document 342 Revived. Changed use of DNSSEC OK in the priming query as per the WG 343 discussion. 345 A.3. -01 WG Document 347 Revived with minor edits. Open issues marked [[]]. 349 A.4. -00 WG Document 351 Reposted as WG document with minor edits. 353 Added re-primimg proposal and A/AAAA TTL considerations. 355 A.5. Initial Document 357 First draft 359 Authors' Addresses 361 Peter Koch 362 DENIC eG 363 Kaiserstrasse 75-77 364 Frankfurt 60329 365 DE 367 Phone: +49 69 27235 0 368 Email: pk@DENIC.DE 370 Matt Larson 371 Dyn, Inc. 372 150 Dow St 373 Manchester, NH 03101 374 USA 376 Email: mlarson@dyn.com