diff options
Diffstat (limited to 'doc/rfc/rfc8375.txt')
| -rw-r--r-- | doc/rfc/rfc8375.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc8375.txt b/doc/rfc/rfc8375.txt new file mode 100644 index 0000000..120d6f3 --- /dev/null +++ b/doc/rfc/rfc8375.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Pfister +Request for Comments: 8375 Cisco Systems +Updates: 7788 T. Lemon +Category: Standards Track Nibbhaya Consulting +ISSN: 2070-1721 May 2018 + + + Special-Use Domain 'home.arpa.' + +Abstract + + This document specifies the behavior that is expected from the Domain + Name System with regard to DNS queries for names ending with + '.home.arpa.' and designates this domain as a special-use domain + name. 'home.arpa.' is designated for non-unique use in residential + home networks. The Home Networking Control Protocol (HNCP) is + updated to use the 'home.arpa.' domain instead of '.home'. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8375. + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + +Pfister & Lemon Standards Track [Page 1] + +RFC 8375 home.arpa. May 2018 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 + 3. General Guidance . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Domain Name Reservation Considerations . . . . . . . . . . . 4 + 5. Updates to Home Networking Control Protocol . . . . . . . . . 7 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 + 6.1. Local Significance . . . . . . . . . . . . . . . . . . . 7 + 6.2. Insecure Delegation . . . . . . . . . . . . . . . . . . . 8 + 6.3. Bypassing Manually Configured Resolvers . . . . . . . . . 9 + 7. Delegation of 'home.arpa.' . . . . . . . . . . . . . . . . . 9 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 9.2. Informative References . . . . . . . . . . . . . . . . . 10 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Pfister & Lemon Standards Track [Page 2] + +RFC 8375 home.arpa. May 2018 + + +1. Introduction + + Users and devices within a home network (hereafter referred to as + "homenet") require devices and services to be identified by names + that are unique within the boundaries of the homenet [RFC7368]. The + naming mechanism needs to function without configuration from the + user. While it may be possible for a name to be delegated by an ISP, + homenets must also function in the absence of such a delegation. + This document reserves the name 'home.arpa.' to serve as the default + name for this purpose, with a scope limited to each individual + homenet. + + This document corrects an error in [RFC7788] by replacing '.home' + with 'home.arpa.' as the default domain name for homenets. '.home' + was selected as the most user-friendly option; however, there are + existing uses of '.home' that may be in conflict with this use. + Evidence indicates that '.home' queries frequently leak out and reach + the root name servers [ICANN1] [ICANN2]. + + In addition, for compatibility with DNSSEC (see Section 6), it's + necessary that an insecure delegation (see Section 4.3 of [RFC4035]) + be present for the name. There is an existing process for allocating + names under '.arpa.' [RFC3172]. No such process is available for + requesting a similar delegation in the root at the request of the + IETF, which does not administer that zone. As a result, all + unregistered uses of '.home' (that is, all current uses at the time + of this document's publication), particularly as specified in + [RFC7788], are deprecated. + + This document registers the domain 'home.arpa.' as a special-use + domain name [RFC6761] and specifies the behavior that is expected + from the Domain Name System with regard to DNS queries for names + whose rightmost non-terminal labels are 'home.arpa.'. Queries for + names ending with '.home.arpa.' are of local significance within the + scope of a homenet, meaning that identical queries will result in + different results from one homenet to another. In other words, a + name ending in '.home.arpa.' is not globally unique. + + Although this document makes specific reference to [RFC7788], it is + not intended that the use of 'home.arpa.' be restricted solely to + networks where HNCP is deployed. Rather, 'home.arpa.' is intended to + be the correct domain for uses like the one described for '.home' in + [RFC7788]: local name service in residential homenets. + + + + + + + + +Pfister & Lemon Standards Track [Page 3] + +RFC 8375 home.arpa. May 2018 + + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +3. General Guidance + + The domain name 'home.arpa.' is to be used for naming within + residential homenets. Names ending with '.home.arpa.' reference a + zone that is served locally, the contents of which are unique only to + a particular homenet and are not globally unique. Such names refer + to nodes and/or services that are located within a homenet (e.g., a + printer or a toaster). + + DNS queries for names ending with '.home.arpa.' are resolved using + local resolvers on the homenet. Such queries MUST NOT be recursively + forwarded to servers outside the logical boundaries of the homenet. + + Some service discovery user interfaces that are expected to be used + on homenets conceal information such as domain names from end users. + However, in some cases, it is still expected that users will need to + see, remember, and even type names ending with '.home.arpa.'. The + Homenet Working Group hopes that this name will in some way indicate + to as many readers as possible that such domain names are referring + to devices in the home, but we recognize that it is an imperfect + solution. + +4. Domain Name Reservation Considerations + + This section specifies considerations for systems involved in domain + name resolution when resolving queries for names ending with + '.home.arpa.'. Each item in this section addresses some aspect of + the DNS or the process of resolving domain names that would be + affected by this special-use allocation. Detailed explanations of + these items can be found in Section 5 of [RFC6761]. Although the + term 'homenet' in [RFC7788] refers to home networks that implement a + particular set of features, in this document the term is used to mean + any home network, regardless of the set of features it implements. + + 1. Users can use names ending with '.home.arpa.' just as they would + use any other domain name. The 'home.arpa.' name is chosen to be + readily recognized by users as signifying that the name is + addressing a service on the homenet to which the user's device is + connected. + + + + +Pfister & Lemon Standards Track [Page 4] + +RFC 8375 home.arpa. May 2018 + + + 2. Application software SHOULD NOT treat names ending in + '.home.arpa.' differently than other names. In particular, there + is no basis for trusting names that are subdomains of + 'home.arpa.' (see Section 6). + + 3. Name resolution APIs and libraries MUST NOT recognize names that + end in '.home.arpa.' as special and MUST NOT treat them as having + special significance, except that it may be necessary that such + APIs not bypass the locally configured recursive resolvers. + + One or more IP addresses for recursive DNS servers will usually + be supplied to the client through router advertisements or DHCP. + For an administrative domain that uses subdomains of + 'home.arpa.', such as a homenet, the recursive resolvers provided + by that domain will be able to answer queries for subdomains of + 'home.arpa.'; other resolvers will not, or they will provide + answers that are not correct within that administrative domain. + + A host that is configured to use a resolver other than one that + has been provided by the local network may be unable to resolve, + or may receive incorrect results for, subdomains of 'home.arpa.'. + In order to avoid this, it is permissible that hosts use the + resolvers that are locally provided for resolving 'home.arpa.', + even when they are configured to use other resolvers. + + 4. There are three considerations for recursive resolvers that + follow this specification: + + A. Recursive resolvers at sites using 'home.arpa.' MUST + transparently support DNSSEC queries: queries for DNSSEC + records and queries with the DNSSEC OK (DO) bit set (see + Section 3.2.1 of [RFC4035]). While validation is not + required, it is strongly encouraged: a caching recursive + resolver that does not validate answers that can be validated + may cache invalid data. This, in turn, will prevent + validating stub resolvers from successfully validating + answers. + + B. Unless configured otherwise, recursive resolvers and DNS + proxies MUST behave as described in Section 3 of the Locally + Served Zones document [RFC6303]. That is, queries for + 'home.arpa.' and subdomains of 'home.arpa.' MUST NOT be + forwarded, with one important exception: a query for a DS + record with the DO bit set MUST return the correct answer for + that question, including correct information in the authority + section that proves that the record is nonexistent. + + + + + +Pfister & Lemon Standards Track [Page 5] + +RFC 8375 home.arpa. May 2018 + + + So, for example, a query for the NS record for 'home.arpa.' + MUST NOT result in that query being forwarded to an upstream + cache nor to the authoritative DNS server for '.arpa.'. + However, as necessary to provide accurate authority + information, a query for the DS record MUST result in + forwarding whatever queries are necessary; typically, this + will just be a query for the DS record, since the necessary + authority information will be included in the authority + section of the response if the DO bit is set. + + C. In addition to the behavior specified above, recursive + resolvers that can be used in a homenet MUST be configurable + to forward queries for 'home.arpa.' and subdomains of + 'home.arpa.' to an authoritative server for 'home.arpa.'. + This server will provide authoritative data for 'home.arpa.' + within a particular homenet. The special handling for DS + records for the 'home.arpa.' delegation is still required. + + It is permissible to combine the recursive resolver function + for general DNS lookups with an authoritative resolver for + 'home.arpa.'; in this case, rather than forwarding queries + for subdomains of 'home.arpa.' to an authoritative server, + the resolver answers them authoritatively. The behavior with + respect to forwarding queries specifically for 'home.arpa.' + remains the same. + + 5. No special processing of 'home.arpa.' is required for + authoritative DNS server implementations. It is possible that an + authoritative DNS server might attempt to check the authoritative + servers for 'home.arpa.' for a delegation beneath that name + before answering authoritatively for such a delegated name. In + such a case, because the name always has only local significance, + there will be no such delegation in the 'home.arpa.' zone, and so + the server would refuse to answer authoritatively for such a + zone. A server that implements this sort of check MUST be + configurable so that either it does not do this check for the + 'home.arpa.' domain or it ignores the results of the check. + + 6. DNS server operators MAY configure an authoritative server for + 'home.arpa.' for use in homenets and other home networks. The + operator for the DNS servers authoritative for 'home.arpa.' in + the global DNS will configure any such servers as described in + Section 7. + + 7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which + is operated by IANA under the authority of the Internet + Architecture Board according to the rules established in + [RFC3172]. There are no other registrars for '.arpa'. + + + +Pfister & Lemon Standards Track [Page 6] + +RFC 8375 home.arpa. May 2018 + + +5. Updates to Home Networking Control Protocol + + The final paragraph in Section 8 of [RFC7788], the Home Networking + Control Protocol, is updated as follows: + + OLD: + Names and unqualified zones are used in an HNCP network to provide + naming and service discovery with local significance. A network- + wide zone is appended to all single labels or unqualified zones in + order to qualify them. ".home" is the default; however, an + administrator MAY configure the announcement of a Domain-Name TLV + (Section 10.6) for the network to use a different one. In case + multiple are announced, the domain of the node with the greatest + node identifier takes precedence. + + NEW: + Names and unqualified zones are used in an HNCP network to provide + naming and service discovery with local significance. A network- + wide zone is appended to all single labels or unqualified zones in + order to qualify them. 'home.arpa.' is the default; however, an + administrator MAY configure the announcement of a Domain-Name TLV + (Section 10.6) for the network to use a different one. In case + multiple TLVs are announced, the domain of the node with the + greatest node identifier takes precedence. + + The 'home.arpa.' special-use name does not require a special + resolution protocol. Names for which the rightmost two labels are + 'home.arpa.' are resolved using the DNS protocol [RFC1035]. + +6. Security Considerations + +6.1. Local Significance + + A DNS record that is returned as a response to a query for a Fully + Qualified Domain Name (FQDN) that is a subdomain of 'home.arpa.' is + expected to have local significance. It is expected to be returned + by a server involved in name resolution for the homenet the device is + connected in. However, such a response MUST NOT be considered more + trustworthy than a similar response for any other DNS query. + + Because 'home.arpa.' is not globally scoped and cannot be secured + using DNSSEC based on the root domain's trust anchor, there is no way + to tell, using a standard DNS query, in which homenet scope an answer + belongs. Consequently, users may experience surprising results with + such names when roaming to different homenets. + + + + + + +Pfister & Lemon Standards Track [Page 7] + +RFC 8375 home.arpa. May 2018 + + + To prevent this from happening, it could be useful for the resolver + on the host to securely differentiate between different homenets and + between identical names on different homenets. However, a mechanism + for doing this has not yet been standardized and doing so is out of + scope for this document. It is expected that this will be explored + in future work. + + The advice in [RFC6303], Section 7, to install local trust anchors + for locally served zones can only work if there is some way of + configuring the trust anchor in the host. Homenet currently + specifies no mechanism for configuring such trust anchors. As a + result, while this advice sounds good, it is not practicable. + + Also, although it might be useful to install a trust anchor for a + particular instance of 'home.arpa.', it's reasonable to expect that a + host with such a trust anchor might, from time to time, connect to + more than one network with its own instance of 'home.arpa.'. Such a + host would be unable to access services on any instance of + 'home.arpa.' other than the one for which a trust anchor was + configured. + + It is, in principle, possible to attach an identifier to an instance + of 'home.arpa.' that could be used to identify which trust anchor to + rely on for validating names in that particular instance. However, + the security implications of this are complicated, and such a + mechanism, as well as a discussion of those implications, is out of + scope for this document. + +6.2. Insecure Delegation + + It is not possible to install a trust anchor (a DS RR) for this zone + in the '.arpa' zone. The reason for this is that in order to do so, + it would be necessary to have the key-signing key for the zone (see + Section 5 of [RFC4034]). Since the zone is not globally unique, no + one key would work. + + An alternative would be to provide an authenticated denial of + existence (see Section 3.2 of [RFC4033]). This would be done simply + by not having a delegation from the 'arpa.' zone. However, this + requires the validating resolver to treat 'home.arpa.' specially. If + a validating resolver that doesn't treat 'home.arpa.' specially + attempts to validate a name in 'home.arpa.', an authenticated denial + of existence of 'home' as a subdomain of 'arpa.' would cause the + validation to fail. Therefore, the only delegation that will allow + names under 'home.arpa.' to be resolved by all validating resolvers + is an insecure delegation, as in Section 7 of [RFC6303]. + + + + + +Pfister & Lemon Standards Track [Page 8] + +RFC 8375 home.arpa. May 2018 + + + Consequently, unless a trust anchor for the particular instance of + the 'home.arpa.' zone being validated is manually configured on the + validating resolver, DNSSEC signing and validation of names within + the 'home.arpa.' zone is not possible. + +6.3. Bypassing Manually Configured Resolvers + + In item 3 of Section 4, an exception is made to the behavior of stub + resolvers that allows them to query local resolvers for subdomains of + 'home.arpa.' even when they have been manually configured to use + other resolvers. This behavior obviously has security and privacy + implications and may not be desirable depending on the context. It + may be better to simply ignore this exception and, when one or more + recursive resolvers are configured manually, simply fail to provide + correct answers for subdomains of 'home.arpa.'. At this time, we do + not have operational experience that would guide us in making this + decision; implementors are encouraged to consider the context in + which their software will be deployed when deciding how to resolve + this question. + +7. Delegation of 'home.arpa.' + + In order to be fully functional, there must be a delegation of + 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST + NOT include a DS record and MUST point to one or more black hole + servers, for example, 'blackhole-1.iana.org.' and 'blackhole- + 2.iana.org.'. The reason that this delegation must not be signed is + that not signing the delegation breaks the DNSSEC chain of trust, + which prevents a validating stub resolver from rejecting names + published under 'home.arpa.' on a homenet name server. + +8. IANA Considerations + + IANA has recorded the domain name 'home.arpa.' in the "Special-Use + Domain Names" registry [SUDN]. IANA, with the approval of the IAB, + has implemented the delegation requested in Section 7. + + IANA has created a new subregistry within the "Locally-Served DNS + Zones" registry [LSDZ], titled "Transport-Independent Locally-Served + DNS Zone Registry", with the same format as the other subregistries. + IANA has added an entry in this new registry for 'home.arpa.' with + the description "Homenet Special-Use Domain", listing this document + as the reference. The registration procedure for this subregistry + should be the same as for the others, currently "IETF Review" (see + Section 4.8 of [RFC8126]). + + + + + + +Pfister & Lemon Standards Track [Page 9] + +RFC 8375 home.arpa. May 2018 + + +9. References + +9.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3172] Huston, G., Ed., "Management Guidelines & Operational + Requirements for the Address and Routing Parameter Area + Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, + September 2001, <https://www.rfc-editor.org/info/rfc3172>. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, + <https://www.rfc-editor.org/info/rfc4035>. + + [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, + RFC 6303, DOI 10.17487/RFC6303, July 2011, + <https://www.rfc-editor.org/info/rfc6303>. + + [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", + RFC 6761, DOI 10.17487/RFC6761, February 2013, + <https://www.rfc-editor.org/info/rfc6761>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +9.2. Informative References + + [ICANN1] "New gTLD Collision Risk Mitigation", August 2013, + <https://www.icann.org/en/system/files/files/ + new-gtld-collision-mitigation-05aug13-en.pdf>. + + [ICANN2] "New gTLD Collision Occurence Management", October 2013, + <https://www.icann.org/en/system/files/files/ + resolutions-new-gtld-annex-1-07oct13-en.pdf>. + + [LSDZ] "Locally-Served DNS Zones", July 2011, + <https://www.iana.org/assignments/ + locally-served-dns-zones/>. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, + November 1987, <https://www.rfc-editor.org/info/rfc1035>. + + + +Pfister & Lemon Standards Track [Page 10] + +RFC 8375 home.arpa. May 2018 + + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, DOI 10.17487/RFC4033, March 2005, + <https://www.rfc-editor.org/info/rfc4033>. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", + RFC 4034, DOI 10.17487/RFC4034, March 2005, + <https://www.rfc-editor.org/info/rfc4034>. + + [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. + Weil, "IPv6 Home Networking Architecture Principles", + RFC 7368, DOI 10.17487/RFC7368, October 2014, + <https://www.rfc-editor.org/info/rfc7368>. + + [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking + Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April + 2016, <https://www.rfc-editor.org/info/rfc7788>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [SUDN] "Special-Use Domain Names", July 2012, + <https://www.iana.org/assignments/ + special-use-domain-names/>. + + + + + + + + + + + + + + + + + + + + + + + + +Pfister & Lemon Standards Track [Page 11] + +RFC 8375 home.arpa. May 2018 + + +Acknowledgments + + The authors would like to thank Stuart Cheshire, as well as the + homenet chairs, Mark Townsley and Ray Bellis, for their prior work on + '.home'. We would also like to thank Paul Hoffman for providing + review and comments on the IANA Considerations section, Andrew + Sullivan for his review and proposed text, and Suzanne Woolf and Ray + Bellis for their very detailed review comments and process insights. + Thanks to Mark Andrews for providing an exhaustive reference list on + the topic of insecure delegations. Thanks to Dale Worley for + catching a rather egregious mistake and for the Gen-Art review, and + thanks to Daniel Migault for a thorough SecDir review. Thanks to + Warren Kumari for catching some additional issues and to Adam Roach + for some helpful clarifications. + +Authors' Addresses + + Pierre Pfister + Cisco Systems + Paris + France + + Email: pierre.pfister@darou.fr + + + Ted Lemon + Nibbhaya Consulting + P.O. Box 958 + Brattleboro, Vermont 05301-0958 + United States of America + + Email: mellon@fugue.com + + + + + + + + + + + + + + + + + + + +Pfister & Lemon Standards Track [Page 12] + |