[要約] RFC 8553は、アンダースコアでノード名を使用する仕様を修正するためのものであり、DNSの属性葉の変更に関するものです。その目的は、アンダースコアを使用することによる問題を解決し、より一貫性のある仕様を提供することです。
Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 8553 Brandenburg InternetWorking
BCP: 222 March 2019
Updates: 2782, 3263, 3529, 3620, 3832,
3887, 3958, 4120, 4227, 4386,
4387, 4976, 5026, 5328, 5389,
5415, 5518, 5555, 5617, 5679,
5766, 5780, 5804, 5864, 5928,
6120, 6186, 6376, 6733, 6763,
7208, 7489, 8145
Category: Best Current Practice
ISSN: 2070-1721
DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names
DNS AttrLeafの変更：下線付きノード名を使用する仕様の修正
Abstract
概要
Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.
プレフィックスにアンダースコアを使用すると、リソースレコードの制限された相互運用のためのスペースが作成されます。ドメインノード名のプレフィックスとしてのアンダースコア文字の元の使用は、IANAレジストリの利点なしで指定されました。これにより、完全に調整されていない名前作成アクティビティのセットが生成され、すべて同じ名前空間から取得されました。これらの名前のレジストリはRFC 8552で定義されています。ただし、下線付きの名前を使用する既存の仕様は、新しいレジストリと一致するように変更する必要があります。このドキュメントでは、それらの変更について説明します。これらの変更により、既存のソフトウェアと運用慣行が維持され、これらの慣行の仕様が新しいアンダースコアレジストリモデルに適合します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc8553.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8553で入手できます。
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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Underscored RRset Use in Specifications . . . . . . . . . . . 3
2.1. TXT RRset . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SRV RRset . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. URI RRset . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Underscored Template Specifications . . . . . . . . . . . . . 7
3.1. SRV Specification Changes . . . . . . . . . . . . . . . . 7
3.2. URI Specification Changes . . . . . . . . . . . . . . . . 8
3.3. DNSSEC Signaling Specification Changes . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Original uses of an underscore character as a domain node name [RFC1035] prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an IANA registry [IANA-reg]. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry has now been defined (see Section 4 of [RFC8552]); the RFC that defined it discusses the background for the use of underscored domain names [RFC8552].
リソースレコードの制約付き解釈のためのスペースを作成するドメインノード名[RFC1035]プレフィックスとしての下線文字の元の使用は、IANAレジストリ[IANA-reg]の利点なしに指定されました。これにより、完全に調整されていない名前作成アクティビティのセットが生成され、すべて同じ名前空間から取得されました。レジストリが定義されました（[RFC8552]のセクション4を参照）。それを定義したRFCは、下線の付いたドメイン名[RFC8552]の使用の背景について説明しています。
The basic model for underscored name registration, as specified in [RFC8552], is to have each registry entry be unique in terms of the combination of a resource record type and a "global" (highest-level) underscored node name; that is, the node name beginning with an underscore that is the closest to the DNS root.
[RFC8552]で指定されている、下線付きの名前登録の基本モデルは、各レジストリエントリを、リソースレコードタイプと「グローバル」（最上位）の下線付きノード名の組み合わせに関して一意にすることです。つまり、DNSルートに最も近いアンダースコアで始まるノード名です。
The specifications describing the existing uses of underscored naming do not reflect the existence of this integrated registry. For the new reader or the new editor of one of those documents, there is currently nothing signaling that the underscored name(s) defined in the document are now processed through an IANA registry. This document remedies that, by marking such a published document with an update that indicates the nature of the change.
下線付きの命名の既存の使用法を説明する仕様は、この統合レジストリの存在を反映していません。これらのドキュメントのいずれかの新しいリーダーまたは新しいエディターの場合、現在、ドキュメントで定義されているアンダースコア付きの名前がIANAレジストリを通じて処理されていることを示すものは何もありません。このドキュメントは、そのような公開されたドキュメントを変更の性質を示す更新でマークすることによってそれを修正します。
Further, the documents that define the SRV [RFC2782] and URI [RFC7553] DNS resource records provide a meta-template for underscored name assignments, partially based on separate registries [RFC6335]. For the portion that selects the global (highest-level) underscored node name, this perpetuates uncoordinated assignment activities by separate technical specifications, out of the same namespace. This document remedies that by providing detail for revisions to the SRV and URI specifications to bring their use in line with the single, integrated "Underscored and Globally Scoped DNS Node Names" registry.
さらに、SRV [RFC2782]およびURI [RFC7553] DNSリソースレコードを定義するドキュメントは、部分的に個別のレジストリ[RFC6335]に基づいて、アンダースコア付きの名前割り当てのメタテンプレートを提供します。グローバル（最上位）の下線付きノード名を選択する部分については、これにより、同じ名前空間から、個別の技術仕様によって調整されていない割り当てアクティビティが永続化されます。このドキュメントは、SRVおよびURI仕様の改訂の詳細を提供することにより、それらの使用を単一の統合された「アンダースコアおよびグローバルスコープのDNSノード名」レジストリと一致させることで改善します。
The result of these changes preserves existing software and operations practices while adapting the technical specifications to the newer underscore registry model.
これらの変更の結果、技術仕様を新しいアンダースコアレジストリモデルに適合させながら、既存のソフトウェアと操作の実践が維持されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
The use of underscored node names is specific to each RR TYPE that is being scoped. Each name defines a place but does not define the rules for what appears underneath that place, either as additional underscored naming or as a leaf node with resource records. Details for those rules are provided by specifications for individual RR TYPEs. The sections below describe the way that existing underscored names are used with the RR TYPEs that they name.
下線付きのノード名の使用は、スコープされている各RRタイプに固有です。それぞれの名前は場所を定義しますが、その場所の下に表示されるルールを定義しません。追加のアンダースコア付きの名前として、またはリソースレコードを持つリーフノードとして。これらのルールの詳細は、個々のRRタイプの仕様によって提供されます。以下のセクションでは、既存の下線付きの名前が、それらが指定するRRタイプで使用される方法について説明します。
NOTE - Documents falling into this category include: [RFC5518], [RFC5617], [RFC6120], [RFC6376], [RFC6763], [RFC7208], and [RFC7489].
注-このカテゴリに分類されるドキュメントには、[RFC5518]、[RFC5617]、[RFC6120]、[RFC6376]、[RFC6763]、[RFC7208]、および[RFC7489]が含まれます。
This section provides a generic approach for changes to existing specifications that define straightforward use of underscored node names when scoping the use of a TXT RRset. The approach provides the information needed for adapting such specifications to the use of the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. Hence, the approach is meant both as an update to these existing specifications and as guidance for changes when those documents are revised.
このセクションでは、TXT RRsetの使用を範囲指定するときに下線付きのノード名を簡単に使用することを定義する、既存の仕様を変更するための一般的なアプローチを提供します。このアプローチは、IANAの「アンダースコアおよびグローバルスコープのDNSノード名」レジストリ[RFC8552]の使用にそのような仕様を適合させるために必要な情報を提供します。したがって、このアプローチは、これらの既存の仕様の更新と、これらのドキュメントが改訂された場合の変更のガイダンスの両方を意味します。
For any document that specifies the use of a TXT RRset under one or more underscored names, the global node name is expected to be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. An effort has been made to locate existing documents that do this, to register the global underscored node names, and to list them in the initial set of names added to the registry.
TXT RRsetを1つまたは複数の下線付きの名前で使用することを指定しているドキュメントの場合、グローバルノード名はIANAの「アンダースコアおよびグローバルスコープのDNSノード名」レジストリ[RFC8552]に登録されている必要があります。これを行う既存のドキュメントを見つけ、グローバルな下線付きノード名を登録し、レジストリに追加された名前の初期セットにそれらをリストするための努力が行われました。
If a public specification defines use of a TXT RRset and calls for the use of an underscored node name, here is a template of suggested text for registering the global underscored node name -- the one closest to the root -- that can be used through the IANA Considerations section of the specification:
公開仕様がTXT RRsetの使用を定義し、アンダースコア付きのノード名の使用を要求する場合、グローバルアンダースコア付きノード名（ルートに最も近いもの）を登録するための推奨テキストのテンプレートは次のとおりです。仕様のIANAに関する考慮事項セクション：
"Per [RFC8552], please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:"
「[RFC8552]ごとに、「アンダースコアおよびグローバルスコープのDNSノード名」レジストリに次のエントリを追加してください：」
+--------+----------------+-----------------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+--------+----------------+-----------------------------------------+
| TXT | _{DNS node | {citation for the document making the |
| | name} | addition} |
+--------+----------------+-----------------------------------------+
Table 1: Entry for the "Underscored and Globally Scoped DNS Node Names" Registry for TXT RR Use
表1：TXT RRを使用するための「アンダースコアおよびグローバルスコープのDNSノード名」レジストリのエントリ
NOTE - Documents falling into this category include:
注-このカテゴリに該当するドキュメントは次のとおりです。
[RFC3263], [RFC3529], [RFC3620], [RFC3832], [RFC3887],
[RFC3958], [RFC4120], [RFC4227], [RFC4386], [RFC4387],
[RFC4976], [RFC5026], [RFC5328], [RFC5389], [RFC5415],
[RFC5555], [RFC5679], [RFC5766], [RFC5780], [RFC5804],
[RFC5864], [RFC5928], and [RFC6186].
Specification of the SRV resource record [RFC2782] provides a template for use of underscored node names. The global node name is characterized as referencing the 'protocol' that is associated with SRV RRset usage.
SRVリソースレコードの仕様[RFC2782]は、下線付きのノード名を使用するためのテンプレートを提供します。グローバルノード名は、SRV RRsetの使用に関連付けられている「プロトコル」を参照するものとして特徴付けられます。
This section provides a generic approach for changes to existing specifications that define the use of an SRV RRset. The approach provides the information needed for adapting such specifications to the use of the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. Hence, the approach is meant both as an update to these existing specifications and as guidance for changes when those documents are revised.
このセクションでは、SRV RRsetの使用を定義する既存の仕様を変更するための一般的なアプローチについて説明します。このアプローチは、IANAの「アンダースコアおよびグローバルスコープのDNSノード名」レジストリ[RFC8552]の使用にそのような仕様を適合させるために必要な情報を提供します。したがって、このアプローチは、これらの既存の仕様の更新と、これらのドキュメントが改訂された場合の変更のガイダンスの両方を意味します。
For any document that specifies the use of an SRV RRset, the global ('protocol') underscored node name is expected to be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. An effort has been made to locate existing documents that do this, to register the global underscored node names, and to list them in the initial set of names added to the registry.
SRV RRsetの使用を指定するドキュメントの場合、グローバル（「プロトコル」）の下線付きノード名は、IANAの「下線付きおよびグローバルスコープのDNSノード名」レジストリ[RFC8552]に登録されることが期待されています。これを行う既存のドキュメントを見つけ、グローバルな下線付きノード名を登録し、レジストリに追加された名前の初期セットにそれらをリストするための努力が行われました。
If a public specification defines use of an SRV RRset and calls for the use of an underscored node name, here is a template of suggested text for registering the global underscored node name -- the one closest to the root -- that can be used through the IANA Considerations section of the specification:
公開仕様がSRV RRsetの使用を定義し、アンダースコア付きのノード名の使用を要求する場合、以下に使用できるグローバルアンダースコア付きノード名（ルートに最も近いもの）を登録するための推奨テキストのテンプレートを次に示します仕様のIANAに関する考慮事項セクション：
"Per [RFC8552], please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:
「[RFC8552]ごとに、「アンダースコアおよびグローバルスコープのDNSノード名」レジストリに次のエントリを追加してください：
+--------+----------------------+-----------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+--------+----------------------+-----------------------------------+
| SRV | _{DNS 'protocol' | {citation for the document making |
| | node name} | the addition} |
+--------+----------------------+-----------------------------------+
Table 2: Entry for the "Underscored and Globally Scoped DNS Node Names" Registry for SRV RR Use
表2：SRV RRを使用するための「アンダースコアおよびグローバルスコープのDNSノード名」レジストリのエントリ
Specification of the URI resource record [RFC7553] provides a template for use of underscored node names. The global node name is characterized as naming the 'protocol' that is associated with URI RR usage or by reversing an Enumservice sequence [RFC6117].
URIリソースレコードの仕様[RFC7553]は、下線付きのノード名を使用するためのテンプレートを提供します。グローバルノード名は、URI RRの使用に関連付けられた「プロトコル」に名前を付けるか、Enumserviceシーケンスを逆にすることで特徴付けられます[RFC6117]。
This section provides a generic approach for changes to existing specifications that define use of a URI RRset. The approach provides the information needed for adapting such specifications to the use of the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. Hence, the approach is meant both as an update to these existing specifications and as guidance for changes when those documents are revised.
このセクションでは、URI RRsetの使用を定義する既存の仕様を変更するための一般的なアプローチについて説明します。このアプローチは、IANAの「アンダースコアおよびグローバルスコープのDNSノード名」レジストリ[RFC8552]の使用にそのような仕様を適合させるために必要な情報を提供します。したがって、このアプローチは、これらの既存の仕様の更新と、これらのドキュメントが改訂された場合の変更のガイダンスの両方を意味します。
For any document that specifies the use of a URI RRset, the global ('protocol' or highest-level Enumservice) underscored node name is expected to be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. An effort has been made to locate existing documents that do this, to register the global underscored node names, and to list them in the initial set of names added to the registry.
URI RRsetの使用を指定するドキュメントの場合、グローバル（「プロトコル」または最高レベルのEnumservice）下線付きノード名は、IANAの「下線付きおよびグローバルスコープのDNSノード名」レジストリ[RFC8552]に登録されることが期待されます。これを行う既存のドキュメントを見つけ、グローバルな下線付きノード名を登録し、レジストリに追加された名前の初期セットにそれらをリストするための努力が行われました。
If a public specification defines use of a URI RRset and calls for the use of an underscored node name, here is a template of suggested text for registering the global underscored node name -- the one closest to the root -- that can be used through the IANA Considerations section of the specification:
パブリック仕様がURI RRsetの使用を定義し、アンダースコア付きのノード名の使用を要求する場合、グローバルアンダースコア付きノード名（ルートに最も近いもの）を登録するための推奨テキストのテンプレートは次のとおりです。仕様のIANAに関する考慮事項セクション：
"Per [RFC8552], please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:
「[RFC8552]ごとに、「アンダースコアおよびグローバルスコープのDNSノード名」レジストリに次のエントリを追加してください：
+-------+----------------------------+------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+-------+----------------------------+------------------------------+
| URI | _{DNS 'protocol' or | {citation for the document |
| | Enumservice node name} | making the addition} |
+-------+----------------------------+------------------------------+
Table 3: Entry for the "Underscored and Globally Scoped DNS Node Names" Registry for URI RR Use
表3：URI RRを使用するための「アンダースコアおよびグローバルスコープのDNSノード名」レジストリのエントリ
The specification for a domain name, under which an SRV resource record [RFC2782] appears, provides a template for use of underscored node names. The global underscored node name is characterized as indicating the 'protocol' that is associated with SRV RR usage.
SRVリソースレコード[RFC2782]が表示されるドメイン名の仕様は、下線付きのノード名を使用するためのテンプレートを提供します。下線付きのグローバルノード名は、SRV RRの使用に関連付けられている「プロトコル」を示すものとして特徴付けられます。
The text of [RFC2782] is changed as described below. In addition, note that a normative reference to RFC 8552 is added to the References section of RFC 2782.
[RFC2782]の文章を以下のように変更しました。また、RFC 2782の参照セクションにRFC 8552への規範的な参照が追加されていることに注意してください。
OLD:
古い：
The format of the SRV RR
SRV RRのフォーマット
Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target ... Proto The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive.
DNSタイプコードが33であるSRV RRの形式は次のとおりです。_Service._Proto.Name TTLクラスSRV優先度重みポートターゲット...プロト衝突を防ぐためにアンダースコア（_）を前に付けた、目的のプロトコルの記号名。自然に発生するDNSラベルを使用します。 _TCPおよび_UDPは現在、このフィールドで最も有用な値ですが、割り当てられた番号またはローカルで定義された任意の名前を使用できます（サービスの場合と同様）。プロトは大文字と小文字を区別しません。
NEW:
新着：
The format of the SRV RR
SRV RRのフォーマット
Here is the format of the SRV RR, whose DNS type code is 33:
DNSタイプコードが33であるSRV RRの形式は次のとおりです。
"_Service._Proto.Name TTL Class SRV Priority Weight Port Target"
「_Service._Proto.Name TTL Class SRV Priority Weight Port Target」
_..._
＿。。。＿
Proto
したがって
The symbolic name of the desired protocol with an underscore (e.g., "_name") prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field. The Proto is case insensitive.
自然に発生するDNSラベルとの衝突を防ぐために、アンダースコアを前に付けた目的のプロトコルの記号名（「_name」など）。 _TCPと_UDPは現在、このフィールドで最も有用な値です。プロトは大文字と小文字を区別しません。
The SRV RRset 'protocol' (global) underscored node name SHOULD be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552].
SRV RRset 'プロトコル'（グローバル）アンダースコア付きノード名は、IANA "アンダースコア付きおよびグローバルスコープのDNSノード名"レジストリ[RFC8552]に登録する必要があります（SHOULD）。
Specification for the domain name (under which a URI resource record [RFC7553] occurs) is similar to that for the SRV resource record [RFC2782], although the text refers only to 'service' name, rather than distinguishing 'service' from 'protocol'. Further, the URI RR specification permits alternative underscored naming schemes:
（URIリソースレコード[RFC7553]が発生する）ドメイン名の仕様はSRVリソースレコード[RFC2782]の仕様と似ていますが、テキストは「サービス」と「プロトコル」を区別するのではなく、「サービス」名のみを参照しています'。さらに、URI RR仕様では、下線付きの代替命名スキームを許可しています。
One matches what is used for SRV, with the global underscored node name called 'protocol'.
1つはSRVで使用されるものと一致し、「プロトコル」と呼ばれる下線付きのグローバルノード名を持ちます。
The other is based on a reversing of an Enumservice [RFC6117] sequence.
もう1つは、Enumservice [RFC6117]シーケンスの逆転に基づいています。
Text of [RFC7553] is changed as described below. In addition, a normative reference to RFC 8552 is added to the References section of RFC 7553.
[RFC7553]のテキストを以下のように変更しました。さらに、RFC 8553の規範的な参照がRFC 7553の参照セクションに追加されています。
OLD:
古い：
4.1. Owner Name, Class, and Type
4.1. 所有者の名前、クラス、およびタイプ
The URI owner name is subject to special conventions.
URI所有者名は、特別な規則に従います。
Just like the SRV RR [RFC2782], the URI RR has service information
encoded in its owner name. In order to encode the service for a
specific owner name, one uses service parameters. Valid service
parameters are those registered by IANA in the "Service Name and
Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice
---
Registrations [RFC6117]. The Enumservice Registration parameters are
reversed (i.e., subtype(s) before type), prepended with an underscore
(_), and prepended to the owner name in separate labels. The
underscore is prepended to the service parameters to avoid collisions
with DNS labels that occur in nature, and the order is reversed to
make it possible to do delegations, if needed, to different zones
(and therefore providers of DNS).
For example, suppose we are looking for the URI for a service with ENUM Service Parameter "A:B:C" for host example.com. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI").
たとえば、ホストexample.comのENUMサービスパラメータ「A：B：C」を持つサービスのURIを探しているとします。次に、（QNAME、QTYPE）=（ "_ C._B._A.example.com"、 "URI"）を照会します。
As another example, suppose we are looking for the URI for a service with Service Name "A" and Transport Protocol "B" for host example.com. Then we would query for (QNAME,QTYPE)=("_A._B.example.com","URI").
別の例として、ホストexample.comのサービス名「A」とトランスポートプロトコル「B」を持つサービスのURIを探しているとします。次に、（QNAME、QTYPE）=（ "_ A._B.example.com"、 "URI"）を照会します。
NEW:
新着：
4.1. Owner Name, Class, and Type
4.1. 所有者の名前、クラス、およびタイプ
The URI owner name is subject to special conventions.
URI所有者名は、特別な規則に従います。
As for the SRV RRset [RFC2782], the URI RRset global (highest-level) underscored node name SHOULD be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552].
SRV RRset [RFC2782]と同様に、URI RRsetグローバル（最高レベル）の下線付きノード名は、IANA "下線付きおよびグローバルスコープのDNSノード名"レジストリ[RFC8552]に登録する必要があります（SHOULD）。
Just like the SRV RRset, the URI RRset has service information encoded in its owner name. In order to encode the service for a specific owner name, one uses service parameters. Valid service parameters are:
SRV RRsetと同様に、URI RRsetには所有者名でエンコードされたサービス情報があります。特定の所有者名のサービスをエンコードするには、サービスパラメータを使用します。有効なサービスパラメータは次のとおりです。
+ Those registered by IANA in the "Service Name and Transport Protocol Port Number Registry" [RFC6335]. The underscore is prepended to the service parameters to avoid collisions with DNS labels that occur in nature, and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS).
+「サービス名およびトランスポートプロトコルのポート番号レジストリ」[RFC6335]にIANAによって登録されたもの。実際に発生するDNSラベルとの衝突を回避するために、アンダースコアがサービスパラメータの前に追加され、必要に応じて異なるゾーン（したがってDNSのプロバイダー）に委任を実行できるように順序が逆になります。
+ Those listed in "Enumservice Registrations" [RFC6117]. The Enumservice Registration parameters are reversed (i.e., subtype(s) before type), prepended with an underscore (e.g., "_name"), and prepended to the owner name in separate labels. The highest-level (global) underscored Enumservice name becomes the global name per RFC 8552 to register.
+ 「Enumservice Registrations」[RFC6117]にリストされているもの。 Enumservice登録パラメーターは逆になり（つまり、タイプの前のサブタイプ）、先頭に下線（たとえば、「_ name」）が追加され、別のラベルで所有者名の先頭に追加されます。最上位（グローバル）の下線付きのEnumservice名は、登録するRFC 8552に基づくグローバル名になります。
For example, suppose we are looking for the URI for a service with ENUM Service Parameter "A:B:C" for host example.com. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI").
たとえば、ホストexample.comのENUMサービスパラメータ「A：B：C」を持つサービスのURIを探しているとします。次に、（QNAME、QTYPE）=（ "_ C._B._A.example.com"、 "URI"）を照会します。
As another example, suppose we are looking for the URI for a service with Service Name "A" and Transport Protocol "B" for host example.com. Then we would query for (QNAME,QTYPE)=("_A._B.example.com","URI").
別の例として、ホストexample.comのサービス名「A」とトランスポートプロトコル「B」を持つサービスのURIを探しているとします。次に、（QNAME、QTYPE）=（ "_ A._B.example.com"、 "URI"）を照会します。
"Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)" [RFC8145] defines a use of DNS node names that effectively consumes all names beginning with the string "_ta-" when using the NULL RR in the query.
「DNS Security Extensions（DNSSEC）のシグナルトラストアンカーナレッジ」[RFC8145]は、クエリでNULL RRを使用するときに文字列「_ta-」で始まるすべての名前を効率的に消費するDNSノード名の使用を定義します。
Text of Section 5.1, "Query Format", of RFC 8145 is changed as described below. In addition, a normative reference to RFC 8552 is added to the References section of RFC 8145.
RFC 8145のセクション5.1「Query Format」のテキストは、以下のように変更されています。さらに、RFC 8145の参照セクションにRFC 8552への規範的な参照が追加されています。
OLD:
古い：
For example, a validating DNS resolver ... QNAME=_ta-4444.
たとえば、検証中のDNSリゾルバー... QNAME = _ta-4444。
NEW:
新着：
For example, a validating DNS resolver ... "QNAME=_ta-4444".
たとえば、検証中のDNSリゾルバー... "QNAME = _ta-4444"。
Under the NULL RR, an entry is registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552] for all node names beginning with "_ta-".
NULL RRの下では、「_ ta-」で始まるすべてのノード名のエントリがIANAの「アンダースコアおよびグローバルスコープのDNSノード名」レジストリ[RFC8552]に登録されています。
Although this document makes reference to IANA registries, it introduces no new IANA registries or procedures.
このドキュメントではIANAレジストリを参照していますが、新しいIANAレジストリや手順は紹介していません。
This memo raises no security issues.
このメモはセキュリティ上の問題を引き起こしません。
[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>。
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations", RFC 6117, DOI 10.17487/RFC6117, March 2011, <https://www.rfc-editor.org/info/rfc6117>.
[RFC6117] Hoeneisen、B.、Mayrhofer、A。、およびJ. Livingood、「EnumservicesのIANA登録：ガイド、テンプレート、およびIANAに関する考慮事項」、RFC 6117、DOI 10.17487 / RFC6117、2011年3月、<https：// www .rfc-editor.org / info / rfc6117>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc6335>。
[RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015, <https://www.rfc-editor.org/info/rfc7553>.
[RFC7553] Faltstrom、P。およびO. Kolkman、「The Uniform Resource Identifier（URI）DNS Resource Record」、RFC 7553、DOI 10.17487 / RFC7553、2015年6月、<https://www.rfc-editor.org/info / rfc7553>。
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC 8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-editor.org/info/rfc8145>.
[RFC8145] Wessels、D.、Kumari、W。、およびP. Hoffman、「Signaling Trust Anchor Knowledge in DNS Security Extensions（DNSSEC）」、RFC 8145、DOI 10.17487 / RFC8145、2017年4月、<https：// www。 rfc-editor.org/info/rfc8145>。
[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>。
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.
[RFC8552] Crocker、D。、「属性リーフの「アンダースコア付き」命名によるDNSリソースレコードのスコープ付き解釈」、RFC 8552、DOI 10.17487 / RFC8552、2019年3月、<https://www.rfc-editor.org/info / rfc8552>。
[IANA-reg] IANA, "Protocol Registries", <https://www.iana.org/protocols>.
[IANA-reg] IANA、「プロトコルレジストリ」、<https://www.iana.org/protocols>。
[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>。
[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>。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、DOI 10.17487 / RFC3263、2002年6月、<https://www.rfc-editor.org/info / rfc3263>。
[RFC3529] Harold, W., "Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3529, DOI 10.17487/RFC3529, April 2003, <https://www.rfc-editor.org/info/rfc3529>.
[RFC3529] Harold、W。、「Blocks Extensible Exchange Protocol（BEEP）でのExtensible Markup Language-Remote Procedure Calling（XML-RPC）の使用」、RFC 3529、DOI 10.17487 / RFC3529、2003年4月、<https：// www。 rfc-editor.org/info/rfc3529>。
[RFC3620] New, D., "The TUNNEL Profile", RFC 3620, DOI 10.17487/RFC3620, October 2003, <https://www.rfc-editor.org/info/rfc3620>.
[RFC3620]新規、D。、「The TUNNEL Profile」、RFC 3620、DOI 10.17487 / RFC3620、2003年10月、<https://www.rfc-editor.org/info/rfc3620>。
[RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV", RFC 3832, DOI 10.17487/RFC3832, July 2004, <https://www.rfc-editor.org/info/rfc3832>.
[RFC3832] Zhao、W.、Schulzrinne、H.、Guttman、E.、Bisdikian、C。、およびW. Jerome、「DNS SRVによるService Location Protocol（SLP）でのリモートサービス検出」、RFC 3832、DOI 10.17487 / RFC3832、2004年7月、<https://www.rfc-editor.org/info/rfc3832>。
[RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, DOI 10.17487/RFC3887, September 2004, <https://www.rfc-editor.org/info/rfc3887>.
[RFC3887] Hansen、T。、「Message Tracking Query Protocol」、RFC 3887、DOI 10.17487 / RFC3887、2004年9月、<https://www.rfc-editor.org/info/rfc3887>。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005, <https://www.rfc-editor.org/info/rfc3958>.
[RFC3958] Daigle、L。およびA. Newton、「SRV RRおよび動的委任発見サービス（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、DOI 10.17487 / RFC3958、2005年1月、<https：// www .rfc-editor.org / info / rfc3958>。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/info/rfc4120>.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、DOI 10.17487 / RFC4120、2005年7月、<https：// www.rfc-editor.org/info/rfc4120>。
[RFC4227] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 4227, DOI 10.17487/RFC4227, January 2006, <https://www.rfc-editor.org/info/rfc4227>.
[RFC4227] O'Tuathail、E。およびM. Rose、「Blocks Extensible Exchange Protocol（BEEP）でのシンプルオブジェクトアクセスプロトコル（SOAP）の使用」、RFC 4227、DOI 10.17487 / RFC4227、2006年1月、<https：// www.rfc-editor.org/info/rfc4227>。
[RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key Infrastructure Repository Locator Service", RFC 4386, DOI 10.17487/RFC4386, February 2006, <https://www.rfc-editor.org/info/rfc4386>.
[RFC4386] Boeyen、S。およびP. Hallam-Baker、「Internet X.509 Public Key Infrastructure Repository Locator Service」、RFC 4386、DOI 10.17487 / RFC4386、2006年2月、<https://www.rfc-editor.org / info / rfc4386>。
[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February 2006, <https://www.rfc-editor.org/info/rfc4387>.
[RFC4387] Gutmann、P。、編、「インターネットX.509公開鍵インフラ運用プロトコル：HTTP経由の証明書ストアアクセス」、RFC 4387、DOI 10.17487 / RFC4387、2006年2月、<https：//www.rfc-editor .org / info / rfc4387>。
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, <https://www.rfc-editor.org/info/rfc4976>.
[RFC4976] Jennings、C.、Mahy、R。、およびA. Roach、「Relay Extensions for the Message Sessions Relay Protocol（MSRP）」、RFC 4976、DOI 10.17487 / RFC4976、2007年9月、<https：// www。 rfc-editor.org/info/rfc4976>。
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, DOI 10.17487/RFC5026, October 2007, <https://www.rfc-editor.org/info/rfc5026>.
[RFC5026]ジャレッタ、G。、編、ケンプ、J。、およびV.デバラパリ、編、「スプリットシナリオでのモバイルIPv6ブートストラップ」、RFC 5026、DOI 10.17487 / RFC5026、2007年10月、<https：// www .rfc-editor.org / info / rfc5026>。
[RFC5328] Adolf, A. and P. MacAvock, "A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)", RFC 5328, DOI 10.17487/RFC5328, September 2008, <https://www.rfc-editor.org/info/rfc5328>.
[RFC5328] Adolf、A。およびP. MacAvock、「デジタルビデオブロードキャストプロジェクト（DVB）のUniform Resource Name（URN）名前空間」、RFC 5328、DOI 10.17487 / RFC5328、2008年9月、<https：// www。 rfc-editor.org/info/rfc5328>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<https：// www.rfc-editor.org/info/rfc5389>。
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, <https://www.rfc-editor.org/info/rfc5415>.
[RFC5415] Calhoun、P.、Ed。、Montemurro、M.、Ed。、and D. Stanley、Ed。、 "Control And Provisioning of Wireless Access Points（CAPWAP）Protocol Specification"、RFC 5415、DOI 10.17487 / RFC5415、 2009年3月、<https://www.rfc-editor.org/info/rfc5415>。
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, <https://www.rfc-editor.org/info/rfc5518>.
[RFC5518] Hoffman、P.、Levine、J。、およびA. Hathcock、「Vouch By Reference」、RFC 5518、DOI 10.17487 / RFC5518、2009年4月、<https://www.rfc-editor.org/info/ rfc5518>。
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 2009, <https://www.rfc-editor.org/info/rfc5555>.
[RFC5555] Soliman、H。、編、「デュアルスタックホストとルーターのモバイルIPv6サポート」、RFC 5555、DOI 10.17487 / RFC5555、2009年6月、<https://www.rfc-editor.org/info/rfc5555 >。
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August 2009, <https://www.rfc-editor.org/info/rfc5617>.
[RFC5617] Allman、E.、Fenton、J.、Delany、M。、およびJ. Levine、「DomainKeys Identified Mail（DKIM）Author Domain Signing Practices（ADSP）」、RFC 5617、DOI 10.17487 / RFC5617、2009年8月、 <https://www.rfc-editor.org/info/rfc5617>。
[RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using DNS", RFC 5679, DOI 10.17487/RFC5679, December 2009, <https://www.rfc-editor.org/info/rfc5679>.
[RFC5679] Bajko、G。、「Locating IEEE 802.21 Mobility Services Using DNS」、RFC 5679、DOI 10.17487 / RFC5679、2009年12月、<https://www.rfc-editor.org/info/rfc5679>。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.
[RFC5766] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATのリレーを使用したトラバーサル（TURN）：NATのセッショントラバーサルユーティリティへのリレー拡張（STUN）」、RFC 5766、DOI 10.17487 / RFC5766、4月2010、<https://www.rfc-editor.org/info/rfc5766>。
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, DOI 10.17487/RFC5780, May 2010, <https://www.rfc-editor.org/info/rfc5780>.
[RFC5780] MacDonald、D。およびB. Lowekamp、「NAT（STUN）のセッショントラバーサルユーティリティを使用したNAT動作検出」、RFC 5780、DOI 10.17487 / RFC5780、2010年5月、<https://www.rfc-editor.org / info / rfc5780>。
[RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, July 2010, <https://www.rfc-editor.org/info/rfc5804>.
[RFC5804] Melnikov、A.、Ed。 T.マーティン、「A Sieve Scriptsをリモート管理するためのプロトコル」、RFC 5804、DOI 10.17487 / RFC5804、2010年7月、<https://www.rfc-editor.org/info/rfc5804>。
[RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, DOI 10.17487/RFC5864, April 2010, <https://www.rfc-editor.org/info/rfc5864>.
[RFC5864] Allbery、R。、「AFSのDNS SRVリソースレコード」、RFC 5864、DOI 10.17487 / RFC5864、2010年4月、<https://www.rfc-editor.org/info/rfc5864>。
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Resolution Mechanism", RFC 5928, DOI 10.17487/RFC5928, August 2010, <https://www.rfc-editor.org/info/rfc5928>.
[RFC5928] Petit-Huguenin、M。、「NAT（TURN）解決メカニズムの周りのリレーを使用したトラバーサル」、RFC 5928、DOI 10.17487 / RFC5928、2010年8月、<https://www.rfc-editor.org/info/rfc5928 >。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120] Saint-Andre、P。、「Extensible Messaging and Presence Protocol（XMPP）：Core」、RFC 6120、DOI 10.17487 / RFC6120、2011年3月、<https://www.rfc-editor.org/info/rfc6120 >。
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <https://www.rfc-editor.org/info/rfc6186>.
[RFC6186] Daboo、C。、「電子メールの送信/アクセスサービスを特定するためのSRVレコードの使用」、RFC 6186、DOI 10.17487 / RFC6186、2011年3月、<https://www.rfc-editor.org/info/rfc6186> 。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376] Crocker、D.、Ed。、Hansen、T.、Ed。、and M. Kucherawy、Ed。、 "DomainKeys Identified Mail（DKIM）Signatures"、STD 76、RFC 6376、DOI 10.17487 / RFC6376、September 2011 、<https://www.rfc-editor.org/info/rfc6376>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、DOI 10.17487 / RFC6763、2013年2月、<https://www.rfc-editor.org/info/rfc6763>。
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7208]キッターマンS.、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 7208、DOI 10.17487 / RFC7208、2014年4月、<https://www.rfc-editor.org / info / rfc7208>。
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489] Kucherawy、M.、Ed。およびE. Zwicky、編、「ドメインベースのメッセージ認証、レポート、および準拠（DMARC）」、RFC 7489、DOI 10.17487 / RFC7489、2015年3月、<https://www.rfc-editor.org/info/ rfc7489>。
Acknowledgements
謝辞
Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf Kolkman, and Andrew Sullivan for diligent review of the (much) earlier draft versions. For the later enhancements, thanks to Tim Wicinski, John Levine, Bob Harold, Joel Jaeggli, Ondrej Sury, and Paul Wouters.
以前のドラフトバージョンの（多くの）入念なレビューをしてくれたBill Fenner、Dick Franks、Tony Hansen、Peter Koch、Olaf Kolkman、Andrew Sullivanに感謝します。後の拡張については、Tim Wicinski、John Levine、Bob Harold、Joel Jaeggli、Ondrej Sury、およびPaul Woutersのおかげです。
Special thanks to Ray Bellis for his persistent encouragement to continue this effort, as well as the suggestion for an essential simplification to the registration model.
レイベリスがこの取り組みを継続するよう継続的に励ましてくれたこと、および登録モデルの本質的な簡略化を提案してくれたことに特に感謝します。
Author's Address
著者のアドレス
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 United States of America
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale、CA 94086アメリカ合衆国
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
URI: http://bbiw.net/