idnits 2.17.1 draft-ietf-homenet-dot-09.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 2 instances 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 (July 3, 2017) is 2482 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: January 4, 2018 July 3, 2017 8 Special Use Domain '.home.arpa' 9 draft-ietf-homenet-dot-09 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 4, 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. However, it is 181 possible that an authoritative DNS server might attempt to 182 validate the delegation for a zone before answering 183 authoritatively for that zone. In this situation, it would find 184 an invalid delegation, and would not answer authoritatively. A 185 server that implements this sort of check MUST be configurable so 186 that either it does not do this check for the 'home.arpa' domain, 187 or it ignores the results of the check. 189 6. DNS server operators MAY configure an authoritative server for 190 '.home.arpa' for use in homenets and other home networks. The 191 operator for the DNS servers authoritative for '.home.arpa' in 192 the global DNS will configure any such servers as described in 193 Section 7. 195 7. 'home.arpa' is a subdomain of the 'arpa' top-level domain, which 196 is operated by IANA under the authority of the Internet 197 Architecture Board according to the rules established in 198 [RFC3172]. There are no other registrars for .arpa. 200 5. Updates to Home Networking Control Protocol 202 The final paragraph of Home Networking Control Protocol [RFC7788], 203 section 8, is updated as follows: 205 OLD: 207 Names and unqualified zones are used in an HNCP network to provide 208 naming and service discovery with local significance. A network- 209 wide zone is appended to all single labels or unqualified zones in 210 order to qualify them. ".home" is the default; however, an 211 administrator MAY configure the announcement of a Domain-Name TLV 212 (Section 10.6) for the network to use a different one. In case 213 multiple are announced, the domain of the node with the greatest 214 node identifier takes precedence. 216 NEW: 218 Names and unqualified zones are used in an HNCP network to provide 219 naming and service discovery with local significance. A network- 220 wide zone is appended to all single labels or unqualified zones in 221 order to qualify them. '.home.arpa' is the default; however, an 222 administrator MAY configure the announcement of a Domain-Name TLV 223 (Section 10.6) for the network to use a different one. In case 224 multiple are announced, the domain of the node with the greatest 225 node identifier takes precedence. 227 The '.home.arpa' special-use name does not require a special 228 resolution protocol. Names for which the rightmost two labels are 229 '.home.arpa' are resolved using the DNS protocol [RFC1035]. 231 6. Security Considerations 233 A DNS record that is returned as a response to a query for an FQDN in 234 the domain '.home.arpa.' is expected to have local significance. It 235 is expected to be returned by a server involved in name resolution 236 for the homenet the device is connected in. However, such response 237 MUST NOT be considered more trustworthy than would be a similar 238 response for any other DNS query. 240 Because '.home.arpa' is not globally scoped and cannot be secured 241 using DNSSEC based on the root domain's trust anchor, there is no way 242 to tell, using a standard DNS query, in which homenet scope an answer 243 belongs. Consequently, users may experience surprising results with 244 such names when roaming to different homenets. To prevent this from 245 happening, it may be useful for the resolver to identify different 246 homenets on which it has resolved names, but this is out of scope for 247 this document. 249 It is not possible to install a trust anchor for this zone in the 250 '.arpa' zone. The reason for this is that in order to do so, it 251 would be necessary to have the key-signing key for the zone 252 ([RFC4034] Section 5). Since the zone is not globally unique, no one 253 key would work. 255 An alternative would be to install a authenticated denial of 256 existence ([RFC4033] Section 3.2). However, this assumes that 257 validation is being done on a caching resolver that is aware of the 258 special local meaning of '.home.arpa'. If a host stub resolver 259 attempts to validate a name in '.home.arpa', an authenticated denial 260 of existence of 'home' as a subdomain of 'arpa.' would cause the 261 validation to fail. Therefore, the only delegation that will allow 262 names under '.home.arpa' to be resolved is an unsigned delegation. 264 Consequently, unless a trust anchor for the particular instance of 265 the '.home.arpa' zone being validated is manually configured on the 266 validating resolver, DNSSEC signing of names within the '.home.arpa' 267 zone is not possible. 269 Although in principle it might be useful to install a trust anchor 270 for a particular instance of '.home.arpa', it's reasonable to expect 271 that a host with such a trust anchor might from time to time connect 272 to more than one network with its own instance of '.home.arpa'. Such 273 a host would be unable to access services on any instance of 274 '.home.arpa' other than the one for which a trust anchor was 275 configured. 277 It is in principle possible to attach an identifier to an instance of 278 '.home.arpa' that could be used to identify which trust anchor to 279 rely on for validating names in that particular instance. However, 280 the security implications of this are complicated, and such a 281 mechanism, as well as a discussion of those implications, is out of 282 scope for this document. 284 7. Delegation of 'home.arpa' 286 In order to be fully functional, there must be a delegation of 287 'home.arpa' in the '.arpa' zone [RFC3172]. This delegation MUST NOT 288 be signed, MUST NOT include a DS record, and MUST point to one or 289 more black hole servers, for example BLACKHOLE-1.IANA.ORG and 290 BLACKHOLE-2.IANA.ORG. The reason that this delegation must not be 291 signed is that not signing the delegation breaks the DNSSEC chain of 292 trust, which prevents a validating stub resolver from rejecting names 293 published under 'home.arpa' on a homenet name server. 295 8. IANA Considerations 297 IANA is requested to record the domain name '.home.arpa' in the 298 Special-Use Domain Names registry [SUDN]. IANA is requested, with 299 the approval of IAB, to implement the delegation requested in 300 Section 7. 302 9. Acknowledgments 304 The authors would like to thank Stuart Cheshire for his prior work on 305 '.home', as well as the homenet chairs: Mark Townsley and Ray Bellis. 306 We would also like to thank Paul Hoffman for providing review and 307 comments on the IANA considerations section and Suzanne Woolf and Ray 308 Bellis for their detailed review comments. 310 10. References 312 10.1. Normative References 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, 317 . 319 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 320 Requirements for the Address and Routing Parameter Area 321 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 322 September 2001, . 324 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 325 RFC 6303, DOI 10.17487/RFC6303, July 2011, 326 . 328 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 329 RFC 6761, DOI 10.17487/RFC6761, February 2013, 330 . 332 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 333 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 334 May 2017, . 336 10.2. Informative References 338 [ICANN1] "New gTLD Collision Risk Mitigation", October 2013, 339 . 342 [ICANN2] "New gTLD Collision Occurence Management", October 2013, 343 . 346 [RFC1035] Mockapetris, P., "Domain names - implementation and 347 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 348 November 1987, . 350 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 351 Rose, "DNS Security Introduction and Requirements", 352 RFC 4033, DOI 10.17487/RFC4033, March 2005, 353 . 355 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 356 Rose, "Resource Records for the DNS Security Extensions", 357 RFC 4034, DOI 10.17487/RFC4034, March 2005, 358 . 360 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 361 Weil, "IPv6 Home Networking Architecture Principles", 362 RFC 7368, DOI 10.17487/RFC7368, October 2014, 363 . 365 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 366 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 367 2016, . 369 [SUDN] "Special-Use Domain Names Registry", July 2012, 370 . 373 Authors' Addresses 374 Pierre Pfister 375 Cisco Systems 376 Paris 377 France 379 Email: pierre.pfister@darou.fr 381 Ted Lemon 382 Nominum, Inc. 383 800 Bridge Parkway 384 Redwood City, California 94065 385 United States of America 387 Phone: +1 650 381 6000 388 Email: ted.lemon@nominum.com