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
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.'
特殊用途域“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'.
此文档指定域名系统在DNS查询以“.home.arpa.”结尾的名称时预期的行为，并将此域指定为特殊用途域名“home.arpa.”指定用于住宅家庭网络中的非唯一用途。家庭网络控制协议（HNCP）更新为使用“Home.arpa.”域而不是“.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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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.
家庭网络（以下简称“家庭网络”）中的用户和设备要求设备和服务在家庭网络的边界内以唯一的名称进行标识[RFC7368]。命名机制需要在没有用户配置的情况下运行。虽然ISP可能会委派一个名称，但家庭网络也必须在没有这种委派的情况下发挥作用。本文档保留名称“home.arpa.”作为此用途的默认名称，其范围仅限于每个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].
本文档更正了[RFC7788]中的一个错误，将“.home”替换为“home.arpa.”作为homenets的默认域名。“家”被选为最方便用户的选项；但是，.home的现有用法可能与此用法冲突。有证据表明，.home查询经常泄漏并到达根名称服务器[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.
此外，为了与DNSSEC兼容（见第6节），有必要为名称提供不安全的委托（见[RFC4035]第4.3节）。在“.arpa.”[RFC3172]下存在分配名称的现有进程。在IETF的请求下，没有这样的过程可用于请求根目录中的类似委托，IETF不管理该区域。因此，'.home'的所有未注册使用（即本文档发布时的所有当前使用），特别是[RFC7788]中规定的使用，都不推荐使用。
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.
本文档将域“home.arpa.”注册为特殊用途域名[RFC6761]，并指定域名系统在DNS查询最右边的非终端标签为“home.arpa”的名称时预期的行为。对以“.home.arpa.”结尾的名称的查询在homenet的范围内具有本地意义，这意味着相同的查询将导致从一个homenet到另一个homenet的不同结果。换句话说，以“.home.arpa.”结尾的名称不是全局唯一的。
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.
尽管本文件特别提及[RFC7788]，但并不打算将“home.arpa.”的使用仅限于部署HNCP的网络。相反，“home.arpa.”是一个正确的域，用于[RFC7788]：住宅家庭网络中的本地名称服务中描述的“.home”的用途。
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.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
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).
域名“home.arpa.”将用于住宅家庭网络中的命名。以“.home.arpa.”结尾的名称引用本地提供服务的区域，该区域的内容仅对特定homenet是唯一的，并且不是全局唯一的。此类名称指的是位于家庭网络（例如打印机或烤面包机）内的节点和/或服务。
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.
对以“.home.arpa.”结尾的名称的DNS查询使用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.
某些预期在家庭网络上使用的服务发现用户界面向最终用户隐藏了域名等信息。但是，在某些情况下，用户仍然需要看到、记住甚至键入以“.home.arpa”结尾的名称。Homenet工作组希望这个名称能在某种程度上向尽可能多的读者表明，这样的域名指的是家庭中的设备，但我们承认这是一个不完美的解决方案。
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.
本节指定在解析以“.home.arpa”结尾的名称的查询时，涉及域名解析的系统的注意事项。本节中的每一项都涉及DNS的某些方面或解析域名的过程，这些方面将受到此特殊用途分配的影响。这些项目的详细说明见[RFC6761]第5节。尽管[RFC7788]中的术语“家庭网络”指的是实现一组特定功能的家庭网络，但在本文档中，该术语指的是任何家庭网络，无论其实现的功能是什么。
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.
1. 用户可以使用以“.home.arpa.”结尾的名称，就像使用任何其他域名一样。“home.arpa.”名称的选择应便于用户识别，以表示该名称正在为用户设备所连接的家庭网络上的服务寻址。
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).
2. 应用软件不应将以“.home.arpa.”结尾的名称与其他名称区别对待。特别是，不存在信任作为“home.arpa”子域的名称的基础（参见第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.
3. 名称解析API和库不能将以“.home.arpa.”结尾的名称识别为特殊名称，也不能将其视为具有特殊意义，除非此类API可能需要绕过本地配置的递归解析程序。
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.
递归DNS服务器的一个或多个IP地址通常通过路由器广告或DHCP提供给客户端。对于使用“home.arpa”子域的管理域，如homenet，该域提供的递归解析程序将能够回答对“home.arpa”子域的查询；其他冲突解决程序不会，或者他们将提供在该管理域内不正确的答案。
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.
配置为使用本地网络提供的解析程序以外的解析程序的主机可能无法解析“home.arpa”的子域，或者可能收到不正确的结果。为了避免这种情况，允许主机使用本地提供的用于解析“home.arpa”的解析程序，即使它们配置为使用其他解析程序。
4. There are three considerations for recursive resolvers that follow this specification:
4. 遵循此规范的递归解析器有三个注意事项：
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.
A.使用“home.arpa.”的站点上的递归解析器必须透明地支持DNSSEC查询：查询DNSSEC记录和使用DNSSEC OK（DO）位集的查询（见[RFC4035]第3.2.1节）。虽然不需要验证，但强烈建议：不验证可验证答案的缓存递归解析器可能会缓存无效数据。这反过来会阻止验证存根解析程序成功验证答案。
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.
B.除非另有配置，否则递归解析程序和DNS代理必须按照本地服务区域文件[RFC6303]第3节中的描述进行操作。也就是说，对“home.arpa.”和“home.arpa.”子域的查询不能转发，但有一个重要的例外：对设置了DO位的DS记录的查询必须返回该问题的正确答案，包括权限部分中证明该记录不存在的正确信息。
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.
因此，例如，对“home.arpa.”的NS记录的查询不得导致该查询被转发到上游缓存或“.arpa.”的权威DNS服务器。但是，为了提供准确的权威信息，对DS记录的查询必须导致转发任何必要的查询；通常，这只是对DS记录的查询，因为如果设置了DO位，则响应的权限部分将包括必要的权限信息。
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.
C.除了上面指定的行为外，可以在家庭网络中使用的递归解析器必须可配置为将“home.arpa.”和“home.arpa.”子域的查询转发到“home.arpa.”的权威服务器。此服务器将为特定homenet中的“home.arpa.”提供权威数据。仍然需要对“home.arpa.”委托的DS记录进行特殊处理。
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.
允许将用于一般DNS查找的递归解析器功能与用于“home.arpa”的权威解析器结合使用；在这种情况下，解析程序不是将“home.arpa.”子域的查询转发到权威服务器，而是权威地回答这些查询。专门为“home.arpa.”转发查询的行为保持不变。
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.
5. 权威DNS服务器实施不需要对“home.arpa.”进行特殊处理。权威DNS服务器可能会在以权威方式回答此类委托名称之前，尝试检查权威服务器的“home.arpa.”是否存在该名称下的委托。在这种情况下，由于名称始终仅具有本地意义，因此“home.arpa.”区域中不会有此类委派，因此服务器将拒绝对此类区域进行授权应答。实现此类检查的服务器必须是可配置的，以便它不会对“home.arpa.”域执行此检查，或者忽略检查结果。
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.
6. DNS服务器运营商可以为“home.arpa.”配置权威服务器，以便在家庭网络和其他家庭网络中使用。全球DNS中授权为“home.arpa.”的DNS服务器的运营商将按照第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'.
7. “home.arpa.”是“arpa”顶级域的子域，由IANA根据[RFC3172]中制定的规则在互联网体系结构委员会的授权下运营。“.arpa”没有其他注册器。
The final paragraph in Section 8 of [RFC7788], the Home Networking Control Protocol, is updated as follows:
[RFC7788]第8节（家庭网络控制协议）的最后一段更新如下：
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.
旧：HNCP网络中使用名称和非限定区域，以提供具有本地意义的命名和服务发现。网络范围的区域附加到所有单个标签或不合格区域，以便对其进行限定。默认为“.home”；但是，管理员可以将网络的域名TLV公告（第10.6节）配置为使用不同的域名TLV。如果宣布了多个，则具有最大节点标识符的节点的域优先。
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.
新增：HNCP网络中使用名称和非限定区域，以提供具有本地意义的命名和服务发现。网络范围的区域附加到所有单个标签或不合格区域，以便对其进行鉴定。”默认为home.arpa；但是，管理员可以将网络的域名TLV公告（第10.6节）配置为使用不同的域名TLV。在宣布多个TLV的情况下，具有最大节点标识符的节点的域优先。
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].
“home.arpa.”特殊使用名称不需要特殊解析协议。使用DNS协议[RFC1035]解析最右边两个标签为“home.arpa”的名称。
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.
作为对作为“home.arpa.”子域的完全限定域名（FQDN）查询的响应而返回的DNS记录应具有本地意义。它应该由参与设备所连接的家庭网络的名称解析的服务器返回。但是，对于任何其他DNS查询，此类响应不得被视为比类似响应更可信。
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.
由于“home.arpa.”不是全局作用域，并且无法使用基于根域的信任锚的DNSSEC进行安全保护，因此无法使用标准DNS查询确定答案属于哪个homenet作用域。因此，当漫游到不同的家庭网络时，用户可能会体验到使用这些名称的惊人结果。
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.
[RFC6303]第7节中关于为本地服务区域安装本地信任锚的建议只有在主机中有某种方式配置信任锚的情况下才能起作用。Homenet当前未指定配置此类信任锚的机制。因此，尽管这一建议听起来不错，但并不可行。
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.
此外，尽管为“home.arpa”的特定实例安装信任锚可能很有用，但可以合理地预期，具有此类信任锚的主机可能会不时使用其自己的“home.arpa”实例连接到多个网络。这样的主机将无法访问“home.arpa.”的任何实例上的服务，但配置了信任锚的实例除外。
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.
原则上，可以将标识符附加到“home.arpa”的实例上。该标识符可用于标识验证该特定实例中的名称所依赖的信任锚。然而，这涉及的安全问题是复杂的，这种机制以及对这些问题的讨论超出了本文件的范围。
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.
无法在“.arpa”区域中为此区域安装信任锚（DS RR）。这样做的原因是，为了做到这一点，有必要为区域提供密钥签名密钥（见[RFC4034]第5节）。由于分区不是全局唯一的，因此任何一个键都不起作用。
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].
另一种方法是提供经验证的拒绝存在（见[RFC4033]第3.2节）。这可以通过没有来自“arpa.”区域的授权来实现。但是，这需要验证解析器专门处理“home.arpa.”。如果不处理“home.arpa.”的验证解析程序特别尝试验证“home.arpa.”中的名称，则经过身份验证的拒绝将“home”作为“arpa.”的子域存在将导致验证失败。因此，唯一允许所有验证解析程序解析“home.arpa.”下名称的委托是不安全的委托，如[RFC6303]第7节所述。
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.
因此，除非正在验证的“home.arpa.”区域的特定实例的信任锚在验证解析程序上手动配置，否则无法对“home.arpa.”区域内的名称进行DNSSEC签名和验证。
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.
在第4节的第3项中，存根解析程序的行为有一个例外，允许它们查询“home.arpa”子域的本地解析程序，即使它们已手动配置为使用其他解析程序。这种行为显然有安全和隐私方面的影响，根据上下文的不同，可能不可取。最好忽略此异常，并且在手动配置一个或多个递归解析器时，无法为“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.
为了充分发挥功能，“.arpa.”区域[RFC3172]中必须有“home.arpa.”的委托。此委派不得包含DS记录，并且必须指向一个或多个黑洞服务器，例如“blackhole-1.iana.org.”和“blackhole-2.iana.org.”。不得对此委派进行签名的原因是，不对委派进行签名会破坏DNSSEC信任链，从而阻止验证存根解析器拒绝在homenet名称服务器上的“home.arpa.”下发布的名称。
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已将域名“home.arpa.”记录在“特殊用途域名”注册表[SUDN]中。IANA在IAB的批准下，实施了第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]).
IANA在“本地服务DNS区域”注册中心[LSDZ]内创建了一个新的子区域，名为“独立于传输的本地服务DNS区域注册中心”，其格式与其他子区域相同。IANA在这个新的注册表中为“home.arpa.”添加了一个条目，其描述为“Homenet特殊用途域”，将此文档列为参考。该分区域的注册程序应与其他分区域的注册程序相同，目前为“IETF审查”（见[RFC8126]第4.8节）。
[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>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<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>.
[RFC3172]Huston，G.，Ed.“地址和路由参数区域域（“arpa”）的管理指南和操作要求”，BCP 52，RFC 3172，DOI 10.17487/RFC3172，2001年9月<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>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<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>.
[RFC6303]Andrews，M.，“本地服务DNS区域”，BCP 163，RFC 6303，DOI 10.17487/RFC6303，2011年7月<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>.
[RFC6761]Cheshire，S.和M.Krochmal，“特殊用途域名”，RFC 6761，DOI 10.17487/RFC6761，2013年2月<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>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[ICANN1] "New gTLD Collision Risk Mitigation", August 2013, <https://www.icann.org/en/system/files/files/ new-gtld-collision-mitigation-05aug13-en.pdf>.
[ICANN1]“新gTLD碰撞风险缓解”，2013年8月<https://www.icann.org/en/system/files/files/ new-gtld-collision-Milization-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>.
[ICANN2]“新gTLD碰撞发生管理”，2013年10月<https://www.icann.org/en/system/files/files/ resolutions-new-gtld-Appendment-1-07oct13-en.pdf>。
[LSDZ] "Locally-Served DNS Zones", July 2011, <https://www.iana.org/assignments/ locally-served-dns-zones/>.
[LSDZ]“本地服务DNS区域”，2011年7月<https://www.iana.org/assignments/ 本地服务dns区域/>。
[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>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[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>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<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>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<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>.
[RFC7368]Chown，T.，Ed.，Arkko，J.，Brandt，A.，Troan，O.，和J.Weil，“IPv6家庭网络架构原则”，RFC 7368，DOI 10.17487/RFC7368，2014年10月<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>.
[RFC7788]Stenberg，M.，Barth，S.，和P.Pfister，“家庭网络控制协议”，RFC 7788，DOI 10.17487/RFC7788，2016年4月<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>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[SUDN] "Special-Use Domain Names", July 2012, <https://www.iana.org/assignments/ special-use-domain-names/>.
[SUDN]“特殊用途域名”，2012年7月<https://www.iana.org/assignments/ 特殊用途域名/>。
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.
作者要感谢斯图尔特·切希尔，以及家庭网络主席马克·汤斯利和雷·贝利斯，感谢他们之前在“家”方面的工作。我们还要感谢Paul Hoffman对IANA注意事项部分的审查和评论，感谢Andrew Sullivan的审查和建议文本，感谢Suzanne Woolf和Ray Bellis的非常详细的审查评论和流程见解。感谢马克·安德鲁斯就不安全的代表团问题提供了详尽的参考清单。感谢戴尔·沃利（Dale Worley）抓住了一个相当严重的错误，感谢《当代艺术评论》（Gen Art review），感谢丹尼尔·米戈尔特（Daniel Migault）进行了全面的SecDir评论。感谢沃伦·库马里（Warren Kumari）抓住了一些额外的问题，感谢亚当·罗奇（Adam Roach）做出了一些有益的澄清。
Authors' Addresses
作者地址
Pierre Pfister Cisco Systems Paris France
法国巴黎思科系统公司
Email: pierre.pfister@darou.fr
Email: pierre.pfister@darou.fr
Ted Lemon Nibbhaya Consulting P.O. Box 958 Brattleboro, Vermont 05301-0958 United States of America
Ted Lemon Nibbhaya Consulting美国佛蒙特州布拉特波罗958号邮政信箱05301-0958
Email: mellon@fugue.com
Email: mellon@fugue.com