[Joke-RFC] RFC8567 顧客管理 DNS リソースレコード

はじめに

• この文書は RFC8567 を勉強と好奇心のため適当に訳したものです。
• 翻訳の正確さは全く保証しません。
• 誤字誤訳等の指摘はいつでも大歓迎です。

Customer Management DNS Resource Records（顧客管理 DNS リソースレコード）

• Independent Submission
• Request for Comments: 8567
• Category: Informational
• ISSN: 2070-1721

• E. Rye
• R. Beverly
• CMAND
• 1 April 2019

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.

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.

高い経験品質 (Quality of Experience; QoE) を維持するためには、マネージド CPE (Customer Premises Equipment) を含むエンドツーエンドの総合的なネットワーク管理がますます必要になってきている。
顧客管理は世界共通の責任であるため、ドメインネームシステム (DNS) は、迅速、確実、かつ一般にアクセス可能でなければならない権威ある顧客情報を維持するための理想的な既存のインフラストラクチャを提供する。

本文書は、DNS において顧客情報を符号化するための 4 つの新しい DNS リソースレコードタイプについて記述している。
これらのレコードは、プロバイダー間の協力と顧客データの管理により、顧客の高い QoE をより促進することを目的としている。

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.

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.

この文書はインターネット標準化過程の仕様ではなく、情報提供の目的で発行されたものである。

この文書は、他のいかなるRFCストリームとも無関係に、RFCシリーズに貢献するものである。
RFCエディターは自らの裁量でこの文書の公開を選択し、その実装や配備の価値について何ら表明するものではない。
RFCエディターによって発行が承認された文書は、どのレベルのインターネット標準の候補にもならない。

この文書の現在の状態、正誤表、それに対するフィードバックの提供方法に関する情報は、 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.

   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.

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（序論）

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].

残念ながら、宅内機器 (Customer Premises Equipment; 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 の選択である。
顧客がプロバイダーを変えても、経歴や課金、技術的な詳細は変わらない。
したがって、サービスプロバイダーは、顧客のネットワークへの移行およびネットワークからの退出を、技術的および請求書の両方の観点から可能な限りシームレスに行うためのメカニズムを必要としている。

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 リソースレコード (Resource Record; 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 のメンテナンスの共有を可能にするため、本文書は RFC1034 [RFC1034] と RFC1035 [RFC1035] で説明されているドメインネームシステム (DNS) を活用し、ネットワーク管理を支援する新しい RR タイプを導入する。

1.1. Terminology（用語解説）

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.

本文書では、登録された RR タイプを使用するための要件を記述するために、「MUST」や「MAY」といった大文字のキーワードを使用する。
本文書におけるこれらのキーワードの意図する意味は、RFC 2119 [RFC2119] および RFC 8174 [RFC8174] に記述されているものと同じである。
これらのキーワードは、IETF 標準における規範的な要件を指定するためによく使用されるが、本文書におけるこれらのキーワードの使用は、本文書がいかなる種類の標準であることを意味するものでもない。

2. Customer Management Resource Records（顧客管理リソースレコード）

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?

This document introduces four new RRs to assist in the management of customer data by ISPs.

This section describes the purpose and wire format of the new DNS RRs.

家庭用ブロードバンドインターネットサービスの普及は、消費者に無数の利益をもたらすが、インターネットサービスプロバイダにとって、ネットワーク上の CPE デバイスの回復力とセキュリティを確保しながら、機密性の高い顧客識別と請求の詳細をどのように管理するのが最善か、という困難な課題も提起している。

この文書では、ISP による顧客データの管理を支援するために、4 つの新しい RR を導入している。

ここでは、新しい DNS RR の目的とワイヤーフォーマットを説明する。

2.1. The PASSWORD Resource Record（PASSWORD リソースレコード）

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 は、CPE のログイン認証情報を 1 つの RR で提供することにより、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

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 文字でなければならず、句読点を含んではならない (MUST NOT)。

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.

USERNAME に関連付けられた <character-string> のパスワード。
RR サイズを最小にするため、32ビットより長いパスワードはサポートされていない。

Hosts on which multiple accounts exist SHOULD have separate PASSWORD RRs for each account.

複数のアカウントが存在するホストは、アカウントごとに別々の PASSWORD RR を持つべきである (SHOULD)。

2.2. The CREDITCARD Resource Record（CREDITCARD リソースレコード）

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 にその課金詳細を入力し、自動課金目的で必要なときに照会してもよい (MAY)。
さらに、顧客が定期的な支払い計画を策定する外部組織は、同様にこの 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

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.

ホストのサービスプロバイダが請求に使用する <character-string> 16桁のクレジットカード番号。
このフィールドは句読点やスペースを含んではいけない (MUST NOT)。ASCIIで表現された数字のみが許可される。
このフィールドの長さは 16 桁なので、ユーザーはアメリカンエキスプレスカードを使用してはならない (MUST NOT)。

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.

クレジットカードの有効期限を月と年を2桁で指定した <character-string> である。
このフィールドは句読点やスペースを含んではいけない (MUST NOT)。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.

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.

Note that this novel use of Luhn's algorithm MAY have applications outside of the CREDITCARD RR.

CARDNUMBER フィールドで発生するビットエラーから保護するために、この RR タイプは 以下のようなエラーチェックを使用しなければならない(MUST)。
Luhn アルゴリズムは、16 桁の数字が転送中に破損していないことを検証するための単純なチェックサムとして採用される。
左端の桁から始めて、その桁の値を合計し、ただし 2 桁ごとに (左から 2 番目の桁から)、その値の2倍を合計する。
この作業を 16 桁の数字を使い切るまで続ける。
この部分和を手に入れたら、部分和に x を加えると 10 のモジュロで 0 と合同になるような値 x を解き、x を CHECKSUM フィールドに格納する。

CREDITCARD RR が照会されたとき、受信者は上記と同じ方法で Luhn アルゴリズムを計算し、計算された x の値が CHECKSUM フィールドに格納された値と一致するかどうかを検証するだけである。

Luhn のアルゴリズムのこの新しい使用法は、CREDITCARD RR 以外にも応用できるかもしれないことに注意すること。

訳注：本来の Luhn アルゴリズムは、別名「モジュラス10 ウェイト2・1分割」と言うように、「分割」する（2倍したあと、10以上になった場合、10の位の値と1の位の値を合計する）必要があるが、上記説明ではそれが抜けている。ちなみに、クレジットカード番号の16桁目は、この Luhn アルゴリズムのチェックデジットになっている。

2.3. The SSN Resource Record（SSN リソースレコード）

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.

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 は、ホスト名をそのホストに位置するユーザーの米国社会保障番号と生年月日にマップする。
CPE の後ろに複数のユーザーが存在する場合には、各ユーザーに対して個別の SSN RR が DNS に入力されるべきである (SHOULD)。
住宅用ブロードバンドサービスが米国外で利用可能になった場合、これらの国は、DNS と多国籍サービスプロバイダの管理負担を軽減するために、米国の SSN と互換性のある識別子を採用すべきである (SHOULD)。

納税準備期間中、米国内国歳入庁は居住地とホスト名所有者の証明を確認するために 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

Where:

SOCIAL

The Social Security number of the user associated with the host, formatted as a 32-bit unsigned integer in network byte order.

ホストに関連するユーザーの社会保障番号で、ネットワークバイトオーダーの 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.

64 ビットのタイムスタンプで、この RR で記述される個人が生まれた Unix Epoch から何秒経過したかを表す。
Unix Epoch はすべてのインターネットユーザーの誕生より前のものなので、このフィールドは ISP が加入者を記述するために十分な値の幅を提供する。
64 ビットのタイムスタンプフィールドはまた、2038 年問題を回避し、SSN RR の適用性を予測可能な将来にわたって保証する「future proof」である。

2.4. The SSNPTR Resource Record（SSNPTR リソースレコード）

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.

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 は SSN RR の逆の機能を提供する; つまり、社会保障番号をホスト名にマップする。
ISP がサービスを提供するすべての個人は、主要なアカウント所有者だけでなく、 DNS に SSNPTR RR エントリを持つべきである (SHOULD)。

SSNPTR RR がもたらす利点の 1 つは、一部の人口調査機能をリモートで実行できることである。
例えば、住宅用 ISP が、その加入者ごとに SSNPTR RR を持っているとする。
すべての加入者の 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

Where:

DNAME

A <domain-name> that points to a location in the domain name space.

ドメイン名空間内の場所を指す <domain-name> である。

3. Related RR Types（関連する RR タイプ）

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 (Dynamic Host Configuration Protocol) クライアントが DHCP リース取得後に DNS 更新を行う際の FQDN (Fully Qualified Domain Name) 衝突の問題を解決するために、 DHCID RR タイプを導入している。
TLSA RR タイプ [RFC6698] は、バインドとして DNSSEC を活用し、TLS 証明書をドメインと関連付けるために使用され、CAA RR タイプ [RFC6844] は、ドメインに対して証明書を発行することを許可された認証局を指定するものである。
[RFC7043] で指定された EUI48 および EUI64 RR タイプは、本質的に MAC アドレスの A レコードを作成することで、TCP/IP モデルにおける境界をなくそうとするものである。

4. IANA Considerations（IANAに関する考慮事項）

This document has no IANA actions.

この文書には IANA アクションはない。

5. Security Considerations（セキュリティに関する考慮事項）

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 に対する正当なリクエストに応答して無効なログイン資格を提供しようとする攻撃者でないことが保証される。

6. References

6.1. Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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>.

6.2. Informative References

   [CAMEL]    Hubert, B., "The DNS Camel", March 2018,
              <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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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>.

   [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.

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.

我々は、米国連邦通信委員会がネットワーク中立性に関する法律を廃止し、顧客に ISP が期待する水準と種類のサービスを提供できるようになったことに感謝します。

また、バート・ヒューバート氏が、過去数十年にわたる DNS 対応機能の旱魃にちなんで名付けられた「DNS Camel [CAMEL]」と題するブログ投稿と IETF 講演で、DNS RR 標準の少なさを明らかにしたことに感謝します。

Authors' Addresses

   Erik C. Rye
   CMAND
   1 University Circle
   Monterey, CA  93943
   United States of America

   Email: [e-mail]


   Robert Beverly
   CMAND
   1 University Circle
   Monterey, CA  93943
   United States of America

   Email: [e-mail]