Independent Submission E. Rye
Request for Comments: 8567 R. Beverly
Category: Informational CMAND
ISSN: 2070-1721 1 April 2019
Independent Submission E. Rye
Request for Comments: 8567 R. Beverly
Category: Informational CMAND
ISSN: 2070-1721 1 April 2019
Customer Management DNS Resource Records
客户管理DNS资源记录
Abstract
摘要
Maintaining high Quality of Experience (QoE) increasingly requires end-to-end, holistic network management, including managed Customer Premises Equipment (CPE). Because customer management is a shared global responsibility, the Domain Name System (DNS) provides an ideal existing infrastructure for maintaining authoritative customer information that must be readily, reliably, and publicly accessible.
维护高质量的体验（QoE）越来越需要端到端的整体网络管理，包括受管理的客户场所设备（CPE）。由于客户管理是一项共同的全球责任，域名系统（DNS）提供了一个理想的现有基础设施，用于维护必须易于、可靠和公开访问的权威客户信息。
This document describes four new DNS resource record types for encoding customer information in the DNS. These records are intended to better facilitate high customer QoE via inter-provider cooperation and management of customer data.
本文档描述了四种新的DNS资源记录类型，用于在DNS中编码客户信息。这些记录旨在通过供应商间的合作和客户数据的管理，更好地促进高客户质量。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见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/rfc8567.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8567.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Customer Management Resource Records . . . . . . . . . . . . 3
2.1. The PASSWORD Resource Record . . . . . . . . . . . . . . 4
2.2. The CREDITCARD Resource Record . . . . . . . . . . . . . 4
2.3. The SSN Resource Record . . . . . . . . . . . . . . . . . 6
2.4. The SSNPTR Resource Record . . . . . . . . . . . . . . . 7
3. Related RR Types . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Customer Management Resource Records . . . . . . . . . . . . 3
2.1. The PASSWORD Resource Record . . . . . . . . . . . . . . 4
2.2. The CREDITCARD Resource Record . . . . . . . . . . . . . 4
2.3. The SSN Resource Record . . . . . . . . . . . . . . . . . 6
2.4. The SSNPTR Resource Record . . . . . . . . . . . . . . . 7
3. Related RR Types . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
A significant portion of today's Internet is comprised of residential access networks. These access networks, and their providers, are now critical infrastructure, and significant research is devoted to measuring residential broadband speed and reliability [SAMKNOWS].
当今互联网的很大一部分由住宅接入网络组成。这些接入网络及其提供商现在是关键的基础设施，大量研究致力于测量住宅宽带速度和可靠性[SAMKNOWS]。
Unfortunately, Customer Premises Equipment (CPE) is one of the weakest links in the chain of network equipment connecting consumers to the Internet. Customers typically do not perform proactive maintenance, e.g., firmware updates, on their own CPE. In many cases, CPE is even deployed with default authentication credentials, a fact that has been exploited by various Internet-wide denial-of-service attacks [MIRAI].
不幸的是，客户场所设备（CPE）是连接消费者与互联网的网络设备链中最薄弱的环节之一。客户通常不会在自己的CPE上执行主动维护，例如固件更新。在许多情况下，CPE甚至使用默认身份验证凭据进行部署，这一事实已被各种Internet范围的拒绝服务攻击[MIRAI]利用。
A central observation motivating this document is that customers simply cannot be trusted to manage their own networks, much less the path-critical CPE. Given the difficulty in maintaining the hygiene
激励本文档的一个中心观察结果是，客户根本无法信任管理自己的网络，更不用说关键路径的CPE了。考虑到保持卫生的困难
and resilience of broadband access, CPE maintenance should instead be treated as a shared global responsibility among Internet Service Providers (ISPs).
由于宽带接入的弹性，CPE维护应被视为互联网服务提供商（ISP）共同承担的全球责任。
Further complicating customer management is choice in ISP, which is currently available to nearly half of US households. While customers may switch providers, their biographical, billing, and technological details remain constant. Therefore, service providers need mechanisms to ensure that transitioning customers into and out of their network is as seamless as possible from both a technical and billing standpoint.
使客户管理更加复杂的是ISP的选择，目前美国近一半的家庭都可以使用ISP。虽然客户可能会更换供应商，但他们的简历、账单和技术细节保持不变。因此，服务提供商需要各种机制来确保从技术和计费角度来看，客户进出其网络的过程尽可能无缝。
Finally, service providers, advertisers, and law enforcement agencies have varying but important reasons to track unique users' behavior on the Internet. While RFC 7043 [RFC7043] makes use of EUI48 and EUI64 Resource Record (RR) types to uniquely identify CPE devices and better support third-party tracking, these mechanisms can be defeated by the customer simply purchasing new CPE.
最后，服务提供商、广告商和执法机构有不同但重要的理由来跟踪互联网上独特用户的行为。虽然RFC 7043[RFC7043]利用EUI48和EUI64资源记录（RR）类型来唯一标识CPE设备并更好地支持第三方跟踪，但客户只需购买新的CPE就可以克服这些机制。
This document takes a holistic, end-to-end view of customer management with the aim of enhancing customer QoE and overall network security. To enable shared CPE maintenance, this document leverages the Domain Name System (DNS), described in RFC 1034 [RFC1034] and RFC 1035 [RFC1035], and introduces new RR types to aid network management.
本文档从整体、端到端的角度介绍了客户管理，旨在提高客户QoE和整体网络安全性。为了实现共享CPE维护，本文档利用RFC 1034[RFC1034]和RFC 1035[RFC1035]中描述的域名系统（DNS），并引入新的RR类型来帮助网络管理。
This document uses capitalized keywords such as MUST and MAY to describe the requirements for using the registered RR types. The intended meaning of those keywords in this document are the same as those described in RFC 2119 [RFC2119] and RFC 8174 [RFC8174]. Although these keywords are often used to specify normative requirements in IETF Standards, their use in this document does not imply that this document is a standard of any kind.
本文档使用大写关键字（如MUST和MAY）来描述使用注册RR类型的要求。本文档中这些关键字的预期含义与RFC 2119[RFC2119]和RFC 8174[RFC8174]中描述的相同。尽管这些关键字通常用于指定IETF标准中的规范性要求，但在本文件中使用这些关键字并不意味着本文件是任何类型的标准。
The ubiquity of residential broadband Internet service affords myriad benefits to consumers, but also poses a daunting challenge for Internet Service Providers -- how to best manage sensitive customer identifiers and billing details, while ensuring the resilience and security of CPE devices on their network?
住宅宽带互联网服务的普及为消费者带来了诸多好处，但也给互联网服务提供商带来了严峻的挑战——如何最好地管理敏感的客户标识符和计费细节，同时确保其网络上CPE设备的弹性和安全性？
This document introduces four new RRs to assist in the management of customer data by ISPs.
本文件介绍了四种新的RRs，以协助ISP管理客户数据。
This section describes the purpose and wire format of the new DNS RRs.
本节介绍新DNS RRs的用途和接线格式。
The PASSWORD RR facilitates remote management of CPE devices by providing the login credentials for the CPE in a single RR. These credentials are used by authorized service providers to authenticate to the CPE. Authenticated users can then install important software and configuration updates to benefit the security and health of the provider's network.
密码RR通过在单个RR中提供CPE的登录凭证来促进CPE设备的远程管理。授权服务提供商使用这些凭证向CPE进行身份验证。然后，经过身份验证的用户可以安装重要的软件和配置更新，从而有利于提供商网络的安全和健康。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| USERNAME |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PASSWORD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| USERNAME |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PASSWORD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PASSWORD RDATA Format
图1：密码RDATA格式
Where:
哪里：
USERNAME The <character-string> username of the account holder located at the CPE. In order to limit gratuitous expressions of individuality, usernames MUST be 16 or fewer ASCII characters and MUST NOT include punctuation.
用户名位于CPE的帐户持有人的<character string>用户名。为了限制不必要的个性化表达，用户名必须是16个或更少的ASCII字符，并且不得包含标点符号。
PASSWORD The <character-string> password associated with the USERNAME. In order to keep the RR size to a minimum, passwords longer than 32 bits are NOT supported.
密码与用户名关联的<character string>密码。为了将RR大小保持在最小值，不支持超过32位的密码。
Hosts on which multiple accounts exist SHOULD have separate PASSWORD RRs for each account.
存在多个帐户的主机应为每个帐户提供单独的密码RRs。
The CREDITCARD RR stores the billing details of the primary account holder located at the hostname associated with the CPE. Upon gaining a new subscriber, an ISP enters their billing details in a CREDITCARD RR so that it MAY be queried as needed for automated billing purposes. In addition, any outside entity with whom the customer
信用卡RR存储位于与CPE关联的主机名处的主帐户持有人的账单详细信息。在获得新的订户后，ISP会在信用卡RR中输入他们的账单详细信息，以便根据需要进行查询，以实现自动计费。此外，与客户合作的任何外部实体
develops a recurring payment plan MAY query this RR for payment details as well. Storing payment information in an RR, rather than in the databases of disparate organizations with varying data security postures, helps reduce attack vectors available to malicious actors seeking this data.
制定定期付款计划，也可以查询此RR的付款详细信息。将支付信息存储在RR中，而不是存储在具有不同数据安全态势的不同组织的数据库中，有助于减少恶意参与者寻找这些数据时可用的攻击向量。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CARDNUMBER |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPIRE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| CARDNUMBER |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EXPIRE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: CREDITCARD RDATA Format
图2：信用卡RDATA格式
Where:
哪里：
CARDNUMBER The <character-string> 16-digit credit card number used for billing by the host's service provider. This field MUST NOT contain punctuation or spaces; only numeric digits represented in ASCII are allowed. Because this field is 16 digits in length, users MUST NOT use American Express cards.
CARDNUMBER主机服务提供商用于计费的<字符串>16位信用卡号。此字段不得包含标点或空格；仅允许使用ASCII表示的数字。由于此字段长度为16位，用户不得使用美国运通卡。
EXPIRE A <character-string> specifying the two-digit month and two-digit year in which the credit card expires. This field MUST NOT contain punctuation or spaces; only numeric digits represented in ASCII are allowed.
过期指定信用卡过期的两位数月份和两位数年份的<character string>。此字段不得包含标点或空格；仅允许使用ASCII表示的数字。
CHECKSUM In order to protect against bit errors occurring in the CARDNUMBER field, this RR type MUST use error checking as follows: Luhn's algorithm is employed as a simple checksum to validate that none of the 16 digits were corrupted in transit. Starting with the leftmost digit, we add this digit's value to a running total; for every second digit (beginning with the second-from-left digit), we add twice its value to the running total. This algorithm continues until all 16 digits have been exhausted. With this partial sum in
校验和为了防止CARDNUMBER字段中出现位错误，此RR类型必须使用如下错误检查：使用Luhn算法作为简单校验和，以验证16位数字在传输过程中没有损坏。从最左边的数字开始，我们将这个数字的值添加到一个运行总数中；对于每第二个数字（从左数第二位开始），我们将其值的两倍添加到运行总数中。此算法将继续执行，直到16位数字全部用完。用这个部分和
hand, we solve for the value x such that x added to our partial sum is congruent to 0 modulo 10, and store x in the CHECKSUM field.
另一方面，我们对值x进行求解，使得添加到部分和中的x与模10的0全等，并将x存储在校验和字段中。
When a CREDITCARD RR is queried, the recipient simply computes Luhn's algorithm in the same manner as described above, and validates that their computed value of x matches that stored in the CHECKSUM field.
当查询信用卡RR时，接收者只需以与上述相同的方式计算Luhn算法，并验证其计算的x值是否与存储在校验和字段中的值匹配。
Note that this novel use of Luhn's algorithm MAY have applications outside of the CREDITCARD RR.
请注意，Luhn算法的这种新颖用法可能在信用卡RR之外也有应用。
The SSN RR maps hostnames to the US Social Security number and birth date of a user located at that host. For CPE behind which multiple users reside, a separate SSN RR SHOULD be entered into the DNS for each user. When residential broadband service becomes available outside of the United States, those countries SHOULD adopt identifiers that are compatible with the US SSN in order to ease administrative burden on the DNS and multinational service providers.
SSN RR将主机名映射到位于该主机的用户的美国社会安全号码和出生日期。对于多个用户驻留的CPE，应在DNS中为每个用户输入单独的SSN RR。当住宅宽带服务在美国境外可用时，这些国家应采用与美国SSN兼容的标识符，以减轻DNS和跨国服务提供商的管理负担。
During tax preparation season, the United States Internal Revenue Service WILL query the SSN RR to verify residency and proof of hostname ownership. In addition, the SSN RR MAY be used in conjunction with the CREDITCARD RR to automate the collection of back taxes owed.
在纳税准备季节，美国国税局将查询SSN RR，以验证居住和主机名所有权证明。此外，SSN RR可与信用卡RR一起使用，以自动收取所欠税款。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOCIAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIRTHDATE |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOCIAL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIRTHDATE |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SSN RDATA Format
图3:SSN RDATA格式
Where:
哪里：
SOCIAL The Social Security number of the user associated with the host, formatted as a 32-bit unsigned integer in network byte order.
SOCIAL与主机关联的用户的社会保险号，格式为网络字节顺序的32位无符号整数。
BIRTHDATE A 64-bit timestamp representing the number of seconds past the Unix Epoch that the individual described by this RR was born. Because the Unix Epoch predates the birth of all Internet users, this field provides a sufficient range of values for ISPs to describe their subscribers. The 64-bit timestamp field is also "future proof", avoiding the Year 2038 problem and ensuring SSN RR applicability into the foreseeable future.
BIRTHDATE一个64位时间戳，表示此RR描述的个人出生的Unix纪元后的秒数。由于Unix时代早于所有Internet用户的诞生，因此此字段为ISP提供了足够的值范围来描述其订户。64位时间戳字段也是“未来证明”，避免了2038年的问题，并确保SSN RR在可预见的未来的适用性。
The SSNPTR RR provides the reverse functionality of the SSN RR; it maps Social Security numbers to hostnames. Every individual for whom an ISP provides service, not only primary account holders, SHOULD have an SSNPTR RR entry in the DNS.
SSNPTR RR提供SSN RR的反向功能；它将社会安全号码映射到主机名。ISP为其提供服务的每个个人，而不仅仅是主要帐户持有人，都应该在DNS中有一个SSNPTR RR条目。
One benefit provided by the SSNPTR RR is the ability to conduct some population census functions remotely. For example, consider a residential ISP with SSNPTR RRs for each of its subscribers. Performing SSNPTR queries for all of their SSNs returns the host at which those individuals are located, allowing for the trivial association of family members behind the same CPE device. Further, these hosts can then be geolocated using an IP geolocation service or LOC RR [RFC1876], providing the ability to determine municipal populations and thereby inform decisions about appropriations and appropriate public policies.
SSNPTR RR提供的一个好处是能够远程执行某些人口普查功能。例如，考虑为每个订户使用SSNPTR RRS的住宅ISP。对其所有SSN执行SSNPTR查询将返回这些个人所在的主机，从而允许家庭成员在同一CPE设备后面进行琐碎的关联。此外，可以使用IP地理定位服务或LOC RR[RFC1876]对这些主机进行地理定位，从而提供确定市政人口的能力，从而告知有关拨款和适当公共政策的决定。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ DNAME /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ DNAME /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SSNPTR RDATA Format
图4:SSNPTR RDATA格式
Where:
哪里：
DNAME A <domain-name> that points to a location in the domain name space.
DNAME指向域名空间中某个位置的<domain name>。
The practice of introducing new RR types to the DNS to support functionality that is either only tangentially related or wholly unrelated to name resolution is well established.
在DNS中引入新的RR类型以支持与名称解析仅相关或完全无关的功能的做法已经确立。
[RFC2539] describes the Diffie-Hellman KEY RR type, which is used to conveniently store public key parameters for a domain. The SRV RR type [RFC2782] combines name resolution with transport- and application-layer details, providing a "no-fuss" way for network administrators to advertise the location of specific services. The Name Authority PTR (NAPTR) RR [RFC2915] recognized and corrected the lack of POSIX Extended Regular Expression support in the DNS, allowing for DNS-based automobile parts identification systems [RFC3402] among other use cases. Having established the DNS's role in encryption in [RFC2539], the IPSECKEY RR resurrected the since-obsoleted ability to store public key parameters for the purposes of IPsec encryption [RFC4025]. [RFC4255] codified the natural inter-dependency between the Secure Shell (SSH) protocol [RFC4253] and DNS by providing the SSHFP RR type, which is used to verify the host key of a server.
[RFC2539]描述Diffie-Hellman密钥RR类型，用于方便地存储域的公钥参数。SRV RR类型[RFC2782]将名称解析与传输层和应用层细节相结合，为网络管理员提供了一种“无需大惊小怪”的方式来公布特定服务的位置。名称管理机构PTR（NAPTR）RR[RFC2915]认识到并纠正了DNS中缺乏POSIX扩展正则表达式支持的问题，允许在其他用例中使用基于DNS的汽车零件识别系统[RFC3402]。在[RFC2539]中确立了DNS在加密中的作用后，IPSECKEY RR恢复了为IPsec加密目的存储公钥参数的能力[RFC4025]。[RFC4255]通过提供用于验证服务器主机密钥的SSHFP RR类型，对安全外壳（SSH）协议[RFC4253]和DNS之间的自然相互依赖关系进行了编码。
Extending the idea of distributing public key parameters via DNS, [RFC4398] introduced the CERT RR type to publish X.509 and PGP certificates. [RFC4701] introduces the DHCID RR type to solve the problem of Fully Qualified Domain Name (FQDN) collisions when Dynamic Host Configuration Protocol (DHCP) clients make DNS updates after obtaining a DHCP lease. The TLSA RR type [RFC6698] is used to associate a TLS certificate with a domain, leveraging DNSSEC as the binding, and the CAA RR type [RFC6844] specifies the Certificate Authority allowed to issue certificates for a domain. The EUI48 and EUI64 RR types specified in [RFC7043] seek to eliminate boundaries in the TCP/IP model by creating, in essence, A records for MAC addresses.
扩展了通过DNS分发公钥参数的思想，[RFC4398]引入了CERT RR类型来发布X.509和PGP证书。[RFC4701]引入DHCID RR类型，以解决动态主机配置协议（DHCP）客户端在获得DHCP租约后进行DNS更新时出现的完全限定域名（FQDN）冲突问题。TLSA RR类型[RFC6698]用于将TLS证书与域关联，利用DNSSEC作为绑定，CAA RR类型[RFC6844]指定允许为域颁发证书的证书颁发机构。[RFC7043]中指定的EUI48和EUI64 RR类型本质上是通过创建MAC地址记录来消除TCP/IP模型中的边界。
This document has no IANA actions.
本文档没有IANA操作。
DNSSEC [RFC4033] SHOULD be used in conjunction with the PASSWORD, CREDITCARD, SSN, and SSNPTR RR types to provide data integrity. Employing DNSSEC ensures that the data contained in these RRs originates from an authoritative source and is not, for example, an attacker attempting to provide invalid login credentials in response to a legitimate request for a PASSWORD RR.
DNSSEC[RFC4033]应与密码、信用卡、SSN和SSNPTR RR类型一起使用，以提供数据完整性。使用DNSSEC可确保这些RRs中包含的数据来自权威来源，而不是（例如）试图提供无效登录凭据以响应密码RR的合法请求的攻击者。
[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>.
[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>.
[CAMEL] Hubert, B., "The DNS Camel", March 2018, <https://blog.powerdns.com/2018/03/22/ the-dns-camel-or-the-rise-in-dns-complexit/>.
[骆驼]休伯特，B.，“DNS骆驼”，2018年3月<https://blog.powerdns.com/2018/03/22/ dns骆驼或dns复杂性的上升/>。
[MIRAI] Antonakakis, M., April, T., Bailey, M., Bernhard, M., Bursztein, E., Cochran, J., Durumeric, Z., Halderman, J., Invernizzi, L., Kallitsis, M., Kumar, D., Lever, C., Ma, Z., Mason, J., Menscher, D., Seaman, C., Sullivan, N., Thomas, K., and Y. Zhou, "Understanding the Mirai Botnet", Proceedings of the 26th USENIX Security Symposium, August 2017, <https://www.usenix.org/system/files/conference/ usenixsecurity17/sec17-antonakakis.pdf>.
[MIRAI]Antonakakis，M.，April，T.，Bailey，M.，Bernhard，M.，Bursztein，E.，Cochran，J.，Durumeric，Z.，Halderman，J.，Invernizzi，L.，Kallitsis，M.，Kumar，D.，Lever，C.，Ma，Z.，Mason，J.，Menscher，D.，Seaman，C.，Sullivan，N.，Thomas，K.，和Y.Zhou，“理解MIRAI僵尸网络”，第26届USENIX安全研讨会论文集，2017年8月<https://www.usenix.org/system/files/conference/ 请使用nixsecurity17/sec17 antonakakis.pdf>。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<https://www.rfc-editor.org/info/rfc1034>.
[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>.
[RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, DOI 10.17487/RFC1876, January 1996, <https://www.rfc-editor.org/info/rfc1876>.
[RFC1876]Davis，C.，Vixie，P.，Goodwin，T.，和I.Dickinson，“域名系统中表达位置信息的方法”，RFC 1876，DOI 10.17487/RFC1876，1996年1月<https://www.rfc-editor.org/info/rfc1876>.
[RFC2539] Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, DOI 10.17487/RFC2539, March 1999, <https://www.rfc-editor.org/info/rfc2539>.
[RFC2539]Eastlake 3rd，D.，“域名系统（DNS）中Diffie-Hellman密钥的存储”，RFC 2539，DOI 10.17487/RFC2539，1999年3月<https://www.rfc-editor.org/info/rfc2539>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<https://www.rfc-editor.org/info/rfc2782>.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, DOI 10.17487/RFC2915, September 2000, <https://www.rfc-editor.org/info/rfc2915>.
[RFC2915]Mealling，M.和R.Daniel，“命名机构指针（NAPTR）DNS资源记录”，RFC 2915，DOI 10.17487/RFC29152000年9月<https://www.rfc-editor.org/info/rfc2915>.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, DOI 10.17487/RFC3402, October 2002, <https://www.rfc-editor.org/info/rfc3402>.
[RFC3402]Mealling，M，“动态委托发现系统（DDDS）第二部分：算法”，RFC 3402，DOI 10.17487/RFC3402，2002年10月<https://www.rfc-editor.org/info/rfc3402>.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March 2005, <https://www.rfc-editor.org/info/rfc4025>.
[RFC4025]Richardson，M.，“在DNS中存储IPsec密钥材料的方法”，RFC 4025，DOI 10.17487/RFC4025，2005年3月<https://www.rfc-editor.org/info/rfc4025>.
[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>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4253]Ylonen，T.和C.Lonvick，编辑，“安全外壳（SSH）传输层协议”，RFC 4253，DOI 10.17487/RFC4253，2006年1月<https://www.rfc-editor.org/info/rfc4253>.
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", RFC 4255, DOI 10.17487/RFC4255, January 2006, <https://www.rfc-editor.org/info/rfc4255>.
[RFC4255]Schlyter，J.和W.Griffin，“使用DNS安全发布安全外壳（SSH）密钥指纹”，RFC 4255，DOI 10.17487/RFC4255，2006年1月<https://www.rfc-editor.org/info/rfc4255>.
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, DOI 10.17487/RFC4398, March 2006, <https://www.rfc-editor.org/info/rfc4398>.
[RFC4398]Josefsson，S.，“在域名系统（DNS）中存储证书”，RFC 4398，DOI 10.17487/RFC4398，2006年3月<https://www.rfc-editor.org/info/rfc4398>.
[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)", RFC 4701, DOI 10.17487/RFC4701, October 2006, <https://www.rfc-editor.org/info/rfc4701>.
[RFC4701]Stapp，M.，Lemon，T.和A.Gustafsson，“用于编码动态主机配置协议（DHCP）信息（DHCID RR）的DNS资源记录（RR）”，RFC 4701，DOI 10.17487/RFC4701，2006年10月<https://www.rfc-editor.org/info/rfc4701>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<https://www.rfc-editor.org/info/rfc6698>.
[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 6844, DOI 10.17487/RFC6844, January 2013, <https://www.rfc-editor.org/info/rfc6844>.
[RFC6844]Hallam Baker，P.和R.Stradling，“DNS认证机构授权（CAA）资源记录”，RFC 6844，DOI 10.17487/RFC6844，2013年1月<https://www.rfc-editor.org/info/rfc6844>.
[RFC7043] Abley, J., "Resource Records for EUI-48 and EUI-64 Addresses in the DNS", RFC 7043, DOI 10.17487/RFC7043, October 2013, <https://www.rfc-editor.org/info/rfc7043>.
[RFC7043]Abley，J.，“DNS中EUI-48和EUI-64地址的资源记录”，RFC 7043，DOI 10.17487/RFC7043，2013年10月<https://www.rfc-editor.org/info/rfc7043>.
[SAMKNOWS] Crawford, S., "SamKnows: The Internet Measurement Standard", <https://samknows.com/>.
[SAMKNOWS]Crawford，S.，“SAMKNOWS:互联网测量标准”<https://samknows.com/>.
Acknowledgements
致谢
We thank the US Federal Communications Commission for the repeal of network neutrality legislation, allowing ISPs to provide their customers with the level and type of service that ISPs have come to expect.
我们感谢美国联邦通信委员会废除网络中立立法，允许ISP向其客户提供ISP所期望的服务水平和类型。
We also thank Bert Hubert for identifying the dearth of DNS RR standards in his blog post and IETF lecture entitled The DNS Camel [CAMEL], so named for the drought of DNS-enabled functionality of the last several decades.
我们还感谢伯特·休伯特（Bert Hubert）在其博客文章和IETF讲座《DNS骆驼》（the DNS Camel）[Camel]中指出DNS RR标准的缺乏，该讲座因过去几十年来DNS功能的匮乏而得名。
Authors' Addresses
作者地址
Erik C. Rye CMAND 1 University Circle Monterey, CA 93943 United States of America
Erik C.Rye CMAND美国加利福尼亚州蒙特利大学环1号，邮编：93943
Email: rye@cmand.org
Email: rye@cmand.org
Robert Beverly CMAND 1 University Circle Monterey, CA 93943 United States of America
罗伯特·贝弗利·克曼德美国加利福尼亚州蒙特利大学环1号，邮编：93943
Email: rbeverly@cmand.org
Email: rbeverly@cmand.org