idnits 2.17.1 draft-ietf-dnsop-let-localhost-be-localhost-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6761, but the abstract doesn't seem to directly say this. It does mention RFC6761 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 18, 2017) is 2321 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1537 (Obsoleted by RFC 1912) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP M. West 3 Internet-Draft Google, Inc 4 Updates: 6761 (if approved) December 18, 2017 5 Intended status: Standards Track 6 Expires: June 21, 2018 8 Let 'localhost' be localhost. 9 draft-ietf-dnsop-let-localhost-be-localhost-02 11 Abstract 13 This document updates the treatment of the special-use domain name 14 "localhost" as specified in RFC6761, Section 6.3, with the goal of 15 ensuring that it can be safely relied upon as a name for the local 16 host's loopback interface. To that end, stub resolvers are required 17 to resolve localhost names to loopback addresses. Recursive DNS 18 servers are required to return "NXDOMAIN" when queried for localhost 19 names, making non-conformant stub resolvers more likely to fail and 20 produce problem reports that result in updates. 22 Together, these requirements would allow applications and 23 specifications to join regular users in drawing the common-sense 24 conclusions that "localhost" means "localhost", and doesn't resolve 25 to somewhere else on the network. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on June 21, 2018. 44 Copyright Notice 46 Copyright (c) 2017 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology and notation . . . . . . . . . . . . . . . . . . 4 63 3. The "localhost." Special-Use Domain Name . . . . . . . . . . 4 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Domain Name Reservation Considerations . . . . . . . . . 5 66 4.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5.1. Applications are encouraged to resolve localhost names 69 themselves. . . . . . . . . . . . . . . . . . . . . . . . 6 70 5.2. 'localhost' labels in subdomains . . . . . . . . . . . . 6 71 6. Implementation Considerations . . . . . . . . . . . . . . . . 6 72 6.1. Non-DNS usage of localhost names . . . . . . . . . . . . 6 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 7.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Appendix A. Changes from RFC 6761 . . . . . . . . . . . . . . . 7 77 Appendix B. Changes in this draft . . . . . . . . . . . . . . . 8 78 B.1. draft-ietf-dnsop-let-localhost-be-localhost-02 . . . . . 8 79 B.2. draft-ietf-dnsop-let-localhost-be-localhost-01 . . . . . 8 80 B.3. draft-ietf-dnsop-let-localhost-be-localhost-00 . . . . . 9 81 B.4. draft-west-let-localhost-be-localhost-06 . . . . . . . . 9 82 B.5. draft-west-let-localhost-be-localhost-05 . . . . . . . . 9 83 B.6. draft-west-let-localhost-be-localhost-04 . . . . . . . . 9 84 B.7. draft-west-let-localhost-be-localhost-03 . . . . . . . . 9 85 B.8. draft-west-let-localhost-be-localhost-02 . . . . . . . . 9 86 B.9. draft-west-let-localhost-be-localhost-01 . . . . . . . . 10 87 B.10. draft-west-let-localhost-be-localhost-00 . . . . . . . . 10 88 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 10 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 The "127.0.0.0/8" IPv4 address block and "::1/128" IPv6 address block 94 are reserved as loopback addresses. Traffic to these blocks is 95 assured to remain within a single host, and can not legitimately 96 appear on any network anywhere. This turns out to be a very useful 97 property in a number of circumstances; useful enough to label 98 explicitly and interoperably as "localhost". [RFC1537] suggests that 99 this special-use top-level domain name has been implicitly mapped to 100 loopback addresses for decades at this point, and that [RFC6761]'s 101 assertion that developers may "assume that IPv4 and IPv6 address 102 queries for localhost names will always resolve to the respective IP 103 loopback address" is well-founded. 105 Unfortunately, the rest of that latter document's requirements 106 undercut the assumption it suggests. Client software is empowered to 107 send localhost names to DNS servers, and resolvers are empowered to 108 return unexpectedly non-loopback results. This divide between theory 109 and practice has a few impacts: 111 First, the lack of confidence that "localhost" actually resolves to 112 the loopback interface encourages application developers to hard-code 113 IP addresses like "127.0.0.1" in order to obtain certainty regarding 114 routing. This causes problems in the transition from IPv4 to IPv6 115 (see problem 8 in [I-D.ietf-sunset4-gapanalysis]). 117 Second, HTTP user agents sometimes distinguish certain contexts as 118 "secure"-enough to make certain features available. Given the 119 certainty that "127.0.0.1" cannot be maliciously manipulated or 120 monitored, [SECURE-CONTEXTS] treats it as such a context. Since 121 "localhost" might not actually map to the loopback address, that 122 document declines to give it the same treatment. This exclusion has 123 (rightly) surprised some developers, and exacerbates the risks of 124 hard-coded IP addresses by giving developers positive encouragement 125 to use an explicit loopback address rather than a localhost name. 127 This document updates [RFC6761]'s recommendations regarding 128 "localhost" by requiring that name resolution APIs and libraries 129 themselves return a loopback address when queried for localhost 130 names, bypassing lookup via recursive and authoritative DNS servers 131 entirely. 133 In addition, recursive and authoritative DNS servers are required to 134 return "NXDOMAIN" for such queries. This increases the likelihood 135 that non-conformant stub resolvers will not go undetected. Note that 136 this does not have the result that such resolvers will fail safe--it 137 just makes it more likely that they will be detected and fixed, since 138 they will fail in the presence of conforming name servers. 140 These changes are not sufficient to ensure that "localhost" can be 141 assumed to actually refer to an address on the local machine. This 142 document therefore further requires that applications that wish to 143 make that assumption handle the name "localhost" specially. 145 2. Terminology and notation 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 IPv4 loopback addresses are registered in Table 4 of Section 2.2.2 of 152 [RFC6890] as "127.0.0.0/8". 154 IPv6 loopback addresses are registered in Table 17 of Section 2.2.3 155 of [RFC6890] as "::1/128". 157 The domain "localhost.", and any names falling within ".localhost.", 158 are known as "localhost names". 160 3. The "localhost." Special-Use Domain Name 162 Localhost names are special insofar as these names do not exist in 163 the DNS, and querying the DNS for them is an error. With that 164 principle in mind, the considerations outlined in [RFC6761] can be 165 answered as follows: 167 1. Users are free to use localhost names as they would any other 168 domain names. Users may assume that IPv4 and IPv6 address 169 queries for localhost names will always resolve to the respective 170 IP loopback address. 172 2. Application software MAY recognize localhost names as special, or 173 MAY pass them to name resolution APIs as they would for other 174 domain names. 176 If application software wishes to make security decisions based 177 upon the assumption that localhost names resolve to loopback 178 addresses (e.g. if it wishes to ensure that a context meets the 179 requirements laid out in [SECURE-CONTEXTS]), then it MUST 180 directly translate localhost names to a loopback address, and 181 MUST NOT rely upon name resolution APIs to do so. 183 Application software MUST NOT use a searchlist to resolve a 184 localhost name. That is, even if DHCP's domain search option 185 [RFC3397] is used to specify a searchlist of "example.com" for a 186 given network, the name "localhost" will not be resolved as 187 "localhost.example.com." but as "localhost.", and 188 "subdomain.localhost" will not be resolved as 189 "subdomain.localhost.example.com." but as "subdomain.localhost.". 191 3. Name resolution APIs and libraries MUST recognize localhost names 192 as special, and MUST always return an appropriate IP loopback 193 address for IPv4 and IPv6 address queries and negative responses 194 for all other query types. Name resolution APIs MUST NOT send 195 queries for localhost names to their configured recursive DNS 196 server(s). 198 As for application software, name resolution APIs and libraries 199 MUST NOT use a searchlist to resolve a localhost name. 201 4. (Caching) recursive DNS servers MUST respond to queries for 202 localhost names with NXDOMAIN. 204 5. Authoritative DNS servers MUST respond to queries for localhost 205 names with NXDOMAIN. 207 6. DNS server operators SHOULD be aware that the effective RDATA for 208 localhost names is defined by protocol specification and cannot 209 be modified by local configuration. 211 7. DNS Registries/Registrars MUST NOT grant requests to register 212 localhost names in the normal way to any person or entity. 213 Localhost names are defined by protocol specification and fall 214 outside the set of names available for allocation by registries/ 215 registrars. Attempting to allocate a localhost name as if it 216 were a normal DNS domain name will not work as desired, for 217 reasons 2, 3, 4, and 5 above. 219 4. IANA Considerations 221 4.1. Domain Name Reservation Considerations 223 This document requests that IANA updates the "localhost." 224 registration in the registry of Special-Use Domain Names [RFC6761] to 225 reference this document rather than [RFC6761]. 227 Considerations for this reservation are detailed in Section 3. 229 4.2. DNSSEC 231 The ".localhost" TLD is already assigned to IANA, as per [RFC2606], 232 but does not have an entry in the root-zone. This means that the 233 root will return an NXDOMAIN response along with NSEC records 234 constituting a secure denial of existence if queried. That's 235 consistent with the general principle that localhost names do not 236 exist in the DNS, and the subsequent requirements to return NXDOMAIN 237 that are laid out in Section 3. 239 5. Security Considerations 241 5.1. Applications are encouraged to resolve localhost names themselves. 243 Applications that attempt to use the local resolver to query 244 "localhost" do not fail safely. If an attacker sets up a malicious 245 DNS server which returns a non-loopback address when queried for 246 localhost names, such applications will connect to that remote server 247 assuming it is local. This risk drives the requirement that 248 applications resolve localhost names themselves if they intend to 249 make security decisions based on the assumption that localhost names 250 resolve locally. 252 There may be cases in which the target runtime environment can be 253 safely assumed to do the right thing with localhost names. In this 254 case, the requirement that the application resolve localhost names on 255 its own may be safe to ignore, but only if all the requirements under 256 point 2 of Section 3 are known to be followed by the resolver that is 257 known to be present in the target environment. 259 5.2. 'localhost' labels in subdomains 261 Hosts like "localhost.example.com" and 262 "subdomain.localhost.example.com" contain a "localhost" label, but 263 are not themselves localhost names, as they do not fall within 264 "localhost.". Therefore, they are not directly affected by the 265 recommendations in this document. They have no resolution guarantees 266 one way or another, and should not be given special treatment, either 267 in DNS or in client software. 269 Note, however, that the admonition against searchlist usage could 270 affect their resolution in practice, as discussed in Section 3. For 271 example, even with a searchlist of "example.com" in place for a given 272 network, the name "localhost" will not be resolved as 273 "localhost.example.com." but as "localhost.", and 274 "subdomain.localhost" will not be resolved as 275 "subdomain.localhost.example.com." but as "subdomain.localhost.". 277 6. Implementation Considerations 279 6.1. Non-DNS usage of localhost names 281 Some application software differentiates between the hostname 282 "localhost" and the IP address "127.0.0.1". MySQL, for example, uses 283 a unix domain socket for the former, and a TCP connection to the 284 loopback address for the latter. The constraints on name resolution 285 APIs above do not preclude this kind of differentiation. 287 7. References 289 7.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, . 296 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 297 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 298 . 300 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 301 RFC 6761, DOI 10.17487/RFC6761, February 2013, 302 . 304 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 305 "Special-Purpose IP Address Registries", BCP 153, 306 RFC 6890, DOI 10.17487/RFC6890, April 2013, 307 . 309 7.2. Informative References 311 [I-D.ietf-sunset4-gapanalysis] 312 LIU, W., Xu, W., Zhou, C., Tsou, T., Perreault, S., Fan, 313 P., Gu, R., Xie, C., and Y. Cheng, "Gap Analysis for IPv4 314 Sunset", draft-ietf-sunset4-gapanalysis-09 (work in 315 progress), August 2017. 317 [RFC1537] Beertema, P., "Common DNS Data File Configuration Errors", 318 RFC 1537, DOI 10.17487/RFC1537, October 1993, 319 . 321 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 322 Protocol (DHCP) Domain Search Option", RFC 3397, 323 DOI 10.17487/RFC3397, November 2002, . 326 [SECURE-CONTEXTS] 327 West, M., "Secure Contexts", n.d., 328 . 330 Appendix A. Changes from RFC 6761 332 Section 3 updates the requirements in section 6.3 of [RFC6761] in a 333 few substantive ways: 335 1. Application software and name resolution APIs and libraries are 336 prohibited from using searchlists when resolving localhost names, 337 and encouraged to bypass resolution APIs and libraries altogether 338 if they intend to make security decisions based on the 339 "localhost" name. 341 2. Name resolution APIs and libraries are required to resolve 342 localhost names to loopback addresses, without sending the query 343 on to caching DNS servers. 345 3. Caching and authoritative DNS servers are required to respond to 346 resolution requests for localhost names with NXDOMAIN. 348 Appendix B. Changes in this draft 350 B.1. draft-ietf-dnsop-let-localhost-be-localhost-02 352 o Based on some feedback from Suzanne Woolf, this draft: 354 * Clarified the abstract 355 (https://github.com/mikewest/internetdrafts/ 356 commit/837b89f35e08e98b0e02df87032c4ccc19cd06eb ) 358 * Addressed nits in the "IANA considerations" section 359 (https://github.com/mikewest/internetdrafts/commit/ 360 d65d4fbaec6afbbae70496ffb98dfb60e8d3e2eb ) 362 * Reworded the "Non-TLD localhost" section 363 (https://github.com/mikewest/internetdrafts/ 364 commit/44b1d7d4cfcb65aab3c46ff1c436a75a2fb3403f ) 366 * Made the reference to [RFC2606] normative 367 (https://github.com/mikewest/internetdrafts/commit/ 368 cd94988a966b93d2239de03d54513031a5823c0a ) 370 B.2. draft-ietf-dnsop-let-localhost-be-localhost-01 372 o Explicit adoption of the principle Wes Hardaker proposed in 373 https://www.ietf.org/mail-archive/web/dnsop/current/msg21039.html 374 , and that Warren Kumari reiterated in https://www.ietf.org/mail- 375 archive/web/dnsop/current/msg21129.html : localhost names do not 376 exist in the DNS, there is no authoritative source for these 377 names, and querying resolvers for them is an error. 379 o Slight tightening of the admonition against search lists. 381 o Addressed "localhost" labels in non-localhost names. 383 B.3. draft-ietf-dnsop-let-localhost-be-localhost-00 385 o No change since draft-west-let-localhost-be-localhost-06, just 386 renaming the document after DNSOP adopted it. 388 B.4. draft-west-let-localhost-be-localhost-06 390 o Incorporated Ted Lemon's further feedback from 391 https://www.ietf.org/mail-archive/web/dnsop/current/msg20769.html 393 o Explicitly waffling on DNSSEC. 395 B.5. draft-west-let-localhost-be-localhost-05 397 o Updated obsolete references to RFC 5735 and 5156 in favor of 398 [RFC6890]. 400 o Clarify that non-caching recursive DNS servers are also addressed 401 by #4 in Section 3. 403 o Reformulating the abstract and introduction based on feedback like 404 Ted Lemon's in https://www.ietf.org/mail- 405 archive/web/dnsop/current/msg20757.html 407 o Added a request that an insecure delegation for "localhost." be 408 added to the root-zone. 410 B.6. draft-west-let-localhost-be-localhost-04 412 o Restructured the draft as a stand-alone document, rather than as 413 set of monkey-patches against [RFC6761]. 415 B.7. draft-west-let-localhost-be-localhost-03 417 o Explicitly referenced [I-D.ietf-sunset4-gapanalysis]. 419 o Added a prohibition against using searchlists to resolve localhost 420 names. 422 o Noted that MySQL has special behavior differentiating the 423 connection mechanism used for "localhost" and "127.0.0.1". 425 B.8. draft-west-let-localhost-be-localhost-02 427 o Pulled in definitions for IPv4 and IPv6 loopback addresses. 429 B.9. draft-west-let-localhost-be-localhost-01 431 o Added a requirement that caching DNS servers MUST generate an 432 immediate negative response. 434 B.10. draft-west-let-localhost-be-localhost-00 436 First draft. 438 Appendix C. Acknowledgements 440 Ryan Sleevi and Emily Stark informed me about the strange state of 441 localhost name resolution. Erik Nygren poked me to take another look 442 at the set of decisions we made in [SECURE-CONTEXTS] around 443 "localhost."; this document is the result. They, along with Warren 444 Kumari, Ted Lemon, John Levine, Mark Andrews, and many other members 445 of DNSOP offered substantive feedback that markedly improved the 446 quality of this document. 448 Author's Address 450 Mike West 451 Google, Inc 453 Email: mkwst@google.com 454 URI: https://mikewest.org/