idnits 2.17.1 draft-ietf-homenet-dot-05.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 108: '...t. Such queries MUST NOT be recursive...' RFC 2119 keyword, line 133: '...2. Applications SHOULD treat domain n...' RFC 2119 keyword, line 134: '... other FQDN, and MUST NOT make any ass...' RFC 2119 keyword, line 137: '...Is and libraries MUST NOT recognize na...' RFC 2119 keyword, line 138: '...a.' as special and MUST NOT treat them...' (8 more instances...) == 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 (April 20, 2017) is 2555 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: 1 error (**), 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: October 22, 2017 April 20, 2017 8 Special Use Domain '.home.arpa' 9 draft-ietf-homenet-dot-05 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. The '.home.arpa' domain replaces '.home' as the default domain 17 used by the Home Networking Control Protocol (HNCP). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 22, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. General Guidance . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Domain Name Reservation Considerations . . . . . . . . . . . 3 56 4. Updates to Home Networking Control Protocol . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 6. Delegation of 'home.arpa' . . . . . . . . . . . . . . . . . . 5 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 9.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Users and devices within a home network require devices and services 69 to be identified by names that are unique within the boundaries of 70 the home network [RFC7368]. The naming mechanism needs to function 71 without configuration from the user. While it may be possible for a 72 name to be delegated by an ISP, home networks must also function in 73 the absence of such a delegation. A default name with a scope 74 limited to each individual home network needs to be used. 76 The '.home.arpa' domain replaces '.home' which was specified in 77 [RFC7788] as the default domain-name for home networks. '.home' had 78 been selected as the most user-friendly option. However, there are 79 existing uses of '.home' that may be in conflict with this use: 80 evidence indicates that '.home' queries frequently leak out and reach 81 the root name servers [ICANN1] [ICANN2]. Also, ICANN has about a 82 dozen applicants for the '.home' top-level domain name, which creates 83 a significant risk of litigation if it were claimed by the IETF 84 outside of that process. As a result, the use of '.home' has been 85 deprecated; this document updates [RFC7788] to replace '.home' with 86 '.home.arpa', while another document, [I-D.ietf-homenet-redact] 87 deprecates the use of the '.home' TLD. 89 This document registers the domain '.home.arpa.' as a special-use 90 domain name [RFC6761] and specifies the behavior that is expected 91 from the Domain Name System with regard to DNS queries for names 92 whose rightmost non-terminal label is 'homenet'. Queries for names 93 ending with '.home.arpa.' are of local significance within the scope 94 of a home network, meaning that identical queries will result in 95 different results from one home network to another. In other words, 96 a name ending in '.home.arpa' is not globally unique. 98 2. General Guidance 100 The domain name '.home.arpa.' is to be used for naming within a home 101 network. Names ending with '.home.arpa.' reference a locally-served 102 zone, the contents of which are unique only to a particular home 103 network, and are not globally unique. Such names refer to nodes and/ 104 or services that are located within a home network (e.g., a printer, 105 or a toaster). 107 DNS queries for names ending with '.home.arpa.' are resolved using 108 local resolvers on the homenet. Such queries MUST NOT be recursively 109 forwarded to servers outside the logical boundaries of the home 110 network. 112 Some service discovery user interfaces that are expected to be used 113 on homenets conceal information such as domain names from end users. 114 However, it is still expected that in some cases, users will need to 115 see, remember, and even type, names ending with '.home.arpa'. It is 116 therefore desirable that users identify the domain and understand 117 that using it expresses the intention to connect to a service that is 118 specific to the home network to which they are connected. Enforcing 119 the fulfillment of this intention is out of scope for this document. 121 3. Domain Name Reservation Considerations 123 This section defines the behavior of systems involved in domain name 124 resolution when serving queries for names ending with '.home.arpa.' 125 (as per [RFC6761]). 127 1. Users can use names ending with '.home.arpa.' just as they would 128 use any other domain name. The '.home.arpa' name is chosen to be 129 readily recognized by users as signifying that the name is 130 addressing a service on the homenet to which the user's device is 131 connected. 133 2. Applications SHOULD treat domain names ending with '.home.arpa.' 134 just like any other FQDN, and MUST NOT make any assumption on the 135 level of additional security implied by its presence. 137 3. Name resolution APIs and libraries MUST NOT recognize names that 138 end in '.home.arpa.' as special and MUST NOT treat them 139 differently. Name resolution APIs MUST send queries for such 140 names to a recursive DNS server that is configured to be 141 authoritative for the .home.arpa zone appropriate to the home 142 network. One or more IP addresses for recursive DNS servers will 143 usually be supplied to the client through router advertisements 144 or DHCP. If a host is configured to use a resolver other than 145 one that is authoritative for the appropriate .home.arpa zone, 146 the client may be unable to resolve, or may receive incorrect 147 results for, names in sub domains of ".home.arpa". 149 4. Unless configured otherwise, recursive resolvers and DNS proxies 150 MUST behave as described in Locally Served Zones ([RFC6303] 151 Section 3). Recursive resolvers that are part of a home network 152 MAY be configured manually or automatically (e.g., for auto- 153 configuration purposes) to act differently, e.g., by querying 154 another name server configured as authoritative for part or all 155 of the '.home.arpa' domain, or proxying the request through a 156 different mechanism. 158 5. Only a DNS server that is authoritative for the '.arpa' zone or 159 is configured to be authoritative for '.home.arpa' or a subdomain 160 of '.home.arpa' will ever answer a query about '.home.arpa.' In 161 both of these cases, the server should simply answer as 162 configured: no special handling is required. 164 6. DNS servers outside a home network should not be configured to be 165 authoritative for .home.arpa. 167 7. 'home.arpa' is a subdomain of the 'arpa' top-level domain, which 168 is entirely operated by the Internet Architecture Board. As 169 such, no new advice for registrars is required here. 171 4. Updates to Home Networking Control Protocol 173 The final paragraph of Homenet Considerations Protocol [RFC7788], 174 section 8, is updated as follows: 176 OLD: 178 Names and unqualified zones are used in an HNCP network to provide 179 naming and service discovery with local significance. A network- 180 wide zone is appended to all single labels or unqualified zones in 181 order to qualify them. ".home" is the default; however, an 182 administrator MAY configure the announcement of a Domain-Name TLV 183 (Section 10.6) for the network to use a different one. In case 184 multiple are announced, the domain of the node with the greatest 185 node identifier takes precedence. 187 NEW: 189 Names and unqualified zones are used in an HNCP network to provide 190 naming and service discovery with local significance. A network- 191 wide zone is appended to all single labels or unqualified zones in 192 order to qualify them. ".home.arpa" is the default; however, an 193 administrator MAY configure the announcement of a Domain-Name TLV 194 (Section 10.6) for the network to use a different one. In case 195 multiple are announced, the domain of the node with the greatest 196 node identifier takes precedence. 198 The '.home.arpa' special-use name does not require a special 199 resolution protocol. Names for which the rightmost non-terminal 200 label is 'homenet' are resolved using the DNS protocol [RFC1035]. 202 5. Security Considerations 204 A DNS record that is returned as a response to a query ending with 205 '.home.arpa.' is expected to have local significance. It is expected 206 to be returned by a server involved in name resolution for the home 207 network the device is connected in. However, such response MUST NOT 208 be considered more trustworthy than would be a similar response for 209 any other DNS query. 211 Because '.home.arpa' is not globally scoped and cannot be secured 212 using DNSSEC based on the root domain's trust anchor, there is no way 213 to tell, using a standard DNS query, in which home network scope an 214 answer belongs. Consequently, users may experience surprising 215 results with such names when roaming to different home networks. To 216 prevent this from happening, it may be useful for the resolver to 217 identify different home networks on which it has resolved names, but 218 this is out of scope for this document. 220 In order to enable DNSSEC validation of a particular '.home.arpa', it 221 might make sense to configure a trust anchor for that homenet. How 222 this might be done is out of scope for this document. 224 6. Delegation of 'home.arpa' 226 In order to be fully functional, there must be a delegation of 227 'home.arpa' in the '.arpa' zone. This delegation MUST NOT be signed, 228 MUST NOT include a DS record, and MUST point to one or more black 229 hole servers, for example BLACKHOLE-1.IANA.ORG and BLACKHOLE- 230 2.IANA.ORG. The reason that this delegation must not be signed is 231 that not signing the delegation breaks the DNSSEC chain of trust, 232 which prevents a validating stub resolver from rejecting names 233 published under 'home.arpa' on a homenet name server. 235 7. IANA Considerations 237 IANA is requested to record the domain name ".home.arpa" in the 238 Special-Use Domain Names registry [SUDN]. 240 8. Acknowledgments 242 The authors would like to thank Stuart Cheshire for his prior work on 243 '.home', as well as the homenet chairs: Mark Townsley and Ray Bellis. 244 We would also like to thank Paul Hoffman for providing review and 245 comments on the IANA considerations section. 247 9. References 249 9.1. Normative References 251 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 252 RFC 6303, DOI 10.17487/RFC6303, July 2011, 253 . 255 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 256 RFC 6761, DOI 10.17487/RFC6761, February 2013, 257 . 259 [I-D.ietf-homenet-redact] 260 Lemon, T., "Redacting .home from HNCP", draft-ietf- 261 homenet-redact-03 (work in progress), March 2017. 263 9.2. Informative References 265 [RFC1035] Mockapetris, P., "Domain names - implementation and 266 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 267 November 1987, . 269 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 270 Weil, "IPv6 Home Networking Architecture Principles", 271 RFC 7368, DOI 10.17487/RFC7368, October 2014, 272 . 274 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 275 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 276 2016, . 278 [ICANN1] "New gTLD Collision Risk Mitigation", October 2013, 279 . 282 [ICANN2] "New gTLD Collision Occurence Management", October 2013, 283 . 286 [SUDN] "Special-Use Domain Names Registry", July 2012, 287 . 290 Authors' Addresses 292 Pierre Pfister 293 Cisco Systems 294 Paris 295 France 297 Email: pierre.pfister@darou.fr 299 Ted Lemon 300 Nominum, Inc. 301 800 Bridge Parkway 302 Redwood City, California 94065 303 United States of America 305 Phone: +1 650 381 6000 306 Email: ted.lemon@nominum.com