正文共：2567 字 4 图，预估阅读时间：3 分钟
RFC8567：Customer Management DNS Resource Records，1 April 2019摘要
保持高体验质量（Quality of Experience，QoE）越来越需要端到端的整体网络管理，包括托管的客户前置设备（Customer Premises Equipment，CPE）。由于客户管理是一项共同的全球责任，域名系统（Domain Name System，DNS）为维护权威客户信息提供了一个理想的现有基础设施，这些信息必须易于、可靠且可公开访问。
本文档介绍了四种新的DNS资源记录类型，用于在DNS中对客户信息进行编码。这些记录旨在通过提供商间的合作和客户数据的管理，更好地促进高客户QoE。
本文件不是互联网标准轨道规范；它是为了提供信息而发布的。
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已经选择自行发布此文档，并且没有对其实现或部署的价值做出任何声明。RFC编辑器批准发布的文件不适用于任何级别的互联网标准；参见RFC 7841的第2节。
有关本文件的当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8567.
版权所有（c）2019 IETF Trust和被认定为文件作者的人员。保留所有权利。
本文件受BCP 78和IETF信托与IETF文件相关的法律规定的约束(https://trustee.ietf.org/license-info)自本文件发布之日起生效。请仔细查看这些文件，因为它们描述了您对本文件的权利和限制。
当今互联网的很大一部分是由住宅接入网络组成的。这些接入网络及其提供商现在是关键的基础设施，并且致力于测量住宅宽带速度和可靠性的重要研究[SAMKNOWS]。
不幸的是，客户前置设备（CPE）是连接消费者与互联网的网络设备链中最薄弱的环节之一。客户通常不会在自己的CPE上执行主动维护，例如固件更新。在许多情况下，CPE甚至使用默认身份验证凭据进行部署，这一事实已被各种互联网范围的拒绝服务攻击[MIRAI]所利用。
激励本文档的一个核心观察结果是，根本无法信任客户管理自己的网络，更不用说路径关键型CPE了。鉴于难以保持宽带接入的卫生和弹性，CPE维护应被视为互联网服务提供商（Internet Service Providers，ISP）的共同全球责任。
ISP的选择使客户管理更加复杂，目前近一半的美国家庭都可以使用ISP。虽然客户可能会更换供应商，但他们的简历、账单和技术细节保持不变。因此，服务提供商需要一些机制，以确保从技术和计费角度来看，客户进出网络的过渡尽可能无缝。
最后，服务提供商、广告商和执法机构有不同但重要的理由来跟踪独特用户在互联网上的行为。虽然RFC 7043[RFC7043]利用EUI48和EUI64资源记录（Resource Record，RR）类型来唯一识别CPE设备并更好地支持第三方跟踪，但这些机制可能会被客户简单地购买新CPE所击败。
本文档从整体、端到端的角度看待客户管理，旨在增强客户QoE和整体网络安全。为了实现共享CPE维护，本文档利用了RFC 1034[RFC1034]（域名概念）和RFC 1035[RFC1035]中描述的域名系统（DNS），并引入了新的RR类型来帮助网络管理。
本文件使用大写关键字（如MUST和MAY）来描述使用注册RR类型的要求。本文档中这些关键词的意图含义与RFC 2119[RFC2119]和RFC 8174[RFC8174]中描述的含义相同。尽管这些关键字通常用于指定IETF标准中的规范性要求，但在本文档中使用这些关键字并不意味着本文档是任何类型的标准。
住宅宽带互联网服务的普遍性为消费者带来了无数好处，但也给互联网服务提供商带来了严峻的挑战——如何最好地管理敏感的客户标识符和计费细节，同时确保CPE设备在其网络上的弹性和安全性？
本文档介绍了四个新的RR，以帮助ISP管理客户数据。
本节介绍了新DNS RR的用途和有线格式。
密码RR通过在单个RR中提供CPE的登录凭证来促进CPE设备的远程管理。这些证书由授权的服务提供商用来向CPE进行认证。经过身份验证的用户可以安装重要的软件和配置更新，从而有利于提供商网络的安全和健康。
图1：PASSWORD RDATA格式
其中：
USERNAME：用户名，CPE账户持有人的用户名<character-string>。为了限制无端的个性表达，用户名必须是16个或更少的ASCII字符，并且不得包含标点符号。
PASSWORD：密码，与USERNAME关联的密码<character-string>。为了将RR大小保持在最小值，不支持长度超过32位的密码。
存在多个帐户的主机应该为每个帐户具有单独的PASSWORD RR。
CREDITCARD RR存储位于与CPE相关联的主机名处的主要账户持有人的计费详细信息。获得新用户后，ISP会在CREDITCARD RR中输入其计费详细信息，以便根据需要进行查询以实现自动计费。此外，与客户一起制定定期付款计划的任何外部实体也可以查询此RR以获取付款详细信息。将支付信息存储在RR中，而不是存储在具有不同数据安全态势的不同组织的数据库中，有助于减少寻求这些数据的恶意行为者可用的攻击向量。
图2：CREDITCARD RDATA格式
其中：
CARDNUMBER：卡片号码，主机服务提供商用于计费的16位信用卡号<character-string>。此字段不得包含标点符号或空格；只允许使用ASCII表示的数字。由于此字段的长度为16位，用户不得使用美国运通卡。
EXPIRE：过期时间，一个指定信用卡到期的两位数月份和两位数年份的字符串<character-string>。此字段不得包含标点符号或空格；只允许使用ASCII表示的数字。
CHECKSUM：校验和，为了防止在CARDNUMBER字段中发生比特错误，这种RR类型必须使用如下错误检查：Luhn算法被用作简单的校验和，以验证16位数字在传输过程中没有损坏。从最左边的数字开始，我们将这个数字的值添加到一个连续的总数中；对于每一个第二位（从左起第二位开始），我们将其值的两倍添加到运行总数中。该算法一直持续到所有16位数字都用完为止。有了这个部分和，我们求解值x，使得加在部分和上的x等于0的模10，并将x存储在CHECKSUM字段中。
当查询CREDITCARD RR时，接收方只需以与上述相同的方式计算Luhn算法，并验证其计算的x值是否与CHECKSUM字段中存储的值匹配。
请注意，Luhn算法的这种新颖使用可能在CREDITCARD RR之外有应用。
SSN RR将主机名映射到位于该主机的用户的美国社会安全号码和出生日期。对于多个用户所在的CPE，应为每个用户在DNS中输入一个单独的SSN RR。当住宅宽带服务在美国境外可用时，这些国家应采用与美国SSN兼容的标识符，以减轻DNS和跨国服务提供商的管理负担。
在纳税准备季节，美国国税局将查询SSN RR，以验证居住权和主机名所有权证明。此外，SSN RR可与CREDITCARD RR一起使用，以自动收取所欠欠税。
图3:SSN RDATA格式
其中：
SOCIAL：社会信息，与主机关联的用户的社会安全号码，格式为网络字节顺序的32位无符号整数。
BIRTHDATE：出生日期，一个64位的时间戳，表示该RR所描述的个人出生的Unix Epoch之后的秒数。由于Unix时代早于所有互联网用户的诞生，因此该字段为ISP提供了足够的值范围来描述其订户。64位时间戳字段也是“经得起未来考验的”，避免了2038年的问题，并确保了SSN RR在可预见的未来的适用性。
SSNPTR RR提供与SSN RR相反的功能；它将社会安全号码映射到主机名。ISP为其提供服务的每个人，不仅仅是主要账户持有人，都应该在DNS中有一个SSNPTR RR条目。
SSNPTR RR提供的一个好处是能够远程执行一些人口普查功能。例如，考虑一个住宅ISP，其每个用户都有SSNPTR RR。对其所有的SSN执行SSNPTR查询会返回这些个体所在的主机，从而允许同一CPE设备后面的家庭成员的琐碎关联。此外，这些主机可以使用IP地理定位服务或LOC RR[RFC1876]进行地理定位，从而提供确定城市人口的能力，从而为有关拨款和适当的公共政策的决策提供信息。
图4:SSNPTR RDATA格式
其中：
DNAME：一个指向域名空间中某个位置的＜域名＞。
在DNS中引入新的RR类型以支持与名称解析仅略微相关或完全无关的功能的做法已经确立。
[RFC2539]描述了Diffie-Hellman KEY RR类型，用于方便地存储域的公钥参数。SRV RR类型[RFC2782]将名称解析与传输层和应用层详细信息相结合，为网络管理员提供了一种“无需大惊小怪”的方式来公布特定服务的位置。Name Authority PTR（NAPTR）RR[RFC2915]识别并纠正了DNS中缺乏POSIX扩展正则表达式支持的问题，允许使用基于DNS的动态委托发现系统[RFC3402]（DDDS2）以及其他用例。在[RFC2539]中确立了DNS在加密中的作用后，IPSECKEY RR恢复了为IPsec加密[RFC4025]而存储公钥参数的过时能力。[RFC4255]通过提供用于验证服务器的主机密钥的SSHFP RR类型，对安全外壳（Secure Shell，SSH）协议[RFC4253]和DNS之间的自然相互依赖性进行了编码。
[RFC4398]扩展了通过DNS分发公钥参数的想法，引入了CERT RR类型来发布X.509和PGP证书。[RFC4701]引入了DHCID RR类型，以解决动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）客户端在获得DHCP租约后进行DNS更新时完全限定域名（Fully Qualified Domain Name，FQDN）冲突的问题。TLSA RR类型[RFC6698]用于将TLS证书与域相关联，利用DNSSEC作为绑定，CAA RR类型[RFC 6844]指定允许为域颁发证书的证书颁发机构。[RFC7043]中指定的EUI48和EUI64 RR类型试图通过本质上为MAC地址创建A记录来消除TCP/IP模型中的边界。
本文档没有IANA操作。
DNSSEC[RFC4033]应与PASSWORD、CREDITCARD、SSN和SSNPTR RR类型结合使用，以提供数据完整性。使用DNSSEC可以确保这些RR中包含的数据来自权威来源，而不是攻击者试图提供无效的登录凭据来响应对密码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>.[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>.
[] Hubert, B., "The DNS Camel", March 2018, <https://blog.powerdns.com/2018/03/22/the-dns-camel-or-the-rise-in-dns-complexit/>.[] 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>.[] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.[] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[] 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>.[]Crawford, S., "SamKnows: The Internet Measurement Standard", <https://samknows.com/>.
我们感谢美国联邦通信委员会废除网络中立性立法，允许互联网服务提供商为其客户提供互联网服务提供商所期望的服务水平和类型。
我们还感谢Bert Hubert在他的博客文章和IETF演讲《DNS骆驼[Camel]》中指出DNS RR标准的缺乏，该演讲因过去几十年DNS功能的匮乏而得名。
长按二维码
关注我们吧
