idnits 2.17.1 draft-ietf-dnsop-let-localhost-be-localhost-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 (October 24, 2017) is 2347 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 (==), 2 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) October 24, 2017 5 Intended status: Standards Track 6 Expires: April 27, 2018 8 Let 'localhost' be localhost. 9 draft-ietf-dnsop-let-localhost-be-localhost-01 11 Abstract 13 This document updates RFC6761 with the goal of ensuring that 14 "localhost" can be safely relied upon as a name for the local host's 15 loopback interface. To that end, stub resolvers are required to 16 resolve localhost names to loopback addresses. Recursive DNS servers 17 are required to return "NXDOMAIN" when queried for localhost names, 18 making non-conformant stub resolvers more likely to fail and produce 19 problem reports that result in updates. 21 Together, these requirements would allow applications and 22 specifications to join regular users in drawing the common-sense 23 conclusions that "localhost" means "localhost", and doesn't resolve 24 to somewhere else on the network. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 27, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology and notation . . . . . . . . . . . . . . . . . . 4 62 3. The "localhost." Special-Use Domain Name . . . . . . . . . . 4 63 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 4.1. Domain Name Reservation Considerations . . . . . . . . . 5 65 4.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 5.1. Applications are encouraged to resolve localhost names 68 themselves. . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.2. Non-TLD 'localhost' labels . . . . . . . . . . . . . . . 6 70 6. Implementation Considerations . . . . . . . . . . . . . . . . 6 71 6.1. Non-DNS usage of localhost names . . . . . . . . . . . . 6 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 74 7.2. Informative References . . . . . . . . . . . . . . . . . 7 75 Appendix A. Changes from RFC 6761 . . . . . . . . . . . . . . . 7 76 Appendix B. Changes in this draft . . . . . . . . . . . . . . . 8 77 B.1. draft-ietf-dnsop-let-localhost-be-localhost-01 . . . . . 8 78 B.2. draft-ietf-dnsop-let-localhost-be-localhost-01 . . . . . 8 79 B.3. draft-west-let-localhost-be-localhost-06 . . . . . . . . 8 80 B.4. draft-west-let-localhost-be-localhost-05 . . . . . . . . 8 81 B.5. draft-west-let-localhost-be-localhost-04 . . . . . . . . 9 82 B.6. draft-west-let-localhost-be-localhost-03 . . . . . . . . 9 83 B.7. draft-west-let-localhost-be-localhost-02 . . . . . . . . 9 84 B.8. draft-west-let-localhost-be-localhost-01 . . . . . . . . 9 85 B.9. draft-west-let-localhost-be-localhost-00 . . . . . . . . 9 86 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 9 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 89 1. Introduction 91 The "127.0.0.0/8" IPv4 address block and "::1/128" IPv6 address block 92 are reserved as loopback addresses. Traffic to this block is assured 93 to remain within a single host, and can not legitimately appear on 94 any network anywhere. This turns out to be a very useful property in 95 a number of circumstances; useful enough to label explicitly and 96 interoperably as "localhost". [RFC1537] suggests that this special- 97 use top-level domain name has been implicitly mapped to loopback 98 addresses for decades at this point, and that [RFC6761]'s assertion 99 that developers may "assume that IPv4 and IPv6 address queries for 100 localhost names will always resolve to the respective IP loopback 101 address" is well-founded. 103 Unfortunately, the rest of that latter document's requirements 104 undercut the assumption it suggests. Client software is empowered to 105 send localhost names to DNS servers, and resolvers are empowered to 106 return unexpectedly non-loopback results. This divide between theory 107 and practice has a few impacts: 109 First, the lack of confidence that "localhost" actually resolves to 110 the loopback interface encourages application developers to hard-code 111 IP addresses like "127.0.0.1" in order to obtain certainty regarding 112 routing. This causes problems in the transition from IPv4 to IPv6 113 (see problem 8 in [I-D.ietf-sunset4-gapanalysis]). 115 Second, HTTP user agents sometimes distinguish certain contexts as 116 "secure"-enough to make certain features available. Given the 117 certainty that "127.0.0.1" cannot be maliciously manipulated or 118 monitored, [SECURE-CONTEXTS] treats it as such a context. Since 119 "localhost" might not actually map to the loopback address, that 120 document declines to give it the same treatment. This exclusion has 121 (rightly) surprised some developers, and exacerbates the risks of 122 hard-coded IP addresses by giving developers positive encouragement 123 to use an explicit loopback address rather than a localhost name. 125 This document updates [RFC6761]'s recommendations regarding 126 "localhost" by requiring that name resolution APIs and libraries 127 themselves return a loopback address when queried for localhost 128 names, bypassing lookup via recursive and authoritative DNS servers 129 entirely. 131 In addition, recursive and authoritative DNS servers are required to 132 return "NXDOMAIN" for such queries. This increases the likelihood 133 that non-conformant stub resolvers will not go undetected. Note that 134 this does not have the result that such resolvers will fail safe--it 135 just makes it more likely that they will be detected and fixed, since 136 they will fail in the presence of conforming name servers. 138 These changes are not sufficient to ensure that "localhost" can be 139 assumed to actually refer to an address on the local machine. This 140 document therefore further requires that applications that wish to 141 make that assumption handle the name "localhost" specially. 143 2. Terminology and notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 IPv4 loopback addresses are registered in Table 4 of Section 2.2.2 of 150 [RFC6890] as "127.0.0.0/8". 152 IPv6 loopback addresses are registered in Table 17 of Section 2.2.3 153 of [RFC6890] as "::1/128". 155 The domain "localhost.", and any names falling within ".localhost.", 156 are known as "localhost names". 158 3. The "localhost." Special-Use Domain Name 160 Localhost names are special insofar as these names do not exist in 161 the DNS, and querying the DNS for them is an error. With that 162 principle in mind, the considerations outlined in [RFC6761] can be 163 answered as follows: 165 1. Users are free to use localhost names as they would any other 166 domain names. Users may assume that IPv4 and IPv6 address 167 queries for localhost names will always resolve to the respective 168 IP loopback address. 170 2. Application software MAY recognize localhost names as special, or 171 MAY pass them to name resolution APIs as they would for other 172 domain names. 174 If application software wishes to make security decisions based 175 upon the assumption that localhost names resolve to loopback 176 addresses (e.g. if it wishes to ensure that a context meets the 177 requirements laid out in [SECURE-CONTEXTS]), then it MUST 178 directly translate localhost names to a loopback address, and 179 MUST NOT rely upon name resolution APIs to do so. 181 Application software MUST NOT use a searchlist to resolve a 182 localhost name. That is, even if DHCP's domain search option 183 [RFC3397] is used to specify a searchlist of "example.com" for a 184 given network, the name "localhost" will not be resolved as 185 "localhost.example.com." but as "localhost.", and 186 "subdomain.localhost" will not be resolved as 187 "subdomain.localhost.example.com." but as "subdomain.localhost.". 189 3. Name resolution APIs and libraries MUST recognize localhost names 190 as special, and MUST always return an appropriate IP loopback 191 address for IPv4 and IPv6 address queries and negative responses 192 for all other query types. Name resolution APIs MUST NOT send 193 queries for localhost names to their configured recursive DNS 194 server(s). 196 As for application software, name resolution APIs and libraries 197 MUST NOT use a searchlist to resolve a localhost name. 199 4. (Caching) recursive DNS servers MUST respond to queries for 200 localhost names with NXDOMAIN. 202 5. Authoritative DNS servers MUST respond to queries for localhost 203 names with NXDOMAIN. 205 6. DNS server operators SHOULD be aware that the effective RDATA for 206 localhost names is defined by protocol specification and cannot 207 be modified by local configuration. 209 7. DNS Registries/Registrars MUST NOT grant requests to register 210 localhost names in the normal way to any person or entity. 211 Localhost names are defined by protocol specification and fall 212 outside the set of names available for allocation by registries/ 213 registrars. Attempting to allocate a localhost name as if it 214 were a normal DNS domain name will not work as desired, for 215 reasons 2, 3, 4, and 5 above. 217 4. IANA Considerations 219 IANA is requested to update the "localhost." registration in the 220 registry of Special-Use Domain Names [RFC6761] to reference the 221 domain name reservations considerations section of this document. 223 4.1. Domain Name Reservation Considerations 225 This document requests that IANA update the "localhost." registration 226 in the registry of Special-Use Domain Names [RFC6761] to reference 227 the domain name reservation considerations defined 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 DNSSEC root-zone. This means that 233 the 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. Non-TLD 'localhost' labels 261 Hosts like "localhost.example.com" contain a "localhost" label, but 262 are not affected one way or another by the recommendations in this 263 document. They are not "localhost names", have no resolution 264 guarantees, and should not be given special treatment, either in DNS 265 or in client software. 267 6. Implementation Considerations 269 6.1. Non-DNS usage of localhost names 271 Some application software differentiates between the hostname 272 "localhost" and the IP address "127.0.0.1". MySQL, for example, uses 273 a unix domain socket for the former, and a TCP connection to the 274 loopback address for the latter. The constraints on name resolution 275 APIs above do not preclude this kind of differentiation. 277 7. References 279 7.1. Normative References 281 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 282 Requirement Levels", BCP 14, RFC 2119, 283 DOI 10.17487/RFC2119, March 1997, . 286 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 287 RFC 6761, DOI 10.17487/RFC6761, February 2013, 288 . 290 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 291 "Special-Purpose IP Address Registries", BCP 153, 292 RFC 6890, DOI 10.17487/RFC6890, April 2013, 293 . 295 7.2. Informative References 297 [I-D.ietf-sunset4-gapanalysis] 298 LIU, W., Xu, W., Zhou, C., Tsou, T., Perreault, S., Fan, 299 P., Gu, R., Xie, C., and Y. Cheng, "Gap Analysis for IPv4 300 Sunset", draft-ietf-sunset4-gapanalysis-09 (work in 301 progress), August 2017. 303 [RFC1537] Beertema, P., "Common DNS Data File Configuration Errors", 304 RFC 1537, DOI 10.17487/RFC1537, October 1993, 305 . 307 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 308 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 309 . 311 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 312 Protocol (DHCP) Domain Search Option", RFC 3397, 313 DOI 10.17487/RFC3397, November 2002, . 316 [SECURE-CONTEXTS] 317 West, M., "Secure Contexts", n.d., 318 . 320 Appendix A. Changes from RFC 6761 322 Section 3 updates the requirements in section 6.3 of [RFC6761] in a 323 few substantive ways: 325 1. Application software and name resolution APIs and libraries are 326 prohibited from using searchlists when resolving localhost names, 327 and encouraged to bypass resolution APIs and libraries altogether 328 if they intend to make security decisions based on the 329 "localhost" name. 331 2. Name resolution APIs and libraries are required to resolve 332 localhost names to loopback addresses, without sending the query 333 on to caching DNS servers. 335 3. Caching and authoritative DNS servers are required to respond to 336 resolution requests for localhost names with NXDOMAIN. 338 Appendix B. Changes in this draft 340 B.1. draft-ietf-dnsop-let-localhost-be-localhost-01 342 o Explicit adoption of the principle Wes Hardaker proposed in 343 https://www.ietf.org/mail-archive/web/dnsop/current/msg21039.html 344 , and that Warren Kumari reiterated in https://www.ietf.org/mail- 345 archive/web/dnsop/current/msg21129.html : localhost names do not 346 exist in the DNS, there is no authoritative source for these 347 names, and querying resolvers for them is an error. 349 o Slight tightening of the admonition against search lists. 351 o Addressed "localhost" labels in non-localhost names. 353 B.2. draft-ietf-dnsop-let-localhost-be-localhost-00 355 o No change since draft-west-let-localhost-be-localhost-06, just 356 renaming the document after DNSOP adopted it. 358 B.3. draft-west-let-localhost-be-localhost-06 360 o Incorporated Ted Lemon's further feedback from 361 https://www.ietf.org/mail-archive/web/dnsop/current/msg20769.html 363 o Explicitly waffling on DNSSEC. 365 B.4. draft-west-let-localhost-be-localhost-05 367 o Updated obsolete references to RFC 5735 and 5156 in favor of 368 [RFC6890]. 370 o Clarify that non-caching recursive DNS servers are also addressed 371 by #4 in Section 3. 373 o Reformulating the abstract and introduction based on feedback like 374 Ted Lemon's in https://www.ietf.org/mail- 375 archive/web/dnsop/current/msg20757.html 377 o Added a request that an insecure delegation for "localhost." be 378 added to the root-zone. 380 B.5. draft-west-let-localhost-be-localhost-04 382 o Restructured the draft as a stand-alone document, rather than as 383 set of monkey-patches against [RFC6761]. 385 B.6. draft-west-let-localhost-be-localhost-03 387 o Explicitly referenced [I-D.ietf-sunset4-gapanalysis]. 389 o Added a prohibition against using searchlists to resolve localhost 390 names. 392 o Noted that MySQL has special behavior differentiating the 393 connection mechanism used for "localhost" and "127.0.0.1". 395 B.7. draft-west-let-localhost-be-localhost-02 397 o Pulled in definitions for IPv4 and IPv6 loopback addresses. 399 B.8. draft-west-let-localhost-be-localhost-01 401 o Added a requirement that caching DNS servers MUST generate an 402 immediate negative response. 404 B.9. draft-west-let-localhost-be-localhost-00 406 First draft. 408 Appendix C. Acknowledgements 410 Ryan Sleevi and Emily Stark informed me about the strange state of 411 localhost name resolution. Erik Nygren poked me to take another look 412 at the set of decisions we made in [SECURE-CONTEXTS] around 413 "localhost."; this document is the result. They, along with Warren 414 Kumari, Ted Lemon, John Levine, Mark Andrews, and many other members 415 of DNSOP offered substantive feedback that markedly improved the 416 quality of this document. 418 Author's Address 420 Mike West 421 Google, Inc 423 Email: mkwst@google.com 424 URI: https://mikewest.org/