idnits 2.17.1 draft-ietf-homenet-dot-11.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == 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 (August 8, 2017) is 2425 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 (~~), 3 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: February 9, 2018 August 8, 2017 8 Special Use Domain 'home.arpa.' 9 draft-ietf-homenet-dot-11 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 February 9, 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 . . . . . . . . . . . . . . . . . . . . . . . 9 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 insecure delegation ([RFC4035] section 4.3) be 87 present for the name. There is an existing process for allocating 88 names under '.arpa' [RFC3172]. No such process is available for 89 requesting a similar delegation in the root at the request of the 90 IETF, which does not administer that zone. As a result, the use of 91 '.home' is deprecated. 93 This document registers the domain '.home.arpa.' as a special-use 94 domain name [RFC6761] and specifies the behavior that is expected 95 from the Domain Name System with regard to DNS queries for names 96 whose rightmost non-terminal labels are 'home.arpa.'. Queries for 97 names ending with '.home.arpa.' are of local significance within the 98 scope of a homenet, meaning that identical queries will result in 99 different results from one homenet to another. In other words, a 100 name ending in 'home.arpa.' is not globally unique. 102 Although this document makes specific reference to RFC7788, it is not 103 intended that the use of 'home.arpa.' be restricted solely to 104 networks where HNCP is deployed; it is rather the case that 105 'home.arpa.' is the correct domain for uses like the one described 106 for '.home' in RFC7788: local name service in residential homenets. 108 2. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 3. General Guidance 118 The domain name '.home.arpa.' is to be used for naming within 119 residential homenets. Names ending with '.home.arpa.' reference a 120 locally-served zone, the contents of which are unique only to a 121 particular homenet, and are not globally unique. Such names refer to 122 nodes and/or services that are located within a homenet (e.g., a 123 printer, or a toaster). 125 DNS queries for names ending with '.home.arpa.' are resolved using 126 local resolvers on the homenet. Such queries MUST NOT be recursively 127 forwarded to servers outside the logical boundaries of the homenet. 129 Some service discovery user interfaces that are expected to be used 130 on homenets conceal information such as domain names from end users. 131 However, it is still expected that in some cases, users will need to 132 see, remember, and even type, names ending with 'home.arpa.'. It is 133 therefore desirable that users identify the domain and understand 134 that using it expresses the intention to connect to a service that is 135 specific to the homenet to which they are connected. Enforcing the 136 fulfillment of this intention is out of scope for this document. 138 4. Domain Name Reservation Considerations 140 This section defines the behavior of systems involved in domain name 141 resolution when resolving queries for names ending with '.home.arpa.' 142 (as per [RFC6761]). 144 1. Users can use names ending with '.home.arpa.' just as they would 145 use any other domain name. The 'home.arpa.' name is chosen to be 146 readily recognized by users as signifying that the name is 147 addressing a service on the homenet to which the user's device is 148 connected. 150 2. Application software SHOULD NOT treat names ending in 151 'home.arpa.' differently than other names. In particular, there 152 is no basis for trusting names that are subdomains of 153 'home.arpa.' (see Section 6). 155 3. Name resolution APIs and libraries MUST NOT recognize names that 156 end in '.home.arpa.' as special and MUST NOT treat them 157 differently. Name resolution APIs MUST send queries for such 158 names to a recursive DNS server that is configured to be 159 authoritative for the 'home.arpa.' zone appropriate to the 160 homenet. One or more IP addresses for recursive DNS servers will 161 usually be supplied to the client through router advertisements 162 or DHCP. If a host is configured to use a resolver other than 163 one that is authoritative for the appropriate 'home.arpa.' zone, 164 the client may be unable to resolve, or may receive incorrect 165 results for, names in sub domains of 'home.arpa.'. 167 4. Unless configured otherwise, recursive resolvers and DNS proxies 168 MUST behave as described in Locally Served Zones ([RFC6303] 169 Section 3). Recursive resolvers that can be used in a homenet 170 MUST be configurable with a delegation to an authoritative server 171 for that particular homenet's instance of the domain 172 'home.arpa.', and, when so configured, MUST NOT attempt to look 173 up a delegation for 'home.arpa.' in the public DNS. Of course, 174 from an implementation standpoint it may be that a hybrid name 175 server acts as a caching resolver or DNS proxy for non-local 176 domains and as an authoritative server for 'home.arpa.' and other 177 locally served zones, responding directly to queries for 178 subdomains of 'home.arpa.' rather than using a delegation. 180 5. No special processing of 'home.arpa.' is required for 181 authoritative DNS server implementations. It is possible that an 182 authoritative DNS server might attempt to check the authoritative 183 servers for 'home.arpa.' for a delegation beneath that name 184 before answering authoritatively for such a delegated name. In 185 such a case, because the name always has only local significance 186 there will be no such delegation in the 'home.arpa.' zone, and so 187 the server would refuse to answer authoritatively for such a 188 zone. A server that implements this sort of check MUST be 189 configurable so that either it does not do this check for the 190 'home.arpa.' domain, or it ignores the results of the check. 192 6. DNS server operators MAY configure an authoritative server for 193 'home.arpa.' for use in homenets and other home networks. The 194 operator for the DNS servers authoritative for 'home.arpa.' in 195 the global DNS will configure any such servers as described in 196 Section 7. 198 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which 199 is operated by IANA under the authority of the Internet 200 Architecture Board according to the rules established in 201 [RFC3172]. There are no other registrars for .arpa. 203 5. Updates to Home Networking Control Protocol 205 The final paragraph of Home Networking Control Protocol [RFC7788], 206 section 8, is updated as follows: 208 OLD: 210 Names and unqualified zones are used in an HNCP network to provide 211 naming and service discovery with local significance. A network- 212 wide zone is appended to all single labels or unqualified zones in 213 order to qualify them. ".home" is the default; however, an 214 administrator MAY configure the announcement of a Domain-Name TLV 215 (Section 10.6) for the network to use a different one. In case 216 multiple are announced, the domain of the node with the greatest 217 node identifier takes precedence. 219 NEW: 221 Names and unqualified zones are used in an HNCP network to provide 222 naming and service discovery with local significance. A network- 223 wide zone is appended to all single labels or unqualified zones in 224 order to qualify them. 'home.arpa.' is the default; however, an 225 administrator MAY configure the announcement of a Domain-Name TLV 226 (Section 10.6) for the network to use a different one. In case 227 multiple are announced, the domain of the node with the greatest 228 node identifier takes precedence. 230 The 'home.arpa.' special-use name does not require a special 231 resolution protocol. Names for which the rightmost two labels are 232 'home.arpa.' are resolved using the DNS protocol [RFC1035]. 234 6. Security Considerations 236 A DNS record that is returned as a response to a query for an FQDN in 237 the domain '.home.arpa.' is expected to have local significance. It 238 is expected to be returned by a server involved in name resolution 239 for the homenet the device is connected in. However, such response 240 MUST NOT be considered more trustworthy than would be a similar 241 response for any other DNS query. 243 Because 'home.arpa.' is not globally scoped and cannot be secured 244 using DNSSEC based on the root domain's trust anchor, there is no way 245 to tell, using a standard DNS query, in which homenet scope an answer 246 belongs. Consequently, users may experience surprising results with 247 such names when roaming to different homenets. To prevent this from 248 happening, it may be useful for the resolver to identify different 249 homenets on which it has resolved names, but this is out of scope for 250 this document. 252 It is not possible to install a trust anchor for this zone in the 253 '.arpa' zone. The reason for this is that in order to do so, it 254 would be necessary to have the key-signing key for the zone 255 ([RFC4034] Section 5). Since the zone is not globally unique, no one 256 key would work. 258 An alternative would be to install a authenticated denial of 259 existence ([RFC4033] Section 3.2). However, this assumes that 260 validation is being done on a caching resolver that is aware of the 261 special local meaning of 'home.arpa.'. If a host stub resolver 262 attempts to validate a name in 'home.arpa.', an authenticated denial 263 of existence of 'home' as a subdomain of 'arpa.' would cause the 264 validation to fail. Therefore, the only delegation that will allow 265 names under 'home.arpa.' to be resolved is an insecure delegation, as 266 in [RFC6303] section 7. 268 Consequently, unless a trust anchor for the particular instance of 269 the 'home.arpa.' zone being validated is manually configured on the 270 validating resolver, DNSSEC signing of names within the 'home.arpa.' 271 zone is not possible. 273 Although in principle it might be useful to install a trust anchor 274 for a particular instance of 'home.arpa.', it's reasonable to expect 275 that a host with such a trust anchor might from time to time connect 276 to more than one network with its own instance of 'home.arpa.'. Such 277 a host would be unable to access services on any instance of 278 'home.arpa.' other than the one for which a trust anchor was 279 configured. 281 It is in principle possible to attach an identifier to an instance of 282 'home.arpa.' that could be used to identify which trust anchor to 283 rely on for validating names in that particular instance. However, 284 the security implications of this are complicated, and such a 285 mechanism, as well as a discussion of those implications, is out of 286 scope for this document. 288 7. Delegation of 'home.arpa.' 290 In order to be fully functional, there must be a delegation of 291 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST 292 NOT include a DS record, and MUST point to one or more black hole 293 servers, for example 'blackhole-1.iana.org.' and 'blackhole- 294 2.iana.org.'. The reason that this delegation must not be signed is 295 that not signing the delegation breaks the DNSSEC chain of trust, 296 which prevents a validating stub resolver from rejecting names 297 published under 'home.arpa.' on a homenet name server. 299 8. IANA Considerations 301 IANA is requested to record the domain name 'home.arpa.' in the 302 Special-Use Domain Names registry [SUDN]. IANA is requested, with 303 the approval of IAB, to implement the delegation requested in 304 Section 7. 306 9. Acknowledgments 308 The authors would like to thank Stuart Cheshire for his prior work on 309 '.home', as well as the homenet chairs: Mark Townsley and Ray Bellis. 310 We would also like to thank Paul Hoffman for providing review and 311 comments on the IANA considerations section, Andrew Sullivan for his 312 review and proposed text, and Suzanne Woolf and Ray Bellis for their 313 very detailed review comments and process insights. Thanks to Mark 314 Andrews for providing an exhaustive reference list on the topic of 315 insecure delegations. 317 10. References 319 10.1. Normative References 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 327 Requirements for the Address and Routing Parameter Area 328 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 329 September 2001, . 331 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 332 Rose, "Protocol Modifications for the DNS Security 333 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 334 . 336 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 337 RFC 6303, DOI 10.17487/RFC6303, July 2011, 338 . 340 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 341 RFC 6761, DOI 10.17487/RFC6761, February 2013, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 10.2. Informative References 350 [ICANN1] "New gTLD Collision Risk Mitigation", October 2013, 351 . 354 [ICANN2] "New gTLD Collision Occurence Management", October 2013, 355 . 358 [RFC1035] Mockapetris, P., "Domain names - implementation and 359 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 360 November 1987, . 362 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 363 Rose, "DNS Security Introduction and Requirements", 364 RFC 4033, DOI 10.17487/RFC4033, March 2005, 365 . 367 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 368 Rose, "Resource Records for the DNS Security Extensions", 369 RFC 4034, DOI 10.17487/RFC4034, March 2005, 370 . 372 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 373 Weil, "IPv6 Home Networking Architecture Principles", 374 RFC 7368, DOI 10.17487/RFC7368, October 2014, 375 . 377 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 378 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 379 2016, . 381 [SUDN] "Special-Use Domain Names Registry", July 2012, 382 . 385 Authors' Addresses 387 Pierre Pfister 388 Cisco Systems 389 Paris 390 France 392 Email: pierre.pfister@darou.fr 394 Ted Lemon 395 Nominum, Inc. 396 800 Bridge Parkway 397 Redwood City, California 94065 398 United States of America 400 Phone: +1 650 381 6000 401 Email: ted.lemon@nominum.com