idnits 2.17.1 draft-cheshire-homenet-dot-home-00.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, 2014) is 3444 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Cheshire 3 Internet-Draft Apple Inc. 4 Intended status: Standards Track October 24, 2014 5 Expires: April 27, 2015 7 Special Use Top Level Domain "home" 8 draft-cheshire-homenet-dot-home-00 10 Abstract 12 This document specifies usage of the top-level domain "home", for 13 names that are meaningful and resolvable within some scope smaller 14 than the entire global Internet, but larger than the single link 15 supported by Multicast DNS. 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 April 27, 2015. 34 Copyright Notice 36 Copyright (c) 2014 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 Globally unique domain names are available to individuals and 52 organizations for a modest annual fee. However, there are situations 53 where a globally unique domain name is not available, or has not yet 54 been configured, and in these situations it is still desirable to be 55 able to use DNS host names [RFC1034] [RFC1035], DNS-Based Service 56 Discovery [RFC6763], and other DNS facilites. 58 In the absence of available globally unique domain names, Multicast 59 DNS [RFC6762] makes it possible to use DNS facilities with names that 60 are unique within the local link, using the "local" top-level domain. 62 This document specifies usage of a similar top-level domain, "home", 63 for names that have scope larger than a single link, but smaller than 64 the entire global Internet. 66 Author's Note [to be removed when document is published]: The purpose 67 of this draft is not to propose some novel new usage for ".home" 68 names. The purpose is to learn more about the current widespread use 69 of ".home" names, and to document and formalize that usage. 71 Evidence [ICANN1][ICANN2] indicates that ".home" queries frequently 72 leak out and reach the root name servers. We speculate that this is 73 because of widespread usage of ".home" names in home networks, for 74 example to name a printer "printer.home." When a user takes their 75 laptop to a public Wi-Fi hotspot, attempts by that laptop to contact 76 that printer result in fruitless ".home" queries to the root name 77 servers. It would be beneficial for operators of public Wi-Fi 78 hotspots to recognize and answer such queries locally, thereby 79 reducing unnecessary load on the root name servers, and this document 80 would give those operators the authority to do that. Readers who are 81 aware of other usages of ".home" names, that are not compatible with 82 the rules proposed here, are encouraged to contact the authors with 83 information to help revise and improve this draft. 85 It is expected that the rules for ".home" names outlined here will 86 also be suitable to meet the needs of the IETF HOMENET Working Group, 87 though that is not the primary goal of this document. The primary 88 goal of this draft is to understand and document the current usage. 89 If the needs of the IETF HOMENET Working Group are not met by this 90 document codifying the current de facto usage, then the Working Group 91 may choose to reserve a different Special Use Domain Name [RFC6761] 92 which does meet their needs. With luck that may not be necessary, 93 and a single document may turn out to be sufficient to serve both 94 purposes. In any case, the HOMENET Working Group is likely to be a 95 good community in which to find knowledge about how ".home" names are 96 currently used. 98 2. Conventions and Terminology Used in this Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 105 3. Mechanism 107 Typical residential home gateways configure their local clients via 108 DHCP. In addition to the client's IP address, this DHCP 109 configuration information typically also includes other configuration 110 parameters, like the IP address of the recursive (caching) DNS server 111 the client is to use, which is usually the home gateway's own address 112 (the home gateway is also a DNS cache/relay). 114 For a home network consisting of just a single link (or several 115 physical links bridged together to appear as a single logical link to 116 IP) Multicast DNS [RFC6762] is sufficient for client devices to look 117 up the dot-local host names of peers on the same home network, and 118 perform DNS-Based Service Discovery (DNS-SD) [RFC6763] of services 119 offered on that home network. 121 For a home network consisting of multiple links that are 122 interconnected using IP-layer routing instead of link-layer bridging, 123 link-local Multicast DNS alone is insufficient because link-local 124 Multicast DNS requests, by design, do not cross between links. (This 125 was a deliberate design choice for Multicast DNS, since even on a 126 single link multicast traffic is expensive -- especially on Wi-Fi 127 links -- and multiplying the amount of multicast traffic by flooding 128 it across multiple links would make that problem even worse.) In 129 this environment, unicast DNS requests (as facilated by use of 130 ".home" names instead of ".local" names) should be used for cross- 131 link name resolution and service discovery. 133 For residential home networks, Zero Configuration [ZC] operation is 134 desirable. A client device learns the appropriate DNS-SD queries to 135 perform, without requiring any manual configuration from the user, by 136 sending domain enumeration queries [RFC6763] to its configured DNS 137 server (typically the home gateway). 139 For organizations and individuals with registered globally unique 140 domain names under their control, the answers to the domain 141 enumeration queries SHOULD reference appropriate globally unique 142 domain names. For example, at IETF meetings, domain enumeration 143 queries [RFC6763] currently return the domain "meeting.ietf.org.", 144 which is globally unique and under the control of the IETF. This 145 domain enumeration answer is configured manually by the IETF meeting 146 network administrators. 148 When a suitable globally unique domain name is available, manual 149 configuration of that name in a residential home gateway (or similar 150 enterprise equipment) is appropriate. The network infrastructure 151 then communicates that information to clients, without any additional 152 manual configuration required on those clients. 154 However, many residential customers do not have any registered 155 globally unique domain name available. This may be because they 156 don't want to pay the annual fee, or because they are unaware of the 157 process for obtaining one, or because they are simply uninterested in 158 having their own globally unique domain. This category also includes 159 customers who intend to obtain a globally unique domain, but have not 160 yet done so. For these users, it would be valuable to be able to 161 perform cross-link name resolution and service discovery using 162 unicast DNS without requiring a globally unique domain name. 164 To facilitate zero configuration operation, residential home gateways 165 should be sold preconfigured with the default unicast domain name 166 "home". This default unicast domain name is not globally unique, 167 since many different residential home gateways will be using the name 168 "home" at the same time, but is sufficient for useful operation 169 within a small collection of links. Such residential home gateways 170 SHOULD offer a configuration option to allow the default (non-unique) 171 unicast domain name to be replaced with a globally unique domain name 172 for cases where the customer has a globally unique domain available 173 and wishes to use it. 175 This use of the the top-level domain "home" for private local use is 176 not new. Many home gateways have been using the name this way for 177 many years, and it remains in widespread use, as evidenced by the 178 large volume of invalid queries for "home" reaching the root name 179 servers [ICANN1][ICANN2]. The current root server traffic load is 180 due to things like home gateways configuring clients with "home" as a 181 search domain, and then leaking the resulting dot-home queries 182 upstream. In large part what the document proposes is, "stop leaking 183 dot-home queries upstream." This document codifies the existing 184 practice, and provides formal grounds basis for ISPs to legitimately 185 block such queries in order to reduce unnecessary load on the root 186 name servers. 188 4. Security Considerations 190 Users should be aware that names in the "home" domain have only local 191 significance. The name "My-Printer.home" in one location may not 192 reference the same device as "My-Printer.home" in a different 193 location. 195 5. IANA Considerations 197 [Once published, this should say] IANA has recorded the top-level 198 domain "home" in the Special-Use Domain Names registry [SUDN]. 200 5.1. Domain Name Reservation Considerations 202 The top-level domain "home", and any names falling within that domain 203 (e.g. "My-Computer.home.", "My-Printer.home.", "_ipp._tcp.home."), 204 are special [RFC6761] in the following ways: 206 1. Users may use these names as they would other DNS names, entering 207 them anywhere that they would otherwise enter a conventional DNS 208 name, or a dotted decimal IPv4 address, or a literal IPv6 209 address. 211 Since there is no global authority responsible for assigning dot- 212 home names, devices on different parts of the Internet could be 213 using the same name. Users SHOULD be aware that using a name 214 like "www.home" may not actually connect them to the web site 215 they expected, and could easily connect them to a different web 216 page, or even a fake or spoof of their intended web site, 217 designed to trick them into revealing confidential information. 218 As always with networking, end-to-end cryptographic security can 219 be a useful tool. For example, when connecting with ssh, the ssh 220 host key verification process will inform the user if it detects 221 that the identity of the entity they are communicating with has 222 changed since the last time they connected to that name. 224 2. Application software may use these names the same way it uses 225 traditional globally unique unicast DNS names, and does not need 226 to recognize these names and treat them specially in order to 227 work correctly. This document specifies the use of the top-level 228 domain "home" in on-the-wire messages. Ideally this would be 229 purely a protocol-level identifier, not seen by end users. 230 However, in some applications domain names are seen by end users, 231 and in those cases, the protocol-level identifier "home" becomes 232 visible, even for users for whom English is not their preferred 233 language. For this reason, applications MAY choose to use 234 additional UI cues (icon, text color, font, highlighting, etc.) 235 to communicate to the user that this is a special name with 236 special properties. Due to the relative ease of spoofing dot- 237 home names, end-to-end cryptographic security remains important 238 when communicating across a local network, just as it is when 239 communicating across the global Internet. 241 3. Name resolution APIs and libraries SHOULD NOT recognize these 242 names as special and SHOULD NOT treat them differently. Name 243 resolution APIs SHOULD send queries for these names to their 244 configured recursive/caching DNS server(s). 246 4. Recursive/caching DNS servers SHOULD recognize these names as 247 special and SHOULD NOT, by default, attempt to look up NS records 248 for them, or otherwise query authoritative DNS servers in an 249 attempt to resolve these names. Instead, recursive/caching DNS 250 servers SHOULD, by default, act as authoritative and generate 251 immediate responses for all such queries. This is to avoid 252 unnecessary load on the root name servers and other name servers. 254 The type of response generated depends on the role of the 255 recursive/caching DNS server: (i) Traditional recursive DNS 256 servers (such as those run by ISPs providing service to their 257 customers) SHOULD, by default, generate immediate negative 258 responses for all such queries. (ii) Recursive/caching DNS 259 servers incorporated into residential home gateways of the kind 260 described by this document should act as authoritative for these 261 names and return positive or negative responses as appropriate. 263 Recursive/caching DNS servers MAY offer a configuration option to 264 enable upstream resolving of these names, for use in networks 265 where these names are known to be handled by an authoritative DNS 266 server in said private network. This option SHOULD be disabled 267 by default, and SHOULD be enabled only when appropriate, to avoid 268 queries leaking out of the private network and placing 269 unnecessary load on the root name servers. 271 5. Traditional authoritative DNS servers SHOULD recognize these 272 names as special and SHOULD, by default, generate immediate 273 negative responses for all such queries, unless explicitly 274 configured otherwise by the administrator. As described above, 275 DNS servers incorporated into residential home gateways of the 276 kind described by this document should act as authoritative for 277 these names and return positive or negative responses as 278 appropriate, unless explicitly configured otherwise by the 279 administrator. 281 6. DNS server operators SHOULD, if they are using these names, 282 configure their authoritative DNS servers to act as authoritative 283 for these names. In the case of zero-configuration residential 284 home gateways of the kind described by this document, this 285 configuration is implicit in the design of the product, rather 286 than a result of conscious administration by the customer. 288 7. DNS Registries/Registrars MUST NOT grant requests to register 289 these names in the normal way to any person or entity. These 290 names are reserved for use in private networks and fall outside 291 the set of names available for allocation by registries/ 292 registrars. Attempting to allocate a these name as if it were a 293 normal DNS domain name will probably not work as desired, for 294 reasons 4, 5, and 6 above. 296 6. Acknowledgments 298 Thanks to Francisco Arias of ICANN for his review and comments on 299 this draft. 301 7. References 303 7.1. Normative References 305 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 306 STD 13, RFC 1034, November 1987. 308 [RFC1035] Mockapetris, P., "Domain names - implementation and 309 specification", STD 13, RFC 1035, November 1987. 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 315 RFC 6761, February 2013. 317 7.2. Informative References 319 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 320 February 2013. 322 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 323 Discovery", RFC 6763, February 2013. 325 [ICANN1] "New gTLD Collision Risk Mitigation", . 329 [ICANN2] "New gTLD Collision Occurrence Management", . 333 [SUDN] "Special-Use Domain Names Registry", . 336 [ZC] Cheshire, S. and D. Steinberg, "Zero Configuration 337 Networking: The Definitive Guide", O'Reilly Media, Inc. , 338 ISBN 0-596-10100-7, December 2005. 340 Author's Address 342 Stuart Cheshire 343 Apple Inc. 344 1 Infinite Loop 345 Cupertino, California 95014 346 USA 348 Phone: +1 408 974 3207 349 Email: cheshire@apple.com