idnits 2.17.1 draft-west-let-localhost-be-localhost-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2016) is 2688 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 normative reference: RFC 5156 (Obsoleted by RFC 6890) ** Obsolete normative reference: RFC 5735 (Obsoleted by RFC 6890) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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) November 17, 2016 5 Intended status: Standards Track 6 Expires: May 21, 2017 8 Let 'localhost' be localhost. 9 draft-west-let-localhost-be-localhost-03 11 Abstract 13 This document updates RFC6761 by requiring that the domain 14 "localhost." and any names falling within ".localhost." resolve to 15 loopback addresses. This would allow other specifications to join 16 regular users in drawing the common-sense conclusions that 17 "localhost" means "localhost", and doesn't resolve to somewhere else 18 on the network. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 21, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology and notation . . . . . . . . . . . . . . . . . . 3 56 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Implementation Considerations . . . . . . . . . . . . . . . . 4 58 4.1. Non-DNS usage of localhost names . . . . . . . . . . . . 4 59 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 61 5.2. Informative References . . . . . . . . . . . . . . . . . 4 62 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 Section 6.3 of [RFC6761] invites developers to "assume that IPv4 and 68 IPv6 address queries for localhost names will always resolve to the 69 respective IP loopback address". That suggestion, unfortunately, 70 doesn't match reality. Client software is empowered to send 71 localhost names to DNS resolvers, and resolvers are empowered to 72 return unexpected results in various cases. This has several 73 impacts. 75 One of the clearest is that the [SECURE-CONTEXTS] specification 76 declines to treat "localhost" as "secure enough", as it might not 77 actually be the "localhost" that developers are expecting. This 78 exclusion has (rightly) surprised some developers. 80 Following on from that, the lack of confidence that "localhost" 81 actually resolves to the loopback interface may encourage application 82 developers to hard-code IP addresses, which causes problems in the 83 transition from IPv4 to IPv6 (see problem 8 in 84 [draft-ietf-sunset4-gapanalysis]). [SECURE-CONTEXTS] excluding 85 "localhost" would exacerbate this risk, giving developers positive 86 encouragement to use the loopback address rather than a localhost 87 name. 89 This document suggests that we should resolve the confusion by 90 requiring that DNS resolution work the way that users expect: 91 "localhost" is the loopback interface on the local host. Resolver 92 APIs will resolve "localhost." and any names falling within 93 ".localhost." to loopback addresses [RFC5735] 95 2. Terminology and notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 IPv4 loopback addresses are defined in Section 2.1 of [RFC5735] as 102 "127.0.0.0/8". 104 IPv6 loopback addresses are defined in Section 3 of [RFC5156] as 105 "::1/128". 107 3. Recommendations 109 This document updates Section 6.3 of [RFC6761] in the following ways: 111 1. Item #3 is changed to read as follows: 113 Name resolution APIs and libraries MUST recognize localhost names 114 as special, and MUST always return an IP loopback address for 115 address queries and negative responses for all other query types. 116 Name resolution APIs MUST NOT send queries for localhost names to 117 their configured caching DNS server(s). 119 Note that any loopback address is acceptable: 120 "subdomain.localhost" could resolve to "127.0.0.1", "127.0.0.2", 121 "127.127.127.127", etc. 123 2. Item #4 is changed to read as follows: 125 Caching DNS servers MUST recognize localhost names as special, 126 and MUST NOT attempt to look up NS records for them, or otherwise 127 query authoritative DNS servers in an attempt to resolve 128 localhost names. Instead, caching DNS servers MUST generate an 129 immediate negative response. 131 3. Item #5 is changed to replace "SHOULD" with "MUST": 133 Authoritative DNS servers MUST recognize localhost names as 134 special and handle them as described above for caching DNS 135 servers. 137 4. Item #7 is changed to remove "probably" from the last sentence: 139 DNS Registries/Registrars MUST NOT grant requests to register 140 localhost names in the normal way to any person or entity. 141 Localhost names are defined by protocol specification and fall 142 outside the set of names available for allocation by registries/ 143 registrars. Attempting to allocate a localhost name as if it 144 were a normal DNS domain name will not work as desired, for 145 reasons 2, 3, 4, and 5 above. 147 5. Item #8 is added to the list, reading as follows: 149 Name resolution APIs, libraries, and application software MUST 150 NOT use a searchlist to resolve the name "localhost". That is, 151 even if DHCP's domain search option [RFC3397] is used to specify 152 a searchlist of "example.com" for a given network, the name 153 "localhost" will not be resolved as "localhost.example.com". 155 4. Implementation Considerations 157 4.1. Non-DNS usage of localhost names 159 Some application software like MySQL differentiate between the 160 hostname "localhost" and the IP address "127.0.0.1", using a unix 161 domain socket for the former, and a TCP connection to the loopback 162 address for the latter. The constraints on name resolution APIs 163 above do not preclude this kind of differentiation. 165 5. References 167 5.1. Normative References 169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 170 Requirement Levels", BCP 14, RFC 2119, 171 DOI 10.17487/RFC2119, March 1997, 172 . 174 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 175 DOI 10.17487/RFC5156, April 2008, 176 . 178 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 179 RFC 5735, DOI 10.17487/RFC5735, January 2010, 180 . 182 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 183 RFC 6761, DOI 10.17487/RFC6761, February 2013, 184 . 186 5.2. Informative References 188 [draft-ietf-sunset4-gapanalysis] 189 Perreault, S., Tsou, T., Zhou, C., and P. Fan, "Gap 190 Analysis for IPv4 Sunset", n.d., 191 . 194 [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration 195 Protocol (DHCP) Domain Search Option", RFC 3397, 196 DOI 10.17487/RFC3397, November 2002, 197 . 199 [SECURE-CONTEXTS] 200 West, M., "Secure Contexts", n.d., 201 . 203 Appendix A. Acknowledgements 205 Ryan Sleevi and Emily Stark informed me about the strange state of 206 localhost name resolution. Erik Nygren poked me to take another look 207 at the set of decisions we made in [SECURE-CONTEXTS] around 208 "localhost."; this document is the result, and his feedback has been 209 very helpful. 211 Author's Address 213 Mike West 214 Google, Inc 216 Email: mkwst@google.com 217 URI: https://mikewest.org/