idnits 2.17.1 draft-ietf-homenet-dot-12.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 10, 2017) is 2444 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 11, 2018 August 10, 2017 8 Special Use Domain 'home.arpa.' 9 draft-ietf-homenet-dot-12 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 11, 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 . . . . . . . . . . . . . . . . . . . 6 60 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 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. Caching resolvers conforming to this specification MUST support 168 DNSSEC queries. While validation is not required, it is strongly 169 encouraged; a caching resolver that does not validate answers 170 that can be validated may cache invalid data; this will prevent 171 validating stub resolvers from successfully validating answers. 173 Unless configured otherwise, recursive resolvers and DNS proxies 174 MUST behave as described in Locally Served Zones ([RFC6303] 175 Section 3). That is, queries for domains that are subdomains of 176 'home.arpa.' MUST NOT be forwarded, with one important 177 exception: a query for a DS record when the DO bit ([RFC4035] 178 section 3.2.1) set MUST return the correct answer for that 179 question, including correct information in the authority section 180 that proves that the record is nonexistent. 182 So for example a query for the NS record for 'home.arpa.' MUST 183 NOT result in that query being forwarded to an upstream cache nor 184 to the authoritative DNS server for '.arpa.'. However, as 185 necessary to provide accurate authority information, a query for 186 the DS record MUST result in whatever queries are necessary being 187 forwarded; typically, this will just be a query for the DS 188 record, since the necessary authority information will be 189 included in the authority section of the response if the DO bit 190 is set. 192 In addition to the behavior specified above, recursive resolvers 193 that can be used in a homenet MUST be configurable with a 194 delegation to an authoritative server for that particular 195 homenet's instance of the domain 'home.arpa.'. 197 It is permissible to combine the recursive resolver function for 198 general DNS lookups with an authoritative resolver for 199 'home.arpa.'; in this case, rather than forwarding queries for 200 subdomains of 'home.arpa.' to an authoritative server, the 201 caching resolver answers them authoritatively. The behavior with 202 respect to forwarding queries specifically for 'home.arpa.' 203 remains the same. 205 5. No special processing of 'home.arpa.' is required for 206 authoritative DNS server implementations. It is possible that an 207 authoritative DNS server might attempt to check the authoritative 208 servers for 'home.arpa.' for a delegation beneath that name 209 before answering authoritatively for such a delegated name. In 210 such a case, because the name always has only local significance 211 there will be no such delegation in the 'home.arpa.' zone, and so 212 the server would refuse to answer authoritatively for such a 213 zone. A server that implements this sort of check MUST be 214 configurable so that either it does not do this check for the 215 'home.arpa.' domain, or it ignores the results of the check. 217 6. DNS server operators MAY configure an authoritative server for 218 'home.arpa.' for use in homenets and other home networks. The 219 operator for the DNS servers authoritative for 'home.arpa.' in 220 the global DNS will configure any such servers as described in 221 Section 7. 223 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which 224 is operated by IANA under the authority of the Internet 225 Architecture Board according to the rules established in 226 [RFC3172]. There are no other registrars for .arpa. 228 5. Updates to Home Networking Control Protocol 230 The final paragraph of Home Networking Control Protocol [RFC7788], 231 section 8, is updated as follows: 233 OLD: 235 Names and unqualified zones are used in an HNCP network to provide 236 naming and service discovery with local significance. A network- 237 wide zone is appended to all single labels or unqualified zones in 238 order to qualify them. ".home" is the default; however, an 239 administrator MAY configure the announcement of a Domain-Name TLV 240 (Section 10.6) for the network to use a different one. In case 241 multiple are announced, the domain of the node with the greatest 242 node identifier takes precedence. 244 NEW: 246 Names and unqualified zones are used in an HNCP network to provide 247 naming and service discovery with local significance. A network- 248 wide zone is appended to all single labels or unqualified zones in 249 order to qualify them. 'home.arpa.' is the default; however, an 250 administrator MAY configure the announcement of a Domain-Name TLV 251 (Section 10.6) for the network to use a different one. In case 252 multiple are announced, the domain of the node with the greatest 253 node identifier takes precedence. 255 The 'home.arpa.' special-use name does not require a special 256 resolution protocol. Names for which the rightmost two labels are 257 'home.arpa.' are resolved using the DNS protocol [RFC1035]. 259 6. Security Considerations 261 A DNS record that is returned as a response to a query for an FQDN in 262 the domain '.home.arpa.' is expected to have local significance. It 263 is expected to be returned by a server involved in name resolution 264 for the homenet the device is connected in. However, such response 265 MUST NOT be considered more trustworthy than would be a similar 266 response for any other DNS query. 268 Because 'home.arpa.' is not globally scoped and cannot be secured 269 using DNSSEC based on the root domain's trust anchor, there is no way 270 to tell, using a standard DNS query, in which homenet scope an answer 271 belongs. Consequently, users may experience surprising results with 272 such names when roaming to different homenets. To prevent this from 273 happening, it may be useful for the resolver to identify different 274 homenets on which it has resolved names, but this is out of scope for 275 this document. 277 It is not possible to install a trust anchor for this zone in the 278 '.arpa' zone. The reason for this is that in order to do so, it 279 would be necessary to have the key-signing key for the zone 280 ([RFC4034] Section 5). Since the zone is not globally unique, no one 281 key would work. 283 An alternative would be to install a authenticated denial of 284 existence ([RFC4033] Section 3.2). However, this assumes that 285 validation is being done on a caching resolver that is aware of the 286 special local meaning of 'home.arpa.'. If a host stub resolver 287 attempts to validate a name in 'home.arpa.', an authenticated denial 288 of existence of 'home' as a subdomain of 'arpa.' would cause the 289 validation to fail. Therefore, the only delegation that will allow 290 names under 'home.arpa.' to be resolved is an insecure delegation, as 291 in [RFC6303] section 7. 293 Consequently, unless a trust anchor for the particular instance of 294 the 'home.arpa.' zone being validated is manually configured on the 295 validating resolver, DNSSEC signing of names within the 'home.arpa.' 296 zone is not possible. 298 Although in principle it might be useful to install a trust anchor 299 for a particular instance of 'home.arpa.', it's reasonable to expect 300 that a host with such a trust anchor might from time to time connect 301 to more than one network with its own instance of 'home.arpa.'. Such 302 a host would be unable to access services on any instance of 303 'home.arpa.' other than the one for which a trust anchor was 304 configured. 306 It is in principle possible to attach an identifier to an instance of 307 'home.arpa.' that could be used to identify which trust anchor to 308 rely on for validating names in that particular instance. However, 309 the security implications of this are complicated, and such a 310 mechanism, as well as a discussion of those implications, is out of 311 scope for this document. 313 7. Delegation of 'home.arpa.' 315 In order to be fully functional, there must be a delegation of 316 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST 317 NOT include a DS record, and MUST point to one or more black hole 318 servers, for example 'blackhole-1.iana.org.' and 'blackhole- 319 2.iana.org.'. The reason that this delegation must not be signed is 320 that not signing the delegation breaks the DNSSEC chain of trust, 321 which prevents a validating stub resolver from rejecting names 322 published under 'home.arpa.' on a homenet name server. 324 8. IANA Considerations 326 IANA is requested to record the domain name 'home.arpa.' in the 327 Special-Use Domain Names registry [SUDN]. IANA is requested, with 328 the approval of IAB, to implement the delegation requested in 329 Section 7. 331 9. Acknowledgments 333 The authors would like to thank Stuart Cheshire for his prior work on 334 '.home', as well as the homenet chairs: Mark Townsley and Ray Bellis. 335 We would also like to thank Paul Hoffman for providing review and 336 comments on the IANA considerations section, Andrew Sullivan for his 337 review and proposed text, and Suzanne Woolf and Ray Bellis for their 338 very detailed review comments and process insights. Thanks to Mark 339 Andrews for providing an exhaustive reference list on the topic of 340 insecure delegations. 342 10. References 344 10.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, 348 DOI 10.17487/RFC2119, March 1997, 349 . 351 [RFC3172] Huston, G., Ed., "Management Guidelines & Operational 352 Requirements for the Address and Routing Parameter Area 353 Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, 354 September 2001, . 356 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 357 Rose, "Protocol Modifications for the DNS Security 358 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 359 . 361 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 362 RFC 6303, DOI 10.17487/RFC6303, July 2011, 363 . 365 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 366 RFC 6761, DOI 10.17487/RFC6761, February 2013, 367 . 369 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 370 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 371 May 2017, . 373 10.2. Informative References 375 [ICANN1] "New gTLD Collision Risk Mitigation", October 2013, 376 . 379 [ICANN2] "New gTLD Collision Occurence Management", October 2013, 380 . 383 [RFC1035] Mockapetris, P., "Domain names - implementation and 384 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 385 November 1987, . 387 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 388 Rose, "DNS Security Introduction and Requirements", 389 RFC 4033, DOI 10.17487/RFC4033, March 2005, 390 . 392 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 393 Rose, "Resource Records for the DNS Security Extensions", 394 RFC 4034, DOI 10.17487/RFC4034, March 2005, 395 . 397 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 398 Weil, "IPv6 Home Networking Architecture Principles", 399 RFC 7368, DOI 10.17487/RFC7368, October 2014, 400 . 402 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 403 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 404 2016, . 406 [SUDN] "Special-Use Domain Names Registry", July 2012, 407 . 410 Authors' Addresses 412 Pierre Pfister 413 Cisco Systems 414 Paris 415 France 417 Email: pierre.pfister@darou.fr 419 Ted Lemon 420 Nominum, Inc. 421 800 Bridge Parkway 422 Redwood City, California 94065 423 United States of America 425 Phone: +1 650 381 6000 426 Email: ted.lemon@nominum.com