idnits 2.17.1 draft-ietf-homenet-dot-13.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 29, 2017) is 2431 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: March 2, 2018 August 29, 2017 8 Special Use Domain 'home.arpa.' 9 draft-ietf-homenet-dot-13 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 March 2, 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 . . . . . . . . . . . 4 58 5. Updates to Home Networking Control Protocol . . . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 60 6.1. Local Significance . . . . . . . . . . . . . . . . . . . 6 61 6.2. Insecure Delegation . . . . . . . . . . . . . . . . . . . 7 62 6.3. Bypassing Manually Configured Resolvers . . . . . . . . . 8 63 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 8 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 68 10.2. Informative References . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 Users and devices within a home network (hereafter "homenet") require 74 devices and services to be identified by names that are unique within 75 the boundaries of the homenet [RFC7368]. The naming mechanism needs 76 to function without configuration from the user. While it may be 77 possible for a name to be delegated by an ISP, homenets must also 78 function in the absence of such a delegation. A default name with a 79 scope limited to each individual homenet needs to be used. 81 This document corrects an error in [RFC7788], replacing '.home' with 82 'home.arpa.' as the default domain-name for homenets. '.home' had 83 been selected as the most user-friendly option. However, there are 84 existing uses of '.home' that may be in conflict with this use: 85 evidence indicates that '.home' queries frequently leak out and reach 86 the root name servers [ICANN1] [ICANN2]. 88 In addition, it's necessary, for compatibility with DNSSEC 89 (Section 6), that an insecure delegation ([RFC4035] section 4.3) be 90 present for the name. There is an existing process for allocating 91 names under '.arpa' [RFC3172]. No such process is available for 92 requesting a similar delegation in the root at the request of the 93 IETF, which does not administer that zone. As a result, the use of 94 '.home' is deprecated. 96 This document registers the domain '.home.arpa.' as a special-use 97 domain name [RFC6761] and specifies the behavior that is expected 98 from the Domain Name System with regard to DNS queries for names 99 whose rightmost non-terminal labels are 'home.arpa.'. Queries for 100 names ending with '.home.arpa.' are of local significance within the 101 scope of a homenet, meaning that identical queries will result in 102 different results from one homenet to another. In other words, a 103 name ending in 'home.arpa.' is not globally unique. 105 Although this document makes specific reference to RFC7788, it is not 106 intended that the use of 'home.arpa.' be restricted solely to 107 networks where HNCP is deployed; it is rather the case that 108 'home.arpa.' is the correct domain for uses like the one described 109 for '.home' in RFC7788: local name service in residential homenets. 111 2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 3. General Guidance 121 The domain name '.home.arpa.' is to be used for naming within 122 residential homenets. Names ending with '.home.arpa.' reference a 123 locally-served zone, the contents of which are unique only to a 124 particular homenet, and are not globally unique. Such names refer to 125 nodes and/or services that are located within a homenet (e.g., a 126 printer, or a toaster). 128 DNS queries for names ending with '.home.arpa.' are resolved using 129 local resolvers on the homenet. Such queries MUST NOT be recursively 130 forwarded to servers outside the logical boundaries of the homenet. 132 Some service discovery user interfaces that are expected to be used 133 on homenets conceal information such as domain names from end users. 134 However, it is still expected that in some cases, users will need to 135 see, remember, and even type, names ending with 'home.arpa.'. The 136 working group hopes that this name will in some way indicate to as 137 many readers as possible that such domain names are referring to 138 devices in the home, but we recognize that it is an imperfect 139 solution. 141 4. Domain Name Reservation Considerations 143 This section defines the behavior of systems involved in domain name 144 resolution when resolving queries for names ending with '.home.arpa.' 145 (as per [RFC6761]). 147 1. Users can use names ending with '.home.arpa.' just as they would 148 use any other domain name. The 'home.arpa.' name is chosen to be 149 readily recognized by users as signifying that the name is 150 addressing a service on the homenet to which the user's device is 151 connected. 153 2. Application software SHOULD NOT treat names ending in 154 'home.arpa.' differently than other names. In particular, there 155 is no basis for trusting names that are subdomains of 156 'home.arpa.' (see Section 6). 158 3. Name resolution APIs and libraries MUST NOT recognize names that 159 end in '.home.arpa.' as special and MUST NOT treat them as having 160 special significance, except that it may be necessary that such 161 APIs not bypass the locally configured recursive resolvers. 163 One or more IP addresses for recursive DNS servers will usually 164 be supplied to the client through router advertisements or DHCP. 165 For an administrative domain that uses names in 'home.arpa.', 166 such as a homenet, the recursive resolvers provided by that 167 domain will be able to answer queries for subdomains of 168 home.arpa; other resolvers will not, or will provide answers that 169 are not correct within that administrative domain. 171 A host that is configured to use a resolver other than one that 172 has been provided by the local network may be unable to resolve, 173 or may receive incorrect results for, names in sub domains of 174 'home.arpa.'. In order to avoid this, it is permissible that 175 hosts use the locally-provided resolvers for resolving 176 'home.arpa.' even when they are configured to use other 177 resolvers. 179 4. 181 A. Recursive resolvers at sites using 'home.arpa.' MUST 182 transparently support DNSSEC queries: queries for DNSSEC 183 records and queries with the DO bit set ([RFC4035] section 184 3.2.1). While validation is not required, it is strongly 185 encouraged: a caching recursive resolver that does not 186 validate answers that can be validated may cache invalid 187 data. This in turn will prevent validating stub resolvers 188 from successfully validating answers. 190 B. Unless configured otherwise, recursive resolvers and DNS 191 proxies MUST behave as described in Locally Served Zones 192 ([RFC6303] Section 3). That is, queries for domains that are 193 subdomains of 'home.arpa.' MUST NOT be forwarded, with one 194 important exception: a query for a DS record when the DO bit 195 set MUST return the correct answer for that question, 196 including correct information in the authority section that 197 proves that the record is nonexistent. 199 So for example a query for the NS record for 'home.arpa.' 200 MUST NOT result in that query being forwarded to an upstream 201 cache nor to the authoritative DNS server for '.arpa.'. 202 However, as necessary to provide accurate authority 203 information, a query for the DS record MUST result in 204 whatever queries are necessary being forwarded; typically, 205 this will just be a query for the DS record, since the 206 necessary authority information will be included in the 207 authority section of the response if the DO bit is set. 209 C. In addition to the behavior specified above, recursive 210 resolvers that can be used in a homenet MUST be configurable 211 with a delegation to an authoritative server for that 212 particular homenet's instance of the domain 'home.arpa.'. 214 It is permissible to combine the recursive resolver function 215 for general DNS lookups with an authoritative resolver for 216 'home.arpa.'; in this case, rather than forwarding queries 217 for subdomains of 'home.arpa.' to an authoritative server, 218 the caching resolver answers them authoritatively. The 219 behavior with respect to forwarding queries specifically for 220 'home.arpa.' remains the same. 222 5. No special processing of 'home.arpa.' is required for 223 authoritative DNS server implementations. It is possible that an 224 authoritative DNS server might attempt to check the authoritative 225 servers for 'home.arpa.' for a delegation beneath that name 226 before answering authoritatively for such a delegated name. In 227 such a case, because the name always has only local significance 228 there will be no such delegation in the 'home.arpa.' zone, and so 229 the server would refuse to answer authoritatively for such a 230 zone. A server that implements this sort of check MUST be 231 configurable so that either it does not do this check for the 232 'home.arpa.' domain, or it ignores the results of the check. 234 6. DNS server operators MAY configure an authoritative server for 235 'home.arpa.' for use in homenets and other home networks. The 236 operator for the DNS servers authoritative for 'home.arpa.' in 237 the global DNS will configure any such servers as described in 238 Section 7. 240 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which 241 is operated by IANA under the authority of the Internet 242 Architecture Board according to the rules established in 243 [RFC3172]. There are no other registrars for .arpa. 245 5. Updates to Home Networking Control Protocol 247 The final paragraph of Home Networking Control Protocol [RFC7788], 248 section 8, is updated as follows: 250 OLD: 252 Names and unqualified zones are used in an HNCP network to provide 253 naming and service discovery with local significance. A network- 254 wide zone is appended to all single labels or unqualified zones in 255 order to qualify them. ".home" is the default; however, an 256 administrator MAY configure the announcement of a Domain-Name TLV 257 (Section 10.6) for the network to use a different one. In case 258 multiple are announced, the domain of the node with the greatest 259 node identifier takes precedence. 261 NEW: 263 Names and unqualified zones are used in an HNCP network to provide 264 naming and service discovery with local significance. A network- 265 wide zone is appended to all single labels or unqualified zones in 266 order to qualify them. 'home.arpa.' is the default; however, an 267 administrator MAY configure the announcement of a Domain-Name TLV 268 (Section 10.6) for the network to use a different one. In case 269 multiple are announced, the domain of the node with the greatest 270 node identifier takes precedence. 272 The 'home.arpa.' special-use name does not require a special 273 resolution protocol. Names for which the rightmost two labels are 274 'home.arpa.' are resolved using the DNS protocol [RFC1035]. 276 6. Security Considerations 278 6.1. Local Significance 280 A DNS record that is returned as a response to a query for an FQDN in 281 the domain '.home.arpa.' is expected to have local significance. It 282 is expected to be returned by a server involved in name resolution 283 for the homenet the device is connected in. However, such response 284 MUST NOT be considered more trustworthy than would be a similar 285 response for any other DNS query. 287 Because 'home.arpa.' is not globally scoped and cannot be secured 288 using DNSSEC based on the root domain's trust anchor, there is no way 289 to tell, using a standard DNS query, in which homenet scope an answer 290 belongs. Consequently, users may experience surprising results with 291 such names when roaming to different homenets. To prevent this from 292 happening, it may be useful for the resolver to identify different 293 homenets on which it has resolved names, but this is out of scope for 294 this document. 296 Locally Served Zones ([RFC6303] section 7) recommends installing 297 trust anchors for locally served zones. However, in order for this 298 to be effective, there must be some way of configuring the trust 299 anchor in the host. Homenet currently specifies no mechanism for 300 configuring such trust anchors. As a result, while this advice 301 sounds good, it is not practicable. 303 Also, although in principle it might be useful to install a trust 304 anchor for a particular instance of 'home.arpa.', it's reasonable to 305 expect that a host with such a trust anchor might from time to time 306 connect to more than one network with its own instance of 307 'home.arpa.'. Such a host would be unable to access services on any 308 instance of 'home.arpa.' other than the one for which a trust anchor 309 was configured. 311 It is in principle possible to attach an identifier to an instance of 312 'home.arpa.' that could be used to identify which trust anchor to 313 rely on for validating names in that particular instance. However, 314 the security implications of this are complicated, and such a 315 mechanism, as well as a discussion of those implications, is out of 316 scope for this document. 318 6.2. Insecure Delegation 320 It is not possible to install a trust anchor (a DS RR) for this zone 321 in the '.arpa' zone. The reason for this is that in order to do so, 322 it would be necessary to have the key-signing key for the zone 323 ([RFC4034] Section 5). Since the zone is not globally unique, no one 324 key would work. 326 An alternative would be to provide a authenticated denial of 327 existence ([RFC4033] Section 3.2). This would be done simply by not 328 having a delegation from the 'arpa.' zone. However, this requires 329 the validating resolver to treat 'home.arpa.' specially. If a 330 validating resolver that doesn't treat 'home.arpa.' specially 331 attempts to validate a name in 'home.arpa.', an authenticated denial 332 of existence of 'home' as a subdomain of 'arpa.' would cause the 333 validation to fail. Therefore, the only delegation that will allow 334 names under 'home.arpa.' to be resolved by all validating resolvers 335 is an insecure delegation as in [RFC6303] section 7. 337 Consequently, unless a trust anchor for the particular instance of 338 the 'home.arpa.' zone being validated is manually configured on the 339 validating resolver, DNSSEC signing and validation of names within 340 the 'home.arpa.' zone is not possible. 342 6.3. Bypassing Manually Configured Resolvers 344 In Section 4, item 3, an exception is made to the behavior of stub 345 resolvers allowing them to query local resolvers for subdomains of 346 'home.arpa.' even when they have been manually configured to use 347 other resolvers. This behavior obviously has security and privacy 348 implications, and may not be desirable depending on the context. It 349 may be better to simply ignore this exception and, when one or more 350 recursive resolvers are configured manually, simply fail to provide 351 correct answers for subdomains of 'home.arpa.'. At this time we do 352 not have operational experience that would guide us in making this 353 decision; implementors are encouraged to consider the context in 354 which their software will be deployed when deciding how to resolve 355 this question. 357 7. Delegation of 'home.arpa.' 359 In order to be fully functional, there must be a delegation of 360 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST 361 NOT include a DS record, and MUST point to one or more black hole 362 servers, for example 'blackhole-1.iana.org.' and 'blackhole- 363 2.iana.org.'. The reason that this delegation must not be signed is 364 that not signing the delegation breaks the DNSSEC chain of trust, 365 which prevents a validating stub resolver from rejecting names 366 published under 'home.arpa.' on a homenet name server. 368 8. IANA Considerations 370 IANA is requested to record the domain name 'home.arpa.' in the 371 Special-Use Domain Names registry [SUDN]. IANA is requested, with 372 the approval of IAB, to implement the delegation requested in 373 Section 7. 375 9. Acknowledgments 377 The authors would like to thank Stuart Cheshire for his prior work on 378 '.home', as well as the homenet chairs: Mark Townsley and Ray Bellis. 379 We would also like to thank Paul Hoffman for providing review and 380 comments on the IANA considerations section, Andrew Sullivan for his 381 review and proposed text, and Suzanne Woolf and Ray Bellis for their 382 very detailed review comments and process insights. Thanks to Mark 383 Andrews for providing an exhaustive reference list on the topic of 384 insecure delegations. Thanks to Dale Worley for catching a rather 385 egregious mistake and for the Gen-Art review, and to Daniel Migault 386 for a thorough SecDir review. 388 10. References 390 10.1. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, 394 DOI 10.17487/RFC2119, March 1997, . 397 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 398 Requirements for the Address and Routing Parameter Area 399 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 400 September 2001, . 402 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 403 Rose, "Protocol Modifications for the DNS Security 404 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 405 . 407 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 408 RFC 6303, DOI 10.17487/RFC6303, July 2011, 409 . 411 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 412 RFC 6761, DOI 10.17487/RFC6761, February 2013, 413 . 415 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 416 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 417 May 2017, . 419 10.2. Informative References 421 [ICANN1] "New gTLD Collision Risk Mitigation", October 2013, 422 . 425 [ICANN2] "New gTLD Collision Occurence Management", October 2013, 426 . 429 [RFC1035] Mockapetris, P., "Domain names - implementation and 430 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 431 November 1987, . 433 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 434 Rose, "DNS Security Introduction and Requirements", 435 RFC 4033, DOI 10.17487/RFC4033, March 2005, 436 . 438 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 439 Rose, "Resource Records for the DNS Security Extensions", 440 RFC 4034, DOI 10.17487/RFC4034, March 2005, 441 . 443 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 444 Weil, "IPv6 Home Networking Architecture Principles", 445 RFC 7368, DOI 10.17487/RFC7368, October 2014, 446 . 448 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 449 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 450 2016, . 452 [SUDN] "Special-Use Domain Names Registry", July 2012, 453 . 456 Authors' Addresses 458 Pierre Pfister 459 Cisco Systems 460 Paris 461 France 463 Email: pierre.pfister@darou.fr 465 Ted Lemon 466 Nominum, Inc. 467 800 Bridge Parkway 468 Redwood City, California 94065 469 United States of America 471 Phone: +1 650 381 6000 472 Email: ted.lemon@nominum.com