RFC 8375 - Special-Use Domain 'home.arpa.' 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8375
タイトル : RFC 8375 - 特殊用途ドメイン「home.arpa。」
翻訳編集 : 自動生成

[要約] RFC 8375は、特殊な使用目的のドメイン名「home.arpa.」に関するものであり、その目的は、ホームネットワークのデバイスの識別と管理を容易にすることです。

Internet Engineering Task Force (IETF)                        P. Pfister
Request for Comments: 8375                                 Cisco Systems
Updates: 7788                                                   T. Lemon
Category: Standards Track                            Nibbhaya Consulting
ISSN: 2070-1721                                                 May 2018

Special-Use Domain 'home.arpa.'

特殊用途ドメイン「home.arpa。」

Abstract

概要

This document specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names ending with '.home.arpa.' and designates this domain as a special-use domain name. 'home.arpa.' is designated for non-unique use in residential home networks. The Home Networking Control Protocol (HNCP) is updated to use the 'home.arpa.' domain instead of '.home'.

このドキュメントでは、「。home.arpa」で終わる名前のDNSクエリに関して、ドメインネームシステムに期待される動作を指定します。このドメインを特殊用途ドメイン名として指定します。「home.arpa」住宅用ホームネットワークでの非固有使用のために指定されています。ホームネットワーキングコントロールプロトコル（HNCP）は、「home.arpa」を使用するように更新されています。「.home」の代わりにドメイン。

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

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc8375.

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

著作権表示

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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  General Guidance  . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Domain Name Reservation Considerations  . . . . . . . . . . .   4
   5.  Updates to Home Networking Control Protocol . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.1.  Local Significance  . . . . . . . . . . . . . . . . . . .   7
     6.2.  Insecure Delegation . . . . . . . . . . . . . . . . . . .   8
     6.3.  Bypassing Manually Configured Resolvers . . . . . . . . .   9
   7.  Delegation of 'home.arpa.'  . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction

1. はじめに

Users and devices within a home network (hereafter referred to as "homenet") require devices and services to be identified by names that are unique within the boundaries of the homenet [RFC7368]. The naming mechanism needs to function without configuration from the user. While it may be possible for a name to be delegated by an ISP, homenets must also function in the absence of such a delegation. This document reserves the name 'home.arpa.' to serve as the default name for this purpose, with a scope limited to each individual homenet.

ホームネットワーク（以下、「ホームネット」と呼ぶ）内のユーザーとデバイスは、ホームネットの境界内で一意の名前でデバイスとサービスを識別する必要があります[RFC7368]。命名メカニズムは、ユーザーの構成なしで機能する必要があります。 ISPが名前を委任することは可能かもしれませんが、ホームネットはそのような委任がない場合にも機能する必要があります。このドキュメントでは、「home.arpa」という名前を予約しています。この目的のデフォルト名として機能し、スコープは個々のホームネットに限定されます。

This document corrects an error in [RFC7788] by replacing '.home' with 'home.arpa.' as the default domain name for homenets. '.home' was selected as the most user-friendly option; however, there are existing uses of '.home' that may be in conflict with this use. Evidence indicates that '.home' queries frequently leak out and reach the root name servers [ICANN1] [ICANN2].

このドキュメントは、「。home」を「home.arpa」で置き換えることにより、[RFC7788]のエラーを修正します。ホームネットのデフォルトのドメイン名として。「.home」が最もユーザーフレンドリーなオプションとして選択されました。ただし、この使用と競合する可能性がある「.home」の既存の使用があります。「.home」クエリが頻繁にリークし、ルートネームサーバー[ICANN1] [ICANN2]に到達するという証拠があります。

In addition, for compatibility with DNSSEC (see Section 6), it's necessary that an insecure delegation (see Section 4.3 of [RFC4035]) be present for the name. There is an existing process for allocating names under '.arpa.' [RFC3172]. No such process is available for requesting a similar delegation in the root at the request of the IETF, which does not administer that zone. As a result, all unregistered uses of '.home' (that is, all current uses at the time of this document's publication), particularly as specified in [RFC7788], are deprecated.

さらに、DNSSEC（セクション6を参照）との互換性のために、名前に安全でない委任（[RFC4035]のセクション4.3を参照）が存在する必要があります。「.arpa」の下に名前を割り当てるための既存のプロセスがあります。 [RFC3172]。そのゾーンを管理しないIETFの要求で、ルートに同様の委任を要求するためのそのようなプロセスはありません。その結果、特に[RFC7788]で指定されているように、「。home」の未登録の使用（つまり、このドキュメントの公開時点での現在のすべての使用）は非推奨になりました。

This document registers the domain 'home.arpa.' as a special-use domain name [RFC6761] and specifies the behavior that is expected from the Domain Name System with regard to DNS queries for names whose rightmost non-terminal labels are 'home.arpa.'. Queries for names ending with '.home.arpa.' are of local significance within the scope of a homenet, meaning that identical queries will result in different results from one homenet to another. In other words, a name ending in '.home.arpa.' is not globally unique.

このドキュメントはドメイン「home.arpa」を登録します。特殊用途のドメイン名[RFC6761]として、右端の非終端ラベルが 'home.arpa。'である名前のDNSクエリに関してドメインネームシステムから予期される動作を指定します。「.home.arpa」で終わる名前のクエリホームネットの範囲内でローカルに重要です。つまり、同じクエリを実行すると、ホームネットごとに結果が異なります。つまり、「。home.arpa」で終わる名前です。世界的にユニークではありません。

Although this document makes specific reference to [RFC7788], it is not intended that the use of 'home.arpa.' be restricted solely to networks where HNCP is deployed. Rather, 'home.arpa.' is intended to be the correct domain for uses like the one described for '.home' in [RFC7788]: local name service in residential homenets.

このドキュメントでは[RFC7788]を具体的に参照していますが、「home.arpa」の使用を意図したものではありません。 HNCPが展開されているネットワークのみに制限されます。むしろ、「home.arpa」。 [RFC7788]の「.home」で説明されているような用途向けの正しいドメインであることが意図されています：住宅用ホームネットのローカルネームサービス。

2. Requirements Language

2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。

3. General Guidance

3. 一般的なガイダンス

The domain name 'home.arpa.' is to be used for naming within residential homenets. Names ending with '.home.arpa.' reference a zone that is served locally, the contents of which are unique only to a particular homenet and are not globally unique. Such names refer to nodes and/or services that are located within a homenet (e.g., a printer or a toaster).

ドメイン名「home.arpa」住宅用ホームネット内での命名に使用されます。「.home.arpa」で終わる名前ローカルで提供されるゾーンを参照します。そのコンテンツは特定のホームネットにのみ固有であり、グローバルに固有ではありません。このような名前は、ホームネット内にあるノードやサービス（プリンターやトースターなど）を指します。

DNS queries for names ending with '.home.arpa.' are resolved using local resolvers on the homenet. Such queries MUST NOT be recursively forwarded to servers outside the logical boundaries of the homenet.

「.home.arpa」で終わる名前のDNSクエリホームネット上のローカルリゾルバを使用して解決されます。このようなクエリは、ホームネットの論理境界外のサーバーに再帰的に転送してはなりません（MUST NOT）。

Some service discovery user interfaces that are expected to be used on homenets conceal information such as domain names from end users. However, in some cases, it is still expected that users will need to see, remember, and even type names ending with '.home.arpa.'. The Homenet Working Group hopes that this name will in some way indicate to as many readers as possible that such domain names are referring to devices in the home, but we recognize that it is an imperfect solution.

ホームネットで使用されることが予想される一部のサービス検出ユーザーインターフェイスは、エンドユーザーからドメイン名などの情報を隠します。ただし、場合によっては、ユーザーが「.home.arpa。」で終わる名前を表示、記憶、さらには入力する必要があることが予想されます。 Homenetワーキンググループは、この名前がこのようなドメイン名が家庭内のデバイスを指していることをできるだけ多くの読者に何らかの形で示すことを期待していますが、これは不完全な解決策であることを認識しています。

4. Domain Name Reservation Considerations

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

This section specifies considerations for systems involved in domain name resolution when resolving queries for names ending with '.home.arpa.'. Each item in this section addresses some aspect of the DNS or the process of resolving domain names that would be affected by this special-use allocation. Detailed explanations of these items can be found in Section 5 of [RFC6761]. Although the term 'homenet' in [RFC7788] refers to home networks that implement a particular set of features, in this document the term is used to mean any home network, regardless of the set of features it implements.

このセクションでは、「。home.arpa。」で終わる名前のクエリを解決するときのドメイン名解決に関係するシステムの考慮事項を指定します。このセクションの各項目では、DNSのいくつかの側面、またはこの特殊用途の割り当てによって影響を受けるドメイン名を解決するプロセスについて説明します。これらの項目の詳細な説明は、[RFC6761]のセクション5にあります。 [RFC7788]の「ホームネット」という用語は、特定の機能セットを実装するホームネットワークを指しますが、このドキュメントでは、実装する機能セットに関係なく、この用語はホームネットワークを意味するために使用されます。

1. Users can use names ending with '.home.arpa.' just as they would use any other domain name. The 'home.arpa.' name is chosen to be readily recognized by users as signifying that the name is addressing a service on the homenet to which the user's device is connected.

1. ユーザーは「.home.arpa」で終わる名前を使用できます。他のドメイン名を使用するのと同じように。「home.arpa」名前は、その名前がユーザーのデバイスが接続されているホームネット上のサービスのアドレスであることを示すものとして、ユーザーがすぐに認識できるように選択されます。

2. Application software SHOULD NOT treat names ending in '.home.arpa.' differently than other names. In particular, there is no basis for trusting names that are subdomains of 'home.arpa.' (see Section 6).

2. アプリケーションソフトウェアは、「。home.arpa」で終わる名前を扱わないでください。他の名前とは異なります。特に、「home.arpa」のサブドメインである名前を信頼する根拠はありません。（セクション6を参照）。

3. Name resolution APIs and libraries MUST NOT recognize names that end in '.home.arpa.' as special and MUST NOT treat them as having special significance, except that it may be necessary that such APIs not bypass the locally configured recursive resolvers.

3. 名前解決APIとライブラリは、「。home.arpa」で終わる名前を認識してはなりません。特別なものとして扱い、これらのAPIがローカルに構成された再帰リゾルバをバイパスしないことが必要な場合を除いて、特別な意味を持つものとして扱わないでください。

One or more IP addresses for recursive DNS servers will usually be supplied to the client through router advertisements or DHCP. For an administrative domain that uses subdomains of 'home.arpa.', such as a homenet, the recursive resolvers provided by that domain will be able to answer queries for subdomains of 'home.arpa.'; other resolvers will not, or they will provide answers that are not correct within that administrative domain.

通常、再帰DNSサーバーの1つ以上のIPアドレスは、ルーター通知またはDHCPを介してクライアントに提供されます。ホームネットなど、「home.arpa。」のサブドメインを使用する管理ドメインの場合、そのドメインによって提供される再帰リゾルバは、「home.arpa。」のサブドメインに対するクエリに応答できます。他のリゾルバはそうしないか、その管理ドメイン内で正しくない答えを提供します。

A host that is configured to use a resolver other than one that has been provided by the local network may be unable to resolve, or may receive incorrect results for, subdomains of 'home.arpa.'. In order to avoid this, it is permissible that hosts use the resolvers that are locally provided for resolving 'home.arpa.', even when they are configured to use other resolvers.

ローカルネットワークから提供されたリゾルバー以外のリゾルバーを使用するように構成されたホストは、「home.arpa。」のサブドメインを解決できないか、正しくない結果を受け取る可能性があります。これを回避するために、ホストが他のリゾルバーを使用するように構成されている場合でも、ホストが「home.arpa。」を解決するためにローカルに提供されているリゾルバーを使用することは許容されます。

4. There are three considerations for recursive resolvers that follow this specification:

4. この仕様に従う再帰リゾルバには、3つの考慮事項があります。

A. Recursive resolvers at sites using 'home.arpa.' MUST transparently support DNSSEC queries: queries for DNSSEC records and queries with the DNSSEC OK (DO) bit set (see Section 3.2.1 of [RFC4035]). While validation is not required, it is strongly encouraged: a caching recursive resolver that does not validate answers that can be validated may cache invalid data. This, in turn, will prevent validating stub resolvers from successfully validating answers.

A.「home.arpa」を使用するサイトでの再帰リゾルバ。 DNSSECクエリを透過的にサポートする必要があります：DNSSECレコードのクエリとDNSSEC OK（DO）ビットが設定されたクエリ（[RFC4035]のセクション3.2.1を参照）。検証は必須ではありませんが、強くお勧めします。検証可能な回答を検証しないキャッシュ再帰リゾルバは、無効なデータをキャッシュする可能性があります。これにより、検証スタブリゾルバーが回答を正常に検証できなくなります。

B. Unless configured otherwise, recursive resolvers and DNS proxies MUST behave as described in Section 3 of the Locally Served Zones document [RFC6303]. That is, queries for 'home.arpa.' and subdomains of 'home.arpa.' MUST NOT be forwarded, with one important exception: a query for a DS record with the DO bit set MUST return the correct answer for that question, including correct information in the authority section that proves that the record is nonexistent.

B.特に設定されていない限り、再帰リゾルバとDNSプロキシは、ローカルサービスゾーンドキュメント[RFC6303]のセクション3で説明されているように動作する必要があります。つまり、「home.arpa」に対するクエリです。「home.arpa」のサブドメイン重要な例外が1つありますが、転送してはなりません。DOビットが設定されたDSレコードのクエリは、その質問に対する正しい回答を返す必要があります。これには、レコードが存在しないことを証明する機関セクションの正しい情報が含まれます。

So, for example, a query for the NS record for 'home.arpa.' MUST NOT result in that query being forwarded to an upstream cache nor to the authoritative DNS server for '.arpa.'. However, as necessary to provide accurate authority information, a query for the DS record MUST result in forwarding whatever queries are necessary; typically, this will just be a query for the DS record, since the necessary authority information will be included in the authority section of the response if the DO bit is set.

したがって、たとえば、「home.arpa」のNSレコードのクエリ。そのクエリが上流のキャッシュや '.arpa。'の信頼できるDNSサーバーに転送されてはいけません。ただし、正確な権限情報を提供するために必要な場合、DSレコードのクエリは、必要なクエリを転送する必要があります。 DOビットが設定されている場合、必要な権限情報は応答の権限セクションに含まれるため、通常、これはDSレコードのクエリになります。

C. In addition to the behavior specified above, recursive resolvers that can be used in a homenet MUST be configurable to forward queries for 'home.arpa.' and subdomains of 'home.arpa.' to an authoritative server for 'home.arpa.'. This server will provide authoritative data for 'home.arpa.' within a particular homenet. The special handling for DS records for the 'home.arpa.' delegation is still required.

C.上記で指定された動作に加えて、ホームネットで使用できる再帰リゾルバは、「home.arpa」のクエリを転送するように構成可能でなければなりません。「home.arpa」のサブドメイン「home.arpa。」の権限のあるサーバーに。このサーバーは、「home.arpa」の信頼できるデータを提供します。特定のホームネット内。「home.arpa」のDSレコードの特別な処理。委任はまだ必要です。

It is permissible to combine the recursive resolver function for general DNS lookups with an authoritative resolver for 'home.arpa.'; in this case, rather than forwarding queries for subdomains of 'home.arpa.' to an authoritative server, the resolver answers them authoritatively. The behavior with respect to forwarding queries specifically for 'home.arpa.' remains the same.

一般的なDNSルックアップ用の再帰リゾルバ機能と「home.arpa。」用の信頼できるリゾルバを組み合わせることは許可されています。この場合、「home.arpa」のサブドメインのクエリを転送するのではなく、権限のあるサーバーに対して、リゾルバは権限のあるサーバーに応答します。「home.arpa」専用のクエリの転送に関する動作。同じまま。

5. No special processing of 'home.arpa.' is required for authoritative DNS server implementations. It is possible that an authoritative DNS server might attempt to check the authoritative servers for 'home.arpa.' for a delegation beneath that name before answering authoritatively for such a delegated name. In such a case, because the name always has only local significance, there will be no such delegation in the 'home.arpa.' zone, and so the server would refuse to answer authoritatively for such a zone. A server that implements this sort of check MUST be configurable so that either it does not do this check for the 'home.arpa.' domain or it ignores the results of the check.

5. 「home.arpa」の特別な処理はありません。権威あるDNSサーバーの実装には必須です。権威DNSサーバーが「home.arpa」について権威サーバーをチェックしようとする可能性があります。そのような委任された名前について正式に回答する前に、その名前の下にある委任について。そのような場合、名前は常にローカルな意味を持つだけなので、「home.arpa」にはそのような委任はありません。したがって、サーバーはそのようなゾーンに対して信頼できる応答を拒否します。この種類のチェックを実装するサーバーは、「home.arpa」に対してこのチェックを行わないように構成可能でなければなりません。ドメインまたはそれはチェックの結果を無視します。

6. DNS server operators MAY configure an authoritative server for 'home.arpa.' for use in homenets and other home networks. The operator for the DNS servers authoritative for 'home.arpa.' in the global DNS will configure any such servers as described in Section 7.

6. DNSサーバーオペレーターは、 'home.arpa'の権限のあるサーバーを構成する場合があります。ホームネットおよびその他のホームネットワークで使用するため。「home.arpa」に対して権限のあるDNSサーバーのオペレーター。グローバルDNSでは、セクション7で説明されているように、このようなサーバーを構成します。

7. 'home.arpa.' is a subdomain of the 'arpa' top-level domain, which is operated by IANA under the authority of the Internet Architecture Board according to the rules established in [RFC3172]. There are no other registrars for '.arpa'.

7. 「home.arpa」 [RFC3172]で確立された規則に従って、インターネットアーキテクチャボードの権限下でIANAによって運用される「arpa」トップレベルドメインのサブドメインです。「.arpa」には他にレジストラはありません。

5. Updates to Home Networking Control Protocol

5. ホームネットワーク制御プロトコルの更新

The final paragraph in Section 8 of [RFC7788], the Home Networking Control Protocol, is updated as follows:

[RFC7788]のセクション8の最後の段落であるホームネットワーク制御プロトコルは、次のように更新されます。

OLD: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. ".home" is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. In case multiple are announced, the domain of the node with the greatest node identifier takes precedence.

OLD：名前と非修飾ゾーンはHNCPネットワークで使用され、ローカルで重要なネーミングとサービス検出を提供します。ネットワーク全体のゾーンは、それらを修飾するために、すべての単一ラベルまたは非修飾ゾーンに追加されます。「.home」がデフォルトです。ただし、管理者は、ネットワークが別のTLVを使用するようにドメイン名TLV（セクション10.6）のアナウンスを構成できます（MAY）。複数がアナウンスされる場合、最大のノード識別子を持つノードのドメインが優先されます。

NEW: Names and unqualified zones are used in an HNCP network to provide naming and service discovery with local significance. A network-wide zone is appended to all single labels or unqualified zones in order to qualify them. 'home.arpa.' is the default; however, an administrator MAY configure the announcement of a Domain-Name TLV (Section 10.6) for the network to use a different one. In case multiple TLVs are announced, the domain of the node with the greatest node identifier takes precedence.

NEW：名前と非修飾ゾーンはHNCPネットワークで使用され、ローカルで重要なネーミングとサービス検出を提供します。ネットワーク全体のゾーンは、それらを修飾するために、すべての単一ラベルまたは非修飾ゾーンに追加されます。「home.arpa」デフォルトです。ただし、管理者は、ネットワークが別のTLVを使用するようにドメイン名TLV（セクション10.6）のアナウンスを構成できます（MAY）。複数のTLVがアナウンスされる場合、最大のノード識別子を持つノードのドメインが優先されます。

The 'home.arpa.' special-use name does not require a special resolution protocol. Names for which the rightmost two labels are 'home.arpa.' are resolved using the DNS protocol [RFC1035].

「home.arpa」特殊用途の名前には、特別な解決プロトコルは必要ありません。右端の2つのラベルが「home.arpa」である名前。 DNSプロトコル[RFC1035]を使用して解決されます。

6. Security Considerations

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

6.1. Local Significance

6.1. 地域の重要性

A DNS record that is returned as a response to a query for a Fully Qualified Domain Name (FQDN) that is a subdomain of 'home.arpa.' is expected to have local significance. It is expected to be returned by a server involved in name resolution for the homenet the device is connected in. However, such a response MUST NOT be considered more trustworthy than a similar response for any other DNS query.

「home.arpa」のサブドメインである完全修飾ドメイン名（FQDN）のクエリに対する応答として返されるDNSレコード。現地での意義が期待される。これは、デバイスが接続されているホームネットの名前解決に関与するサーバーによって返されることが期待されています。ただし、そのような応答は、他のDNSクエリに対する同様の応答よりも信頼できると見なしてはなりません。

Because 'home.arpa.' is not globally scoped and cannot be secured using DNSSEC based on the root domain's trust anchor, there is no way to tell, using a standard DNS query, in which homenet scope an answer belongs. Consequently, users may experience surprising results with such names when roaming to different homenets.

「home.arpa。」はグローバルにスコープされておらず、ルートドメインのトラストアンカーに基づくDNSSECを使用して保護することはできません。標準のDNSクエリを使用して、回答が属するホームネットスコープを判別する方法はありません。その結果、ユーザーは、異なるホームネットにローミングするときにそのような名前で驚くべき結果を経験する可能性があります。

To prevent this from happening, it could be useful for the resolver on the host to securely differentiate between different homenets and between identical names on different homenets. However, a mechanism for doing this has not yet been standardized and doing so is out of scope for this document. It is expected that this will be explored in future work.

これが起こらないようにするには、ホスト上のリゾルバが異なるホームネット間および異なるホームネット上の同一名を安全に区別することが役立つ場合があります。ただし、これを行うためのメカニズムはまだ標準化されていないため、このドキュメントの範囲外です。これは、今後の作業で検討される予定です。

The advice in [RFC6303], Section 7, to install local trust anchors for locally served zones can only work if there is some way of configuring the trust anchor in the host. Homenet currently specifies no mechanism for configuring such trust anchors. As a result, while this advice sounds good, it is not practicable.

[RFC6303]のセクション7にある、ローカルで提供されるゾーンにローカルトラストアンカーをインストールするというアドバイスは、ホストでトラストアンカーを構成する方法がいくつかある場合にのみ機能します。 Homenetは現在、このようなトラストアンカーを構成するメカニズムを指定していません。その結果、このアドバイスは良さそうに聞こえますが、実用的ではありません。

Also, although it might be useful to install a trust anchor for a particular instance of 'home.arpa.', it's reasonable to expect that a host with such a trust anchor might, from time to time, connect to more than one network with its own instance of 'home.arpa.'. Such a host would be unable to access services on any instance of 'home.arpa.' other than the one for which a trust anchor was configured.

また、「home.arpa。」の特定のインスタンスにトラストアンカーをインストールすると便利な場合がありますが、そのようなトラストアンカーを持つホストは、時々複数のネットワークに接続する可能性があると予想するのが妥当です。 'home.arpa。'の独自のインスタンス。このようなホストは、「home.arpa」のインスタンスのサービスにアクセスできません。トラストアンカーが設定されたもの以外。

It is, in principle, possible to attach an identifier to an instance of 'home.arpa.' that could be used to identify which trust anchor to rely on for validating names in that particular instance. However, the security implications of this are complicated, and such a mechanism, as well as a discussion of those implications, is out of scope for this document.

原則として、「home.arpa」のインスタンスに識別子を添付することは可能です。これは、その特定のインスタンスで名前を検証するためにどのトラストアンカーに依存するかを識別するために使用できます。ただし、これによるセキュリティへの影響は複雑であり、そのようなメカニズムとそれらの影響に関する説明は、このドキュメントの範囲外です。

6.2. Insecure Delegation

6.2. 安全でない委任

It is not possible to install a trust anchor (a DS RR) for this zone in the '.arpa' zone. The reason for this is that in order to do so, it would be necessary to have the key-signing key for the zone (see Section 5 of [RFC4034]). Since the zone is not globally unique, no one key would work.

このゾーンのトラストアンカー（DS RR）を「.arpa」ゾーンにインストールすることはできません。その理由は、そのためにはゾーンの鍵署名鍵が必要になるためです（[RFC4034]のセクション5を参照）。ゾーンはグローバルに一意ではないため、どのキーも機能しません。

An alternative would be to provide an authenticated denial of existence (see Section 3.2 of [RFC4033]). This would be done simply by not having a delegation from the 'arpa.' zone. However, this requires the validating resolver to treat 'home.arpa.' specially. If a validating resolver that doesn't treat 'home.arpa.' specially attempts to validate a name in 'home.arpa.', an authenticated denial of existence of 'home' as a subdomain of 'arpa.' would cause the validation to fail. Therefore, the only delegation that will allow names under 'home.arpa.' to be resolved by all validating resolvers is an insecure delegation, as in Section 7 of [RFC6303].

別の方法として、認証された存在拒否を提供することもできます（[RFC4033]のセクション3.2を参照）。これは、単に「arpa」からの委任がないことによって行われます。ゾーン。ただし、これには「home.arpa」を処理するための検証リゾルバが必要です。特に。「home.arpa」を扱わない検証リゾルバの場合。特に「home.arpa。」の名前の検証を試みます。これは、「arpa」のサブドメインとしての「home」の存在の認証された拒否です。検証が失敗します。したがって、「home.arpa」の下で名前を許可する唯一の委任。 [RFC6303]のセクション7にあるように、すべての検証リゾルバーによって解決されるのは安全でない委任です。

Consequently, unless a trust anchor for the particular instance of the 'home.arpa.' zone being validated is manually configured on the validating resolver, DNSSEC signing and validation of names within the 'home.arpa.' zone is not possible.

したがって、「home.arpa」の特定のインスタンスのトラストアンカーでない限り、検証されるゾーンは、「home.arpa」内の名前の検証リゾルバー、DNSSEC署名、および検証で手動で構成されます。ゾーンはできません。

6.3. Bypassing Manually Configured Resolvers

6.3. 手動で構成されたリゾルバーのバイパス

In item 3 of Section 4, an exception is made to the behavior of stub resolvers that allows them to query local resolvers for subdomains of 'home.arpa.' even when they have been manually configured to use other resolvers. This behavior obviously has security and privacy implications and may not be desirable depending on the context. It may be better to simply ignore this exception and, when one or more recursive resolvers are configured manually, simply fail to provide correct answers for subdomains of 'home.arpa.'. At this time, we do not have operational experience that would guide us in making this decision; implementors are encouraged to consider the context in which their software will be deployed when deciding how to resolve this question.

セクション4の項目3では、スタブリゾルバーの動作に例外があり、ローカルリゾルバーに「home.arpa」のサブドメインを照会することができます。他のリゾルバーを使用するように手動で構成されている場合でも同様です。この動作には明らかにセキュリティとプライバシーの影響があり、状況によっては望ましくない場合があります。この例外を無視して、1つ以上の再帰リゾルバーを手動で構成すると、「home.arpa。」のサブドメインに対する正しい回答が得られない場合があります。現時点では、この決定を下すのに役立つ運用経験はありません。実装者は、この質問を解決する方法を決定するときに、ソフトウェアが展開されるコンテキストを検討することをお勧めします。

7. Delegation of 'home.arpa.'

7. 「home.arpa」の委任

In order to be fully functional, there must be a delegation of 'home.arpa.' in the '.arpa.' zone [RFC3172]. This delegation MUST NOT include a DS record and MUST point to one or more black hole servers, for example, 'blackhole-1.iana.org.' and 'blackhole-2.iana.org.'. The reason that this delegation must not be signed is that not signing the delegation breaks the DNSSEC chain of trust, which prevents a validating stub resolver from rejecting names published under 'home.arpa.' on a homenet name server.

完全に機能するためには、「home.arpa」の委任が必要です。「.arpa。」ゾーン[RFC3172]。この委任にはDSレコードを含めてはならず（MUST NOT）、1つ以上のブラックホールサーバー（たとえば、「blackhole-1.iana.org」）をポイントする必要があります。および「blackhole-2.iana.org。」。この委任に署名してはならない理由は、委任に署名しないと、DNSSECの信頼チェーンが壊れ、検証用スタブリゾルバーが「home.arpa」で公開された名前を拒否できないためです。ホームネットネームサーバー上。

8. IANA Considerations

8. IANAに関する考慮事項

IANA has recorded the domain name 'home.arpa.' in the "Special-Use Domain Names" registry [SUDN]. IANA, with the approval of the IAB, has implemented the delegation requested in Section 7.

IANAは「home.arpa」というドメイン名を記録しています。「特殊用途ドメイン名」レジストリ[SUDN]。 IANAは、IABの承認を得て、セクション7で要求された委任を実装しました。

IANA has created a new subregistry within the "Locally-Served DNS Zones" registry [LSDZ], titled "Transport-Independent Locally-Served DNS Zone Registry", with the same format as the other subregistries. IANA has added an entry in this new registry for 'home.arpa.' with the description "Homenet Special-Use Domain", listing this document as the reference. The registration procedure for this subregistry should be the same as for the others, currently "IETF Review" (see Section 4.8 of [RFC8126]).

IANAは、「ローカルで提供されるDNSゾーン」レジストリ[LSDZ]内に、「トランスポートに依存しないローカルで提供されるDNSゾーンレジストリ」というタイトルの新しいサブレジストリを、他のサブレジストリと同じ形式で作成しました。 IANAは、この新しいレジストリに「home.arpa」のエントリを追加しました。「Homenet Special-Use Domain」という説明とともに、このドキュメントを参照としてリストします。このサブレジストリの登録手順は、現在の「IETFレビュー」である他のサブレジストリと同じである必要があります（[RFC8126]のセクション4.8を参照）。

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, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。

[RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <https://www.rfc-editor.org/info/rfc3172>.

[RFC3172] Huston、G。、編、「アドレスおよびルーティングパラメータエリアドメイン（ "arpa"）の管理ガイドラインおよび運用要件」、BCP 52、RFC 3172、DOI 10.17487 / RFC3172、2001年9月、<https：/ /www.rfc-editor.org/info/rfc3172>。

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/info/rfc4035>.

[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張機能のプロトコル変更」、RFC 4035、DOI 10.17487 / RFC4035、2005年3月、< https://www.rfc-editor.org/info/rfc4035>。

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

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

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。

9.2. Informative References

9.2. 参考引用

[ICANN1] "New gTLD Collision Risk Mitigation", August 2013, <https://www.icann.org/en/system/files/files/ new-gtld-collision-mitigation-05aug13-en.pdf>.

[ICANN1]「新しいgTLD衝突リスク軽減」、2013年8月、<https://www.icann.org/en/system/files/files/ new-gtld-collision-mitigation-05aug13-en.pdf>。

[ICANN2] "New gTLD Collision Occurence Management", October 2013, <https://www.icann.org/en/system/files/files/ resolutions-new-gtld-annex-1-07oct13-en.pdf>.

[ICANN]「新しいgTLD衝突発生管理」、2013年10月、<https://www.icann.org/en/system/files/files/ resolutions-new-gtld-annex-1-07oct13-en.pdf>。

[LSDZ] "Locally-Served DNS Zones", July 2011, <https://www.iana.org/assignments/ locally-served-dns-zones/>.

[LSDZ]「ローカルでサービスされるDNSゾーン」、2011年7月、<https://www.iana.org/assignments/locally-served-dns-zones/>。

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

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.

[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、DOI 10.17487 / RFC4033、2005年3月、<https： //www.rfc-editor.org/info/rfc4033>。

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.

[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNS Security Extensionsのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、< https://www.rfc-editor.org/info/rfc4034>。

[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. Weil, "IPv6 Home Networking Architecture Principles", RFC 7368, DOI 10.17487/RFC7368, October 2014, <https://www.rfc-editor.org/info/rfc7368>.

[RFC7368] Chown、T.、Ed。、Arkko、J.、Brandt、A.、Troan、O。、およびJ. Weil、「IPv6 Home Networking Architecture Principles」、RFC 7368、DOI 10.17487 / RFC7368、2014年10月、 <https://www.rfc-editor.org/info/rfc7368>。

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

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。

[SUDN] "Special-Use Domain Names", July 2012, <https://www.iana.org/assignments/ special-use-domain-names/>.

[SUDN]「特殊用途ドメイン名」、2012年7月、<https://www.iana.org/assignments/special-use-domain-names/>。

Acknowledgments

謝辞

The authors would like to thank Stuart Cheshire, as well as the homenet chairs, Mark Townsley and Ray Bellis, for their prior work on '.home'. We would also like to thank Paul Hoffman for providing review and comments on the IANA Considerations section, Andrew Sullivan for his review and proposed text, and Suzanne Woolf and Ray Bellis for their very detailed review comments and process insights. Thanks to Mark Andrews for providing an exhaustive reference list on the topic of insecure delegations. Thanks to Dale Worley for catching a rather egregious mistake and for the Gen-Art review, and thanks to Daniel Migault for a thorough SecDir review. Thanks to Warren Kumari for catching some additional issues and to Adam Roach for some helpful clarifications.

著者は、スチュアートチェシャーとホームネットの椅子であるマークタウンズリーとレイベリスの「.home」での以前の作業に感謝します。また、IANAの考慮事項セクションのレビューとコメントを提供してくれたPaul Hoffman、レビューと提案されたテキストについてのAndrew Sullivan、非常に詳細なレビューコメントとプロセスに関する洞察についてのSuzanne WoolfとRay Bellisにも感謝します。安全でない委任のトピックに関する包括的なリファレンスリストを提供してくれたMark Andrewsに感謝します。かなり重大な間違いを見つけてくれたGen-ArtのレビューをしてくれたDale Worleyに感謝し、SecDirを徹底的にレビューしてくれたDaniel Migaultに感謝します。いくつかの追加の問題を把握してくれたWarren Kumariと、役立つ説明をしてくれたAdam Roachに感謝します。

Authors' Addresses

著者のアドレス

Pierre Pfister Cisco Systems Paris France

   Email: pierre.pfister@darou.fr

Ted Lemon Nibbhaya Consulting P.O. Box 958 Brattleboro, Vermont 05301-0958 United States of America

テッドレモンニッバヤコンサルティングP.O. Box 958 Brattleboro、Vermont 05301-0958アメリカ合衆国

   Email: mellon@fugue.com