idnits 2.17.1 draft-ietf-homenet-dot-07.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 (June 30, 2017) is 2489 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 1, 2018 June 30, 2017 8 Special Use Domain '.home.arpa' 9 draft-ietf-homenet-dot-07 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 1, 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' . . . . . . . . . . . . . . . . . . 6 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 10.2. Informative References . . . . . . . . . . . . . . . . . 7 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, if an 181 authoritative DNS server does any sort of sanity checking of the 182 delegation for zones for which it is configured to be 183 authoritative, it must be possible to disable this sanity check 184 for '.home.arpa' or ignore the results. 186 6. DNS server operators MAY configure an authoritative server for 187 '.home.arpa' for use in homenets and other home networks. The 188 operator for the DNS servers authoritative for '.home.arpa' in 189 the global DNS will configure any such servers as described in 190 Section 7. 192 7. 'home.arpa' is a subdomain of the 'arpa' top-level domain, which 193 is operated by IANA under the authority of the Internet 194 Architecture Board according to the rules established in 195 [RFC3172]. There are no other registrars for .arpa. 197 5. Updates to Home Networking Control Protocol 199 The final paragraph of Home Networking Control Protocol [RFC7788], 200 section 8, is updated as follows: 202 OLD: 204 Names and unqualified zones are used in an HNCP network to provide 205 naming and service discovery with local significance. A network- 206 wide zone is appended to all single labels or unqualified zones in 207 order to qualify them. ".home" is the default; however, an 208 administrator MAY configure the announcement of a Domain-Name TLV 209 (Section 10.6) for the network to use a different one. In case 210 multiple are announced, the domain of the node with the greatest 211 node identifier takes precedence. 213 NEW: 215 Names and unqualified zones are used in an HNCP network to provide 216 naming and service discovery with local significance. A network- 217 wide zone is appended to all single labels or unqualified zones in 218 order to qualify them. '.home.arpa' is the default; however, an 219 administrator MAY configure the announcement of a Domain-Name TLV 220 (Section 10.6) for the network to use a different one. In case 221 multiple are announced, the domain of the node with the greatest 222 node identifier takes precedence. 224 The '.home.arpa' special-use name does not require a special 225 resolution protocol. Names for which the rightmost two labels are 226 '.home.arpa' are resolved using the DNS protocol [RFC1035]. 228 6. Security Considerations 230 A DNS record that is returned as a response to a query for an FQDN in 231 the domain '.home.arpa.' is expected to have local significance. It 232 is expected to be returned by a server involved in name resolution 233 for the homenet the device is connected in. However, such response 234 MUST NOT be considered more trustworthy than would be a similar 235 response for any other DNS query. 237 Because '.home.arpa' is not globally scoped and cannot be secured 238 using DNSSEC based on the root domain's trust anchor, there is no way 239 to tell, using a standard DNS query, in which homenet scope an answer 240 belongs. Consequently, users may experience surprising results with 241 such names when roaming to different homenets. To prevent this from 242 happening, it may be useful for the resolver to identify different 243 homenets on which it has resolved names, but this is out of scope for 244 this document. 246 It is not possible to install a trust anchor for this zone in the 247 '.arpa' zone. The reason for this is that in order to do so, it 248 would be necessary to have the key-signing key for the zone 249 ([RFC4034] Section 5). Since the zone is not globally unique, no one 250 key would work. 252 An alternative would be to install a authenticated denial of 253 existence ([RFC4033] Section 3.2). However, this assumes that 254 validation is being done on a caching resolver that is aware of the 255 special local meaning of '.home.arpa'. If a host stub resolver 256 attempts to validate a name in '.home.arpa', an authenticated denial 257 of existence of 'home' as a subdomain of 'arpa.' would cause the 258 validation to fail. Therefore, the only delegation that will allow 259 names under '.home.arpa' to be resolved is an unsigned delegation. 261 Consequently, unless a trust anchor for the particular instance of 262 the '.home.arpa' zone being validated is manually configured on the 263 validating resolver, DNSSEC signing of names within the '.home.arpa' 264 zone is not possible. 266 Although in principle it might be useful to install a trust anchor 267 for a particular instance of '.home.arpa', it's reasonable to expect 268 that a host with such a trust anchor might from time to time connect 269 to more than one network with its own instance of '.home.arpa'. Such 270 a host would be unable to access services on any instance of 271 '.home.arpa' other than the one for which a trust anchor was 272 configured. 274 It is in principle possible to attach an identifier to an instance of 275 '.home.arpa' that could be used to identify which trust anchor to 276 rely on for validating names in that particular instance. However, 277 the security implications of this are complicated, and such a 278 mechanism, as well as a discussion of those implications, is out of 279 scope for this document. 281 7. Delegation of 'home.arpa' 283 In order to be fully functional, there must be a delegation of 284 'home.arpa' in the '.arpa' zone [RFC3172]. This delegation MUST NOT 285 be signed, MUST NOT include a DS record, and MUST point to one or 286 more black hole servers, for example BLACKHOLE-1.IANA.ORG and 287 BLACKHOLE-2.IANA.ORG. The reason that this delegation must not be 288 signed is that not signing the delegation breaks the DNSSEC chain of 289 trust, which prevents a validating stub resolver from rejecting names 290 published under 'home.arpa' on a homenet name server. 292 8. IANA Considerations 294 IANA is requested to record the domain name '.home.arpa' in the 295 Special-Use Domain Names registry [SUDN]. 297 9. Acknowledgments 299 The authors would like to thank Stuart Cheshire for his prior work on 300 '.home', as well as the homenet chairs: Mark Townsley and Ray Bellis. 301 We would also like to thank Paul Hoffman for providing review and 302 comments on the IANA considerations section and Suzanne Woolf and Ray 303 Bellis for their detailed review comments. 305 10. References 307 10.1. Normative References 309 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 310 Requirement Levels", BCP 14, RFC 2119, 311 DOI 10.17487/RFC2119, March 1997, 312 . 314 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 315 Requirements for the Address and Routing Parameter Area 316 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 317 September 2001, . 319 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 320 RFC 6303, DOI 10.17487/RFC6303, July 2011, 321 . 323 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 324 RFC 6761, DOI 10.17487/RFC6761, February 2013, 325 . 327 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 328 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 329 May 2017, . 331 10.2. Informative References 333 [ICANN1] "New gTLD Collision Risk Mitigation", October 2013, 334 . 337 [ICANN2] "New gTLD Collision Occurence Management", October 2013, 338 . 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 [SUDN] "Special-Use Domain Names Registry", July 2012, 365 . 368 Authors' Addresses 370 Pierre Pfister 371 Cisco Systems 372 Paris 373 France 375 Email: pierre.pfister@darou.fr 376 Ted Lemon 377 Nominum, Inc. 378 800 Bridge Parkway 379 Redwood City, California 94065 380 United States of America 382 Phone: +1 650 381 6000 383 Email: ted.lemon@nominum.com