RFC 6761 - Special-Use Domain Names 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6761
タイトル : RFC 6761 - 特殊用途ドメイン名
翻訳編集 : 自動生成

[要約] RFC 6761は「Special-Use Domain Names」と題され、特定の目的や機能のために予約されるドメイン名に関する規定を定めています。この文書の目的は、特殊用途のドメイン名がどのように識別され、DNS（Domain Name System）内でどのように扱われるべきかを明確にすることです。これにより、インターネットの安定性とセキュリティが向上し、特定の技術的要件やプロトコルのために予約されたドメイン名の利用が容易になります。関連するRFCにはRFC 2606（以前に特殊用途ドメイン名を定義したもの）やRFC 6762（Multicast DNSに関するもの）などがあります。

Internet Engineering Task Force (IETF)                       S. Cheshire
Request for Comments: 6761                                   M. Krochmal
Updates: 1918, 2606                                           Apple Inc.
Category: Standards Track                                  February 2013
ISSN: 2070-1721

Special-Use Domain Names

特殊用途ドメイン名

Abstract

概要

This document describes what it means to say that a Domain Name (DNS name) is reserved for special use, when reserving such a name is appropriate, and the procedure for doing so. It establishes an IANA registry for such domain names, and seeds it with entries for some of the already established special domain names.

このドキュメントでは、ドメイン名（DNS名）を予約することが適切である場合に、ドメイン名（DNS名）が特別な用途のために予約されているとはどういう意味か、およびそのための手順について説明します。このようなドメイン名のIANAレジストリを確立し、すでに確立されている特別なドメイン名の一部のエントリをシードします。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これは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). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6761.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6761で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

1. Introduction

1. はじめに

Certain individual IP addresses and IP address ranges are treated specially by network implementations and, consequently, are not suitable for use as unicast addresses. For example, IPv4 addresses 224.0.0.0 to 239.255.255.255 are multicast addresses [RFC5735], with 224.0.0.1 being the "all hosts" multicast address [RFC1112] [RFC5771]. Another example is 127.0.0.1, the IPv4 "local host" address [RFC5735].

特定の個々のIPアドレスとIPアドレスの範囲は、ネットワークの実装によって特別に扱われるため、ユニキャストアドレスとしての使用には適していません。たとえば、IPv4アドレス224.0.0.0から239.255.255.255はマルチキャストアドレス[RFC5735]であり、224.0.0.1は「すべてのホスト」のマルチキャストアドレス[RFC1112] [RFC5771]です。別の例は、127.0.0.1、IPv4「ローカルホスト」アドレス[RFC5735]です。

Analogous to Special-Use IPv4 Addresses [RFC5735], the Domain Name System (DNS) [RFC1034][RFC1035] has its own concept of reserved names, such as "example.com.", "example.net.", and "example.org.", or any name falling under the top-level pseudo-domain "invalid." [RFC2606]. However, "Reserved Top Level DNS Names" [RFC2606] does not state whether implementations are expected to treat such names differently, and if so, in what way.

特殊用途のIPv4アドレス[RFC5735]と同様に、ドメインネームシステム（DNS）[RFC1034] [RFC1035]には、「example.com。」、「example.net。」、「 example.org。」、またはトップレベルの疑似ドメイン「無効」に該当する名前[RFC2606]。ただし、「予約済みトップレベルDNS名」[RFC2606]は、実装がそのような名前を別の方法で処理することが期待されるかどうか、およびそうである場合は、どのように記載されていない。

This document specifies under what circumstances special treatment is appropriate, and in what ways.

このドキュメントでは、特別な扱いが適切な状況とその方法を指定します。

2. Terminology

2. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、「要件レベルを示すためのRFCで使用するキーワード」[RFC2119]で説明されているように解釈されます。

3. Applicability

3. 適用性

When IP multicast was created [RFC1112], implementations had to be updated to understand what an IP multicast address means and what to do with it. Adding IP multicast to a networking stack entailed more than merely adding the right routing table entries for those addresses. Moreover, supporting IP multicast entails some level of commonality that is consistent across all conformant hosts, independent of what networks those hosts may be connected to. While it is possible to build a private isolated network using whatever valid unicast IP addresses and routing topology one chooses (regardless of whether those unicast IP addresses are already in use by other hosts on the public Internet), the IPv4 multicast address 224.0.0.1 is always the "all hosts" multicast address, and that's not a local decision.

IPマルチキャストが作成されたとき[RFC1112]、IPマルチキャストアドレスの意味とそれをどうするかを理解するために、実装を更新する必要がありました。ネットワークスタックにIPマルチキャストを追加するには、単にそれらのアドレスに適切なルーティングテーブルエントリを追加するだけではありません。さらに、IPマルチキャストのサポートには、それらのホストが接続されているネットワークに関係なく、すべての準拠ホスト全体で一貫したある程度の共通性が伴います。選択した有効なユニキャストIPアドレスとルーティングトポロジを使用してプライベート分離ネットワークを構築することは可能ですが（これらのユニキャストIPアドレスがパブリックインターネット上の他のホストによってすでに使用されているかどうかに関係なく）、IPv4マルチキャストアドレス224.0.0.1は常に「すべてのホスト」のマルチキャストアドレスであり、それはローカルな決定ではありません。

Similarly, if a domain name has special properties that affect the way hardware and software implementations handle the name, that apply universally regardless of what network the implementation may be connected to, then that domain name may be a candidate for having the IETF declare it to be a Special-Use Domain Name and specify what special treatment implementations should give to that name. On the other hand, if declaring a given name to be special would result in no change to any implementations, then that suggests that the name may not be special in any material way, and it may be more appropriate to use the existing DNS mechanisms [RFC1034] to provide the desired delegation, data, or lack-of-data, for the name in question. Where the desired behaviour can be achieved via the existing domain name registration processes, that process should be used. Reservation of a Special-Use Domain Name is not a mechanism for circumventing normal domain name registration processes.

同様に、ドメイン名に、ハードウェアとソフトウェアの実装が名前を処理する方法に影響する特別なプロパティがあり、実装が接続されているネットワークに関係なく一般的に適用される場合、そのドメイン名はIETFに宣言する候補となる可能性があります。特殊用途ドメイン名であり、実装にその名前に与える必要がある特別な扱いを指定します。一方、特定の名前を特別であると宣言しても、実装に変更がない場合、その名前は重要な方法で特別ではない可能性があり、既存のDNSメカニズムを使用する方が適切である可能性があります[ RFC1034]は、問題の名前に必要な委任、データ、またはデータの欠如を提供します。既存のドメイン名登録プロセスで目的の動作を実現できる場合は、そのプロセスを使用する必要があります。特殊用途ドメイン名の予約は、通常のドメイン名登録プロセスを回避するためのメカニズムではありません。

As an example, suppose there were to be an IETF document specifying that a particular name (or set of names) is guaranteed to produce an NXDOMAIN ("Name Error" [RFC1035]) result. Such a document falls within the responsibilities of the IETF. The IETF is responsible for protocol rules. The IETF defines name character set, length limits, syntax, the fact that in DNS "A" is equivalent to "a", etc. [RFC1034] [RFC1035]. Portions of the namespace created by those rules are given to ICANN to manage, but, due to established DNS protocol rules, ICANN is not free to allocate "COM" and "com" to two different name servers. The IETF has responsibility for specifying how the DNS protocol works, and ICANN is responsible for allocating the names made possible by that DNS protocol. Now, suppose a developer were to use this special "guaranteed nonexistent" name, "knowing" that it's guaranteed to return NXDOMAIN, and suppose also that the user's DNS server fails to return NXDOMAIN for this name. The developer's software then fails. Who do the user and/or developer complain to? ICANN? The IETF? The DNS server operator? If the developer can't depend on the special "guaranteed nonexistent" name to always return NXDOMAIN, then the special name is worthless, because it can't be relied on to do what it is supposed to. For this special "guaranteed nonexistent" name to have any use, it has to be defined to return NXDOMAIN, BY PROTOCOL, for all installations, not just by ICANN allocation on the public Internet. ICANN has no jurisdiction over how users choose to configure their own private DNS servers on their own private networks, but developers need a protocol specification that states that returning positive answers for the special "guaranteed nonexistent" name is a protocol violation on *all* networks, not just the public Internet. Hence, the act of defining such a special name creates a higher-level protocol rule, above ICANN's management of allocable names on the public Internet.

例として、特定の名前（または名前のセット）がNXDOMAIN（ "Name Error" [RFC1035]）の結果を確実に生成することを指定するIETFドキュメントがあったと仮定します。このような文書は、IETFの責任の範囲内です。 IETFはプロトコルルールを担当します。 IETFは、名前の文字セット、長さ制限、構文、DNSの「A」が「a」と同等であるという事実などを定義しています。[RFC1034] [RFC1035]。これらのルールによって作成された名前空間の一部は、管理するためにICANNに提供されますが、確立されたDNSプロトコルルールにより、ICANNは「COM」と「com」を2つの異なるネームサーバーに自由に割り当てることができません。 IETFはDNSプロトコルがどのように機能するかを指定する責任があり、ICANNはそのDNSプロトコルによって可能になった名前を割り当てる責任があります。ここで、開発者がNXDOMAINを返すことが保証されていることを「知っている」この特別な「保証された存在しない」名前を使用し、ユーザーのDNSサーバーがこの名前のNXDOMAINを返さなかったとします。その後、開発者のソフトウェアは失敗します。ユーザーや開発者は誰に不満を言うのですか？ ICANN？ IETF？ DNSサーバーのオペレーター？開発者が常に「存在しない」という特別な名前に依存して常にNXDOMAINを返すことができない場合、その特別な名前は、本来の目的に依存することができないため、役に立ちません。この特別な「存在しない」名前を使用するには、パブリックインターネット上のICANN割り当てだけでなく、すべてのインストールでNXDOMAIN、BY PROTOCOLを返すように定義する必要があります。 ICANNは、ユーザーが独自のプライベートネットワークで独自のプライベートDNSサーバーを構成する方法を管轄していませんが、開発者は、特別な「存在しない」という名前に対して肯定的な回答を返すことは、*すべての*ネットワークでのプロトコル違反であることを示すプロトコル仕様を必要とします、公共のインターネットだけではありません。したがって、そのような特別な名前を定義する行為は、公衆インターネット上で割り当て可能な名前のICANNによる管理よりも上位のプロトコルルールを作成します。

4. Procedure

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]を公開して、新しい機能を説明する必要があります。

The specification MUST state how implementations determine that the special handling is required for any given name. This is typically done by stating that any fully qualified domain name ending in a certain suffix (i.e., falling within a specified parent pseudo-domain) will receive the special behaviour. In effect, this carves off a sub-tree of the DNS namespace in which the modified name treatment rules apply, analogous to how IP multicast [RFC1112] or IP link-local addresses [RFC3927] [RFC4862] carve off chunks of the IP address space in which their respective modified address treatment rules apply.

仕様では、特定の名前に対して特別な処理が必要であると実装が判断する方法を記載する必要があります。これは通常、特定のサフィックスで終わる完全修飾ドメイン名（つまり、指定された親疑似ドメイン内にある）が特別な動作を受け取ることを示すことによって行われます。実際、これは、IPマルチキャスト[RFC1112]またはIPリンクローカルアドレス[RFC3927] [RFC4862]がIPアドレスのチャンクを切り分ける方法と同様に、変更された名前処理ルールが適用されるDNS名前空間のサブツリーを切り分けます。それぞれの修正されたアドレス処理規則が適用されるスペース。

The specification also MUST state, in each of the seven "Domain Name Reservation Considerations" categories below, what special treatment, if any, is to be applied. If in all seven categories the answer is "none", then possibly no special treatment is required and requesting reservation of a Special-Use Domain Name may not be appropriate.

仕様では、以下の7つの「ドメイン名予約に関する考慮事項」の各カテゴリで、適用される特別な扱い（ある場合）を明記する必要があります。 7つのカテゴリすべてで答えが「なし」の場合、おそらく特別な扱いは必要なく、特別用途のドメイン名の予約を要求することは適切ではない可能性があります。

5. Domain Name Reservation Considerations

5. ドメイン名予約に関する考慮事項

An IETF "Standards Action" or "IESG Approval" document specifying some new naming behaviour, which requires a Special-Use Domain Name be reserved to implement this desired new behaviour, needs to contain a subsection of the "IANA Considerations" section titled "Domain Name Reservation Considerations" giving answers in the seven categories listed below. In the case of algorithmically generated DNS names, the specifying document needs to clearly identify the set of names generated by the algorithm that would require the proposed special treatment.

IETFの「標準アクション」または「IESG承認」ドキュメントには、この新しい動作を実装するために特別用途のドメイン名を予約する必要がある、いくつかの新しい名前付け動作を指定し、「ドメイン」というタイトルの「IANAの考慮事項」セクションのサブセクションを含める必要があります。「名前予約に関する考慮事項」に、以下の7つのカテゴリで回答を示します。アルゴリズムによって生成されたDNS名の場合、指定するドキュメントは、提案された特別な処理を必要とするアルゴリズムによって生成された名前のセットを明確に識別する必要があります。

1. Users:

1. ユーザー：

Are human users expected to recognize these names as special and use them differently? In what way?

人間のユーザーは、これらの名前を特別なものとして認識し、別の方法で使用することを期待されていますか？どのように？

2. Application Software:

2. アプリケーションソフトウェア：

Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way? (For example, if a human user enters such a name, should the application software reject it with an error message?)

アプリケーションソフトウェアの作成者は、ソフトウェアにこれらの名前を特別なものとして認識させ、別の扱いをするように期待されていますか？どのように？（たとえば、人間のユーザーがそのような名前を入力した場合、アプリケーションソフトウェアはそれをエラーメッセージで拒否する必要がありますか？）

3. Name Resolution APIs and Libraries:

3. 名前解決APIおよびライブラリ：

Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently? If so, how?

名前解決APIおよびライブラリの作成者は、ソフトウェアにこれらの名前を特別なものとして認識させ、別の方法で処理することを期待されていますか？もしそうなら、どうですか？

4. Caching DNS Servers:

4. DNSサーバーのキャッシュ：

Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?

キャッシングドメインネームサーバーの開発者は、実装にこれらの名前を特別なものとして認識させ、別の扱いをさせることを期待されていますか？もしそうなら、どうですか？

5. Authoritative DNS Servers:

5. 権限のあるDNSサーバー：

Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently? If so, how?

権威あるドメインネームサーバーの開発者は、実装にこれらの名前を特別なものとして認識させ、別の方法で処理することを期待されていますか？もしそうなら、どうですか？

6. DNS Server Operators:

6. DNSサーバーオペレーター：

Does this reserved Special-Use Domain Name have any potential impact on DNS server operators? If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid? Do DNS server operators need to know about that and understand why? Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware?

この予約された特殊用途ドメイン名は、DNSサーバーオペレーターに影響を与える可能性がありますか？権限のあるDNSサーバーをこの予約名に対して権限のあるものとして構成しようとすると、準拠ネームサーバーソフトウェアはそれを無効として拒否しますか？ DNSサーバーオペレーターはそのことを知り、その理由を理解する必要がありますか？ネームサーバーソフトウェアがこの予約された名前の使用を妨げない場合でも、DNSサーバーオペレーターが知っておくべき他の方法で期待どおりに機能しない可能性がありますか？

7. DNS Registries/Registrars:

7. DNSレジストリ/レジストラ：

How should DNS Registries/Registrars treat requests to register this reserved domain name? Should such requests be denied? Should such requests be allowed, but only to a specially-designated entity? (For example, the name "www.example.org" is reserved for documentation examples and is not available for registration; however, the name is in fact registered; and there is even a web site at that name, which states circularly that the name is reserved for use in documentation and cannot be registered!)

DNSレジストリ/レジストラは、この予約済みドメイン名を登録する要求をどのように処理する必要がありますか？そのような要求は拒否されるべきですか？そのようなリクエストは許可されるべきですか、特別に指定されたエンティティのみに許可されますか？（たとえば、「www.example.org」という名前はドキュメントの例のために予約されており、登録には使用できません。ただし、名前は実際に登録されています。その名前のWebサイトもあり、名前はドキュメントで使用するために予約されており、登録できません！）

6. Initial Registry

6. 初期レジストリ

The initial IANA "Special-Use Domain Names" registry shall contain entries for the private-address [RFC1918] reverse-mapping domains and for the existing Reserved Top Level DNS Names [RFC2606].

最初のIANA「特殊用途ドメイン名」レジストリには、プライベートアドレス[RFC1918]の逆マッピングドメインと既存の予約済みトップレベルDNS名[RFC2606]のエントリが含まれます。

6.1. Domain Name Reservation Considerations for Private Addresses

6.1. プライベートアドレスのドメイン名予約に関する考慮事項

The private-address [RFC1918] reverse-mapping domains listed below, and any names falling within those domains, are Special-Use Domain Names:

下記のプライベートアドレス[RFC1918]の逆マッピングドメインと、それらのドメインに含まれる名前はすべて、特別な用途のドメイン名です。

10.in-addr.arpa. 21.172.in-addr.arpa. 26.172.in-addr.arpa. 16.172.in-addr.arpa. 22.172.in-addr.arpa. 27.172.in-addr.arpa. 17.172.in-addr.arpa. 30.172.in-addr.arpa. 28.172.in-addr.arpa. 18.172.in-addr.arpa. 23.172.in-addr.arpa. 29.172.in-addr.arpa. 19.172.in-addr.arpa. 24.172.in-addr.arpa. 31.172.in-addr.arpa. 20.172.in-addr.arpa. 25.172.in-addr.arpa. 168.192.in-addr.arpa.

These domains, and any names falling within these domains, are special in the following ways:

これらのドメイン、およびこれらのドメインに含まれる名前は、次の点で特別です。

1. Users are free to use these names as they would any other reverse-mapping names. However, since there is no central authority responsible for use of private addresses, users SHOULD be aware that these names are likely to yield different results on different networks.

1. ユーザーは、他のリバースマッピング名と同じようにこれらの名前を自由に使用できます。ただし、プライベートアドレスの使用を担当する中央機関がないため、ユーザーは、これらの名前が異なるネットワークで異なる結果をもたらす可能性が高いことに注意する必要があります。

2. Application software SHOULD NOT recognize these names as special, and SHOULD use these names as they would other reverse-mapping names.

2. アプリケーションソフトウェアは、これらの名前を特別なものとして認識すべきではなく（SHOULD）、他のリバースマッピング名と同じようにこれらの名前を使用する必要があります（SHOULD）。

3. Name resolution APIs and libraries SHOULD NOT recognize these names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for these names to their configured caching DNS server(s).

3. 名前解決APIとライブラリは、これらの名前を特別なものとして認識してはならず（SHOULD NOT）、異なる扱いをすべきではありません（SHOULD NOT）。名前解決APIは、これらの名前に対するクエリを、構成されたキャッシングDNSサーバーに送信する必要があります（SHOULD）。

4. Caching DNS servers SHOULD recognize these names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve these names. Instead, caching DNS servers SHOULD, by default, generate immediate (positive or negative) responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolution of such names, for use in private networks where private-address reverse-mapping names are known to be handled by an authoritative DNS server in said private network.

4. キャッシングDNSサーバーは、これらの名前を特別なものとして認識すべきであり（SHOULD NOT）、デフォルトでは、それらのNSレコードの検索を試みたり、そうでない場合はこれらの名前を解決するために信頼できるDNSサーバーにクエリを実行したりします代わりに、DNSサーバーをキャッシュすると、デフォルトで、そのようなすべてのクエリに対して即時（正または負）の応答を生成する必要があります（SHOULD）。これは、ルートネームサーバーや他のネームサーバーに不要な負荷がかかるのを避けるためです。キャッシングDNSサーバーは、プライベートアドレスの逆マッピング名がプライベートネットワーク内の信頼できるDNSサーバーによって処理されることがわかっているプライベートネットワークで使用するために、そのような名前のアップストリーム解決を有効にする構成オプション（デフォルトでは無効）を提供する必要があります（SHOULD）。

5. Authoritative DNS servers SHOULD recognize these names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for private-address reverse-mapping names.

5. 権限のあるDNSサーバーは、これらの名前を特別なものとして認識し（SHOULD）、デフォルトで、プライベートアドレスの逆マッピング名に対して肯定的な応答を行うように管理者が明示的に設定しない限り、そのようなすべてのクエリに対して即時否定応答を生成する必要があります。

6. DNS server operators SHOULD, if they are using private addresses, configure their authoritative DNS servers to act as authoritative for these names.

6. DNSサーバーオペレーターは、プライベートアドレスを使用している場合は、これらの名前に対して信頼できるものとして機能するように信頼できるDNSサーバーを構成する必要があります（SHOULD）。

7. DNS Registries/Registrars MUST NOT grant requests to register any of these names in the normal way to any person or entity. These names are reserved for use in private networks, and fall outside the set of names available for allocation by registries/ registrars. Attempting to allocate one of these names as if it were a normal DNS domain name will probably not work as desired, for reasons 4, 5 and 6 above.

7. DNSレジストリ/レジストラは、これらの名前を登録する要求を通常の方法で個人またはエンティティに許可してはなりません。これらの名前はプライベートネットワークで使用するために予約されており、レジストリ/レジストラによる割り当てに使用できる名前のセットの範囲外です。これらの名前の1つを通常のDNSドメイン名であるかのように割り当てようとしても、上記の4、5、6の理由により、おそらく期待どおりに機能しません。

6.2. Domain Name Reservation Considerations for "test."

6.2. 「test」のドメイン名予約に関する考慮事項。

The domain "test.", and any names falling within ".test.", are special in the following ways:

ドメイン「test。」、および「.test。」に含まれる名前は、次の点で特別です。

1. Users are free to use these test names as they would any other domain names. However, since there is no central authority responsible for use of test names, users SHOULD be aware that these names are likely to yield different results on different networks.

1. ユーザーは、他のドメイン名と同様に、これらのテスト名を自由に使用できます。ただし、テスト名の使用に責任を負う中央機関がないため、ユーザーは、これらの名前が異なるネットワークで異なる結果をもたらす可能性が高いことに注意する必要があります。

2. Application software SHOULD NOT recognize test names as special, and SHOULD use test names as they would other domain names.

2. アプリケーションソフトウェアはテスト名を特別なものとして認識すべきではなく（SHOULD）、他のドメイン名と同様にテスト名を使用すべきです（SHOULD）。

3. Name resolution APIs and libraries SHOULD NOT recognize test names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for test names to their configured caching DNS server(s).

3. 名前解決APIとライブラリは、テスト名を特別なものとして認識してはならず（SHOULD NOT）、異なる扱いをすべきではありません（SHOULD NOT）。名前解決APIは、テスト名のクエリを構成済みのキャッシングDNSサーバーに送信する必要があります（SHOULD）。

4. Caching DNS servers SHOULD recognize test names as special and SHOULD NOT, by default, attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve test names. Instead, caching DNS servers SHOULD, by default, generate immediate negative responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers. Caching DNS servers SHOULD offer a configuration option (disabled by default) to enable upstream resolving of test names, for use in networks where test names are known to be handled by an authoritative DNS server in said private network.

4. キャッシュDNSサーバーは、テスト名を特別なものとして認識すべきであり（SHOULD NOT）、デフォルトでは、それらのNSレコードを検索しようとしないか、テスト名を解決するために権限のあるDNSサーバーにクエリを実行します。代わりに、DNSサーバーをキャッシュすると、デフォルトで、そのようなすべてのクエリに対して即時否定応答が生成されます。これは、ルートネームサーバーや他のネームサーバーに不要な負荷がかかるのを避けるためです。キャッシュDNSサーバーは、テスト名が上流の解決を有効にするための構成オプション（デフォルトでは無効）を提供して、テスト名がそのプライベートネットワーク内の信頼できるDNSサーバーによって処理されることがわかっているネットワークで使用できるようにする必要があります。

5. Authoritative DNS servers SHOULD recognize test names as special and SHOULD, by default, generate immediate negative responses for all such queries, unless explicitly configured by the administrator to give positive answers for test names.

5. 権限のあるDNSサーバーはテスト名を特別なものとして認識し（SHOULD）、デフォルトで、管理者がテスト名に肯定的な回答を与えるように明示的に構成されていない限り、すべてのクエリに対して即時否定応答を生成する必要があります。

6. DNS server operators SHOULD, if they are using test names, configure their authoritative DNS servers to act as authoritative for test names.

6. DNSサーバーオペレーターは、テスト名を使用している場合は、その信頼できるDNSサーバーをテスト名に対して信頼できるものとして機能するように構成する必要があります（SHOULD）。

7. DNS Registries/Registrars MUST NOT grant requests to register test names in the normal way to any person or entity. Test names are reserved for use in private networks and fall outside the set of names available for allocation by registries/registrars. Attempting to allocate a test name as if it were a normal DNS domain name will probably not work as desired, for reasons 4, 5, and 6 above.

7. DNSレジストリ/レジストラは、テスト名を登録するリクエストを通常の方法で個人またはエンティティに許可してはなりません。テスト名はプライベートネットワークで使用するために予約されており、レジストリ/レジストラによる割り当てに使用できる名前のセットの範囲外です。通常のDNSドメイン名であるかのようにテスト名を割り当てようとしても、上記の4、5、6の理由から、おそらく期待どおりに機能しません。

6.3. Domain Name Reservation Considerations for "localhost."

6.3. 「localhost」のドメイン名予約に関する考慮事項。

The domain "localhost." and any names falling within ".localhost." are special in the following ways:

ドメイン「localhost」。「.localhost」に含まれる名前次の点で特別です。

1. Users are free to use localhost names as they would any other domain names. Users may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address.

1. ユーザーは他のドメイン名と同じようにローカルホスト名を自由に使用できます。ユーザーは、ローカルホスト名のIPv4およびIPv6アドレスクエリが常にそれぞれのIPループバックアドレスに解決されると想定する場合があります。

2. Application software MAY recognize localhost names as special, or MAY pass them to name resolution APIs as they would for other domain names.

2. アプリケーションソフトウェアはlocalhost名を特別なものとして認識してもよいし、他のドメイン名の場合と同様に名前解決APIに渡してもよい（MAY）。

3. Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s).

3. 名前解決APIとライブラリは、ローカルホスト名を特別なものとして認識し（SHOULD）、アドレスクエリのIPループバックアドレスと他のすべてのクエリタイプの否定応答を常に返す必要があります（SHOULD）。名前解決APIは、ローカルホスト名のクエリを構成済みのキャッシュDNSサーバーに送信しないでください。

4. Caching DNS servers SHOULD recognize localhost names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve localhost names. Instead, caching DNS servers SHOULD, for all such address queries, generate an immediate positive response giving the IP loopback address, and for all other query types, generate an immediate negative response. This is to avoid unnecessary load on the root name servers and other name servers.

4. キャッシングDNSサーバーは、ローカルホスト名を特別なものとして認識すべきであり（SHOULD NOT）、それらのNSレコードを検索したり、ローカルホスト名を解決するために権限のあるDNSサーバーにクエリを実行したりしないでください。代わりに、DNSサーバーのキャッシュは、そのようなすべてのアドレスクエリに対して、IPループバックアドレスを与える即時肯定応答を生成し、他のすべてのクエリタイプに対して、即時否定応答を生成する必要があります（SHOULD）。これは、ルートネームサーバーや他のネームサーバーに不要な負荷がかかるのを避けるためです。

5. Authoritative DNS servers SHOULD recognize localhost names as special and handle them as described above for caching DNS servers.

5. 権限のあるDNSサーバーは、ローカルホスト名を特殊なものとして認識し、DNSサーバーをキャッシュするために上記のように処理する必要があります（SHOULD）。

6. DNS server operators SHOULD be aware that the effective RDATA for localhost names is defined by protocol specification and cannot be modified by local configuration.

6. DNSサーバーのオペレーターは、ローカルホスト名の有効なRDATAがプロトコル仕様によって定義されており、ローカル構成によって変更できないことに注意してください。

7. DNS Registries/Registrars MUST NOT grant requests to register localhost names in the normal way to any person or entity. Localhost names are defined by protocol specification and fall outside the set of names available for allocation by registries/ registrars. Attempting to allocate a localhost name as if it were a normal DNS domain name will probably not work as desired, for reasons 2, 3, 4, and 5 above.

7. DNSレジストリ/レジストラは、ローカルホスト名を登録するリクエストを通常の方法で個人またはエンティティに許可してはなりません。ローカルホスト名はプロトコル仕様で定義されており、レジストリ/レジストラによる割り当てに使用できる名前のセットの範囲外です。ローカルホスト名を通常のDNSドメイン名であるかのように割り当てようとしても、上記の2、3、4、および5の理由により、おそらく期待どおりに機能しません。

6.4. Domain Name Reservation Considerations for "invalid."

6.4. 「無効」のドメイン名予約に関する考慮事項。

The domain "invalid." and any names falling within ".invalid." are special in the ways listed below. In the text below, the term "invalid" is used in quotes to signify such names, as opposed to names that may be invalid for other reasons (e.g., being too long).

ドメインが無効です。「.invalid」に含まれる名前以下にリストした方法で特別です。以下のテキストでは、「無効」という用語は、他の理由（長すぎるなど）で無効になる可能性がある名前とは対照的に、そのような名前を示すために引用符で使用されています。

1. Users are free to use "invalid" names as they would any other domain names. Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses.

1. ユーザーは、他のドメイン名と同じように「無効な」名前を自由に使用できます。ユーザーは、「無効な」名前のクエリが常にNXDOMAIN応答を返すと想定する場合があります。

2. Application software MAY recognize "invalid" names as special or MAY pass them to name resolution APIs as they would for other domain names.

2. アプリケーションソフトウェアは、「無効な」名前を特別なものとして認識してもよいし、他のドメイン名の場合と同様に名前解決APIに渡してもよい（MAY）。

3. Name resolution APIs and libraries SHOULD recognize "invalid" names as special and SHOULD always return immediate negative responses. Name resolution APIs SHOULD NOT send queries for "invalid" names to their configured caching DNS server(s).

3. 名前解決APIとライブラリは、「無効な」名前を特別なものとして認識すべきであり（SHOULD）、常に即時否定応答を返す必要があります。名前解決APIは、「無効な」名前のクエリを構成済みのキャッシングDNSサーバーに送信してはなりません（SHOULD NOT）。

4. Caching DNS servers SHOULD recognize "invalid" names as special and SHOULD NOT attempt to look up NS records for them, or otherwise query authoritative DNS servers in an attempt to resolve "invalid" names. Instead, caching DNS servers SHOULD generate immediate NXDOMAIN responses for all such queries. This is to avoid unnecessary load on the root name servers and other name servers.

4. キャッシングDNSサーバーは、「無効な」名前を特別なものとして認識すべきであり（SHOULD NOT）、それらのNSレコードの検索を試みたり、そうでなければ「無効な」名前を解決するために権威あるDNSサーバーにクエリを実行してはなりません。代わりに、DNSサーバーをキャッシュすると、そのようなすべてのクエリに対して即時のNXDOMAIN応答を生成する必要があります（SHOULD）。これは、ルートネームサーバーや他のネームサーバーに不要な負荷がかかるのを避けるためです。

5. Authoritative DNS servers SHOULD recognize "invalid" names as special and handle them as described above for caching DNS servers.

5. 権限のあるDNSサーバーは、「無効な」名前を特殊なものとして認識し、DNSサーバーのキャッシュについて前述したようにそれらを処理する必要があります（SHOULD）。

6. DNS server operators SHOULD be aware that the effective RDATA for "invalid" names is defined by protocol specification to be nonexistent and cannot be modified by local configuration.

6. DNSサーバーオペレーターは、「無効な」名前の有効なRDATAが存在しないようにプロトコル仕様で定義されており、ローカル構成で変更できないことに注意してください。

7. DNS Registries/Registrars MUST NOT grant requests to register "invalid" names in the normal way to any person or entity. These "invalid" names are defined by protocol specification to be nonexistent, and they fall outside the set of names available for allocation by registries/registrars. Attempting to allocate a "invalid" name as if it were a normal DNS domain name will probably not work as desired, for reasons 2, 3, 4, and 5 above.

7. DNSレジストリ/レジストラは、「無効な」名前を通常の方法で登録する要求を個人またはエンティティに許可してはなりません。これらの「無効な」名前は、プロトコル仕様によって存在しないと定義されており、レジストリ/レジストラによる割り当てに使用できる名前のセットの外にあります。上記の2、3、4、および5の理由により、「無効な」名前を通常のDNSドメイン名であるかのように割り当てようとしても、おそらく期待どおりに機能しません。

6.5. Domain Name Reservation Considerations for Example Domains

6.5. サンプルドメインのドメイン名予約に関する考慮事項

The domains "example.", "example.com.", "example.net.", "example.org.", and any names falling within those domains, are special in the following ways:

ドメイン「example。」、「example.com。」、「example.net。」、「example.org。」、およびそれらのドメインに含まれるすべての名前は、次の点で特別です。

1. Users SHOULD understand that example names are reserved for use in documentation.

1. ユーザーは、サンプル名がドキュメントで使用するために予約されていることを理解する必要があります。

2. Application software SHOULD NOT recognize example names as special and SHOULD use example names as they would other domain names.

2. アプリケーションソフトウェアは、サンプル名を特別なものとして認識すべきではなく（SHOULD）、他のドメイン名と同様にサンプル名を使用する必要があります（SHOULD）。

3. Name resolution APIs and libraries SHOULD NOT recognize example names as special and SHOULD NOT treat them differently. Name resolution APIs SHOULD send queries for example names to their configured caching DNS server(s).

3. 名前解決APIとライブラリは、サンプル名を特殊なものとして認識してはならず（SHOULD NOT）、それらを異なる方法で処理する必要があります（SHOULD NOT）。名前解決APIは、構成されたキャッシングDNSサーバーに名前のクエリを送信する必要があります（SHOULD）。

4. Caching DNS servers SHOULD NOT recognize example names as special and SHOULD resolve them normally.

4. DNSサーバーのキャッシングは、サンプル名を特殊なものとして認識してはならず（SHOULD NOT）、通常どおりに解決する必要があります（SHOULD）。

5. Authoritative DNS servers SHOULD NOT recognize example names as special.

5. 権威DNSサーバーは、例の名前を特別なものとして認識すべきではありません。

6. DNS server operators SHOULD be aware that example names are reserved for use in documentation.

6. DNSサーバーのオペレーターは、サンプル名がドキュメントで使用するために予約されていることに注意してください。

7. DNS Registries/Registrars MUST NOT grant requests to register example names in the normal way to any person or entity. All example names are registered in perpetuity to IANA:

7. DNSレジストリ/レジストラは、サンプル名を通常の方法で個人またはエンティティに登録するリクエストを許可してはなりません。すべての例の名前は、IANAに永続的に登録されています。

        Domain Name: EXAMPLE.COM
        Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY
        Whois Server: whois.iana.org
        Referral URL: http://res-dom.iana.org
        Name Server: A.IANA-SERVERS.NET
        Name Server: B.IANA-SERVERS.NET
        Status: clientDeleteProhibited
        Status: clientTransferProhibited
        Status: clientUpdateProhibited
        Updated Date: 26-mar-2004
        Creation Date: 14-aug-1995
        Expiration Date: 13-aug-2011

IANA currently maintains a web server providing a web page explaining the purpose of example domains.

IANAは現在、サンプルドメインの目的を説明するWebページを提供するWebサーバーを維持しています。

7. Security Considerations

7. セキュリティに関する考慮事項

This document outlines the circumstances in which reserving a domain name for special use is appropriate, and the procedure for having that Special-Use Domain Name recorded by IANA. Any document requesting such a Special-Use Domain Name needs to contain an appropriate "Security Considerations" section which describes any security issues relevant to that special use.

このドキュメントでは、特別な用途のためにドメイン名を予約することが適切である状況と、IANAがその特別な用途のドメイン名を記録する手順について説明します。このような特殊用途のドメイン名を要求するドキュメントには、その特殊用途に関連するセキュリティの問題を説明する適切な「セキュリティの考慮事項」セクションを含める必要があります。

8. IANA Considerations

8. IANAに関する考慮事項

IANA has created a new registry of Special-Use Domain Names, initially populated with the private-address reverse-mapping domains and the Reserved Top Level DNS Names outlined above in Section 6.

IANAは特殊用途ドメイン名の新しいレジストリを作成し、最初にプライベートアドレスの逆マッピングドメインと上記のセクション6で概説した予約済みトップレベルDNS名を入力しました。

When IANA receives a request to record a new "Special-Use Domain Name", it should verify, in consultation with the IESG, that the IETF "Standards Action" or "IESG Approval" document [RFC5226] includes the required "Domain Name Reservation Considerations" section stating how the special meaning of this name affects the behavior of hardware, software, and humans in the seven categories. If IANA and the IESG determine that special handling of this "Special-Use Domain Name" is appropriate, IANA should record the Special-Use Domain Name, and a reference to the specification that documents it, in the registry.

IANAが新しい「特別用途ドメイン名」を記録する要求を受け取った場合、IETFと協議して、IETFの「標準アクション」または「IESG承認」ドキュメント[RFC5226]に必要な「ドメイン名予約」が含まれていることを確認する必要がありますこの名前の特別な意味が7つのカテゴリのハードウェア、ソフトウェア、および人間の動作にどのように影響するかを説明している考慮事項」セクション。 IANAおよびIESGがこの「特殊用途ドメイン名」の特別な処理が適切であると判断した場合、IANAは特殊用途ドメイン名とそれを文書化した仕様への参照をレジストリに記録する必要があります。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。

9.2. Informative References

9.2. 参考引用

[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.

[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。

[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.

[RFC2606]イーストレイクD.およびA.パニッツ、「予約済みトップレベルDNS名」、BCP 32、RFC 2606、1999年6月。

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.

[RFC3927] Cheshire、S.、Aboba、B。、およびE. Guttman、「Dynamic Configuration of IPv4 Link-Local Addresses」、RFC 3927、2005年5月。

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。

[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.

[RFC5735]綿、M。およびL.ベゴダ、「特別な用途のIPv4アドレス」、BCP 153、RFC 5735、2010年1月。

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010.

[RFC5771]綿、M。、ベゴダ、L。、およびD.マイヤー、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 5771、2010年3月。

Authors' Addresses

著者のアドレス

Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA

Stuart Cheshire Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA

   Phone: +1 408 974 3207
   EMail: cheshire@apple.com

Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA

Marc Krochmal Apple Inc. 1 Infinite Loop Cupertino、CA 95014 USA

   Phone: +1 408 974 4368
   EMail: marc@apple.com