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