idnits 2.17.1 draft-ietf-homenet-dot-10.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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 28, 2017) is 2464 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 (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Pfister 3 Internet-Draft Cisco Systems 4 Updates: RFC7788 (if approved) T. Lemon 5 Intended status: Standards Track Nominum, Inc. 6 Expires: January 29, 2018 July 28, 2017 8 Special Use Domain 'home.arpa.' 9 draft-ietf-homenet-dot-10 11 Abstract 13 This document specifies the behavior that is expected from the Domain 14 Name System with regard to DNS queries for names ending with 15 '.home.arpa.', and designates this domain as a special-use domain 16 name. 'home.arpa.' is designated for non-unique use in residential 17 home networks. Home Networking Control Protocol (HNCP) is updated to 18 use the 'home.arpa.' domain instead of '.home'. 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 January 29, 2018. 37 Copyright Notice 39 Copyright (c) 2017 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 56 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Domain Name Reservation Considerations . . . . . . . . . . . 3 58 5. Updates to Home Networking Control Protocol . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 10.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 Users and devices within a home network (hereafter "homenet") require 71 devices and services to be identified by names that are unique within 72 the boundaries of the homenet [RFC7368]. The naming mechanism needs 73 to function without configuration from the user. While it may be 74 possible for a name to be delegated by an ISP, homenets must also 75 function in the absence of such a delegation. A default name with a 76 scope limited to each individual homenet needs to be used. 78 This document corrects an error in [RFC7788], replacing '.home' with 79 'home.arpa.' as the default domain-name for homenets. '.home' had 80 been selected as the most user-friendly option. However, there are 81 existing uses of '.home' that may be in conflict with this use: 82 evidence indicates that '.home' queries frequently leak out and reach 83 the root name servers [ICANN1] [ICANN2]. 85 In addition, it's necessary, for compatibility with DNSSEC 86 (Section 6), that an unsigned delegation be present for the name. 87 There is an existing process for allocating names under '.arpa' 88 [RFC3172]. No such process is available for requesting a similar 89 delegation in the root at the request of the IETF, which does not 90 administer that zone. As a result, the use of '.home' is deprecated. 92 This document registers the domain '.home.arpa.' as a special-use 93 domain name [RFC6761] and specifies the behavior that is expected 94 from the Domain Name System with regard to DNS queries for names 95 whose rightmost non-terminal labels are 'home.arpa.'. Queries for 96 names ending with '.home.arpa.' are of local significance within the 97 scope of a homenet, meaning that identical queries will result in 98 different results from one homenet to another. In other words, a 99 name ending in 'home.arpa.' is not globally unique. 101 Although this document makes specific reference to RFC7788, it is not 102 intended that the use of 'home.arpa.' be restricted solely to 103 networks where HNCP is deployed; it is rather the case that 104 'home.arpa.' is the correct domain for uses like the one described 105 for '.home' in RFC7788: local name service in residential homenets. 107 2. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 3. General Guidance 117 The domain name '.home.arpa.' is to be used for naming within 118 residential homenets. Names ending with '.home.arpa.' reference a 119 locally-served zone, the contents of which are unique only to a 120 particular homenet, and are not globally unique. Such names refer to 121 nodes and/or services that are located within a homenet (e.g., a 122 printer, or a toaster). 124 DNS queries for names ending with '.home.arpa.' are resolved using 125 local resolvers on the homenet. Such queries MUST NOT be recursively 126 forwarded to servers outside the logical boundaries of the homenet. 128 Some service discovery user interfaces that are expected to be used 129 on homenets conceal information such as domain names from end users. 130 However, it is still expected that in some cases, users will need to 131 see, remember, and even type, names ending with 'home.arpa.'. It is 132 therefore desirable that users identify the domain and understand 133 that using it expresses the intention to connect to a service that is 134 specific to the homenet to which they are connected. Enforcing the 135 fulfillment of this intention is out of scope for this document. 137 4. Domain Name Reservation Considerations 139 This section defines the behavior of systems involved in domain name 140 resolution when resolving queries for names ending with '.home.arpa.' 141 (as per [RFC6761]). 143 1. Users can use names ending with '.home.arpa.' just as they would 144 use any other domain name. The 'home.arpa.' name is chosen to be 145 readily recognized by users as signifying that the name is 146 addressing a service on the homenet to which the user's device is 147 connected. 149 2. Application software SHOULD NOT treat names ending in 150 'home.arpa.' differently than other names. In particular, there 151 is no basis for trusting names that are subdomains of 152 'home.arpa.' (see Section 6). 154 3. Name resolution APIs and libraries MUST NOT recognize names that 155 end in '.home.arpa.' as special and MUST NOT treat them 156 differently. Name resolution APIs MUST send queries for such 157 names to a recursive DNS server that is configured to be 158 authoritative for the 'home.arpa.' zone appropriate to the 159 homenet. One or more IP addresses for recursive DNS servers will 160 usually be supplied to the client through router advertisements 161 or DHCP. If a host is configured to use a resolver other than 162 one that is authoritative for the appropriate 'home.arpa.' zone, 163 the client may be unable to resolve, or may receive incorrect 164 results for, names in sub domains of 'home.arpa.'. 166 4. Unless configured otherwise, recursive resolvers and DNS proxies 167 MUST behave as described in Locally Served Zones ([RFC6303] 168 Section 3). Recursive resolvers that can be used in a homenet 169 MUST be configurable with a delegation to an authoritative server 170 for that particular homenet's instance of the domain 171 'home.arpa.', and, when so configured, MUST NOT attempt to look 172 up a delegation for 'home.arpa.' in the public DNS. Of course, 173 from an implementation standpoint it may be that a hybrid name 174 server acts as a caching resolver or DNS proxy for non-local 175 domains and as an authoritative server for 'home.arpa.' and other 176 locally served zones, responding directly to queries for 177 subdomains of 'home.arpa.' rather than using a delegation. 179 5. No special processing of 'home.arpa.' is required for 180 authoritative DNS server implementations. It is possible that an 181 authoritative DNS server might attempt to check the authoritative 182 servers for 'home.arpa.' for a delegation beneath that name 183 before answering authoritatively for such a delegated name. In 184 such a case, because the name always has only local significance 185 there will be no such delegation in the 'home.arpa.' zone, and so 186 the server would refuse to answer authoritatively for such a 187 zone. A server that implements this sort of check MUST be 188 configurable so that either it does not do this check for the 189 'home.arpa.' domain, or it ignores the results of the check. 191 6. DNS server operators MAY configure an authoritative server for 192 'home.arpa.' for use in homenets and other home networks. The 193 operator for the DNS servers authoritative for 'home.arpa.' in 194 the global DNS will configure any such servers as described in 195 Section 7. 197 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which 198 is operated by IANA under the authority of the Internet 199 Architecture Board according to the rules established in 200 [RFC3172]. There are no other registrars for .arpa. 202 5. Updates to Home Networking Control Protocol 204 The final paragraph of Home Networking Control Protocol [RFC7788], 205 section 8, is updated as follows: 207 OLD: 209 Names and unqualified zones are used in an HNCP network to provide 210 naming and service discovery with local significance. A network- 211 wide zone is appended to all single labels or unqualified zones in 212 order to qualify them. ".home" is the default; however, an 213 administrator MAY configure the announcement of a Domain-Name TLV 214 (Section 10.6) for the network to use a different one. In case 215 multiple are announced, the domain of the node with the greatest 216 node identifier takes precedence. 218 NEW: 220 Names and unqualified zones are used in an HNCP network to provide 221 naming and service discovery with local significance. A network- 222 wide zone is appended to all single labels or unqualified zones in 223 order to qualify them. 'home.arpa.' is the default; however, an 224 administrator MAY configure the announcement of a Domain-Name TLV 225 (Section 10.6) for the network to use a different one. In case 226 multiple are announced, the domain of the node with the greatest 227 node identifier takes precedence. 229 The 'home.arpa.' special-use name does not require a special 230 resolution protocol. Names for which the rightmost two labels are 231 'home.arpa.' are resolved using the DNS protocol [RFC1035]. 233 6. Security Considerations 235 A DNS record that is returned as a response to a query for an FQDN in 236 the domain '.home.arpa.' is expected to have local significance. It 237 is expected to be returned by a server involved in name resolution 238 for the homenet the device is connected in. However, such response 239 MUST NOT be considered more trustworthy than would be a similar 240 response for any other DNS query. 242 Because 'home.arpa.' is not globally scoped and cannot be secured 243 using DNSSEC based on the root domain's trust anchor, there is no way 244 to tell, using a standard DNS query, in which homenet scope an answer 245 belongs. Consequently, users may experience surprising results with 246 such names when roaming to different homenets. To prevent this from 247 happening, it may be useful for the resolver to identify different 248 homenets on which it has resolved names, but this is out of scope for 249 this document. 251 It is not possible to install a trust anchor for this zone in the 252 '.arpa' zone. The reason for this is that in order to do so, it 253 would be necessary to have the key-signing key for the zone 254 ([RFC4034] Section 5). Since the zone is not globally unique, no one 255 key would work. 257 An alternative would be to install a authenticated denial of 258 existence ([RFC4033] Section 3.2). However, this assumes that 259 validation is being done on a caching resolver that is aware of the 260 special local meaning of 'home.arpa.'. If a host stub resolver 261 attempts to validate a name in 'home.arpa.', an authenticated denial 262 of existence of 'home' as a subdomain of 'arpa.' would cause the 263 validation to fail. Therefore, the only delegation that will allow 264 names under 'home.arpa.' to be resolved is an unsigned delegation. 266 Consequently, unless a trust anchor for the particular instance of 267 the 'home.arpa.' zone being validated is manually configured on the 268 validating resolver, DNSSEC signing of names within the 'home.arpa.' 269 zone is not possible. 271 Although in principle it might be useful to install a trust anchor 272 for a particular instance of 'home.arpa.', it's reasonable to expect 273 that a host with such a trust anchor might from time to time connect 274 to more than one network with its own instance of 'home.arpa.'. Such 275 a host would be unable to access services on any instance of 276 'home.arpa.' other than the one for which a trust anchor was 277 configured. 279 It is in principle possible to attach an identifier to an instance of 280 'home.arpa.' that could be used to identify which trust anchor to 281 rely on for validating names in that particular instance. However, 282 the security implications of this are complicated, and such a 283 mechanism, as well as a discussion of those implications, is out of 284 scope for this document. 286 7. Delegation of 'home.arpa.' 288 In order to be fully functional, there must be a delegation of 289 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST 290 NOT be signed, MUST NOT include a DS record, and MUST point to one or 291 more black hole servers, for example 'blackhole-1.iana.org.' and 292 'blackhole-2.iana.org.'. The reason that this delegation must not be 293 signed is that not signing the delegation breaks the DNSSEC chain of 294 trust, which prevents a validating stub resolver from rejecting names 295 published under 'home.arpa.' on a homenet name server. 297 8. IANA Considerations 299 IANA is requested to record the domain name 'home.arpa.' in the 300 Special-Use Domain Names registry [SUDN]. IANA is requested, with 301 the approval of IAB, to implement the delegation requested in 302 Section 7. 304 9. Acknowledgments 306 The authors would like to thank Stuart Cheshire for his prior work on 307 '.home', as well as the homenet chairs: Mark Townsley and Ray Bellis. 308 We would also like to thank Paul Hoffman for providing review and 309 comments on the IANA considerations section, Andrew Sullivan for his 310 review and proposed text, and Suzanne Woolf and Ray Bellis for their 311 very detailed review comments and process insights. 313 10. References 315 10.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 323 Requirements for the Address and Routing Parameter Area 324 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 325 September 2001, . 327 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 328 RFC 6303, DOI 10.17487/RFC6303, July 2011, 329 . 331 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 332 RFC 6761, DOI 10.17487/RFC6761, February 2013, 333 . 335 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 336 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 337 May 2017, . 339 10.2. Informative References 341 [RFC1035] Mockapetris, P., "Domain names - implementation and 342 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 343 November 1987, . 345 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 346 Rose, "DNS Security Introduction and Requirements", 347 RFC 4033, DOI 10.17487/RFC4033, March 2005, 348 . 350 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 351 Rose, "Resource Records for the DNS Security Extensions", 352 RFC 4034, DOI 10.17487/RFC4034, March 2005, 353 . 355 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 356 Weil, "IPv6 Home Networking Architecture Principles", 357 RFC 7368, DOI 10.17487/RFC7368, October 2014, 358 . 360 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 361 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 362 2016, . 364 [ICANN1] "New gTLD Collision Risk Mitigation", October 2013, 365 . 368 [ICANN2] "New gTLD Collision Occurence Management", October 2013, 369 . 372 [SUDN] "Special-Use Domain Names Registry", July 2012, 373 . 376 Authors' Addresses 377 Pierre Pfister 378 Cisco Systems 379 Paris 380 France 382 Email: pierre.pfister@darou.fr 384 Ted Lemon 385 Nominum, Inc. 386 800 Bridge Parkway 387 Redwood City, California 94065 388 United States of America 390 Phone: +1 650 381 6000 391 Email: ted.lemon@nominum.com