[要約] RFC 8567は、顧客管理DNSリソースレコードに関する標準化された仕様です。その目的は、DNSシステム内で顧客情報を効果的に管理するための新しいリソースレコードを定義することです。
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で顧客情報をエンコードするための4つの新しいDNSリソースレコードタイプについて説明します。これらの記録は、プロバイダー間の協力と顧客データの管理を介して、顧客のQoEを向上させることを目的としています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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
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）は、消費者をインターネットに接続するネットワーク機器のチェーンの中で最も弱いリンクの1つです。顧客は通常、自身のCPEでファームウェアの更新などの予防保守を実行しません。多くの場合、CPEはデフォルトの認証資格情報を使用して展開されることもあります。これは、インターネット全体のさまざまなサービス拒否攻撃[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 and resilience of broadband access, CPE maintenance should instead be treated as a shared global responsibility among Internet Service Providers (ISPs).
このドキュメントの動機となる中心的な観察結果は、パスクリティカルなCPEではなく、顧客が自分のネットワークを管理することを信頼できないということです。ブロードバンドアクセスの衛生と回復力を維持することの難しさを考えると、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デバイスの回復力とセキュリティを確保しながら、機密の顧客IDと請求の詳細を最適に管理する方法？
This document introduces four new RRs to assist in the management of customer data by ISPs.
このドキュメントでは、ISPによる顧客データの管理を支援する4つの新しいRRを紹介します。
This section describes the purpose and wire format of the new DNS RRs.
このセクションでは、新しいDNS RRの目的とワイヤー形式について説明します。
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.
PASSWORD 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
USERNAME CPEにあるアカウント所有者の<文字列>ユーザー名。個性の不必要な表現を制限するために、ユーザー名は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.
PASSWORD USERNAMEに関連付けられた<文字列>パスワード。 RRサイズを最小に保つために、32ビットより長いパスワードはサポートされていません。
Hosts on which multiple accounts exist SHOULD have separate PASSWORD RRs for each account.
複数のアカウントが存在するホストは、アカウントごとに個別のパスワードRRを持つ必要があります。
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 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.
CREDITCARD RRは、CPEに関連付けられたホスト名にあるプライマリアカウントホルダーの請求の詳細を格納します。新しい加入者を獲得すると、ISPは、自動請求の目的で必要に応じて照会できるように、CREDITCARD RRに請求の詳細を入力します。さらに、顧客が定期的な支払いプランを作成する外部エンティティは、このRRに支払いの詳細も問い合わせる場合があります（MAY）。支払い情報を、さまざまなデータセキュリティポスチャを持つ異種組織のデータベースではなく、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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桁の長さであるため、ユーザーはAmerican Expressカードを使用してはなりません。
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.
EXPIREクレジットカードの有効期限が切れる2桁の月と2桁の年を指定する<文字列>。このフィールドに句読点やスペースを含めることはできません。 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 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.
チェックサムCARDNUMBERフィールドで発生するビットエラーから保護するために、このRRタイプは、次のようにエラーチェックを使用する必要があります。左端の数字から始めて、この数字の値を現在の合計に追加します。 1桁おきに（左から2桁目から始まる）、その合計値に2倍の値を加算します。このアルゴリズムは、16桁がすべてなくなるまで続きます。この部分合計を使用して、部分合計に追加されたxが10を法とする0に合同になるように値xを解き、xをCHECKSUMフィールドに格納します。
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.
CREDITCARD RRが照会されると、受信者は上記と同じ方法でLuhnのアルゴリズムを計算し、計算されたxの値がCHECKSUMフィールドに格納されている値と一致することを検証します。
Note that this novel use of Luhn's algorithm MAY have applications outside of the CREDITCARD RR.
ルーンのアルゴリズムのこの斬新な使用法は、クレジットカード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の場合、ユーザーごとに個別のSSN RRをDNSに入力する必要があります（SHOULD）。住宅用ブロードバンドサービスが米国外で利用可能になった場合、それらの国は、DNSおよび多国籍サービスプロバイダーの管理負担を軽減するために、米国のSSNと互換性のある識別子を採用する必要があります。
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をCREDITCARD RRと組み合わせて使用して、未払いの税金の徴収を自動化することもできます（MAY）。
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このRRによって記述された個人が生まれたUnixエポックを過ぎた秒数を表す64ビットのタイムスタンプ。 Unixエポックはすべてのインターネットユーザーの誕生よりも前から存在しているため、このフィールドは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エントリを持っている必要があります（SHOULD）。
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が提供する1つの利点は、一部の人口調査機能をリモートで実行できることです。たとえば、加入者ごとにSSNPTR RRを備えた住宅用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 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 KEY RRタイプについて説明しています。これは、ドメインの公開鍵パラメーターを簡単に格納するために使用されます。 SRV RRタイプ[RFC2782]は、名前解決とトランスポート層およびアプリケーション層の詳細を組み合わせて、ネットワーク管理者が特定のサービスの場所をアドバタイズする「煩わしくない」方法を提供します。 Name Authority PTR（NAPTR）RR [RFC2915]は、DNSでのPOSIX拡張正規表現サポートの欠如を認識および修正し、他のユースケースの中でDNSベースの自動車部品識別システム[RFC3402]を可能にしました。 [RFC2539]での暗号化におけるDNSの役割を確立したIPSECKEY RRは、IPsec暗号化の目的で公開鍵パラメータを保存するために廃止された機能を復活させました[RFC4025]。 [RFC4255]は、サーバーのホストキーを検証するために使用されるSSHFP RRタイプを提供することにより、Secure Shell（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]は、X.509およびPGP証明書を公開するためのCERT RRタイプを導入しました。 [RFC4701]は、動的ホスト構成プロトコル（DHCP）クライアントがDHCPリースを取得した後にDNS更新を行うときの完全修飾ドメイン名（FQDN）の衝突の問題を解決するDHCID RRタイプを導入します。 TLSA RRタイプ[RFC6698]は、TLSSEC証明書をドメインに関連付けて、DNSSECをバインディングとして利用し、CAA RRタイプ[RFC6844]は、ドメインの証明書を発行できる認証局を指定します。 [RFC7043]で指定されているEUI48およびEUI64 RRタイプは、本質的にMACアドレスのAレコードを作成することにより、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]は、データの整合性を提供するために、PASSWORD、CREDITCARD、SSN、およびSSNPTR RRタイプと組み合わせて使用する必要があります（SHOULD）。 DNSSECを採用すると、これらのRRに含まれるデータが信頼できるソースから発信されたものであり、たとえば、攻撃者がPASSWORD 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/>.
[キャメル] Hubert、B。、「The DNS Camel」、2018年3月、<https://blog.powerdns.com/2018/03/22/ the-dns-camel-or-the-rise-in-dns- complexit />。
[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]アントナカキス、M。、エイプリル、T。、ベイリー、M。、ベルンハルト、M。、バーズテイン、E。、コクラン、J。、デュルメリック、Z。、ハルダーマン、J。、インヴェルニッツィ、L。、カリティス、 M.、クマール、D。、レバー、C.、Ma、Z。、メイソン、J。、メンシャー、D。、シーマン、C。、サリバン、N。、トーマス、K。、およびY. Zhou、「理解未来ボットネット」、第26回USENIXセキュリティシンポジウムの議事録、2017年8月、<https://www.usenix.org/system/files/conference/usenixsecurity17/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]デイビス、C。、ビクシー、P。、グッドウィン、T。、およびI.ディキンソン、「ドメインネームシステムで位置情報を表現するための手段」、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。、「Storage of Diffie-Hellman Keys in the Domain Name System（DNS）」、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 RR（DNS SRV）」、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、「The Naming Authority Pointer（NAPTR）DNS Resource Record」、RFC 2915、DOI 10.17487 / RFC2915、2000年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。、「Dynamic Delegation Discovery System（DDDS）Part Two：The Algorithm」、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。、「A Method for Storing IPsec Keying Material in DNS」、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、編、「The Secure Shell（SSH）Transport Layer Protocol」、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を使用したSecure Shell（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 Certification Authority Authorization（CAA）Resource Record」、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：The Internet Measurement Standard」、<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.
また、過去数十年のDNS対応機能の干ばつにちなんで名付けられたブログポストとIETF講義「DNSキャメル[CAMEL]」でDNS RR標準の不足を特定してくれたバートヒューバートにも感謝します。
Authors' Addresses
著者のアドレス
Erik C. Rye CMAND 1 University Circle Monterey, CA 93943 United States of America
エリックC.ライCMAND 1ユニバーシティサークルモントレー、カリフォルニア州93943アメリカ合衆国
Email: rye@cmand.org
Robert Beverly CMAND 1 University Circle Monterey, CA 93943 United States of America
ロバートビバリーCMAND 1ユニバーシティサークルモントレー、カリフォルニア州93943アメリカ合衆国
Email: rbeverly@cmand.org