idnits 2.17.1 draft-west-let-localhost-be-localhost-06.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 (August 31, 2017) is 2401 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) August 31, 2017 5 Intended status: Standards Track 6 Expires: March 4, 2018 8 Let 'localhost' be localhost. 9 draft-west-let-localhost-be-localhost-06 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 March 4, 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 4.2.1. Option 1: Explicit delegation . . . . . . . . . . . . 5 67 4.2.2. Option 2: Implicit failure . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 5.1. Applications are encouraged to resolve localhost names 70 themselves. . . . . . . . . . . . . . . . . . . . . . . . 6 71 6. Implementation Considerations . . . . . . . . . . . . . . . . 6 72 6.1. Non-DNS usage of localhost names . . . . . . . . . . . . 6 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 7.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Appendix A. Changes from RFC 6761 . . . . . . . . . . . . . . . 8 77 Appendix B. Changes in this draft . . . . . . . . . . . . . . . 8 78 B.1. draft-west-let-localhost-be-localhost-06 . . . . . . . . 8 79 B.2. draft-west-let-localhost-be-localhost-05 . . . . . . . . 8 80 B.3. draft-west-let-localhost-be-localhost-04 . . . . . . . . 8 81 B.4. draft-west-let-localhost-be-localhost-03 . . . . . . . . 9 82 B.5. draft-west-let-localhost-be-localhost-02 . . . . . . . . 9 83 B.6. draft-west-let-localhost-be-localhost-01 . . . . . . . . 9 84 B.7. draft-west-let-localhost-be-localhost-00 . . . . . . . . 9 85 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 9 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 The "127.0.0.0/8" IPv4 address block and "::1/128" IPv6 address block 91 are reserved as loopback addresses. Traffic to this block is assured 92 to remain within a single host, and can not legitimately appear on 93 any network anywhere. This turns out to be a very useful property in 94 a number of circumstances; useful enough to label explicitly and 95 interoperably as "localhost". [RFC1537] suggests that this special- 96 use top-level domain name has been implicitly mapped to loopback 97 addresses for decades at this point, and that [RFC6761]'s assertion 98 that developers may "assume that IPv4 and IPv6 address queries for 99 localhost names will always resolve to the respective IP loopback 100 address" is well-founded. 102 Unfortunately, the rest of that latter document's requirements 103 undercut the assumption it suggests. Client software is empowered to 104 send localhost names to DNS servers, and resolvers are empowered to 105 return unexpectedly non-loopback results. This divide between theory 106 and practice has a few impacts: 108 First, the lack of confidence that "localhost" actually resolves to 109 the loopback interface encourages application developers to hard-code 110 IP addresses like "127.0.0.1" in order to obtain certainty regarding 111 routing. This causes problems in the transition from IPv4 to IPv6 112 (see problem 8 in [I-D.ietf-sunset4-gapanalysis]). 114 Second, HTTP user agents sometimes distinguish certain contexts as 115 "secure"-enough to make certain features available. Given the 116 certainty that "127.0.0.1" cannot be maliciously manipulated or 117 monitored, [SECURE-CONTEXTS] treats it as such a context. Since 118 "localhost" might not actually map to the loopback address, that 119 document declines to give it the same treatment. This exclusion has 120 (rightly) surprised some developers, and exacerbates the risks of 121 hard-coded IP addresses by giving developers positive encouragement 122 to use an explicit loopback address rather than a localhost name. 124 This document updates [RFC6761]'s recommendations regarding 125 "localhost" by requiring that name resolution APIs and libraries 126 themselves return a loopback address when queried for localhost 127 names, bypassing lookup via recursive and authoritative DNS servers 128 entirely. 130 In addition, recursive and authoritative DNS servers are required to 131 return "NXDOMAIN" for such queries. This increases the likelihood 132 that non-conformant stub resolvers will not go undetected. Note that 133 this does not have the result that such resolvers will fail safe--it 134 just makes it more likely that they will be detected and fixed, since 135 they will fail in the presence of conforming name servers. 137 These changes are not sufficient to ensure that "localhost" can be 138 assumed to actually refer to an address on the local machine. This 139 document therefore further requires that applications that wish to 140 make that assumption handle the name "localhost" specially. 142 2. Terminology and notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 IPv4 loopback addresses are registered in Table 4 of Section 2.2.2 of 149 [RFC6890] as "127.0.0.0/8". 151 IPv6 loopback addresses are registered in Table 17 of Section 2.2.3 152 of [RFC6890] as "::1/128". 154 The domain "localhost.", and any names falling within ".localhost.", 155 are known as "localhost names". 157 3. The "localhost." Special-Use Domain Name 159 Localhost names are special in the following ways: 161 1. Users are free to use localhost names as they would any other 162 domain names. Users may assume that IPv4 and IPv6 address 163 queries for localhost names will always resolve to the respective 164 IP loopback address. 166 2. Application software MAY recognize localhost names as special, or 167 MAY pass them to name resolution APIs as they would for other 168 domain names. 170 If application software wishes to make security decisions based 171 upon the assumption that localhost names resolve to loopback 172 addresses (e.g. if it wishes to ensure that a context meets the 173 requirements laid out in [SECURE-CONTEXTS]), then it MUST 174 directly translate localhost names to a loopback address, and 175 MUST NOT rely upon name resolution APIs to do so. 177 Application software MUST NOT use a searchlist to resolve a 178 localhost name. That is, even if DHCP's domain search option 179 [RFC3397] is used to specify a searchlist of "example.com" for a 180 given network, the name "localhost" will not be resolved as 181 "localhost.example.com", and "subdomain.localhost" will not be 182 resolved as "subdomain.localhost.example.com". 184 3. Name resolution APIs and libraries MUST recognize localhost names 185 as special, and MUST always return an appropriate IP loopback 186 address for IPv4 and IPv6 address queries and negative responses 187 for all other query types. Name resolution APIs MUST NOT send 188 queries for localhost names to their configured recursive DNS 189 server(s). 191 As for application software, name resolution APIs and libraries 192 MUST NOT use a searchlist to resolve a localhost name. 194 4. (Caching) recursive DNS servers MUST respond to queries for 195 localhost names with NXDOMAIN. 197 5. Authoritative DNS servers MUST respond to queries for localhost 198 names with NXDOMAIN. 200 6. DNS server operators SHOULD be aware that the effective RDATA for 201 localhost names is defined by protocol specification and cannot 202 be modified by local configuration. 204 7. DNS Registries/Registrars MUST NOT grant requests to register 205 localhost names in the normal way to any person or entity. 206 Localhost names are defined by protocol specification and fall 207 outside the set of names available for allocation by registries/ 208 registrars. Attempting to allocate a localhost name as if it 209 were a normal DNS domain name will not work as desired, for 210 reasons 2, 3, 4, and 5 above. 212 4. IANA Considerations 214 IANA is requested to update the "localhost." registration in the 215 registry of Special-Use Domain Names [RFC6761] to reference the 216 domain name reservations considerations section of this document. 218 4.1. Domain Name Reservation Considerations 220 This document requests that IANA update the "localhost." registration 221 in the registry of Special-Use Domain Names [RFC6761] to reference 222 the domain name reservation considerations defined in Section 3. 224 4.2. DNSSEC 226 (Ed note: The following options seem reasonable. I personally prefer 227 the latter, but could be convinced that the former is reasonable if 228 that's the way the working group's concensus trends.) 230 4.2.1. Option 1: Explicit delegation 232 The ".localhost" TLD is already assigned to IANA, as per [RFC2606]. 233 This document requests that a DNSSEC insecure delegation (that is, a 234 delegation with no DS records) be inserted into the root-zone, 235 delegated to "blackhole-[12].iana.org". 237 This request for an insecure delegation relies on the rationale 238 spelled out in section 4 of [I-D.wkumari-dnsop-internal], which 239 discusses the DNSSEC considerations for the ".internal" TLD. The 240 same considerations apply to this document's discussion of localhost 241 names. 243 4.2.2. Option 2: Implicit failure 245 The ".localhost" TLD is already assigned to IANA, as per [RFC2606], 246 but does not have an entry in the DNSSEC root-zone. This means that 247 the root will return an NXDOMAIN response along with NSEC records 248 constituting a secure denial of existence if queried. That's 249 consistent with the requirements to return NXDOMAIN that are laid out 250 in Section 3. 252 5. Security Considerations 254 5.1. Applications are encouraged to resolve localhost names themselves. 256 Applications that attempt to use the local resolver to query 257 "localhost" do not fail safely. If an attacker sets up a malicious 258 DNS server which returns a non-loopback address when queried for 259 localhost names, such applications will connect to that remote server 260 assuming it is local. This risk drives the requirement that 261 applications resolve localhost names themselves if they intend to 262 make security decisions based on the assumption that localhost names 263 resolve locally. 265 There may be cases in which the target runtime environment can be 266 safely assumed to do the right thing with localhost names. In this 267 case, the requirement that the application resolve localhost names on 268 its own may be safe to ignore, but only if all the requirements under 269 point 2 of Section 3 are known to be followed by the resolver that is 270 known to be present in the target environment. 272 6. Implementation Considerations 274 6.1. Non-DNS usage of localhost names 276 Some application software differentiates between the hostname 277 "localhost" and the IP address "127.0.0.1". MySQL, for example, uses 278 a unix domain socket for the former, and a TCP connection to the 279 loopback address for the latter. The constraints on name resolution 280 APIs above do not preclude this kind of differentiation. 282 7. References 283 7.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, . 290 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 291 RFC 6761, DOI 10.17487/RFC6761, February 2013, 292 . 294 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 295 "Special-Purpose IP Address Registries", BCP 153, 296 RFC 6890, DOI 10.17487/RFC6890, April 2013, 297 . 299 7.2. Informative References 301 [I-D.ietf-sunset4-gapanalysis] 302 LIU, W., Xu, W., Zhou, C., Tsou, T., Perreault, S., Fan, 303 P., Gu, R., Xie, C., and Y. Cheng, "Gap Analysis for IPv4 304 Sunset", draft-ietf-sunset4-gapanalysis-09 (work in 305 progress), August 2017. 307 [I-D.wkumari-dnsop-internal] 308 Kumari, W., "The .internal TLD.", draft-wkumari-dnsop- 309 internal-00 (work in progress), July 2017. 311 [RFC1537] Beertema, P., "Common DNS Data File Configuration Errors", 312 RFC 1537, DOI 10.17487/RFC1537, October 1993, 313 . 315 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 316 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 317 . 319 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 320 Protocol (DHCP) Domain Search Option", RFC 3397, 321 DOI 10.17487/RFC3397, November 2002, . 324 [SECURE-CONTEXTS] 325 West, M., "Secure Contexts", n.d., 326 . 328 Appendix A. Changes from RFC 6761 330 Section 3 updates the requirements in section 6.3 of [RFC6761] in a 331 few substantive ways: 333 1. Application software and name resolution APIs and libraries are 334 prohibited from using searchlists when resolving localhost names, 335 and encouraged to bypass resolution APIs and libraries altogether 336 if they intend to make security decisions based on the 337 "localhost" name. 339 2. Name resolution APIs and libraries are required to resolve 340 localhost names to loopback addresses, without sending the query 341 on to caching DNS servers. 343 3. Caching and authoritative DNS servers are required to respond to 344 resolution requests for localhost names with NXDOMAIN. 346 Appendix B. Changes in this draft 348 B.1. draft-west-let-localhost-be-localhost-06 350 o Incorporated Ted Lemon's further feedback from 351 https://www.ietf.org/mail-archive/web/dnsop/current/msg20769.html 353 o Explicitly waffling on DNSSEC. 355 B.2. draft-west-let-localhost-be-localhost-05 357 o Updated obsolete references to RFC 5735 and 5156 in favor of 358 [RFC6890]. 360 o Clarify that non-caching recursive DNS servers are also addressed 361 by #4 in Section 3. 363 o Reformulating the abstract and introduction based on feedback like 364 Ted Lemon's in https://www.ietf.org/mail- 365 archive/web/dnsop/current/msg20757.html 367 o Added a request that an insecure delegation for "localhost." be 368 added to the root-zone. 370 B.3. draft-west-let-localhost-be-localhost-04 372 o Restructured the draft as a stand-alone document, rather than as 373 set of monkey-patches against [RFC6761]. 375 B.4. draft-west-let-localhost-be-localhost-03 377 o Explicitly referenced [I-D.ietf-sunset4-gapanalysis]. 379 o Added a prohibition against using searchlists to resolve localhost 380 names. 382 o Noted that MySQL has special behavior differentiating the 383 connection mechanism used for "localhost" and "127.0.0.1". 385 B.5. draft-west-let-localhost-be-localhost-02 387 o Pulled in definitions for IPv4 and IPv6 loopback addresses. 389 B.6. draft-west-let-localhost-be-localhost-01 391 o Added a requirement that caching DNS servers MUST generate an 392 immediate negative response. 394 B.7. draft-west-let-localhost-be-localhost-00 396 First draft. 398 Appendix C. Acknowledgements 400 Ryan Sleevi and Emily Stark informed me about the strange state of 401 localhost name resolution. Erik Nygren poked me to take another look 402 at the set of decisions we made in [SECURE-CONTEXTS] around 403 "localhost."; this document is the result. They, along with Warren 404 Kumari, Ted Lemon, John Levine, Mark Andrews, and many other members 405 of DNSOP offered substantive feedback that markedly improved the 406 quality of this document. 408 Author's Address 410 Mike West 411 Google, Inc 413 Email: mkwst@google.com 414 URI: https://mikewest.org/