[要約] RFC 8244は、特定の目的で使用されるドメイン名の問題を解決するためのものです。その目的は、特殊なドメイン名の使用に関する一貫性と安全性を確保することです。
Internet Engineering Task Force (IETF) T. Lemon
Request for Comments: 8244 Nominum, Inc.
Category: Informational R. Droms
ISSN: 2070-1721
W. Kumari
Google
October 2017
Special-Use Domain Names Problem Statement
特殊用途ドメイン名の問題ステートメント
Abstract
概要
The policy defined in RFC 6761 for IANA registrations in the "Special-Use Domain Names" registry has been shown, through experience, to present challenges that were not anticipated when RFC 6761 was written. This memo presents a list, intended to be comprehensive, of the problems that have since been identified. In addition, it reviews the history of domain names and summarizes current IETF publications and some publications from other organizations relating to Special-Use Domain Names.
「特殊用途ドメイン名」レジストリのIANA登録についてRFC 6761で定義されたポリシーは、経験を通じて、RFC 6761が作成されたときに予期されなかった課題を提示することが示されています。このメモは、それ以降に特定された問題の、包括的であることを意図したリストを提示します。さらに、ドメイン名の履歴を確認し、現在のIETFの出版物と、特別な用途のドメイン名に関連する他の組織からのいくつかの出版物を要約します。
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names.
このドキュメントは、特別用途のドメイン名のトピックについて情報に基づいた意見を表明したいIETF参加者には必読であると考える必要があります。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 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/rfc8244.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8244で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problems Associated with Special-Use Domain Names . . . . . . 4
4. Existing Practice regarding Special-Use Domain Names . . . . 10
4.1. Primary Special-Use Domain Name Documents . . . . . . . . 10
4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 10
4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 12
4.1.3. MoU Concerning the Technical Work of IANA . . . . . . 13
4.1.4. Liaison Statement on Technical Use of Domain Names . 14
4.1.5. IAB Statement on the Registration of Special Use
Names in the ARPA Domain . . . . . . . . . . . . . . 15
4.2. Secondary Documents Relating to the Special-Use Domain
Name Question . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 15
4.2.2. The '.onion' Special-Use Top-Level Domain Name . . . 16
4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 16
4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 17
4.2.5. SSAC Advisory on the Stability of the Domain
Namespace . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis . . . . . . . . . . . . . . . . . . . . . . 17
4.2.7. Additional Reserved Top-Level Domains . . . . . . . . 18
5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Informative References . . . . . . . . . . . . . . . . . . . 20
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
One of the key services required to use the Internet is name resolution. Name resolution is the process of translating a symbolic name into some object or set of objects to which the name refers, most typically one or more IP addresses. These names are often referred to as "domain names". When reading this document, care must be taken not to assume that the term domain name implies the use of the Domain Name System [RFC1034] for resolving these names. An excellent presentation on this topic can be found in Domain Names [DOMAIN-NAMES].
インターネットを使用するために必要な主要なサービスの1つは名前解決です。名前解決は、シンボリック名を、名前が参照するオブジェクトまたはオブジェクトのセット（最も一般的には1つ以上のIPアドレス）に変換するプロセスです。これらの名前はしばしば「ドメイン名」と呼ばれます。このドキュメントを読むときは、ドメイン名という用語が、これらの名前を解決するためにドメインネームシステム[RFC1034]を使用することを意味するものではないことに注意してください。このトピックに関する優れたプレゼンテーションは、ドメイン名[ドメイン名]にあります。
"Special-Use Domain Names" [RFC6761] created the "Special-Use Domain Names" IANA registry [SDO-IANA-SUDR], defined policies for adding to the registry, and made some suggestions about how those policies might be implemented. Since the publication of RFC 6761, the IETF has been asked to designate several new Special-Use Domain Names in this registry. During the evaluation process for these Special-Use Domain Names, the IETF encountered several different sorts of issues. Because of this, the IETF has decided to investigate the problem and decide if and how the process defined in RFC 6761 can be improved, or whether it should be deprecated. The IETF DNSOP Working Group charter was extended to include conducting a review of the process for adding names to the registry that is defined in RFC 6761. This document is a product of that review.
「特殊用途ドメイン名」[RFC6761]は、「特殊用途ドメイン名」IANAレジストリ[SDO-IANA-SUDR]を作成し、レジストリに追加するポリシーを定義し、それらのポリシーの実装方法についていくつかの提案を行いました。 RFC 6761の公開以来、IETFはこのレジストリでいくつかの新しい特殊用途ドメイン名を指定するように求められています。これらの特殊用途ドメイン名の評価プロセス中に、IETFはいくつかの異なる種類の問題に遭遇しました。このため、IETFは問題を調査し、RFC 6761で定義されているプロセスを改善できるかどうか、またどのように改善できるか、または非推奨にする必要があるかどうかを決定しました。 IETF DNSOPワーキンググループの憲章は、RFC 6761で定義されているレジストリに名前を追加するプロセスのレビューの実施を含むように拡張されました。このドキュメントは、そのレビューの産物です。
Based on current ICANN and IETF practice, including RFC 6761, there are several different types of names in the root of the Domain Namespace:
RFC 6761を含む現在のICANNおよびIETFの慣習に基づいて、ドメイン名前空間のルートにはいくつかの異なるタイプの名前があります。
o Names reserved by the IETF for technical purposes
o IETFが技術的な目的で予約した名前
o Names assigned by ICANN to the public DNS root; some names reserved by the IETF for technical purposes may appear in the global DNS root for reasons pertaining to the operation of the DNS
o ICANNによってパブリックDNSルートに割り当てられた名前。技術的な目的でIETFによって予約されている一部の名前は、DNSの操作に関連する理由により、グローバルDNSルートに表示される場合があります
o ICANN Reserved Names; names that may not be applied for as TLDs (see "Reserved Names" and "Treatment of Country or Territory Names" (Sections 2.2.1.2.1 and 2.2.1.4.1, respectively) of [SDO-ICANN-DAG]).
o ICANNの予約名。 TLDとして適用されない可能性のある名前（[SDO-ICANN-DAG]の「予約名」および「国または地域の名前の扱い」（それぞれセクション2.2.1.2.1および2.2.1.4.1を参照））。
o Names used by other organizations without following established processes
o 確立されたプロセスに従わずに他の組織が使用する名前
o Names that are unused and are available for assignment to one of the previous categories
o 未使用で、前のいずれかのカテゴリーへの割り当てに使用できる名前
This document presents a list, derived from a variety of sources, including discussion in the IETF DNSOP Working Group, of the problems associated with the assignment of Special-Use Domain Names. The list is intended to be an unfiltered compilation of issues. In support of its analysis of the particular set of issues described here, the document also includes descriptions of existing practice as it relates to the use of domain names, a brief history of domain names, and some observations by various IETF participants who have experience with various aspects of the current situation.
このドキュメントは、IETF DNSOPワーキンググループでの議論を含む、さまざまなソースから派生した、特殊用途ドメイン名の割り当てに関連する問題のリストを示しています。このリストは、フィルタリングされていない問題をまとめたものです。ここで説明する特定の一連の問題の分析をサポートするために、このドキュメントには、ドメイン名の使用、ドメイン名の簡単な履歴、および経験のあるさまざまなIETF参加者によるいくつかの観察に関連する既存の慣行の説明も含まれています現在の状況のさまざまな側面。
This document uses the terminology from RFC 7719 [RFC7719]. Other terms used in this document are defined here:
このドキュメントでは、RFC 7719 [RFC7719]の用語を使用しています。このドキュメントで使用されているその他の用語は次のとおりです。
Domain Name: This document uses the term "domain name" as defined in Section 2 of RFC 7719 [RFC7719].
ドメイン名：このドキュメントでは、RFC 7719 [RFC7719]のセクション2で定義されている「ドメイン名」という用語を使用しています。
Domain Namespace: The set of all possible domain names.
ドメイン名前空間：可能なすべてのドメイン名のセット。
Special-Use Domain Name: A domain name listed in the "Special-Use Domain Names" registry [SDO-IANA-SUDR].
特殊用途ドメイン名：「特殊用途ドメイン名」レジストリ[SDO-IANA-SUDR]に記載されているドメイン名。
For the sake of brevity, this document uses some abbreviations, which are expanded here:
簡潔にするために、このドキュメントではいくつかの略語を使用しています。
IANA: Internet Assigned Numbers Authority
IANA：Internet Assigned Numbers Authority
ICANN: Internet Corporation for Assigned Names and Numbers
ICANN：割り当てられた名前と番号のInternet Corporation
TLD: Top-Level Domain, as defined in Section 2 of RFC 7719 [RFC7719]
TLD：RFC 7719 [RFC7719]のセクション2で定義されているトップレベルドメイン
gTLD: Generic Top-Level Domain (see Section 2 of RFC 2352 [RFC2352])
gTLD：一般的なトップレベルドメイン（RFC 2352 [RFC2352]のセクション2を参照）
This section presents a list of problems that have been identified with respect to the assignment of Special-Use Domain Names. Solutions to these problems, including their costs or trade-offs, are out of scope for this document and will be covered in a separate document. New problems that might be created in the process of solving problems described in this document are also out of scope: these problems are expected to be addressed in the process of evaluating potential solutions.
このセクションでは、特殊用途ドメイン名の割り当てに関して特定された問題のリストを示します。これらの問題の解決策（コストやトレードオフを含む）は、このドキュメントの範囲外であり、別のドキュメントで説明します。このドキュメントで説明されている問題を解決するプロセスで作成される可能性のある新しい問題も範囲外です。これらの問題は、潜在的なソリューションを評価するプロセスで対処することが期待されています。
Special-Use Domain Names exist to solve a variety of problems. This document has two goals: enumerate all of the problems that have been identified to which Special-Use Domain Names are a solution and enumerate all of the problems that have been raised in the process of trying to use RFC 6761 as it was intended. As some of those problems may fall into both categories, this document makes no attempt to categorize the problems.
特殊用途のドメイン名は、さまざまな問題を解決するために存在します。このドキュメントには2つの目標があります。特殊用途ドメイン名が解決策であると識別されたすべての問題を列挙すること、および意図したとおりにRFC 6761を使用しようとするプロセスで発生したすべての問題を列挙することです。これらの問題の一部は両方のカテゴリに分類される可能性があるため、このドキュメントでは問題の分類を試みていません。
There is a broad diversity of opinion about this set of problems. Not every participant agrees that each of the problems enumerated in this document is actually a problem. This document takes no position on the relative validity of the various problems that have been enumerated, nor on the organization responsible for addressing each individual problem, if it is to be addressed. This document only enumerates the problems, provides the reader with context for thinking about them, and provides a context for future discussion of solutions, regardless of whether such solutions may work for IETF, ICANN, IANA, or some other group.
この一連の問題については、さまざまな意見があります。すべての参加者が、このドキュメントに列挙されている各問題が実際に問題であることに同意するわけではありません。この文書は、列挙されているさまざまな問題の相対的な妥当性については、また、個々の問題に対処する責任がある組織についても、対処する必要がある場合は、その立場をとりません。このドキュメントは問題を列挙するだけであり、読者に問題について考えるためのコンテキストを提供し、ソリューションがIETF、ICANN、IANA、またはその他のグループで機能するかどうかに関係なく、ソリューションの今後の議論のためのコンテキストを提供します。
The list of problems is not presented in order of importance; numbers are assigned so that each problem can easily be referenced by number, not to indicate priority. The list of problems is as follows:
問題のリストは重要度の高い順に示されていません。番号は、優先順位を示すためではなく、番号によって各問題を簡単に参照できるように割り当てられています。問題のリストは次のとおりです。
1. Although the IETF and ICANN have a liaison relationship through which special-use allocations can be discussed, there exists no formal process for coordinating these allocations (see Section 4.1.3). The lack of coordination complicates the management of the root of the Domain Namespace and could lead to conflicts in name assignments [SDO-ICANN-SAC090].
1. IETFとICANNは、特殊用途の割り当てについて話し合うことができる連絡関係を持っていますが、これらの割り当てを調整するための正式なプロセスはありません（セクション4.1.3を参照）。調整の欠如は、ドメイン名前空間のルートの管理を複雑にし、名前割り当ての競合につながる可能性があります[SDO-ICANN-SAC090]。
2. There is no explicit scoping as to what can constitute a "technical use" [RFC2860] and what cannot; there is also no consensus within the IETF as to what this term means.
2. 「技術的使用」[RFC2860]を構成できるものと構成できないものに関する明示的なスコープはありません。この用語の意味についても、IETF内で合意はありません。
3. Not all developers of protocols on the Internet agree that authority over the entire Domain Namespace should reside solely with the IETF and ICANN.
3. インターネット上のプロトコルのすべての開発者が、ドメイン名前空間全体に対する権限がIETFとICANNにのみ存在することに同意するわけではありません。
4. Although the IETF and ICANN nominally have authority over this namespace, neither organization can enforce that authority over any third party who wants to just start using a subset of the namespace. Such parties may observe that the IETF has never asserted control or authority over what protocols are "allowed" on the Internet, and that the principle of "permissionless innovation" suggests there should be a way for people to include new uses of domain names in new protocols and applications.
4. IETFとICANNは通常、この名前空間に対する権限を持っていますが、どちらの組織も、名前空間のサブセットの使用を開始したいサードパーティに対してその権限を適用することはできません。そのような当事者は、IETFがインターネット上で「許可」されているプロトコルに対して制御または権限を決して表明していないこと、および「パーミッションレスイノベーション」の原則により、人々が新しいドメイン名の新しい使用法を新しいプロトコルとアプリケーション。
5. Organizations do in fact sometimes use subsets of the Domain Namespace without following established processes. Reasons a third party might do this include:
5. 実際、組織は、確立されたプロセスに従わずにドメイン名前空間のサブセットを使用することがあります。サードパーティがこれを行う理由には、次のものがあります。
1. Lack of knowledge that a process exists for assigning such names.
1. そのような名前を割り当てるためのプロセスが存在するという知識の欠如。
2. Intended use is covered by the gTLD process [SDO-ICANN-DAG], but no gTLD process is ongoing.
2. 意図した使用はgTLDプロセス[SDO-ICANN-DAG]でカバーされますが、進行中のgTLDプロセスはありません。
3. Intended use is covered by the gTLD process, but the third party doesn't want to pay a fee.
3. 意図した使用はgTLDプロセスでカバーされますが、サードパーティは料金を支払いたくありません。
4. Intended use is covered by some IETF process, but the third party doesn't want to follow the process.
4. 意図された使用はいくつかのIETFプロセスでカバーされていますが、サードパーティはプロセスに従うことを望んでいません。
5. Intended use is covered by an ICANN or IETF process, but the third party expects that the outcome will be refusal or non-action.
5. 意図された使用はICANNまたはIETFプロセスでカバーされますが、サードパーティは結果が拒否または非行動になることを期待しています。
6. Lack of knowledge that a name intended to be used only locally may nevertheless leak.
6. それでもローカルでのみ使用することを目的とした名前が漏洩する可能性があるという知識の欠如。
7. Lack of knowledge that a name used locally with informal allocation may subsequently be allocated formally, creating operational problems.
7. 非公式の割り当てでローカルに使用される名前がその後正式に割り当てられ、運用上の問題が発生する可能性があるという知識の欠如。
6. There is demand for more than one name resolution protocol for domain names. Domain names contain no metadata to indicate which protocol to use to resolve them. Domain name resolution APIs do not provide a way to specify which protocol to use.
6. ドメイン名には、複数の名前解決プロトコルが必要です。ドメイン名には、それらを解決するために使用するプロトコルを示すメタデータが含まれていません。ドメイン名解決APIは、使用するプロトコルを指定する方法を提供しません。
7. When a Special-Use Domain Name is added to the "Special-Use Domain Names" registry, not all software that processes such names will understand the special use of that name. In many cases, name resolution software will use the Domain Name System for resolution of names not known to have a special use. Consequently, any such use will result in queries for Special-Use Domain Names being sent to Domain Name System authoritative servers. These queries may constitute an operational problem for operators of root zone authoritative name servers. These queries may also inadvertently reveal private information through the contents of the query, which is a privacy consideration.
7. 特殊用途ドメイン名が「特殊用途ドメイン名」レジストリに追加されると、そのような名前を処理するすべてのソフトウェアがその名前の特殊用途を理解するわけではありません。多くの場合、名前解決ソフトウェアは、特別な用途があることが知られていない名前の解決にドメインネームシステムを使用します。その結果、そのような使用は、特殊用途のドメイン名のクエリがドメインネームシステムの権限のあるサーバーに送信されることになります。これらのクエリは、ルートゾーンの権限のあるネームサーバーのオペレーターにとって運用上の問題となる場合があります。これらのクエリは、プライバシーの考慮事項である、クエリの内容を通じて個人情報を誤って明らかにする可能性もあります。
8. Some protocol developers have assumed that they could not succeed in getting a name assigned through the IETF using the process defined in RFC 6761. This is because when the IETF has attempted to follow the process defined in RFC 6761, it has been slow and uncertain. For example, the process of assigning the first new name ('.local') using the process defined in RFC 6761 took more than ten years from beginning to end: longer by a factor of ten than any other part of the protocol development process (largely because this ten years included time to develop the process as well as use it). Other uses of the process have proceeded more smoothly, but there is a reasonably justified perception that using this process is likely to be slow and difficult, with an uncertain outcome.
8. 一部のプロトコル開発者は、RFC 6761で定義されたプロセスを使用してIETFを通じて割り当てられた名前を取得できないと想定しています。これは、IETFがRFC 6761で定義されたプロセスを実行しようとしたときに、遅くて不確実だったためです。たとえば、RFC 6761で定義されたプロセスを使用して最初の新しい名前（ '.local'）を割り当てるプロセスには、最初から最後まで10年以上かかりました。プロトコル開発プロセスの他のどの部分よりも10倍長くなります（これは主に、この10年にプロセスを開発し、使用するための時間が含まれていたためです。プロセスの他の使用法はよりスムーズに進行しましたが、このプロセスの使用は遅く、困難であり、結果は不確かであるという合理的に正当化された認識があります。
9. There is strong resistance within the IETF to assigning domain names to resolution systems outside of the DNS, for a variety of reasons:
9. IETFには、さまざまな理由から、DNS以外の解決システムにドメイン名を割り当てることに強い抵抗があります。
1. It requires a mechanism for identifying which set of resolution processes is required in order to resolve a particular name.
1. 特定の名前を解決するために必要な一連の解決プロセスを識別するメカニズムが必要です。
2. Assertion of authority: there is a sense that the Domain Namespace is "owned" by the IETF or by ICANN, so, if a name is claimed without following their processes, the person or entity that claimed that name should suffer some consequence that would, presumably, deter future circumvention of the official processes.
2. 権限の主張：ドメイン名前空間はIETFまたはICANNによって「所有されている」という意味があるため、プロセスに従わずに名前が主張された場合、その名前を主張した人物またはエンティティは、おそらく、公式プロセスの将来の回避を阻止します。
3. More than one name resolution protocol is bad, in the sense that a single protocol is less complicated to implement and deploy.
3. 1つのプロトコルの実装と展開がそれほど複雑ではないという意味で、複数の名前解決プロトコルは不適切です。
4. The semantics of alternative resolution protocols may differ from the DNS protocol; DNS has the concept of RRtypes, whereas other protocols may not support RRtypes or may support some entirely different data structuring mechanism.
4. 代替解決プロトコルのセマンティクスは、DNSプロトコルとは異なる場合があります。 DNSにはRRtypeの概念がありますが、他のプロトコルはRRtypeをサポートしていない場合や、まったく異なるデータ構造化メカニズムをサポートしている場合があります。
5. If there is an IETF process through which a TLD can be assigned at zero cost other than time, this process will be used as an alternative to the more costly process of getting the name registered through ICANN.
5. 時間以外にゼロコストでTLDを割り当てることができるIETFプロセスがある場合、このプロセスは、ICANNを通じて名前を登録するというよりコストのかかるプロセスの代わりとして使用されます。
6. A name might be assigned for a particular purpose when a more general use of the name would be more beneficial.
6. 名前のより一般的な使用がより有益である場合、名前は特定の目的に割り当てられることがあります。
7. If the IETF assigns a name that some third party or parties believe belongs to them in some way, the IETF could become embroiled in an expensive dispute with those parties.
7. IETFが、一部のサードパーティが何らかの方法でそれらに属していると信じる名前を割り当てた場合、IETFはそれらの当事者との高額な紛争に巻き込まれる可能性があります。
10. If there were no process for assigning names for technical use through the IETF, there is a concern that protocols that require such names would not be able to get them.
10. IETFを通じて技術的に使用するために名前を割り当てるプロセスがなかった場合、そのような名前を必要とするプロトコルがそれらを取得できないことが懸念されます。
11. In some cases where the IETF has made assignments through the process defined in RFC 6761, technical mistakes have been made due to misunderstandings as to the actual process that RFC 6761 specifies (e.g., treating the list of suggested considerations for assigning a name as a set of requirements, all of which must be met). In other cases, the IETF has made de facto assignments of Special-Use Domain Names without following the process in RFC 6761 (see [RFC7050] and [RFC7788]).
11. IETFがRFC 6761で定義されたプロセスを通じて割り当てを行った一部のケースでは、RFC 6761が指定する実際のプロセスに関する誤解（たとえば、名前を割り当てるための推奨される考慮事項のリストをセットとして扱う）により、技術的な誤りが発生しました要件のすべてを満たす必要があります）。その他の場合、IETFはRFC 6761のプロセス（[RFC7050]と[RFC7788]を参照）を行わずに、事実上特殊用途ドメイン名を割り当てています。
12. There are several Top-Level Domain Names that are in use without due process for a variety of purposes. The status of these names need to be clarified and recorded to avoid future disputes about their use [SDO-ICANN-COLL].
12. さまざまな目的のために正当なプロセスなしで使用されているいくつかのトップレベルドメイン名があります。これらの名前のステータスは、それらの使用に関する将来の紛争を回避するために明確にして記録する必要があります[SDO-ICANN-COLL]。
13. In principle, the process defined in RFC 6761 could be used to document the existence of domain names that are not safe to assign and provide information on how those names are used in practice. However, attempts to use RFC 6761 to accomplish this documentation have not been successful (for example, see "Additional Reserved Top Level Domains" [RESERVED-TLDS] and Section 4.2.7 of this document). One side effect of the lack of documentation is that any mitigation effect on the root name servers or on privacy considerations has been missed.
13. 原則として、RFC 6761で定義されているプロセスを使用して、割り当てるのが安全でないドメイン名の存在を文書化し、それらの名前が実際にどのように使用されているかについての情報を提供できます。ただし、このドキュメントを達成するためにRFC 6761を使用する試みは成功していません（たとえば、「追加の予約済みトップレベルドメイン」[予約済み-TLDS]とこのドキュメントのセクション4.2.7を参照してください）。ドキュメントがないことの副作用の1つは、ルートネームサーバーまたはプライバシーに関する考慮事項に対する緩和効果が見落とされていることです。
14. A domain name can be identified as either a DNS name by placing it in the DNS zone(s) or a Special-Use Domain Name by adding it to the IANA registry. Some names are in both places; for example, some locally served zone names are in DNS zones and documented in the "Special-Use Domain Names" registry. At present, the only way a domain name can be added to the "Special-Use Domain Name" registry is for the IETF to take responsibility for the name and designate it for "technical use". There are other potential uses for domain names that should be recorded in the registry, but for which the IETF should not take responsibility.
14. ドメイン名は、DNSゾーンに配置することでDNS名として、またはIANAレジストリに追加することで特殊用途ドメイン名として識別できます。一部の名前は両方の場所にあります。たとえば、ローカルで提供されるゾーン名の一部はDNSゾーンにあり、「特別な用途のドメイン名」レジストリに記載されています。現在、ドメイン名を「特殊用途ドメイン名」レジストリに追加できる唯一の方法は、IETFがその名前を担当し、「技術的使用」に指定することです。レジストリに記録する必要があるが、IETFが責任を負うべきではないドメイン名には、他にも潜在的な用途があります。
15. In some cases, the IETF may see the need to document that a name is in use without claiming that the use of the name is the IETF's particular use of the name. No mechanism exists in the current registry to mark names in this way.
15. 場合によっては、IETFは、名前の使用がIETFの名前の特定の使用であると主張せずに、名前が使用中であることを文書化する必要性を認識することがあります。現在のレジストリには、この方法で名前をマークするメカニズムはありません。
16. During any of the review stages of a document, there is no formal process in which a check is made to ensure that the document does not unintentionally violate the IETF process for adding Special-Use Domain Names to the registry, as was the case, for example, in RFC 7788 [RFC7788].
16. ドキュメントのレビュー段階のいずれにおいても、特殊用途のドメイン名をレジストリに追加するIETFプロセスにドキュメントが意図せず違反していないことを確認するためのチェックが行われる正式なプロセスはありません。たとえば、RFC 7788 [RFC7788]。
17. Use of the registry is inconsistent -- some Special-Use Domain Name RFCs specifically add registry entries, some don't; some specify how and whether special-use name delegations should be done, some don't.
17. レジストリの使用には一貫性がありません-一部の特殊用途ドメイン名RFCは、特にレジストリエントリを追加しますが、そうでないものもあります。特別な用途の名前の委任をどのようにして行うべきかを指定するものもあれば、行わないものもあります。
18. There exists no safe, non-process-violating mechanism for ad hoc assignment of Special-Use Domain Names.
18. 特殊用途ドメイン名のアドホック割り当てのための安全でプロセス違反のないメカニズムはありません。
19. It is generally assumed that protocols that need a Special-Use Domain Name need a mnemonic, single-label, human-readable Special-Use Domain Name for use in user interfaces such as command lines or URL entry fields. While this assumption is correct in some cases, it is likely not correct in all cases, for example, in applications where the domain name is never visible to a user.
19. 一般に、特殊用途ドメイン名を必要とするプロトコルは、コマンドラインやURL入力フィールドなどのユーザーインターフェイスで使用するために、ニーモニックで単一ラベルの人間が読める特殊用途ドメイン名を必要とすると想定されています。この仮定は一部のケースでは正しいですが、たとえば、ドメイン名がユーザーに表示されないアプリケーションでは、すべてのケースで正しくない可能性があります。
20. RFC 6761 uses the term "domain name" to describe the thing for which special uses are registered. This creates a great deal of confusion because some readers take "domain name" to imply the use of the DNS protocol.
20. RFC 6761では、「ドメイン名」という用語を使用して、特別な用途が登録されているものについて説明しています。一部のリーダーはDNSプロトコルの使用を意味する「ドメイン名」を使用するため、これは大きな混乱を引き起こします。
21. The use of DNSSEC with Special-Use Domain Names is an open issue. There is no consensus or guidance about how to use DNSSEC with various classes of Special-Use Domain Names. Considerations in the use of DNSSEC with Special-Use Domain Names include:
21. DNSSECと特殊用途ドメイン名の使用は未解決の問題です。特殊用途ドメイン名のさまざまなクラスでDNSSECを使用する方法についての合意やガイダンスはありません。特殊用途ドメイン名でDNSSECを使用する際の考慮事項は次のとおりです。
1. What class of Special-Use Domain Name is under consideration: non-DNS, locally served zone, or other?
1. 検討中の特殊用途ドメイン名のクラス：非DNS、ローカルサービスゾーン、またはその他？
2. Does the Special-Use Domain Name require a delegation in the root zone; if so, should that delegation be signed or not? If there is no delegation, then this will be treated by validating resolvers as a secure denial of existence for that zone. This would not be appropriate for a name being resolved using the DNS protocol.
2. 特殊用途ドメイン名には、ルートゾーンでの委任が必要ですか。もしそうなら、その代表団は署名されるべきかどうか？委任がない場合、リゾルバーを検証することにより、そのゾーンの存在の安全な拒否として扱われます。これは、DNSプロトコルを使用して解決される名前には適していません。
3. A process would be required through which the IETF can cause a delegation in the root zone to be instantiated.
3. IETFがルートゾーンの委任をインスタンス化させるプロセスが必要になります。
4. What are the recommended practices for using DNS with the specific Special-Use Domain Name?
4. 特定の特殊用途ドメイン名でDNSを使用するための推奨される方法は何ですか？
The above list represents the current understanding of the authors as to the complete set of problems that have been identified during discussion by the working group on this topic. The remainder of this document provides additional context that will be needed for reasoning related to these problems.
上記のリストは、このトピックに関するワーキンググループによる議論中に特定された問題の完全なセットに関する著者の現在の理解を表しています。このドキュメントの残りの部分では、これらの問題に関連する推論に必要となる追加のコンテキストを提供します。
There are three primary (see Section 4.1) and numerous secondary (Section 4.2) documents to consider when thinking about the Special-Use Domain Names process.
特殊用途ドメイン名プロセスについて検討する際に考慮すべき3つの一次ドキュメント（セクション4.1を参照）と多数の二次ドキュメント（セクション4.2を参照）があります。
How names are resolved is ambiguous, in the sense that some names are Special-Use Domain Names that require special handling and some names can be resolved using the DNS protocol with no special handling.
一部の名前は特別な処理を必要とする特殊用途ドメイン名であり、一部の名前は特別な処理なしでDNSプロトコルを使用して解決できるという意味で、名前の解決方法はあいまいです。
The assignment of Internet Names is not under the sole control of any one organization. The IETF has authority in some cases, but only with respect to "technical uses". At present, ICANN is the designated administrator of the root zone; but generally not of zones other than the root zone. Neither of these authorities can, in any practical sense, exclude the practice of ad hoc use of names. Unauthorized use of domain names can be accomplished by any entity that has control over one or more name servers or resolvers, in the context of any hosts and services that entity operates. It can also be accomplished by authors of software who decide that a Special-Use Domain Name is the right way to indicate the use of an alternate resolution mechanism.
インターネット名の割り当ては、1つの組織の単独の管理下にはありません。 IETFは、場合によっては「技術的な使用」に関してのみ権限を持ちます。現在、ICANNはルートゾーンの指定管理者です。ただし、通常はルートゾーン以外のゾーンは対象外です。これらの当局はどちらも、実際的な意味では、名前のその場限りの使用の慣行を排除することはできません。ドメイン名の不正使用は、エンティティが動作するホストとサービスのコンテキストで、1つ以上のネームサーバーまたはリゾルバを制御するエンティティによって実行されます。これは、特殊用途ドメイン名が代替の解決メカニズムの使用を示す正しい方法であると判断したソフトウェアの作成者によっても達成できます。
The primary documents are considered primary because they directly address the IETF's past thoughts on this topic in a general way, and also because they describe what the IETF does in practice.
一次ドキュメントは、このトピックに関するIETFの過去の考えを一般的な方法で直接扱っているため、およびIETFが実際に何をしているのかを説明しているため、一次ドキュメントと見なされます。
[RFC2826] is not an IETF consensus document, and it appears to have been written to address a different problem than the Special-Use Domain Name problem. However, it speaks directly to several of the key issues that must be considered, and, coming as it does from the IAB, it is rightly treated as having significant authority despite not being an IETF consensus document.
[RFC2826]はIETFの合意文書ではなく、特殊用途のドメイン名の問題とは異なる問題に対処するために作成されたようです。ただし、考慮が必要ないくつかの主要な問題に直接言及しており、IABからのように、IETFの合意文書ではないにもかかわらず、重要な権限を持っていると正しく扱われています。
This document should be considered required reading for IETF participants who wish to express an informed opinion on the topic of Special-Use Domain Names. The main points that appear relevant to the Special-Use Domain Names problem are: o The Internet requires a globally unique namespace: a namespace in which any given name refers to the same information (has the same meaning) no matter who requests that information and no matter from which specific name server they request it.
このドキュメントは、特別用途のドメイン名のトピックについて情報に基づいた意見を表明したいIETF参加者には必読であると考える必要があります。特殊用途ドメイン名の問題に関連すると思われる主なポイントは次のとおりです。oインターネットにはグローバルに一意の名前空間が必要です。名前空間は、誰がその情報を要求しても、同じ情報を参照する（同じ意味を持つ）名前空間です。どの特定のネームサーバーから要求しても、
o Private networks may operate private namespaces, with names that have meanings only locally (within the private network), but they still require that names in the public namespace be globally unique.
o プライベートネットワークは、ローカル（プライベートネットワーク内）でのみ意味を持つ名前を持つプライベート名前空間を操作できますが、パブリック名前空間の名前はグローバルに一意である必要があります。
o The Domain Name System [RFC1035] is not the only protocol that may be used for resolving domain names.
o ドメインネームシステム[RFC1035]は、ドメイン名の解決に使用できる唯一のプロトコルではありません。
o Users cannot be assumed to know how to distinguish between symbolic references that have local meaning and references that have global meaning. Therefore, users may share references that incorporate domain names with no global meaning (for example, a URL of 'http://mysite.example.corp', where 'example.corp' is a domain used privately and informally as described in [SDO-ICANN-COLL]).
o ユーザーは、ローカルな意味を持つシンボリック参照とグローバルな意味を持つ参照を区別する方法を知っていると想定することはできません。したがって、ユーザーは、グローバルな意味を持たないドメイン名を組み込んだ参照を共有することがあります（たとえば、「http：//mysite.example.corp」のURL。「example.corp」は、[ SDO-ICANN-COLL]）。
o While such a reference in the user's context refers to the object the user wishes to share, when the reference is used in a different context, it could refer either to some different object in the recipient's context or to no object at all. The effect of this reference escaping the context in which it is valid is that the user's intended communication will not be able to be understood by the recipients of the communication.
o ユーザーのコンテキストでのそのような参照は、ユーザーが共有したいオブジェクトを参照しますが、参照が別のコンテキストで使用される場合、受信者のコンテキスト内の別のオブジェクトを参照することも、オブジェクトをまったく参照しないこともあります。この参照が有効であるコンテキストをエスケープすることの効果は、ユーザーの意図された通信が通信の受信者によって理解されないことです。
This same problem can also occur when a single user copies a name from one context in which it has one meaning into a different context in which it has a different meaning -- for example, copying a '.onion' domain name out of a Tor Browser [TOR], where it has meaning, and pasting this name into an SSH client that doesn't support connecting over the Tor network.
この同じ問題は、1人のユーザーが1つの意味を持つ1つのコンテキストから別の意味を持つ別のコンテキストに名前をコピーするときにも発生する可能性があります。たとえば、「。onion」ドメイン名をTorからコピーするブラウザ[TOR]は、意味があり、Torネットワーク経由の接続をサポートしないSSHクライアントにこの名前を貼り付けます。
We can summarize the advice in this document as follows:
このドキュメントのアドバイスは、次のように要約できます。
o Domain names with unambiguous global meaning are preferable to domain names with local meaning that will be ambiguous. Nevertheless, both globally meaningful and locally special names are in use and must be supported.
o 明確なグローバルな意味を持つドメイン名は、あいまいになるローカルな意味を持つドメイン名よりも望ましいです。それにもかかわらず、グローバルに意味のある名前とローカルに特別な名前の両方が使用されており、サポートする必要があります。
o At the time of the writing of this document, the IAB was of the opinion that there might well be more than one name resolution protocol used to resolve domain names.
o このドキュメントの執筆時点で、ドメイン名の解決に使用される名前解決プロトコルは複数ある可能性があるとIABは考えていました。
The second important document is "Special-Use Domain Names" [RFC6761]. RFC 6761 represents the current IETF consensus on designating and recording Special-Use Domain Names. The IETF has experienced problems with the designation process described in RFC 6761; these concerns motivate this document. Familiarity with RFC 6761 is a prerequisite for having an informed opinion on the topic of Special-Use Domain Names.
2番目の重要なドキュメントは、「特殊用途ドメイン名」[RFC6761]です。 RFC 6761は、特殊用途ドメイン名の指定と記録に関する現在のIETFコンセンサスを表しています。 IETFは、RFC 6761に記載されている指定プロセスで問題を経験しました。これらの懸念がこの文書の動機となります。 RFC 6761に精通していることは、特別な用途のドメイン名のトピックについて十分な情報に基づいた意見を持つための前提条件です。
RFC 6761 defines two aspects of Special-Use Domain Names: designating a domain name to have a special purpose and registering that special use in the "Special-Use Domain Names" registry. The designation process is defined in a single sentence (RFC 6761, Section 4):
RFC 6761は、特殊用途ドメイン名の2つの側面を定義します。特殊な目的を持つドメイン名を指定することと、その特殊用途を「特殊用途ドメイン名」レジストリに登録することです。指定プロセスは単一の文で定義されます（RFC 6761、セクション4）：
If it is determined that special handling of a name is required in order to implement some desired new functionality, then an IETF "Standards Action" or "IESG Approval" specification [RFC5226] MUST be published describing the new functionality.
目的の新しい機能を実装するために名前の特別な処理が必要であると判断された場合、IETFの「標準アクション」または「IESG承認」仕様[RFC5226]を公開して、新しい機能を説明する必要があります。
This sentence requires that any designation of a Special-Use Domain Name is subject to the same open review and consensus process as used to produce and publish all other IETF specifications.
この文では、特殊用途ドメイン名の指定は、他のすべてのIETF仕様の作成および公開に使用されるのと同じオープンレビューおよびコンセンサスプロセスに従う必要があります。
The registration process is a purely mechanical process, in which the existence of the newly designated Special-Use Domain Name is recorded, with a pointer to a section in the relevant specification document that defines the ways in which special handling is to be applied to the name.
登録プロセスは純粋に機械的なプロセスであり、新しく指定された特別用途ドメイン名の存在が記録され、関連する仕様文書のセクションへのポインタが付いており、特別な処理がどのように適用されるかを定義しています。名前。
RFC 6761 provides the process whereby "Multicast DNS" [RFC6762] designated '.local' as a Special-Use Domain Name and included it in the "Special-Use Domain Names" registry. RFC 6761 also enumerates a set of names that were previously used or defined to have special uses prior to its publication. Since there had been no registry for these names prior to the publication of RFC 6761, the documents defining these names could not have added them to the registry.
RFC 6761は、「マルチキャストDNS」[RFC6762]が「.local」を特殊用途ドメイン名として指定し、それを「特殊用途ドメイン名」レジストリに含めるプロセスを提供します。 RFC 6761はまた、公開前に特別に使用するために以前に使用または定義された一連の名前を列挙しています。 RFC 6761の公開以前は、これらの名前のレジストリは存在していなかったため、これらの名前を定義するドキュメントでは、それらをレジストリに追加できませんでした。
Several important points to think about with respect to RFC 6761 are:
RFC 6761に関して考慮すべきいくつかの重要な点は次のとおりです。
o A Special-Use Domain Name may be a name that should be resolved using the DNS protocol with no special handling. An example of this is 'in-addr.arpa' (which is an example of a Special-Use Domain Name that is not a TLD).
o 特殊用途ドメイン名は、特別な処理を行わずにDNSプロトコルを使用して解決する必要がある名前である場合があります。これの例は「in-addr.arpa」です（これはTLDではない特殊用途ドメイン名の例です）。
o A Special-Use Domain Name may be a name that is resolved using the DNS protocol and that requires no special handling in the stub resolver but that requires special handling in the recursive resolver. An example of this would be '10.in-addr.arpa.'.
o 特殊用途ドメイン名は、DNSプロトコルを使用して解決され、スタブリゾルバで特別な処理を必要としないが、再帰リゾルバで特別な処理を必要とする名前である場合があります。この例は「10.in-addr.arpa。」です。
o A Special-Use Domain Name may be a name that requires special handling in the stub resolver. An example would be a Special-Use Top-Level Domain Name like '.local', which acts as a signal to indicate that the local stub resolver should use a non-DNS protocol for name resolution.
o 特殊用途ドメイン名は、スタブリゾルバで特別な処理を必要とする名前の場合があります。例としては、「。local」などの特殊用途のトップレベルドメイン名が挙げられます。これは、ローカルスタブリゾルバーが名前解決に非DNSプロトコルを使用する必要があることを示す信号として機能します。
o The current IETF consensus (from a process perspective, not necessarily from the perspective of what would be consensus if the IETF were to attempt to produce a new consensus document) is that all of these purposes for Special-Use Domain Names are valid.
o 現在のIETFコンセンサス（プロセスの観点から、必ずしもIETFが新しいコンセンサスドキュメントを作成しようとした場合のコンセンサスの観点からではない）は、これらの特殊用途ドメイン名の目的がすべて有効であることです。
In this case, the term "stub resolver" does not mean "DNS protocol stub resolver". The stub resolver is the entity within a particular software stack that takes a question about a domain name and answers it. One way a stub resolver can answer such a question is using the DNS protocol; however, it is in the stub resolver (as we are using the term here) that the decision as to whether to use a protocol (and if so, which protocol) or a local database of some sort is made.
この場合、「スタブリゾルバ」という用語は「DNSプロトコルスタブリゾルバ」を意味するものではありません。スタブリゾルバは、ドメイン名に関する質問を受け取り、それに回答する特定のソフトウェアスタック内のエンティティです。スタブリゾルバーがこのような質問に答えられる1つの方法は、DNSプロトコルを使用することです。ただし、プロトコル（および使用する場合はどのプロトコル）を使用するか、または何らかのローカルデータベースを使用するかを決定するのは、スタブリゾルバ（ここではこの用語を使用しています）です。
RFC 6761 does not limit Special-Use Domain Names to TLDs. However, at present, all Special-Use Domain Names registered in the "Special-Use Domain Names" registry [SDO-IANA-SUDR] either are intended to be resolved using the DNS protocol, are TLDs, or are both. That is, at present there exist no Special-Use Domain Names that require special handling by stub resolvers and which are not at the top level of the naming hierarchy.
RFC 6761は、特殊用途ドメイン名をTLDに制限していません。ただし、現時点では、「特殊用途ドメイン名」レジストリ[SDO-IANA-SUDR]に登録されているすべての特殊用途ドメイン名は、DNSプロトコルを使用して解決することを目的としているか、TLDであるか、またはその両方です。つまり、現在、スタブリゾルバによる特別な処理を必要とし、命名階層の最上位にない特別な用途のドメイン名は存在しません。
One point to take from this is that there is already a requirement in RFC 6762 that when a stub resolver encounters the special label, 'local' as the rightmost label of a domain name, it can only use the Multicast DNS (mDNS) protocol to resolve that domain name.
これから取る1つのポイントは、スタブリゾルバーがドメイン名の右端のラベルとして「local」という特殊なラベルを検出した場合、マルチキャストDNS（mDNS）プロトコルのみを使用できるという要件がRFC 6762にすでにあることです。そのドメイン名を解決します。
There exists a Memorandum of Understanding (MoU) [RFC2860] between the IETF and ICANN that discusses how names and numbers will be managed through IANA. This document is important to the discussion of Special-Use Domain Names because, while it delegates authority for managing the DNS Namespace generally to ICANN, it reserves to the IETF the authority that is then formalized in RFC 6761. RFC 2860 specifically states:
IETFとICANNの間には、IANAを通じて名前と番号を管理する方法について議論する覚書（MoU）[RFC2860]があります。このドキュメントは、DNS名前空間を管理するための権限を一般にICANNに委任する一方で、RFC 6761で正式に定められた権限をIETFに留保するため、特殊用途ドメイン名の議論にとって重要です。RFC2860は具体的に次のように述べています。
Note that (a) assignments of domain names for technical uses (such as domain names for inverse DNS lookup), (b) assignments of specialised address blocks (such as multicast or anycast blocks), and (c) experimental assignments are not considered to be policy issues, and shall remain subject to the provisions of this Section 4.
（a）技術的な用途のためのドメイン名の割り当て（逆DNSルックアップのためのドメイン名など）、（b）特殊なアドレスブロックの割り当て（マルチキャストまたはエニーキャストブロックなど）、および（c）実験的な割り当ては考慮されないことに注意してくださいポリシーの問題であり、このセクション4の規定に従うものとします。
The above text is an addendum to the following:
上記のテキストは、以下の補足です。
Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF: the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU.
IETFによって指定された技術的な考慮事項に加えて、2つの特定の割り当てられたスペースがポリシーの問題を提示します。ドメイン名の割り当てとIPアドレスブロックの割り当てです。これらのポリシーの問題は、このMOUの範囲外です。
The assignment of names in the DNS root zone, and the management of the Domain Namespace, is by default a function that is performed by ICANN. However, the MoU specifically exempts domain names assigned for technical use and uses the example of domains used for inverse DNS lookup. Both 'in-addr.arpa' and 'ip6.arpa' are in the "Special-Use Domain Names" registry.
DNSルートゾーンでの名前の割り当て、およびドメインネームスペースの管理は、デフォルトではICANNによって実行される機能です。ただし、MoUは技術的な使用のために割り当てられたドメイン名を明確に除外し、逆DNSルックアップに使用されるドメインの例を使用します。 「in-addr.arpa」と「ip6.arpa」はどちらも「特別な用途のドメイン名」レジストリにあります。
Implicit in the MoU is the fact that the IETF and ICANN retain, between them, sole authority for assigning any names from the Domain Namespace. Both the IETF and ICANN have internal processes for making such assignments.
MoUで暗黙的に示されているのは、IETFとICANNがドメインネームスペースから名前を割り当てる唯一の権限をそれらの間に保持しているという事実です。 IETFとICANNの両方に、このような割り当てを行うための内部プロセスがあります。
The point here is not to say what the implications of this statement in the MoU are, but rather to call the reader's attention to the existence of this statement.
ここでのポイントは、MoUでのこのステートメントの意味が何であるかを言うことではなく、このステートメントの存在に対する読者の注意を喚起することです。
When the IETF received processing requests to add names to the "Special-Use Domain Names" registry, as documented in [RESERVED-TLDS] and [P2P-DOMAIN-NAMES], the IETF chartered a review of the process defined in RFC 6761 for adding names to the registry (as explained earlier). The IETF sent a liaison statement [SDO-IAB-ICANN-LS] to ICANN to notify them of the review, affirm that the discussion would be "open and transparent to participation by interested parties", and explicitly invite members of the ICANN community to participate.
IETFは、[RESERVED-TLDS]と[P2P-DOMAIN-NAMES]に記載されているように、「特別用途ドメイン名」レジストリに名前を追加する処理要求を受け取ったときに、RFC 6761で定義されているプロセスのレビューを作成しました。レジストリに名前を追加する（前述のとおり）。 IETFはリエゾンステートメント[SDO-IAB-ICANN-LS]をICANNに送信してレビューを通知し、その議論は「利害関係者の参加に対してオープンで透明性がある」ことを確認し、ICANNコミュニティのメンバーに参加する。
4.1.5. IAB Statement on the Registration of Special Use Names in the ARPA Domain
4.1.5. ARPAドメインでの特殊用途名の登録に関するIABステートメント
As part of the process of resolving the controversy mentioned in Section 4.2.7, the IAB issued a statement saying, in part:
セクション4.2.7で言及された論争を解決するプロセスの一環として、IABは次のように述べる声明を発表しました。
There is currently no process defined with ICANN for special use names to be delegated in the root zone; it has seemed likely to take significant effort to create one. The IAB has noted that .arpa can be used "for technical infrastructure established by IETF standards" [SDO-IAB-SUDN-REG].
現在、ルートゾーンで委任される特別な使用名についてICANNで定義されたプロセスはありません。作成にはかなりの労力がかかるようです。 IABは、.arpaは「IETF標準によって確立された技術インフラストラクチャ」[SDO-IAB-SUDN-REG]に使用できると指摘しています。
Given the lack of an established process with ICANN, IETF documents cannot reserve names in the root of the DNS namespace if those names are to be delegated (that is, used by the DNS protocol). It would be possible to work with ICANN to develop a process for such delegations, but the success of that joint work, and the amount of time it would take, would still be uncertain.
ICANNで確立されたプロセスがないため、IETFドキュメントは、それらの名前が委任される（つまり、DNSプロトコルで使用される）場合、DNS名前空間のルートで名前を予約できません。 ICANNと協力してそのような委任のプロセスを開発することは可能ですが、その共同作業の成功と、それにかかる時間は依然として不確実です。
4.2. Secondary Documents Relating to the Special-Use Domain Name Question
4.2. 特別用途のドメイン名の質問に関連する二次ドキュメント
In addition to these documents, there are several others with which participants in this discussion should be familiar.
これらのドキュメントに加えて、このディスカッションの参加者が精通している他のドキュメントがいくつかあります。
Multicast DNS [RFC6762] defines the Multicast DNS protocol, which uses the '.local' Special-Use Top-Level Domain Name. Section 3 describes the semantics of "multicast DNS names". It is of considerable historical importance to note that the -00 version of the document that eventually became RFC 6762, an individual submission, was published in July of 2001. The version posted at that time contains substantially the same text in Section 3 as RFC 6762 did when published and was discussed in the DNSEXT Working Group at IETF 51 in August of 2001 [IETF-PRO-51]. The July 2001 draft designated '.local.arpa' as the Special-Use Domain Name. This idea was strongly opposed by DNSEXT Working Group participants, and as a result, the author eventually switched to using '.local'.
マルチキャストDNS [RFC6762]は、「。local」特殊用途トップレベルドメイン名を使用するマルチキャストDNSプロトコルを定義します。セクション3では、「マルチキャストDNS名」のセマンティクスについて説明します。個別の提出物である最終的にRFC 6762となるドキュメントの-00バージョンが2001年7月に発行されたことに注意することは、歴史的にかなり重要です。そのときに投稿されたバージョンには、セクション3にRFC 6762と実質的に同じテキストが含まれています2001年8月にIETF 51で開催されたDNSEXTワーキンググループで議論された[IETF-PRO-51]。 2001年7月のドラフトでは、「。local.arpa」を特殊用途ドメイン名として指定しました。このアイデアはDNSEXTワーキンググループの参加者によって強く反対され、その結果、著者は最終的に「.local」の使用に切り替えました。
The history of RFC 6762 is documented in substantial detail in Appendix H of RFC 6762; some notable milestones include the initial proposal to replace AppleTalk's Name Binding Protocol (NBP) in July 1997, the chartering of the Zeroconf Working Group in September 1999, and the assignment of a multicast address for link-local name discovery in April of 2000. A companion requirements document, eventually published as [RFC6760], was first published in September of 2001.
RFC 6762の履歴は、RFC 6762の付録Hにかなり詳しく記載されています。注目すべきマイルストーンには、1997年7月にAppleTalkのName Binding Protocol（NBP）を置き換える最初の提案、1999年9月のZeroconfワーキンググループのチャーター、2000年4月のリンクローカル名検出用のマルチキャストアドレスの割り当てなどがあります。最終的に[RFC6760]として公開されたコンパニオン要件ドキュメントは、2001年9月に初めて公開されました。
The point of mentioning these dates is so that discussions involving the time when the '.local' domain was first deployed, and the context in which it was deployed, may be properly informed.
これらの日付について言及するポイントは、「。local」ドメインが最初にデプロイされた時間と、それがデプロイされたコンテキストを含む議論が適切に通知されるようにするためです。
The '.onion' Special-Use Top-Level Domain Name [RFC7686] is important because it is the most recent IETF action on the topic of Special-Use Domain Names; although it does not set a new policy, the mere fact of its publication is worth thinking about.
「.onion」特殊用途トップレベルドメイン名[RFC7686]は、特殊用途ドメイン名のトピックに関する最新のIETFアクションであるため、重要です。新しいポリシーを設定するものではありませんが、その公表の単なる事実は検討する価値があります。
Two important points to consider about this document are that:
このドキュメントについて考慮すべき2つの重要な点は次のとおりです。
o The IETF gained consensus to publish it.
o IETFはそれを公開することで合意を得ました。
o Devising a resolution to the situation was constrained by at least two factors. First, there was no process for allocating Special-Use Domain Names at the time that the '.onion' project started using the name; at the time, and since the scope of use of the name was expected to be very constrained, the developers chose to allocate it unilaterally rather than asking the IETF or some other Standards Development Organization (SDO) to create a new process.
o 状況への解決策を考案することは、少なくとも2つの要因によって制約されました。まず、「。onion」プロジェクトが名前の使用を開始した時点では、特殊用途ドメイン名を割り当てるプロセスがありませんでした。当時、名前の使用範囲は非常に制約されることが予想されていたため、開発者は、IETFまたは他の標準開発機構（SDO）に新しいプロセスを作成するよう依頼するのではなく、一方的に割り当てることを選択しました。
Second, for some time, the CA/Browser Forum [SDO-CABF] had been issuing certificates for what they referred to as "internal names". Internal names are names allocated unilaterally for use in site-specific contexts. Issuing certificates for such names came to be considered problematic, since no formal process for testing the validity of such names existed. Consequently, the CA/ Browser Forum decided to phase out the use of such names in certificates [SDO-CABF-INT] and set a deadline after which no new certificates for such names would be issued [SDO-CABF-DEADLINE]. Because the '.onion' domain was allocated unilaterally, this would mean that certificates for subdomains of '.onion' could no longer be issued.
次に、しばらくの間、CA /ブラウザフォーラム[SDO-CABF]は、「内部名」と呼ばれる証明書を発行していました。内部名は、サイト固有のコンテキストで使用するために一方的に割り当てられる名前です。このような名前の有効性をテストする正式なプロセスが存在しなかったため、そのような名前の証明書を発行することは問題があると見なされるようになりました。その結果、CA /ブラウザーフォーラムは、証明書でのこのような名前の使用を段階的に廃止することを決定し[SDO-CABF-INT]、期限が過ぎると、そのような名前の新しい証明書は発行されなくなります[SDO-CABF-DEADLINE]。 「.onion」ドメインは一方的に割り当てられていたため、「。onion」のサブドメインの証明書を発行できなくなりました。
The IETF's designation of '.onion' as a Special-Use Top-Level Domain Name was needed to facilitate the development of a certificate issuance process specific to '.onion' domain names [SDO-CABF-BALLOT144].
IETFによる特殊用途のトップレベルドメイン名としての「.onion」の指定は、「。onion」ドメイン名に固有の証明書発行プロセスの開発を促進するために必要でした[SDO-CABF-BALLOT144]。
"Locally Served DNS Zones" [RFC6303] describes a particular use case for zones that exist by definition and that are resolved using the DNS protocol, but that cannot have a global meaning because the host IP addresses they reference are not unique. This applies to a variety of addresses, including private IPv4 addresses [RFC1918],
「ローカルで提供されるDNSゾーン」[RFC6303]は、定義によって存在し、DNSプロトコルを使用して解決されるゾーンの特定の使用例を説明しますが、参照するホストIPアドレスは一意ではないため、グローバルな意味を持つことはできません。これは、プライベートIPv4アドレス[RFC1918]を含むさまざまなアドレスに適用されます。
"Unique Local IPv6 Unicast Addresses" [RFC4193] (in which this practice was first described), and "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598].
「ユニークなローカルIPv6ユニキャストアドレス」[RFC4193]（この方法が最初に説明された）、および「共有アドレススペース用のIANA予約IPv4プレフィックス」[RFC6598]。
This use case is distinct from the use case for Special-Use Domain Names like '.local' and '.onion' in that the names are resolved using the DNS protocol (but they do require extensions or exceptions to the usual DNS resolution to enforce resolution in a local context rather than the global DNS context). It shares the problem that such names can be assumed neither to be unique across all contexts nor functional for all Internet-connected hosts.
このユースケースは、名前がDNSプロトコルを使用して解決されるという点で、「。local」や「.onion」などの特殊用途ドメイン名のユースケースとは異なります（ただし、強制するには通常のDNS解決の拡張または例外が必要です。グローバルDNSコンテキストではなくローカルコンテキストでの解決）。このような名前は、すべてのコンテキストにわたって一意であると想定することも、インターネットに接続されたすべてのホストに対して機能することもできないという問題を共有しています。
"Name Collision in the DNS" [SDO-ICANN-COLL] is a study that was commissioned by ICANN in an attempt to characterize the potential risk to the Internet of adding global DNS delegations for names that were not previously delegated in the DNS and were not reserved under any RFC, but were also known to be (in the case of '.home') or surmised to be (in the case of '.corp') in significant use for Special-Use-type reasons (local scope DNS or other resolution protocols altogether).
「DNSでの名前の衝突」[SDO-ICANN-COLL]は、以前はDNSで委任されていなかった名前にグローバルDNS委任を追加するインターネットへの潜在的なリスクを特徴付けるためにICANNから委託された調査ですRFCで予約されていませんが、特殊用途タイプの理由（ローカルスコープDNS）で重要な使用（「.home」の場合）や重大な使用（「.corp」の場合）が疑われることも知られていましたまたは他の解決プロトコルも一緒に）。
The ICANN Security and Stability Advisory Committee (SSAC) [SDO-ICANN-SSAC] specification "SSAC Advisory on the Stability of the Domain Namespace" [SDO-ICANN-SAC090] reports on some issues surrounding the conflicting uses, interested parties, and processes related to the Domain Namespace. The specification recommends the development of collaborative processes among the various interested parties to coordinate their activities related to the Domain Namespace.
ICANNセキュリティおよび安定性諮問委員会（SSAC）[SDO-ICANN-SSAC]仕様「ドメイン名前空間の安定性に関するSSAC勧告」[SDO-ICANN-SAC090]は、競合する使用法、利害関係者、およびプロセスに関するいくつかの問題について報告していますドメイン名前空間に関連しています。この仕様では、ドメインネームスペースに関連する活動を調整するために、さまざまな利害関係者間の共同プロセスの開発を推奨しています。
"Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis" [RFC7050] is an example of a document that successfully used the process in RFC 6761 to designate '.ipv4only.arpa' as a Special-Use Domain Name; in this case, the process worked smoothly and without controversy.
「IPv6アドレス合成に使用されるIPv6プレフィックスの検出」[RFC7050]は、RFC 6761のプロセスを使用して「.ipv4only.arpa」を特殊用途ドメイン名として指定したドキュメントの例です。この場合、プロセスは問題なくスムーズに機能しました。
Unfortunately, while the IETF process worked smoothly, in the sense that there was little controversy or delay in approving the new use, it did not work correctly: the name 'ipv4only.arpa' was never added to the "Special-Use Domain Names" registry. This appears to have happened because the document did not explicitly request the addition of an entry for 'ipv4only.arpa' in the "Special-Use Domain Names" registry. This is an illustration of one of the problems that we have with the process in RFC 6761: it is apparently fairly easy to miss the step of adding the name to the registry.
残念ながら、IETFプロセスはスムーズに機能しましたが、新しい使用の承認にはほとんど論争や遅延がなかったという意味で、正しく機能しませんでした。「ipv4only.arpa」という名前は「特別な用途のドメイン名」に追加されませんでした。レジストリ。これは、ドキュメントが「特別用途ドメイン名」レジストリに「ipv4only.arpa」のエントリの追加を明示的に要求しなかったために発生したようです。これは、RFC 6761のプロセスで発生している問題の1つを示しています。レジストリに名前を追加するステップを見落とすことは明らかに簡単です。
"Additional Reserved Top Level Domains" [RESERVED-TLDS] is an example of a document that attempted to reserve several TLDs identified by ICANN as particularly at risk for collision as Special-Use Domain Names with no documented use. This attempt failed.
「追加の予約済みトップレベルドメイン」[RESERVED-TLDS]は、特に衝突のリスクがあるとICANNによって特定されたいくつかのTLDを、使用が文書化されていない特殊用途ドメイン名として予約しようとしたドキュメントの例です。この試みは失敗しました。
Although the aforementioned document failed to gain consensus to be published, the need it was intended to fill still exists. Unfortunately, although a fair amount is known about the use of these names, no RFC exists that describes how they are used and why it would be a problem to delegate them. Additionally, to the extent that the uses being made of these names are valid, no document exists indicating when it might make sense to use them and when it would not make sense to use them.
前述のドキュメントは公開に向けたコンセンサスを得ることはできませんでしたが、それを満たそうとする必要性は依然として存在しています。残念ながら、これらの名前の使用についてはかなりの量が知られていますが、それらがどのように使用され、なぜ委任することが問題になるのかを説明するRFCは存在しません。さらに、これらの名前の使用法が有効である限り、それらを使用する意味がある場合と使用しない場合を示すドキュメントは存在しません。
RFC 7788 [RFC7788] defines the Top-Level Domain Name '.home' for use as the default name for name resolution relative to a home network context. Although, as defined in RFC 7788, '.home' is a Special-Use Domain Name, RFC 7788 did not follow the process specified in RFC 6761: it did not request that '.home' be added to the "Special-Use Domain Names" registry. This was recognized as a mistake and resulted in the posting of an errata report [Err4677]. Additionally, '.home' is an example of an attempt to reuse a domain name that has already been put into use for other purposes without following established processes [SDO-ICANN-COLL], which further complicates the situation. At the time RFC 8244 was written, the IETF was developing a solution to this problem.
RFC 7788 [RFC7788]は、ホームネットワークコンテキストに関連する名前解決のデフォルト名として使用するトップレベルドメイン名「.home」を定義しています。 RFC 7788で定義されているように、「。home」は特殊用途ドメイン名ですが、RFC 7788はRFC 6761で指定されたプロセスに従っていませんでした。「。home」を「特殊用途ドメイン」に追加するように要求していません名前」レジストリ。これは間違いとして認識され、エラッタレポート[Err4677]が投稿されました。さらに、「。home」は、確立されたプロセス[SDO-ICANN-COLL]を実行せずに、他の目的ですでに使用されているドメイン名を再利用する試みの例であり、状況をさらに複雑にします。 RFC 8244が作成された時点で、IETFはこの問題の解決策を開発していました。
A newcomer to the problem of resolving domain names may be under the impression that the DNS sprang fully formed directly from Paul Mockapetris' head (as was the birth of Athena in Greek Mythology). This is not the case. At the time the IAB technical document was written [RFC2826], memories would have been fresh of the evolutionary process that led to DNS' dominance as a protocol for domain name resolution.
ドメイン名を解決する問題の初心者は、DNSが完全にポールモッカペトリスの頭から直接形成されたように見えるかもしれません（ギリシャ神話でのアテナの誕生と同様）。これはそうではありません。 IABの技術文書が作成された時点[RFC2826]では、DNSがドメイン名解決のプロトコルとして優勢に導いた進化の過程が記憶に新しいものでした。
In fact, in the early days of the Internet, hostnames were resolved using a text file, HOSTS.TXT, which was maintained by a central authority, the Network Information Center, and distributed to all hosts on the Internet using the File Transfer Protocol (FTP)
実際、インターネットの初期の段階では、ホスト名はテキストファイルHOSTS.TXTを使用して解決されました。HOSTS.TXTは中央当局であるネットワークインフォメーションセンターによって管理され、ファイル転送プロトコルを使用してインターネット上のすべてのホストに配布されました（ FTP）
[RFC959]. The inefficiency of this process is cited as a reason for the development of the DNS [RFC882] [RFC883] in 1983.
[RFC959]。このプロセスの非効率性は、1983年にDNS [RFC882] [RFC883]が開発された理由として挙げられています。
However, the transition from HOSTS.TXT to the DNS was not smooth. For example, Sun Microsystems' Network Information System (NIS) [CORP-SUN-NIS], at the time known as Yellow Pages, was an active competitor to the DNS, although it failed to provide a complete solution to the global naming problem.
ただし、HOSTS.TXTからDNSへの移行はスムーズではありませんでした。たとえば、Sun Microsystemsのネットワーク情報システム（NIS）[CORP-SUN-NIS]は、当時イエローページとして知られていましたが、グローバルネーミングの問題を完全に解決することはできませんでしたが、DNSに対する積極的な競争相手でした。
Another example was NetBIOS Name Service, also known as WINS [RFC1002]. This protocol was used mostly by Microsoft Windows machines, but also by open-source BSD and Linux operating systems to do name resolution using Microsoft's own name resolution protocol.
別の例は、WINS [RFC1002]としても知られるNetBIOSネームサービスです。このプロトコルは、主にMicrosoft Windowsマシンで使用されましたが、Microsoft独自の名前解決プロトコルを使用して名前解決を行うために、オープンソースのBSDおよびLinuxオペレーティングシステムでも使用されました。
Most modern operating systems can still use the '/etc/hosts' file for name resolution. Many still have a name service switch that can be configured on the host to resolve some domains using the NIS or WINS. Most have the capability to resolve names using mDNS by recognizing the special meaning of the '.local' Special-Use Top-Level Domain Name.
最近のほとんどのオペレーティングシステムでは、名前解決に「/ etc / hosts」ファイルを引き続き使用できます。多くのホストには、NISまたはWINSを使用して一部のドメインを解決するようにホストで構成できるネームサービススイッチがまだあります。ほとんどは、「。local」特殊用途トップレベルドメイン名の特別な意味を認識することにより、mDNSを使用して名前を解決する機能を備えています。
The Sun Microsystems model of having private domains within a corporate site, while supporting the global Domain Name System for off-site, persisted even after the NIS protocol fell into disuse. Microsoft used to recommend that site administrators use a "private" TLD for internal use, and this practice was very much a part of the zeitgeist at the time (see Section 5.1 of [SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at the root of the widespread practice of simply picking an apparently unused TLD and using it for experimental purposes, which persists even at the time of writing of this memo.
企業サイト内にプライベートドメインを持つというSun Microsystemsモデルは、オフサイト用のグローバルドメインネームシステムをサポートしながら、NISプロトコルが使用されなくなった後も持続しました。 Microsoftは以前、サイト管理者が内部使用のために「プライベート」TLDを使用することを推奨していましたが、これは当時のツァイトガイストの一部でした（[SDO-ICANN-COLL]のセクション5.1および[RFC6762]の付録Gを参照）。 ）。この態度は、明らかに未使用のTLDを単に選択し、それを実験目的で使用するという広範な慣行の根底にあります。これは、このメモの執筆時でも存続します。
This history is being presented because discussions about Special-Use Domain Names in the IETF often come down to the question of why users of new name resolution protocols choose to use domain names rather than using some other naming concept that doesn't overlap with the namespace that, in modern times is, by default, resolved using the DNS.
IETFでの特殊用途ドメイン名に関する議論は、新しい名前解決プロトコルのユーザーが、名前空間と重複しない他の名前付け概念を使用するのではなく、ドメイン名を使用することを選択する理由を問うことが多いため、この歴史が提示されています。これは、現代では、デフォルトでDNSを使用して解決されます。
The answer is that as a consequence of this long history of resolving domain names using a wide variety of name resolution systems, domain names are required in a large variety of contexts in user interfaces and applications programming interfaces. Any name that appears in such a context is a domain name. So, developers of new name resolution systems that must work in existing contexts actually have no choice: they must use a Special-Use Domain Name to segregate a portion of the namespace for use with their system.
その答えは、多種多様な名前解決システムを使用してドメイン名を解決してきたこの長い歴史の結果として、ユーザーインターフェイスとアプリケーションプログラミングインターフェイスの多種多様なコンテキストでドメイン名が必要になることです。このようなコンテキストで表示される名前はすべてドメイン名です。そのため、既存のコンテキストで動作する必要がある新しい名前解決システムの開発者は、実際に選択の余地はありません。特殊用途のドメイン名を使用して、システムで使用する名前空間の一部を分離する必要があります。
This document mentions various security and privacy considerations in the text. However, this document creates no new security or privacy concerns.
このドキュメントでは、セキュリティとプライバシーに関するさまざまな考慮事項について説明しています。ただし、このドキュメントでは、セキュリティやプライバシーに関する新たな懸念は生じません。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[CORP-SUN-NIS] Wikipedia, "Network Information Service", August 2017, <https://en.wikipedia.org/wiki/ Network_Information_Service>.
[CORP-SUN-NIS]ウィキペディア、「ネットワーク情報サービス」、2017年8月、<https://en.wikipedia.org/wiki/ Network_Information_Service>。
[DOMAIN-NAMES] Lewis, E., "Domain Names, A Case for Clarifying", Work in Progress, draft-lewis-domain-names-09, August 2017.
[DOMAIN-NAMES]ルイス、E。、「ドメイン名、明確化のためのケース」、作業中、draft-lewis-domain-names-09、2017年8月。
[Err4677] RFC Errata, "Erratum ID 4677", RFC 7788, <https://www.rfc-editor.org/errata/eid4677>.
[Err4677] RFC Errata、「Erratum ID 4677」、RFC 7788、<https://www.rfc-editor.org/errata/eid4677>。
[IETF-PRO-51] IETF, "Proceedings of the 51st IETF Meeting", August 2001, <http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>.
[IETF-PRO-51] IETF、「第51回IETF会議の議事録」、2001年8月、<http://www.ietf.org/proceedings/51/51-45.htm#TopOfPage>。
[P2P-DOMAIN-NAMES] Grothoff, C., Wachs, M., Wolf, H., Ed., Appelbaum, J., and L. Ryge, "Special-Use Domain Names of Peer-to-Peer Systems", Work in Progress, draft-grothoff-iesg-special-use-p2p-names-04, January 2015.
[P2P-DOMAIN-NAMES] Grothoff、C.、Wachs、M.、Wolf、H.、Ed。、Appelbaum、J。、およびL. Ryge、「ピアツーピアシステムの特殊用途ドメイン名」、 Work in Progress、draft-grothoff-iesg-special-use-p2p-names-04、2015年1月。
[PROBLEM-SPECIAL-NAMES] Huston, G., Koch, P., Durand, A., and W. Kumari, "Problem Statement for the Reservation of Special-Use Domain Names using RFC6761", Work in Progress, draft-adpkja-dnsop-special-names-problem-06, September 2016.
[問題名] Huston、G.、Koch、P.、Durand、A。、およびW. Kumari、「RFC6761を使用した特殊用途ドメイン名の予約に関する問題ステートメント、作業中、draft-adpkja -dnsop-special-names-problem-06、2016年9月。
[RESERVED-TLDS] Chapin, L. and M. McFadden, "Additional Reserved Top Level Domains", Work in Progress, draft-chapin-additional-reserved-tlds-02, March 2015.
[予約済み-TLDS]チャピンL.およびM.マクファデン、「追加の予約済みトップレベルドメイン」、作業中、draft-chapin-additional-reserved-tlds-02、2015年3月。
[RFC882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983, <https://www.rfc-editor.org/info/rfc882>.
[RFC882] Mockapetris、P。、「ドメイン名：概念と機能」、RFC 882、DOI 10.17487 / RFC0882、1983年11月、<https://www.rfc-editor.org/info/rfc882>。
[RFC883] Mockapetris, P., "Domain names: Implementation specification", RFC 883, DOI 10.17487/RFC0883, November 1983, <https://www.rfc-editor.org/info/rfc883>.
[RFC883] Mockapetris、P。、「ドメイン名：実装仕様」、RFC 883、DOI 10.17487 / RFC0883、1983年11月、<https://www.rfc-editor.org/info/rfc883>。
[RFC959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, <https://www.rfc-editor.org/info/rfc959>.
[RFC959] Postel、J。およびJ. Reynolds、「ファイル転送プロトコル」、STD 9、RFC 959、DOI 10.17487 / RFC0959、1985年10月、<https://www.rfc-editor.org/info/rfc959>。
[RFC1002] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications", STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, <https://www.rfc-editor.org/info/rfc1002>.
[RFC1002]国防高等研究計画局、インターネット活動委員会、およびエンドツーエンドサービスタスクフォースのNetBIOSワーキンググループ、「TCP / UDPトランスポート上のNetBIOSサービスのプロトコル標準：詳細な仕様」、STD 19、RFC 1002、DOI 10.17487 / RFC1002、1987年3月、<https://www.rfc-editor.org/info/rfc1002>。
[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>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<https://www.rfc-editor.org/info/rfc1918>。
[RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain Names", RFC 2352, DOI 10.17487/RFC2352, May 1998, <https://www.rfc-editor.org/info/rfc2352>.
[RFC2352] Vaughan、O。、「A Legal Names as Domain Names」、RFC 2352、DOI 10.17487 / RFC2352、1998年5月、<https://www.rfc-editor.org/info/rfc2352>。
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 2000, <https://www.rfc-editor.org/info/rfc2826>.
[RFC2826]インターネットアーキテクチャボード、「IAB Technical Comment on the Unique DNS Root」、RFC 2826、DOI 10.17487 / RFC2826、2000年5月、<https://www.rfc-editor.org/info/rfc2826>。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, June 2000, <https://www.rfc-editor.org/info/rfc2860>.
[RFC2860]カーペンター、B。、ベイカー、F。、およびM.ロバーツ、「Internet Assigned Numbers Authorityの技術的作業に関する覚書」、RFC 2860、DOI 10.17487 / RFC2860、2000年6月、<https：// www.rfc-editor.org/info/rfc2860>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<https://www.rfc-editor.org/info/rfc4193>。
[RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 6303, DOI 10.17487/RFC6303, July 2011, <https://www.rfc-editor.org/info/rfc6303>.
[RFC6303]アンドリュース、M。、「ローカルで提供されるDNSゾーン」、BCP 163、RFC 6303、DOI 10.17487 / RFC6303、2011年7月、<https://www.rfc-editor.org/info/rfc6303>。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <https://www.rfc-editor.org/info/rfc6598>.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、DOI 10.17487 / RFC6598 、2012年4月、<https://www.rfc-editor.org/info/rfc6598>。
[RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 6760, DOI 10.17487/RFC6760, February 2013, <https://www.rfc-editor.org/info/rfc6760>.
[RFC6760] Cheshire、S。、およびM. Krochmal、「AppleTalk Name Binding Protocol（NBP）を置き換えるプロトコルの要件」、RFC 6760、DOI 10.17487 / RFC6760、2013年2月、<https：//www.rfc-editor .org / info / rfc6760>。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <https://www.rfc-editor.org/info/rfc6761>.
[RFC6761] Cheshire、S。およびM. Krochmal、「特殊用途ドメイン名」、RFC 6761、DOI 10.17487 / RFC6761、2013年2月、<https://www.rfc-editor.org/info/rfc6761>。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, <https://www.rfc-editor.org/info/rfc6762>.
[RFC6762]チェシャーS.およびM.クロマル、「マルチキャストDNS」、RFC 6762、DOI 10.17487 / RFC6762、2013年2月、<https://www.rfc-editor.org/info/rfc6762>。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.
[RFC7050] Savolainen、T.、Korhonen、J。、およびD. Wing、「IPv6アドレス合成に使用されるIPv6プレフィックスの発見」、RFC 7050、DOI 10.17487 / RFC7050、2013年11月、<https：//www.rfc -editor.org/info/rfc7050>。
[RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 2015, <https://www.rfc-editor.org/info/rfc7686>.
[RFC7686] Appelbaum、J。およびA. Muffett、「The ".onion" Special-Use Domain Name」、RFC 7686、DOI 10.17487 / RFC7686、2015年10月、<https://www.rfc-editor.org/info / rfc7686>。
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, <https://www.rfc-editor.org/info/rfc7719>.
[RFC7719] Hoffman、P.、Sullivan、A。、およびK. Fujiwara、「DNS用語」、RFC 7719、DOI 10.17487 / RFC7719、2015年12月、<https://www.rfc-editor.org/info/rfc7719 >。
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7788] Stenberg、M.、Barth、S。、およびP. Pfister、「Home Networking Control Protocol」、RFC 7788、DOI 10.17487 / RFC7788、2016年4月、<https://www.rfc-editor.org/info / rfc7788>。
[SDO-CABF] CA/Browser Forum, "CA/Browser Forum Home Page", <https://cabforum.org>.
[SDO-CABF] CA /ブラウザフォーラム、「CA /ブラウザフォーラムホームページ」、<https://cabforum.org>。
[SDO-CABF-BALLOT144] CA/Browser Forum, "Ballot 144 - Validation Rules for .onion Names", February 2015, <https://cabforum.org/2015/ 02/18/ballot-144-validation-rules-dot-onion-names>.
[SDO-CABF-BALLOT144] CA /ブラウザフォーラム、「Ballot 144-.onion名の検証ルール」、2015年2月、<https://cabforum.org/2015/ 02/18 / ballot-144-validation-rules-ドットオニオン名>。
[SDO-CABF-DEADLINE] CA/Browser Forum, "SSL Certificates for Internal Server Names", January 2013, <https://www.digicert.com/internal-names.htm>.
[SDO-CABF-DEADLINE] CA /ブラウザフォーラム、「内部サーバー名のSSL証明書」、2013年1月、<https://www.digicert.com/internal-names.htm>。
[SDO-CABF-INT] CA/Browser Forum, "Guidance on the Deprecation of Internal Server Names and Reserved IP Addresses", June 2012, <https://cabforum.org/internal-names/>.
[SDO-CABF-INT] CA /ブラウザフォーラム、「内部サーバー名と予約済みIPアドレスの廃止に関するガイダンス」、2012年6月、<https://cabforum.org/internal-names/>。
[SDO-IAB-ICANN-LS] IETF, "Liaison Statement from the IAB to the ICANN Board on Technical Use of Domain Names", September 2014, <https://datatracker.ietf.org/liaison/1351>.
[SDO-IAB-ICANN-LS] IETF、「IABからICANN理事会へのドメイン名の技術的使用に関する連絡声明」、2014年9月、<https://datatracker.ietf.org/liaison/1351>。
[SDO-IAB-SUDN-REG] IAB, "Internet Architecture Board statement on the registration of special use names in the ARPA domain", March 2017, <https://www.iab.org/documents/ correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/>.
[SDO-IAB-SUDN-REG] IAB、「ARPAドメインでの特殊用途名の登録に関するインターネットアーキテクチャボードの声明」、2017年3月、<https://www.iab.org/documents/correspondation-reports-documents / 2017-2 / iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain />。
[SDO-IANA-SUDR] IANA, "Special-Use Domain Names", <http://www.iana.org/ assignments/special-use-domain-names>.
[SDO-IANA-SUDR] IANA、「特別用途ドメイン名」、<http://www.iana.org/assignments/special-use-domain-names>。
[SDO-ICANN-COLL] Interisle Consulting Group, LLC, "Name Collision in the DNS", Version 1.5, August 2013, <https://www.icann.org/ en/system/files/files/name-collision-02aug13-en.pdf>.
[SDO-ICANN-COLL] Interisle Consulting Group、LLC、「Name Collision in the DNS」、バージョン1.5、2013年8月、<https://www.icann.org/ en / system / files / files / name-collision- 02aug13-en.pdf>。
[SDO-ICANN-DAG] ICANN, "gTLD Applicant Guidebook", Version 2012-06-04, June 2012, <https://newgtlds.icann.org/en/applicants/agb/ guidebook-full-04jun12-en.pdf>.
[SDO-ICANN-DAG] ICANN、「gTLD Applicant Guidebook」、バージョン2012-06-04、2012年6月、<https://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en。 pdf>。
[SDO-ICANN-SAC090] ICANN Security and Stability Advisory Committee, "SSAC Advisory on the Stability of the Domain Namespace", ICANN SAC090, December 2016, <https://www.icann.org/en/ system/files/files/sac-090-en.pdf>.
[SDO-ICANN-SAC090] ICANNセキュリティおよび安定性諮問委員会、「ドメイン名前空間の安定性に関するSSAC勧告」、ICANN SAC090、2016年12月、<https://www.icann.org/en/system/files/files /sac-090-en.pdf>。
[SDO-ICANN-SSAC] ICANN, "Security and Stability Advisory Committee (SSAC)", December 2016, <https://www.icann.org/groups/ssac>.
[SDO-ICANN-SSAC] ICANN、「セキュリティおよび安定性諮問委員会（SSAC）」、2016年12月、<https://www.icann.org/groups/ssac>。
[TOR] Tor, "Tor - Anonymity Online", <https://www.torproject.org>.
[TOR] Tor、「Tor-Anonymity Online」、<https://www.torproject.org>。
Contributors
貢献者
Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron Falk, and Suzanne Woolf all made helpful and insightful observations or patiently answered questions. This should not be taken as an indication that any of these folks actually agree with what the document says, but their generosity with time and thought are appreciated in any case.
マークアンドリュース、スチュアートチェシャー、デビッドコンラッド、ポールエバースマン、アーロンフォーク、およびスザンヌウルフはすべて、有益で洞察に満ちた観察または辛抱強く答えた質問をしました。これは、これらの人々のいずれかが実際に文書の発言に同意していることを示すものではありませんが、時間と思考に対する寛大さはいずれにせよ高く評価されます。
Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr Spacek, and others provided significant review and/or useful comments.
Stephane Bortzmeyer、John Dickinson、Bob Harold、Paul Hoffman、Russ Housley、Joel Jaeggli、Andrew McConachie、George Michaelson、Petr Spacekなどが、重要なレビューや有益なコメントを提供しました。
This document also owes a great deal to Ed Lewis' excellent work on what a "domain name" is [DOMAIN-NAMES].
このドキュメントはまた、「ドメイン名」が何であるかについてのエド・ルイスの優れた研究[DOMAIN-NAMES]に多くを負っています。
We would also like to acknowledge the authors of [PROBLEM-SPECIAL-NAMES], including Alain Durand, Geoff Huston, Peter Koch, and Joe Abley, for their efforts to frame the issues and engage the working group, as well as their contributions to the list of issues from their document [PROBLEM-SPECIAL-NAMES].
また、問題の枠組みを作り、ワーキンググループに参加する取り組み、およびそれらへの貢献について、Alain Durand、Geoff Huston、Peter Koch、およびJoe Ableyを含む[問題名]の著者にも感謝します。彼らの文書からの問題のリスト[PROBLEM-SPECIAL-NAMES]。
Authors' Addresses
著者のアドレス
Ted Lemon Nominum, Inc. 800 Bridge Parkway Redwood City, CA 94065 United States of America
Ted Lemon Nominum、Inc. 800 Bridge Parkway Redwood City、CA 94065アメリカ合衆国
Phone: +1 650 381 6000
Email: ted.lemon@nominum.com
Ralph Droms
ラルフ・ドロムス
Email: rdroms.ietf@gmail.com
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America
Warren Kumari Google 1600 Amphitheatre Parkway Mountain View、CA 94043アメリカ合衆国
Email: warren@kumari.net