[要約] RFC 8552は、DNSリソースレコードの属性の解釈を改善するために、アンダースコアで属性の葉を命名する方法を提案しています。このRFCの目的は、DNSの柔軟性と拡張性を向上させ、新しい属性の追加や既存の属性の変更を容易にすることです。
Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 8552 Brandenburg InternetWorking
BCP: 222 March 2019
Category: Best Current Practice
ISSN: 2070-1721
Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves
属性リーフの「アンダースコア付き」命名によるDNSリソースレコードのスコープ付き解釈
Abstract
概要
Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.
正式には、DNSリソースレコード（RR）は任意のドメイン名で発生する可能性があります。ただし、一部のサービスは、RRsetが実際に適用される親ドメインの下のDNSブランチにレコードを配置することにより、RRsetの特定の解釈を定義するために操作規則を使用します。この下位ブランチの先頭は、アンダースコア文字で始まる予約済みノード名を使用する命名規則（たとえば、「_ name」）によって定義されます。下線付きの命名構文は、下線付きブランチの上の親ドメインに関連付けられているDNSレコードタイプのセマンティックスコープを定義します。この仕様では、このDNSの使用法の性質を探り、IANAを使用して「アンダースコアおよびグローバルスコープのDNSノード名」レジストリを定義します。このレジストリの目的は、異なるサービスに同じアンダースコア付きの名前を使用したことによる衝突を回避することです。
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/rfc8552.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8552で入手できます。
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
1.1. Underscore-Based Scoping . . . . . . . . . . . . . . . . 3
1.2. Scaling Benefits . . . . . . . . . . . . . . . . . . . . 4
1.3. Global Underscored Node Names . . . . . . . . . . . . . . 4
1.4. Interaction with DNS Wildcards . . . . . . . . . . . . . 5
1.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. "Underscored and Globally Scoped DNS Node Names" Registry . . 6
3. Guidance for Registering RRset Use . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. "Underscored and Globally Scoped DNS Node Names" Registry 8
4.2. Enumservices Registrations Registry . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
The core Domain Name System (DNS) technical specifications ([RFC1035] and [RFC2181]) assign no semantics to domain names or their parts, and no constraints upon which resource record (RR) types are permitted to be stored under particular names [RFC1035] [RFC2181]. Over time, some leaf node names, such as "www" and "ftp", have come to imply support for particular services, but this is a matter of operational convention rather than defined protocol semantics. This freedom in the basic technology has permitted a wide range of administrative and semantic policies to be used -- in parallel. DNS data semantics have been limited to the specification of particular resource record types on the expectation that new resource record types would be added as needed. Unfortunately, the addition of new resource record types has proven extremely challenging, with significant adoption and use barriers occurring over the life of the DNS.
コアドメインネームシステム（DNS）技術仕様（[RFC1035]および[RFC2181]）は、ドメイン名またはその一部にセマンティクスを割り当てず、特定の名前でのリソースレコード（RR）タイプの格納を許可する制約もありません[RFC1035 ] [RFC2181]。時間の経過とともに、「www」や「ftp」などの一部のリーフノード名は特定のサービスのサポートを意味するようになりましたが、これは定義されたプロトコルセマンティクスではなく運用上の規約の問題です。基本テクノロジーにおけるこの自由により、幅広い管理ポリシーとセマンティックポリシーを同時に使用できるようになりました。 DNSデータセマンティクスは、必要に応じて新しいリソースレコードタイプが追加されることを想定して、特定のリソースレコードタイプの指定に限定されています。残念ながら、新しいリソースレコードタイプを追加することは非常に困難であることが証明されており、DNSの存続期間を通じて大幅な導入と使用の障壁が発生しています。
As an alternative to defining a new RR TYPE, some DNS service enhancements call for using an existing resource record type but specifying a restricted scope for its occurrence. Scope is meant as a static property, not one dependent on the nature of the query. It is an artifact of the DNS name. That scope is a leaf node containing the specific resource record sets that are formally defined and constrained. Specifically:
新しいRR TYPEを定義する代わりに、一部のDNSサービス拡張では、既存のリソースレコードタイプを使用することを要求しますが、その発生に対して制限されたスコープを指定します。スコープは静的プロパティであり、クエリの性質に依存するものではありません。 DNS名のアーティファクトです。そのスコープは、正式に定義および制約された特定のリソースレコードセットを含むリーフノードです。具体的には：
The leaf occurs in a branch having a distinguished naming convention: there is a parent domain name to which the scoped data applies. The branch is under this name. The sub-branch is indicated by a sequence of one or more reserved DNS node names; at least the first (highest) of these names begins with an underscore (e.g., "_name").
リーフは、明確な命名規則を持つブランチで発生します。スコープデータが適用される親ドメイン名があります。ブランチはこの名前の下にあります。サブブランチは、1つ以上の予約済みDNSノード名のシーケンスで示されます。これらの名前の少なくとも最初の（最も高い）はアンダースコアで始まります（例： "_name"）。
Because the DNS rules for a "host" (host name) do not allow use of the underscore character, the underscored name is distinguishable from all legal host names [RFC0952]. Effectively, this convention for naming leaf nodes creates a space for the listing of "attributes" -- in the form of resource record types -- that are associated with the parent domain above the underscored sub-branch.
「ホスト」（ホスト名）のDNS規則では下線文字の使用が許可されていないため、下線付きの名前はすべての正当なホスト名と区別できます[RFC0952]。リーフノードに名前を付けるこの規則により、下線の付いたサブブランチの上の親ドメインに関連付けられた、リソースレコードタイプの形式の「属性」のリスト用のスペースが作成されます。
The scoping feature is particularly useful when generalized resource record types are used -- notably "TXT", "SRV", and "URI" [RFC1035] [RFC2782] [RFC6335] [RFC7553]. It provides efficient separation of one use of them from others. Absent this separation, an undifferentiated mass of these RRsets is returned to the DNS client, which then must parse through the internals of the records in the hope of finding ones that are relevant. Worse, in some cases, the results are ambiguous because a record type might not adequately self-identify its specific purpose. With underscore-based scoping, only the relevant RRsets are returned.
スコーピング機能は、一般化されたリソースレコードタイプ、特に「TXT」、「SRV」、および「URI」を使用する場合に特に役立ちます[RFC1035] [RFC2782] [RFC6335] [RFC7553]。それはそれらの1つの使用を他から効果的に分離します。この分離がない場合、これらのRRsetの未分化の質量がDNSクライアントに返され、関連するレコードを見つけるためにレコードの内部を解析する必要があります。さらに悪いことに、場合によっては、レコードタイプがその特定の目的を適切に識別できないため、結果があいまいになることがあります。アンダースコアベースのスコープでは、関連するRRsetのみが返されます。
A simple example is DomainKeys Identified Mail (DKIM) [RFC6376], which uses "_domainkey" to define a place to hold a TXT record containing signing information for the parent domain.
簡単な例はDomainKeys Identified Mail（DKIM）[RFC6376]で、「_ domainkey」を使用して、親ドメインの署名情報を含むTXTレコードを保持する場所を定義します。
This specification formally defines how underscored names are used as "attribute" enhancements for their parent domain names. For example, the domain name "_domainkey.example." acts as an attribute of the parent domain name "example.". To avoid collisions resulting from the use of the same underscored names for different applications using the same resource record type, this document establishes the "Underscored and Globally Scoped DNS Node Names" registry with IANA. Use of such node names, which begin with an underscore character, is reserved when they are the underscored name closest to the DNS root; as in that case, they are considered "global". Underscored names that are farther down the hierarchy are handled within the scope of the global underscored node name.
この仕様は、アンダースコア付きの名前が親ドメイン名の「属性」拡張としてどのように使用されるかを正式に定義しています。たとえば、ドメイン名「_domainkey.example」。親ドメイン名「example。」の属性として機能します。同じリソースレコードタイプを使用する異なるアプリケーションで同じアンダースコア付きの名前を使用することによる衝突を回避するために、このドキュメントでは、IANAを使用して「アンダースコア付きおよびグローバルスコープのDNSノード名」レジストリを確立します。下線文字で始まるこのようなノード名の使用は、それらがDNSルートに最も近い下線付きの名前である場合に予約されています。その場合のように、それらは「グローバル」と見なされます。階層のさらに下にある下線付きの名前は、グローバル下線付きノード名のスコープ内で処理されます。
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]で説明されているように解釈されます。
Some resource record types are used in a fashion that can create scaling problems if an entire RRset associated with a domain name is aggregated in the leaf node for that name. An increasingly popular approach, with excellent scaling properties, places the RRset under a specially named branch, which is in turn under the node name that would otherwise contain the RRset. The rules for naming that branch define the context for interpreting the RRset. That is, rather than:
一部のリソースレコードタイプは、ドメイン名に関連付けられたRRset全体がその名前のリーフノードに集約されている場合、スケーリングの問題を引き起こす可能性がある方法で使用されます。優れたスケーリングプロパティを備えたますます人気のあるアプローチは、特別に名前が付けられたブランチの下にRRsetを配置します。このブランチは、本来ならRRsetを含むノード名の下にあります。そのブランチの命名規則は、RRsetを解釈するためのコンテキストを定義します。つまり、以下ではありません。
domain-name.example / RRset
domain-name.example / RRset
the arrangement is:
配置は次のとおりです。
_branch.domain-name.example / RRset
_branch.domain-name.example / RRset
A direct lookup to the subordinate leaf node produces only the desired record types, at no greater cost than a typical DNS lookup.
従属リーフノードへの直接ルックアップでは、通常のDNSルックアップよりもコストがかからず、必要なレコードタイプのみが生成されます。
As defined in [RFC1034], the DNS uses names organized in a tree-structured or hierarchical fashion. A domain name might have multiple node names that begin with the underscore character (e.g., "_name"). A global underscored node name is the one that is closest to the root of the DNS hierarchy, also called the highest level or topmost. In the presentation convention described in Section 3.1 of [RFC1034], this is the rightmost name beginning with an underscore.
[RFC1034]で定義されているように、DNSはツリー構造または階層的に編成された名前を使用します。ドメイン名には、アンダースコア文字で始まる複数のノード名が含まれる場合があります（「_name」など）。グローバルアンダースコア付きノード名は、DNS階層のルートに最も近いノード名で、最高レベルまたは最上位とも呼ばれます。 [RFC1034]のセクション3.1で説明されている表示規則では、これはアンダースコアで始まる右端の名前です。
In other presentation environments, it might be positioned differently. To avoid concern for the presentation variations, the qualifier "global" is used here.
他のプレゼンテーション環境では、配置が異なる場合があります。表示のバリエーションに関する懸念を回避するために、ここでは修飾子「global」が使用されています。
DNS wildcards interact poorly with underscored names in two ways:
DNSワイルドカードは、下線付きの名前と2つの方法でうまく相互作用しません。
Since wildcards are only interpreted as leaf names, one cannot create the equivalent of a wildcard name for prefixed names. A name such as label.*.example.com is not a wildcard.
ワイルドカードはリーフ名としてのみ解釈されるため、プレフィックス付きの名前に対応するワイルドカード名を作成することはできません。 label。*。example.comなどの名前はワイルドカードではありません。
Conversely, a wildcard such as *.example.com can match any name including an underscored name. So, a wildcard might match an underscored name, returning a record that is the type controlled by the underscored name but is not intended to be used in the underscored context and does not conform to its rules.
逆に、*。example.comなどのワイルドカードは、下線付きの名前を含む任意の名前と一致できます。したがって、ワイルドカードは下線付きの名前と一致する可能性があり、下線付きの名前で制御されるタイプのレコードを返しますが、下線付きのコンテキストでの使用は意図されておらず、その規則に準拠していません。
Originally, different uses of underscored node names developed largely without coordination. For TXT records, there is no consistent, internal syntax that permits distinguishing among the different uses. In the case of the SRV RR and URI RR, distinguishing among different types of use was part of the design (see [RFC2782] and [RFC7553]). The SRV and URI specifications serve as templates, defining RRs that might only be used for specific applications when there is an additional specification. The template definition included reference to two levels of tables of names from which underscored names should be drawn. The lower-level (local scope) set of "_service" names is defined in terms of other IANA tables, namely any table with symbolic names. The upper-level (global scope) SRV naming field is "_proto", although its pool of names is not explicitly defined.
元々、アンダースコアの付いたノード名のさまざまな使用法は、主に調整なしで開発されました。 TXTレコードの場合、さまざまな用途を区別できる一貫した内部構文はありません。 SRV RRとURI RRの場合、さまざまなタイプの使用を区別することが設計の一部でした（[RFC2782]および[RFC7553]を参照）。 SRVとURIの仕様はテンプレートとして機能し、追加の仕様がある場合に特定のアプリケーションでのみ使用されるRRを定義します。テンプレートの定義には、下線付きの名前を引き出す必要がある名前の2つのレベルのテーブルへの参照が含まれていました。下位レベル（ローカルスコープ）の "_service"名のセットは、他のIANAテーブル、つまりシンボリック名を持つテーブルに関して定義されます。上位レベル（グローバルスコープ）のSRV名前付けフィールドは "_proto"ですが、名前のプールは明示的に定義されていません。
The aggregate effect of these independent efforts was a long list of underscored names that were reserved without coordination, which invites an eventual name-assignment collision. The remedy is this base document and a companion document ([RFC8553]), which define a registry for these names and attempt to register all those already in use as well as to direct changes to the pre-registry specifications that used global underscored node names.
これらの独立した取り組みの総体的な影響は、調整なしで予約されたアンダースコア付きの名前の長いリストであり、最終的に名前と割り当ての衝突が発生しました。救済策は、このベースドキュメントと関連ドキュメント（[RFC8553]）であり、これらの名前のレジストリを定義し、すでに使用されているものすべてを登録し、グローバルアンダースコアのノード名を使用した事前レジストリの仕様を変更しようとします。 。
A registry for global DNS node names that begin with an underscore is defined here. The purpose of the "Underscored and Globally Scoped DNS Node Names" registry is to avoid collisions resulting from the use of the same underscored name for different applications.
ここでは、アンダースコアで始まるグローバルDNSノード名のレジストリが定義されています。 「アンダースコア付きでグローバルスコープのDNSノード名」レジストリの目的は、異なるアプリケーションで同じアンダースコア付きの名前を使用したことによる衝突を回避することです。
If a public specification calls for use of an underscored node name, the global underscored node name -- the underscored name that is closest to the DNS root -- MUST be entered into this registry.
公開仕様で下線付きノード名の使用が必要な場合は、グローバル下線付きノード名（DNSルートに最も近い下線付き名）をこのレジストリに入力する必要があります。
An underscored name defines the scope of use for specific resource record types, which are associated with the domain name that is the "parent" to the branch defined by the underscored name. A given name defines a specific, constrained context for one or more RR TYPEs, where use of such record types conforms to the defined constraints.
下線付きの名前は、下線付きの名前で定義されたブランチの「親」であるドメイン名に関連付けられている特定のリソースレコードタイプの使用範囲を定義します。指定された名前は、1つ以上のRR TYPEの特定の制約されたコンテキストを定義します。そのようなレコードタイプの使用は、定義された制約に準拠します。
o Within a leaf that is underscore scoped, other RRsets that are not specified as part of the scope MAY be used.
o アンダースコアスコープのリーフ内では、スコープの一部として指定されていない他のRRsetを使用できます。
Structurally, the registry is defined as a single, flat table of RR TYPEs, under node names beginning with underscore. In some cases, such as for use of an SRV record, the full scoping name might be multi-part, as a sequence of underscored names. Semantically, that sequence represents a hierarchical model, and it is theoretically reasonable to allow reuse of a subordinate underscored name in a different, global underscored context; that is, a subordinate name is meaningful only within the scope of the global underscored node name. Therefore, they are ignored by this "Underscored and Globally Scoped DNS Node Names" registry. This registry is for the definition of highest-level -- that is, global -- underscored node name used.
構造的に、レジストリは、下線で始まるノード名の下のRRタイプの単一のフラットテーブルとして定義されます。 SRVレコードを使用する場合など、一部のケースでは、完全なスコープ名は、アンダースコア付きの名前のシーケンスとしてマルチパートになる場合があります。意味的には、そのシーケンスは階層モデルを表しており、下位のアンダースコア付きの名前を別のグローバルアンダースコア付きコンテキストで再利用できるようにすることは理論的には妥当です。つまり、従属名は、下線付きのグローバルノード名のスコープ内でのみ意味があります。したがって、この「アンダースコアおよびグローバルスコープのDNSノード名」レジストリでは無視されます。このレジストリーは、使用される最高レベル（つまり、グローバル）の下線付きノード名の定義用です。
+----------------------------+
| NAME |
+----------------------------+
| _service1 |
| _protoB._service2 |
| _protoB._service3 |
| _protoC._service3 |
| _useX._protoD._service4 |
| _protoE._region._authority |
+----------------------------+
Table 1: Examples of Underscored Names
表1：下線付きの名前の例
Only global underscored node names are registered in the "Underscored and Globally Scoped DNS Node Names" registry. From the example above, that would mean _service1, _service2, _service3, _service 4, and _authority would be listed in the IANA registry.
「アンダースコア付きおよびグローバルスコープのDNSノード名」レジストリに登録されているのは、グローバルなアンダースコア付きノード名のみです。上記の例から、これは_service1、_service2、_service3、_service 4、および_authorityがIANAレジストリにリストされることを意味します。
o 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.
o 下線付きのノード名の使用は、スコープされている各RRタイプに固有です。それぞれの名前は場所を定義しますが、その場所の下に表示されるルールを定義しません。追加のアンダースコア付きの名前として、またはリソースレコードを持つリーフノードとして。これらのルールの詳細は、個々のRRタイプの仕様によって提供されます。以下のセクションでは、既存の下線付きの名前が、それらが指定するRRタイプで使用される方法について説明します。
o Definition and registration of subordinate underscored node names are the responsibility of the specification that creates the global underscored node name registry entry.
o 下位の下線付きノード名の定義と登録は、グローバルな下線付きノード名レジストリエントリを作成する仕様の責任です。
That is, if a scheme using a global underscored node name has one or more subordinate levels of underscored node naming, the namespaces from which names for those lower levels are chosen are controlled by the parent underscored node name. Each registered global underscored node name owns a distinct, subordinate namespace.
つまり、下線付きのグローバルノード名を使用するスキームに下線付きノードの名前付けの下位レベルが1つ以上ある場合、それらの下位レベルの名前が選択される名前空間は、親の下線付きノード名によって制御されます。登録されたグローバルの下線付きノード名はそれぞれ、異なる従属ネームスペースを所有しています。
This section provides guidance for specification writers, with a basic template they can use, to register new entries in the "Underscored and Globally Scoped DNS Node Names" registry. The text can be added to specifications using RR TYPE / _NODE NAME combinations that have not already been registered:
このセクションでは、仕様作成者が使用できる基本テンプレートを使用して、「アンダースコアおよびグローバルスコープのDNSノード名」レジストリに新しいエントリを登録するためのガイダンスを提供します。テキストは、まだ登録されていないRR TYPE / _NODE NAMEの組み合わせを使用して仕様に追加できます。
Per RFC 8552, please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:
RFC 8552に従って、次のエントリを「アンダースコアおよびグローバルスコープのDNSノード名」レジストリに追加してください。
+---------+-------------------+-------------------------------------+
| RR Type | _NODE NAME | Reference |
+---------+-------------------+-------------------------------------+
| {RR | _{DNS global node | {citation for the document making |
| TYPE} | name} | the addition.} |
+---------+-------------------+-------------------------------------+
Table 2: Template for Entries in the "Underscored and Globally Scoped DNS Node Names" Registry
表2：「アンダースコアおよびグローバルスコープのDNSノード名」レジストリのエントリのテンプレート
IANA has established the "Underscored and Globally Scoped DNS Node Names" registry. This section describes the registry, the definitions, the initial entries, the use of_ta and _example, and the use of [RFC8126] as guidance for expert review. IANA has also updated the "Enumservices Registrations" registry with a pointer to this document.
IANAは、「アンダースコアおよびグローバルスコープのDNSノード名」レジストリを確立しました。このセクションでは、レジストリ、定義、初期エントリ、_taと_exampleの使用、および[RFC8126]の使用について、専門家によるレビューのガイダンスとして説明します。 IANAは、このドキュメントへのポインタで「Enumservices Registrations」レジストリも更新しました。
The "Underscored and Globally Scoped DNS Node Names" registry includes any DNS node name that begins with the underscore character ("_", ASCII 0x5F) and is the underscored node name closest to the root; that is, it defines the highest level of a DNS branch under a "parent" domain name.
「アンダースコアおよびグローバルスコープのDNSノード名」レジストリには、アンダースコア文字（「_」、ASCII 0x5F）で始まり、ルートに最も近いアンダースコア付きのノード名であるDNSノード名が含まれます。つまり、「親」ドメイン名の下でDNSブランチの最高レベルを定義します。
o This registry operates under the IANA rules for "Expert Review" registration; see Section 4.1.5.
o このレジストリは、「エキスパートレビュー」登録のIANA規則に基づいて動作します。セクション4.1.5を参照してください。
o The contents of each entry in the registry are defined in Section 4.1.1.
o レジストリの各エントリの内容は、セクション4.1.1で定義されています。
o Each entry in the registry MUST contain values for all of the fields specified in Section 4.1.1.
o レジストリの各エントリには、セクション4.1.1で指定されたすべてのフィールドの値が含まれている必要があります。
o Within the registry, the combination of RR Type and _NODE NAME MUST be unique.
o レジストリ内では、RRタイプと_NODE NAMEの組み合わせは一意である必要があります。
o The table is to be maintained with entries sorted by the first column (RR Type) and, within that, the second column (_NODE NAME).
o テーブルは、最初の列（RRタイプ）でソートされたエントリで維持され、その中で2番目の列（_NODE NAME）でソートされます。
o The required Reference for an entry MUST have a stable resolution to the organization controlling that registry entry.
o エントリに必要な参照は、そのレジストリエントリを制御する組織に対して安定した解決策を持っている必要があります。
4.1.1. Contents of an Entry in the "Underscored and Globally Scoped DNS Node Names" Registry
4.1.1. 「アンダースコアおよびグローバルスコープのDNSノード名」レジストリのエントリの内容
A registry entry contains:
レジストリエントリには次のものが含まれます。
RR Type: Lists an RR TYPE that is defined for use within this scope.
RRタイプ：このスコープ内で使用するために定義されたRRタイプをリストします。
_NODE NAME: Specifies a single, underscored name that defines a reserved name; this name is the global entry name for the scoped resource record types that are associated with that name. For characters in the name that have an uppercase form and a lowercase form, the character MUST be recorded as lowercase to simplify name comparisons.
_NODE NAME：予約名を定義する単一の下線付きの名前を指定します。この名前は、その名前に関連付けられているスコープ付きリソースレコードタイプのグローバルエントリ名です。大文字と小文字の形式の名前の文字の場合、名前の比較を簡単にするために、文字を小文字として記録する必要があります。
Reference: Lists the specification that defines a record type and its use under this _Node Name. The organization producing the specification retains control over the registry entry for the _Node Name.
参照：この_Node名の下でのレコードタイプとその使用を定義する仕様をリストします。仕様を作成する組織は、_Node名のレジストリエントリに対する制御を保持します。
Each RR TYPE that is to be used with a _Node Name MUST have a separate registry entry.
_Node名で使用される各RR TYPEには、個別のレジストリエントリが必要です。
The initial entries in the registry are as follows:
レジストリの最初のエントリは次のとおりです。
+------------+-----------------------+---------------+
| RR Type | _NODE NAME | Reference |
+------------+-----------------------+---------------+
| * | _example | Section 4.1.4 |
| NULL | _ta-* {Section 4.1.3} | [RFC8145] |
| OPENPGPKEY | _openpgpkey | [RFC7929] |
| SMIMEA | _smimecert | [RFC8162] |
| SRV | _dccp | [RFC2782] |
| SRV | _http | [RFC4386] |
| SRV | _ipv6 | [RFC5026] |
| SRV | _ldap | [RFC4386] |
| SRV | _ocsp | [RFC4386] |
| SRV | _sctp | [RFC2782] |
| SRV | _sip | [RFC5509] |
| SRV | _tcp | [RFC2782] |
| SRV | _udp | [RFC2782] |
| SRV | _xmpp | [RFC3921] |
| TLSA | _dane | [RFC7671] |
| TLSA | _sctp | [RFC6698] |
| TLSA | _tcp | [RFC6698] |
| TLSA | _udp | [RFC6698] |
| TXT | _acme-challenge | [RFC8555] |
| TXT | _dmarc | [RFC7489] |
| TXT | _domainkey | [RFC6376] |
| TXT | _mta-sts | [RFC8461] |
| TXT | _spf | [RFC7208] |
| TXT | _sztp | [ZEROTOUCH] |
| TXT | _tcp | [RFC6763] |
| TXT | _udp | [RFC6763] |
| TXT | _vouch | [RFC5518] |
| URI | _acct | [RFC6118] |
| URI | _dccp | [RFC7566] |
| URI | _email | [RFC6118] |
| URI | _ems | [RFC6118] |
| URI | _fax | [RFC6118] |
| URI | _ft | [RFC6118] |
| URI | _h323 | [RFC6118] |
| URI | _iax | [RFC6118] |
| URI | _ical-access | [RFC6118] |
| URI | _ical-sched | [RFC6118] |
| URI | _ifax | [RFC6118] |
| URI | _im | [RFC6118] |
| URI | _mms | [RFC6118] |
| URI | _pres | [RFC6118] |
| URI | _pstn | [RFC6118] |
| URI | _sctp | [RFC6118] |
| URI | _sip | [RFC6118] |
| URI | _sms | [RFC6118] |
| URI | _tcp | [RFC6118] |
| URI | _udp | [RFC6118] |
| URI | _unifmsg | [RFC6118] |
| URI | _vcard | [RFC6118] |
| URI | _videomsg | [RFC6118] |
| URI | _voice | [RFC6118] |
| URI | _voicemsg | [RFC6118] |
| URI | _vpim | [RFC6118] |
| URI | _web | [RFC6118] |
| URI | _xmpp | [RFC6118] |
+------------+-----------------------+---------------+
Table 3: Initial Contents of the "Underscored and Globally Scoped DNS Node Names" Registry
表3：「アンダースコアおよびグローバルスコープのDNSノード名」レジストリの初期内容
Under the NULL RR Type, the entry "_ta-*" denotes all node names beginning with the string "_ta-*". It does NOT refer to a DNS wildcard specification.
NULL RRタイプでは、エントリ「_ta- *」は、文字列「_ta- *」で始まるすべてのノード名を示します。 DNSワイルドカード仕様は参照しません。
The node name "_example" is reserved across all RRsets.
ノード名「_example」は、すべてのRRsetで予約されています。
This section provides guidance for expert review of registration requests in the "Underscored and Globally Scoped DNS Node Names" registry.
このセクションでは、「アンダースコア付きおよびグローバルスコープのDNSノード名」レジストリでの登録リクエストの専門家によるレビューのためのガイダンスを提供します。
This review is solely to determine adequacy of a requested entry in this registry, and it does not include review of other aspects of the document specifying that entry. For example, such a document might also contain a definition of the resource record type that is referenced by the requested entry. Any required review of that definition is separate from the expert review required here.
このレビューは、このレジストリで要求されたエントリの妥当性を判断するためだけのものであり、そのエントリを指定しているドキュメントの他の側面のレビューは含まれていません。たとえば、そのようなドキュメントには、要求されたエントリによって参照されるリソースレコードタイプの定義も含まれる場合があります。その定義の必要なレビューは、ここで必要な専門家のレビューとは別です。
The review is for the purposes of ensuring that:
レビューは、以下を確実にするためのものです。
o The details for creating the registry entry are sufficiently clear, precise, and complete
o レジストリエントリの作成に関する詳細は、十分に明確、正確、かつ完全です。
o The combination of the underscored name, under which the listed resource record type is used, and the resource record type is unique in the table
o リスト内のリソースレコードタイプが使用されるアンダースコア付きの名前と、リソースレコードタイプがテーブル内で一意の組み合わせ
For the purposes of this expert review, other matters of the specification's technical quality, adequacy, or the like are outside of scope.
この専門家によるレビューのために、仕様の他の技術的な品質や妥当性などの問題は範囲外です。
The following note has been added to the "Enumservice Registrations" registry:
次のメモが「Enumservice Registrations」レジストリに追加されました。
When adding an entry to this registry, strong consideration should be given to also adding an entry to the "Underscored and Globally Scoped DNS Node Names" registry.
このレジストリにエントリを追加するときは、「アンダースコアおよびグローバルスコープのDNSノード名」レジストリにもエントリを追加することを強く検討する必要があります。
This memo raises no security issues.
このメモはセキュリティ上の問題を引き起こしません。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC0952] Harrenstien、K.、Stahl、M。、およびE. Feinler、「DoD Internet host table specification」、RFC 952、DOI 10.17487 / RFC0952、1985年10月、<https://www.rfc-editor.org/ info / rfc952>。
[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>。
[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>。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.
[RFC2181] Elz、R。およびR. Bush、「Clarifications to the DNS Specification」、RFC 2181、DOI 10.17487 / RFC2181、1997年7月、<https://www.rfc-editor.org/info/rfc2181>。
[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>。
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, DOI 10.17487/RFC3921, October 2004, <https://www.rfc-editor.org/info/rfc3921>.
[RFC3921] Saint-Andre、P。、編、「Extensible Messaging and Presence Protocol（XMPP）：Instant Messaging and Presence」、RFC 3921、DOI 10.17487 / RFC3921、2004年10月、<https：//www.rfc-editor .org / info / rfc3921>。
[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>。
[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>。
[RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)", RFC 5509, DOI 10.17487/RFC5509, April 2009, <https://www.rfc-editor.org/info/rfc5509>.
[RFC5509] Loreto、S。、「インターネットから割り当てられた番号認証局（IANA）のセッション開始プロトコル（SIP）のインスタントメッセージングおよびプレゼンスDNS SRV RRの登録」、RFC 5509、DOI 10.17487 / RFC5509、2009年4月、<https：/ /www.rfc-editor.org/info/rfc5509>。
[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>。
[RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA Registrations of Enumservices", RFC 6118, DOI 10.17487/RFC6118, March 2011, <https://www.rfc-editor.org/info/rfc6118>.
[RFC6118] Hoeneisen、B。およびA. Mayrhofer、「Update of Legacy IANA Registrations of Enumservices」、RFC 6118、DOI 10.17487 / RFC6118、2011年3月、<https://www.rfc-editor.org/info/rfc6118> 。
[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>。
[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>。
[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>。
[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>。
[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>。
[RFC7566] Goix, L. and K. Li, "Enumservice Registration for 'acct' URI", RFC 7566, DOI 10.17487/RFC7566, June 2015, <https://www.rfc-editor.org/info/rfc7566>.
[RFC7566] Goix、L。およびK. Li、「 'acct' URIのEnumservice登録」、RFC 7566、DOI 10.17487 / RFC7566、2015年6月、<https://www.rfc-editor.org/info/rfc7566> 。
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7671] Dukhovni、V。およびW. Hardaker、「DNSベースの名前付きエンティティの認証（DANE）プロトコル：更新および運用ガイダンス」、RFC 7671、DOI 10.17487 / RFC7671、2015年10月、<https：// www。 rfc-editor.org/info/rfc7671>。
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", RFC 7929, DOI 10.17487/RFC7929, August 2016, <https://www.rfc-editor.org/info/rfc7929>.
[RFC7929] Wouters、P。、「OpenPGPの名前付きエンティティ（DANE）バインディングのDNSベースの認証」、RFC 7929、DOI 10.17487 / RFC7929、2016年8月、<https://www.rfc-editor.org/info/ rfc7929>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>。
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/info/rfc8162>.
[RFC8162] Hoffman、P。およびJ. Schlyter、「Secure DNSを使用した証明書とS / MIMEのドメイン名の関連付け」、RFC 8162、DOI 10.17487 / RFC8162、2017年5月、<https：//www.rfc-editor。 org / info / rfc8162>。
[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>。
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/info/rfc8461>.
[RFC8461]マーゴリス、D。、リシャー、M。、ラマクリシュナン、B。、ブロトマン、A.、J。ジョーンズ、「SMTP MTA Strict Transport Security（MTA-STS）」、RFC 8461、DOI 10.17487 / RFC8461、9月2018年、<https://www.rfc-editor.org/info/rfc8461>。
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
[RFC8555] Barnes、R.、Hoffman-Andrews、J.、McCarney、D。、およびJ. Kasten、「自動証明書管理環境（ACME）」、RFC 8555、DOI 10.17487 / RFC8555、2019年3月、<https：/ /www.rfc-editor.org/info/rfc8555>。
[RFC8553] Crocker, D., "DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names", RFC 8553, DOI 10.17487/RFC8553, March 2019, <https://www.rfc-editor.org/info/rfc8553>.
[RFC8553] Crocker、D。、「DNS Attrleaf Changes：Fixing Specifications That Uses Underscored Node Names」、RFC 8553、DOI 10.17487 / RFC8553、2019年3月、<https://www.rfc-editor.org/info/rfc8553> 。
[ZEROTOUCH] Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero Touch Provisioning (SZTP)", Work in Progress, draft-ietf-netconf-zerotouch-29, January 2019.
[ZEROTOUCH] Watsen、K.、Abrahamsson、M。、およびI. Farrer、「Secure Zero Touch Provisioning（SZTP）」、Work in Progress、draft-ietf-netconf-zerotouch-29、2019年1月。
Acknowledgements
謝辞
Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Martin Hoffmann, Paul Hoffman, Peter Koch, Olaf Kolkman, Murray Kucherawy, John Levine, Benno Overeinder, and Andrew Sullivan for diligent review of the (much) earlier draft versions. For the later enhancements, thanks to Stephane Bortzmeyer, Alissa Cooper, Bob Harold, Joel Jaeggli, Benjamin Kaduk, Mirja Kuehlewind, Warren Kumari, John Levine, Benno Overeinder, Eric Rescorla, Adam Roach, Petr Spacek, Ondrej Sury, Paul Vixie, Tim Wicinski, and Paul Wouters.
以前のドラフトバージョンの（多くの）入念なレビューをしてくれたBill Fenner、Dick Franks、Tony Hansen、Martin Hoffmann、Paul Hoffman、Peter Koch、Olaf Kolkman、Murray Kucherawy、John Levine、Benno Overeinder、Andrew Sullivanに感謝します。後の拡張については、Stephane Bortzmeyer、Alissa Cooper、Bob Harold、Joel Jaeggli、Benjamin Kaduk、Mirja Kuehlewind、Warren Kumari、John Levine、Benno Overeinder、Eric Rescorla、Adam Roach、Petr Spacek、Ondrej Sury、Paul Vixie、Timに感謝Wicinski、および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/