RFC 7553 - The Uniform Resource Identifier (URI) DNS Resource Record 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7553
タイトル : RFC 7553 - Uniform Resource Identifier（URI）DNSリソースレコード
翻訳編集 : 自動生成

[要約] RFC 7553は、URI DNSリソースレコードに関する標準仕様であり、URIとDNSの相互運用性を向上させることを目的としています。

Internet Engineering Task Force (IETF)                      P. Faltstrom
Request for Comments: 7553                                        Netnod
Category: Informational                                       O. Kolkman
ISSN: 2070-1721                                                     ISOC
                                                               June 2015

The Uniform Resource Identifier (URI) DNS Resource Record

Uniform Resource Identifier（URI）DNSリソースレコード

Abstract

概要

This document describes the already registered DNS resource record (RR) type, called the Uniform Resource Identifier (URI) RR, that is used for publishing mappings from hostnames to URIs.

このドキュメントでは、ホスト名からURIへのマッピングの公開に使用される、Uniform Resource Identifier（URI）RRと呼ばれる、すでに登録されているDNSリソースレコード（RR）タイプについて説明します。

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

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

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

著作権表示

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に記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Applicability Statement . . . . . . . . . . . . . . . . . . .   3
   3.  DNS Considerations  . . . . . . . . . . . . . . . . . . . . .   4
   4.  The Format of the URI RR  . . . . . . . . . . . . . . . . . .   4
     4.1.  Owner Name, Class, and Type . . . . . . . . . . . . . . .   4
     4.2.  Priority  . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Weight  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Target  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.5.  URI RDATA Wire Format . . . . . . . . . . . . . . . . . .   6
   5.  Usages  . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Example: FTP Server in the example.com Domain . . . . . .   6
     5.2.  Relation to S-NAPTR . . . . . . . . . . . . . . . . . . .   7
     5.3.  Relation to U-NAPTR . . . . . . . . . . . . . . . . . . .   7
     5.4.  Relation to SRV . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  Registration of the URI Resource Record Type  . . . . . .   7
     6.2.  Registration of Services  . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  The Original RRTYPE Allocation Request . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction

1. はじめに

This document explains the use of the Domain Name System (DNS) for the storage of URIs [RFC3986] and how to resolve hostnames to such URIs that can be used by various applications using the URI resource record type. For resolution, the application needs to know both the hostname and the protocol that the URI is to be used for. The protocol is registered by IANA.

このドキュメントでは、URI [RFC3986]のストレージにドメインネームシステム（DNS）を使用する方法と、URIリソースレコードタイプを使用してさまざまなアプリケーションで使用できるURIにホスト名を解決する方法について説明します。解決のために、アプリケーションは、URIが使用されるホスト名とプロトコルの両方を知っている必要があります。プロトコルはIANAによって登録されています。

Historically, uses of the DNS to map a domain name to a URL have relied on the Naming Authority Pointer (NAPTR) RRTYPEs [RFC2915] and then on the Dynamic Delegation Discovery System (DDDS) [RFC3401] application framework with the DNS as a database as specified in RFC 3404 [RFC3404]. This has a number of implications such as the fact the RRSet returned will contain all URIs "connected" with the owner, and not only the ones related to a specific service.

歴史的に、DNSを使用してドメイン名をURLにマップすることは、ネーミングオーソリティポインター（NAPTR）RRTYPEs [RFC2915]に依存し、次にDNSをデータベースとして使用する動的委任発見システム（DDDS）[RFC3401]アプリケーションフレームワークに依存してきました。 RFC 3404 [RFC3404]で指定されているとおり。これには、返されるRRSetに、特定のサービスに関連するURIだけでなく、所有者と「接続」されたすべてのURIが含まれるなど、多くの影響があります。

The URI resource record specified in this document enables the querying party to do the equivalent of selecting which of the NAPTR records one is interested in and have only those returned. This is possible because data in the service field of the NAPTR record is included in the owner part of the URI resource record type. It is also the case that as the URI resource record type includes the target URI directly as part of the RDATA, it is very easy to extract the correct target URI, instead of applying rewrite rules as in NAPTR.

このドキュメントで指定されているURIリソースレコードを使用すると、クエリを実行する側は、関心のあるNAPTRレコードを選択し、それらのレコードのみを返すのと同じことを実行できます。これは、NAPTRレコードのサービスフィールドのデータがURIリソースレコードタイプの所有者部分に含まれているために可能です。また、URIリソースレコードタイプにはRDATAの一部として直接ターゲットURIが含まれているため、NAPTRのように書き換えルールを適用する代わりに、正しいターゲットURIを抽出するのが非常に簡単です。

Querying for URI resource records is not replacing querying for NAPTR resource records (or use of S-NAPTR [RFC3958]). Instead, the URI resource record type provides a complementary mechanism to be used when one already knows what service field is interesting. With it, one can directly query for the specific subset of the otherwise possibly large RRSet returned when querying for NAPTR resource records.

URIリソースレコードのクエリは、NAPTRリソースレコードのクエリ（またはS-NAPTR [RFC3958]の使用）に代わるものではありません。代わりに、URIリソースレコードタイプは、興味深いサービスフィールドがすでにわかっている場合に使用される補足的なメカニズムを提供します。これを使用すると、NAPTRリソースレコードのクエリ時に返された、通常は大きなRRSetの特定のサブセットを直接クエリできます。

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 BCP 14, RFC 2119 [RFC2119].

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

2. Applicability Statement

2. 適用性ステートメント

In general, it is expected that URI records will be used by clients for applications where the relevant protocol to be used is known, but, for example, an extra abstraction is needed in order to separate a domain name from a point of service (as addressed by the URI). One example of such a situation is when an organization has many domain names but only one official web page.

一般に、URIレコードは、使用される関連プロトコルがわかっているアプリケーションのクライアントによって使用されることが予想されますが、たとえば、ドメイン名をサービスポイントから分離するために追加の抽象化が必要です（ URIでアドレス指定されます）。このような状況の1つの例は、組織に多数のドメイン名があり、公式Webページが1つしかない場合です。

Applications need to know the specific service to prepend the hostname with. Using repetitive queries for URI records is not a replacement for querying for NAPTR records according to the NAPTR (DDDS) or S-NAPTR algorithms. NAPTR records serve the purpose of discovering the various services or the URIs (for looking up access points for a given service). These are two very different kinds of needs.

アプリケーションは、ホスト名を付加する特定のサービスを知る必要があります。 URIレコードに繰り返しクエリを使用することは、NAPTR（DDDS）またはS-NAPTRアルゴリズムに従ってNAPTRレコードをクエリする代わりにはなりません。 NAPTRレコードは、さまざまなサービスまたはURI（特定のサービスのアクセスポイントを検索するため）を検出する目的で使用されます。これらは2つの非常に異なる種類のニーズです。

3. DNS Considerations

3. DNSに関する考慮事項

Using prefix labels, such as underscored service tags, for a specific owner name may cause a counter-intuitive effect when the owner name is a wildcard name. For example, _s2._s1.*.example.net is not a wildcard name and cannot be used to return a synthesized answer for a query name of _s2._s1.a.example.net. See Section 4.5 of RFC 4592 [RFC4592] for more details. Besides, underscored service tags used for the URI RR (based on the "Service Name and Transport Protocol Port Number Registry") may have slightly different semantics than service tags used for underscored prefix labels that are used in combination with other (yet unspecified) RR types. This may cause subtle management problems when delegation structure that has developed within the context of URI RRs is also to be used for other RR types. Because the service labels might be overloaded, applications should carefully check that the application-level protocol is indeed the protocol they expect.

特定の所有者名に下線付きのサービスタグなどのプレフィックスラベルを使用すると、所有者名がワイルドカード名である場合に、直感に反する効果が生じる可能性があります。たとえば、_s2._s1。*。example.netはワイルドカード名ではないため、_s2._s1.a.example.netのクエリ名に対して合成された回答を返すために使用することはできません。詳細については、RFC 4592 [RFC4592]のセクション4.5をご覧ください。さらに、URI RRに使用されるアンダースコア付きサービスタグ（「サービス名とトランスポートプロトコルのポート番号レジストリ」に基づく）は、他の（まだ指定されていない）RRと組み合わせて使用されるアンダースコア付きプレフィックスラベルに使用されるサービスタグとは少し異なるセマンティクスを持つ場合があります。タイプ。これは、URI RRのコンテキスト内で開発された委任構造が他のRRタイプにも使用される場合、微妙な管理上の問題を引き起こす可能性があります。サービスラベルが過負荷になる可能性があるため、アプリケーションは、アプリケーションレベルのプロトコルが実際に期待するプロトコルであることを注意深く確認する必要があります。

Subtle management issues may also arise when the delegations from service to sub-service labels involve several parties and different stakeholders.

サービスからサブサービスラベルへの委任に複数の関係者やさまざまな利害関係者が関与する場合にも、微妙な管理上の問題が発生する可能性があります。

4. The Format of the URI RR

4. URI RRのフォーマット

This is the presentation format of the URI RR:

これは、URI RRの表示形式です。

Owner name TTL Class URI Priority Weight Target

所有者名TTLクラスURI優先度ウェイトターゲット

The URI RR does not cause any kind of Additional Section processing.

URI RRは、いかなる種類の追加セクション処理も引き起こしません。

4.1. Owner Name, Class, and Type

4.1. 所有者の名前、クラス、およびタイプ

The URI owner name is subject to special conventions.

URI所有者名は、特別な規則に従います。

Just like the SRV RR [RFC2782], the URI RR has service information encoded in its owner name. In order to encode the service for a specific owner name, one uses service parameters. Valid service parameters are those registered by IANA in the "Service Name and Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice Registrations [RFC6117]. The Enumservice Registration parameters are reversed (i.e., subtype(s) before type), prepended with an underscore (_), and prepended to the owner name in separate labels. The underscore is prepended to the service parameters to avoid collisions with DNS labels that occur in nature, and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS).

SRV RR [RFC2782]と同様に、URI RRの所有者名にはサービス情報がエンコードされています。特定の所有者名のサービスをエンコードするには、サービスパラメータを使用します。有効なサービスパラメータは、IANAによって「サービス名およびトランスポートプロトコルのポート番号レジストリ」[RFC6335]または「Enumservice Registrations [RFC6117]」として登録されたものです。EnumserviceRegistrationパラメータは逆になっています（つまり、タイプの前にサブタイプ）アンダースコア（_）を使用し、別のラベルで所有者名の前に付加します。実際に発生するDNSラベルとの衝突を回避するために、サービスパラメータの前にアンダースコアを付加し、委任を実行できるように順序を逆にします異なるゾーン（したがってDNSのプロバイダー）に必要です。

For example, suppose we are looking for the URI for a service with ENUM Service Parameter "A:B:C" for host example.com. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI").

たとえば、ホストexample.comのENUMサービスパラメータ「A：B：C」を持つサービスのURIを探しているとします。次に、（QNAME、QTYPE）=（ "_ C._B._A.example.com"、 "URI"）を照会します。

As another example, suppose we are looking for the URI for a service with Service Name "A" and Transport Protocol "B" for host example.com. Then we would query for (QNAME,QTYPE)=("_A._B.example.com","URI").

別の例として、ホストexample.comのサービス名「A」とトランスポートプロトコル「B」を持つサービスのURIを探しているとします。次に、（QNAME、QTYPE）=（ "_ A._B.example.com"、 "URI"）を照会します。

The type number for the URI record is 256.

URIレコードのタイプ番号は256です。

The URI resource record is class independent.

URIリソースレコードはクラスに依存しません。

The URI RR has no special Time-to-Live (TTL) requirements.

URI RRには、特別な存続可能時間（TTL）の要件はありません。

4.2. Priority

4.2. 優先

This field holds the priority of the target URI in this RR. Its range is 0-65535. A client MUST attempt to contact the URI with the lowest-numbered priority it can reach; URIs with the same priority SHOULD be selected according to probabilities defined by the weight field.

このフィールドは、このRR内のターゲットURIの優先度を保持します。範囲は0〜65535です。クライアントは、到達可能な最も低い番号の優先順位でURIへの接続を試みる必要があります。同じ優先度のURIは、重みフィールドで定義された確率に従って選択する必要があります（SHOULD）。

4.3. Weight

4.3. 重量

This field holds the server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535.

このフィールドは、サーバー選択メカニズムを保持します。重みフィールドは、同じ優先度を持つエントリの相対的な重みを指定します。重みが大きいほど、選択される確率が高くなります。この番号の範囲は0〜65535です。

4.4. Target

4.4. 目標

This field holds the URI of the target, enclosed in double-quote characters ('"'), where the URI is as specified in RFC 3986 [RFC3986]. Resolution of the URI is according to the definitions for the Scheme of the URI.

このフィールドは、二重引用符（ '"'）で囲まれたターゲットのURIを保持します。URIはRFC 3986 [RFC3986]で指定されているとおりです。URIの解決は、URIのスキームの定義に従います。

Since the URI will not be encoded as a <character-string> (see Section 3.3 of RFC 1035 [RFC1035]), there is no 255-character size limitation.

URIは<文字列>としてエンコードされないため（RFC 1035 [RFC1035]のセクション3.3を参照）、255文字のサイズ制限はありません。

The Target MUST NOT be an empty URI ("").

ターゲットは空のURI（ ""）であってはなりません。

4.5. URI RDATA Wire Format

4.5. うりＲだたうぃれふぉｒまｔ

The RDATA for a URI RR consists of a 2-octet Priority field, a 2-octet Weight field, and a variable-length Target field.

URI RRのRDATAは、2オクテットの優先度フィールド、2オクテットの重みフィールド、および可変長のターゲットフィールドで構成されます。

Priority and Weight are unsigned integers in network byte order.

優先度と重みは、ネットワークバイトオーダーの符号なし整数です。

The remaining data in the RDATA contains the Target field. The Target field contains the URI as a sequence of octets (without the enclosing double-quote characters used in the presentation format).

RDATAの残りのデータには、Targetフィールドが含まれています。 [ターゲット]フィールドには、URIがオクテットのシーケンスとして含まれます（プレゼンテーション形式で使用される二重引用符で囲まれていない）。

The length of the Target field MUST be greater than zero.

Targetフィールドの長さはゼロより大きくなければなりません。

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Priority             |          Weight               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /                                                               /
   /                             Target                            /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5. Usages

5. 用途

5.1. Example: FTP Server in the example.com Domain

5.1. 例：example.comドメインのFTPサーバー

An organization has the domain names example.com and example.net, and their FTP archive is at ftp://ftp1.example.com/public. Given the service name "ftp" and transport protocol "tcp" (from the IANA "Service Name and Transport Protocol Port Number Registry"), the following URI resource records could be made available in the respective zones (example.com and example.net):

組織のドメイン名はexample.comとexample.netであり、そのFTPアーカイブはftp://ftp1.example.com/publicにあります。サービス名「ftp」とトランスポートプロトコル「tcp」（IANA「サービス名とトランスポートプロトコルのポート番号レジストリ」から）を指定すると、次のURIリソースレコードをそれぞれのゾーン（example.comとexample.net）で利用できるようになります）：

   $ORIGIN example.com.
   _ftp._tcp    IN URI 10 1 "ftp://ftp1.example.com/public"

   $ORIGIN example.net.
   _ftp._tcp    IN URI 10 1 "ftp://ftp1.example.com/public"

5.2. Relation to S-NAPTR

5.2. S-NAPTRとの関係

The URI resource record type is not a replacement for the S-NAPTR. It is instead an extension and the second step of the S-NAPTR resolution can resolve a URI resource record instead of using SRV records and yet another algorithm for how to use SRV records for the specific protocol.

URIリソースレコードタイプはS-NAPTRの代わりにはなりません。これは拡張機能であり、S-NAPTR解決の2番目のステップは、SRVレコードを使用する代わりにURIリソースレコードを解決でき、特定のプロトコルでSRVレコードを使用するためのさらに別のアルゴリズムを使用できます。

$ORIGIN example.com. ;; order pref flags IN NAPTR 100 10 "D" "EM:ProtA" ( ; service "" ; regexp _http._tcp.example.com. ) ; replacement

$ ORIGIN example.com。 ;;注文設定フラグIN NAPTR 100 10 "D" "EM：ProtA"（; service ""; regexp _http._tcp.example.com。）;置換

   _http._tcp IN URI   10 1 "http://www.example.com/path"

5.3. Relation to U-NAPTR

5.3. U-NAPTRとの関係

The URI resource record type, together with S-NAPTR, can be viewed as a replacement for U-NAPTR [RFC4848]. The URI resource record type is only interesting when one know a base domain name, a protocol, and a service so that one can compose the record to look up. NAPTR records of any kind are used to look up what services exist for a certain domain, which is one step before the URI resource record is used.

URIリソースレコードタイプは、S-NAPTRとともに、U-NAPTR [RFC4848]の代替として表示できます。 URIリソースレコードタイプは、レコードを作成して検索できるように、ベースドメイン名、プロトコル、およびサービスを知っている場合にのみ興味深いものです。任意の種類のNAPTRレコードを使用して、特定のドメインに存在するサービスを検索します。これは、URIリソースレコードが使用される前の1ステップです。

5.4. Relation to SRV

5.4. SRVとの関係

The URI resource record type can be viewed as a replacement for the SRV record. This is because it, like the SRV record, can only be looked up if one knows the base domain, the protocol, and the service. It has a similar functionality and uses the same registry for service names, but instead of returning a hostname and port number, the URI record returns a full URI. As such, it can be viewed as a more powerful resource record than SRV.

URIリソースレコードタイプは、SRVレコードの代替として表示できます。これは、SRVレコードと同様に、ベースドメイン、プロトコル、およびサービスを知っている場合にのみ検索できるためです。同様の機能があり、サービス名に同じレジストリを使用しますが、ホスト名とポート番号を返す代わりに、URIレコードは完全なURIを返します。そのため、SRVよりも強力なリソースレコードと見なすことができます。

6. IANA Considerations

6. IANAに関する考慮事項

6.1. Registration of the URI Resource Record Type

6.1. URIリソースレコードタイプの登録

After an expert review in February 2011 (see Appendix A), IANA allocated RRTYPE 256 for the URI resource record type in the registry named "Resource Record (RR) TYPEs" (as defined in [BCP42], which was RFC 6195 at the time but has since been replaced by RFC 6895) located at <http://www.iana.org/assignments/dns-parameters>.

2011年2月の専門家によるレビュー（付録Aを参照）の後、IANAは、[Resource Record（RR）TYPEs]という名前のレジストリのURIリソースレコードタイプにRRTYPE 256を割り当てました（[BCP42]で定義されており、当時はRFC 6195でした） <http://www.iana.org/assignments/dns-parameters>にあるRFC 6895に置き換えられました。

IANA has updated the reference for this registration to refer to this RFC.

IANAは、このRFCを参照するようにこの登録のリファレンスを更新しました。

6.2. Registration of Services

6.2. サービスの登録

No new registry is needed for the registration of services as the Service Name, Transport Protocol Port Numbers, Enumservices and the DNS SRV Service Type registries are also used for the URI resource record type.

サービスの登録には、サービス名、トランスポートプロトコルのポート番号、Enumservices、DNS SRVサービスタイプのレジストリもURIリソースレコードタイプに使用されるため、新しいレジストリは必要ありません。

7. Security Considerations

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

Using the URI resource record together with security mechanisms that rely on verification of authentication of hostnames, like TLS, makes it important to choose the correct domain name when doing the comparison and ensure that the change in the hostname to be used is secured by DNSSEC so that it can be trusted in a similar way as a redirect in HTTP using TLS.

TLSなどのホスト名の認証の検証に依存するセキュリティメカニズムと一緒にURIリソースレコードを使用すると、比較を行うときに正しいドメイン名を選択し、使用するホスト名の変更がDNSSECによって保護されるようにすることが重要になります。 TLSを使用したHTTPのリダイレクトと同様の方法で信頼できること。

If, for example, the URI resource record is not signed with the help of DNSSEC and then validated successfully, trusting the non-signed URI will effectively lead to a downgrade attack.

たとえば、URIリソースレコードがDNSSECを使用して署名されておらず、正常に検証されていない場合、署名されていないURIを信頼すると、ダウングレード攻撃に効果的につながります。

The basic mechanism for successful use of URI works as follows:

URIを正常に使用するための基本的なメカニズムは、次のように機能します。

1. Announce that example.com is hosted at example.org (with some URL) in DNS.

1. example.comがDNSのexample.org（URLあり）でホストされていることを発表します。

2. Secure the URI resource record with DNSSEC. This is best done by doing validation in the application doing the lookup, but it could also be done in the local recursive resolver or in the trusted recursive resolver also doing validation. All are according to the local trust policy.

2. DNSSECを使用してURIリソースレコードを保護します。これは、ルックアップを実行するアプリケーションで検証を行うことで行うのが最適ですが、ローカルの再帰リゾルバーまたは検証を行う信頼された再帰リゾルバーで行うこともできます。すべてローカルの信頼ポリシーに従っています。

3. Verify the TLS (for example) certificate for the connection to example.org matches, i.e., use the hostname in the URI and not the hostname used originally when looking up the URI resource record.

3. example.orgへの接続のTLS（たとえば）証明書が一致することを確認します。つまり、URIリソースレコードを検索するときに最初に使用されたホスト名ではなく、URIでホスト名を使用します。

4. If needed, do application-layer authentication, etc., over the then encrypted connection.

4. 必要に応じて、暗号化された接続を介してアプリケーション層認証などを実行します。

It is also possible that the URI in the resource record type has errors in it. Applications using the URI resource record type for resolution should behave similarly as if the user typed (or copied and pasted) the URI. At least it must be clear to the user that the error is not due to any error from his side.

リソースレコードタイプのURIにエラーがある可能性もあります。解決にURIリソースレコードタイプを使用するアプリケーションは、ユーザーがURIを入力した（またはコピーして貼り付けた）場合と同様に動作する必要があります。少なくとも、ユーザー側のエラーが原因ではないことをユーザーに明確に示す必要があります。

One SHOULD NOT include userinfo (see "User Information", Section 3.2.1 of RFC 3986 [RFC3986]) in a URI that is used in a URI resource record as DNS data must be viewed as publicly available information.

DNSデータは公開情報として表示する必要があるため、URIリソースレコードで使用されるURIにuserinfo（「ユーザー情報」、RFC 3986 [RFC3986]のセクション3.2.1を参照）を含める必要があります（SHOULD NOT）。

8. References

8. 参考文献

8.1. Normative References

8.1. 引用文献

[BCP42] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, April 2013, <http://www.rfc-editor.org/info/bcp42>.

[BCP42] Eastlake 3rd、D。、「ドメインネームシステム（DNS）IANAに関する考慮事項」、BCP 42、RFC 6895、2013年4月、<http://www.rfc-editor.org/info/bcp42>。

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

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

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。

[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations", RFC 6117, DOI 10.17487/RFC6117, March 2011, <http://www.rfc-editor.org/info/rfc6117>.

[RFC6117] Hoeneisen、B.、Mayrhofer、A.、J。Livingood、「IANA Registration of Enumservices：Guide、Template、and IANA Considerations」、RFC 6117、DOI 10.17487 / RFC6117、2011年3月、<http：// www .rfc-editor.org / info / rfc6117>。

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <http://www.rfc-editor.org/info/rfc6335>.

[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<http://www.rfc-editor.org/info/rfc6335>。

8.2. Informative References

8.2. 参考引用

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.

[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<http：// www.rfc-editor.org/info/rfc2782>。

[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, DOI 10.17487/RFC2915, September 2000, <http://www.rfc-editor.org/info/rfc2915>.

[RFC2915] Mealling、M。およびR. Daniel、「The Naming Authority Pointer（NAPTR）DNS Resource Record」、RFC 2915、DOI 10.17487 / RFC2915、2000年9月、<http://www.rfc-editor.org/info / rfc2915>。

[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, DOI 10.17487/RFC3401, October 2002, <http://www.rfc-editor.org/info/rfc3401>.

[RFC3401] Mealling、M。、「Dynamic Delegation Discovery System（DDDS）Part One：The Comprehensive DDDS」、RFC 3401、DOI 10.17487 / RFC3401、2002年10月、<http://www.rfc-editor.org/info/ rfc3401>。

[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, DOI 10.17487/RFC3403, October 2002, <http://www.rfc-editor.org/info/rfc3403>.

[RFC3403] Mealling、M。、「Dynamic Delegation Discovery System（DDDS）Part Three：The Domain Name System（DNS）Database」、RFC 3403、DOI 10.17487 / RFC3403、2002年10月、<http：//www.rfc-editor .org / info / rfc3403>。

[RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, DOI 10.17487/RFC3404, October 2002, <http://www.rfc-editor.org/info/rfc3404>.

[RFC3404] Mealling、M。、「Dynamic Delegation Discovery System（DDDS）Part Four：The Uniform Resource Identifiers（URI）」、RFC 3404、DOI 10.17487 / RFC3404、2002年10月、<http：//www.rfc-editor。 org / info / rfc3404>。

[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 2003, <http://www.rfc-editor.org/info/rfc3597>.

[RFC3597] Gustafsson、A。、「Handling of Unknown DNS Resource Record（RR）Types」、RFC 3597、DOI 10.17487 / RFC3597、2003年9月、<http://www.rfc-editor.org/info/rfc3597>。

[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005, <http://www.rfc-editor.org/info/rfc3958>.

[RFC3958] Daigle、L。およびA. Newton、「SRV RRおよび動的委任検出サービス（DDDS）を使用したドメインベースのアプリケーションサービスロケーション」、RFC 3958、DOI 10.17487 / RFC3958、2005年1月、<http：// www .rfc-editor.org / info / rfc3958>。

[RFC4592] Lewis, E., "The Role of Wildcards in the Domain Name System", RFC 4592, DOI 10.17487/RFC4592, July 2006, <http://www.rfc-editor.org/info/rfc4592>.

[RFC4592]ルイス、E。、「ドメインネームシステムにおけるワイルドカードの役割」、RFC 4592、DOI 10.17487 / RFC4592、2006年7月、<http://www.rfc-editor.org/info/rfc4592>。

[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, DOI 10.17487/RFC4848, April 2007, <http://www.rfc-editor.org/info/rfc4848>.

[RFC4848] Daigle、L。、「URIと動的委任発見サービス（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 4848、DOI 10.17487 / RFC4848、2007年4月、<http：//www.rfc-editor。 org / info / rfc4848>。

[RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, Ed., "Design Choices When Expanding the DNS", RFC 5507, DOI 10.17487/RFC5507, April 2009, <http://www.rfc-editor.org/info/rfc5507>.

[RFC5507] IAB、Faltstrom、P。、編、Austein、R。、編、およびP.Koch、編、「DNSを拡張するときの設計の選択」、RFC 5507、DOI 10.17487 / RFC5507、2009年4月、< http://www.rfc-editor.org/info/rfc5507>。

Appendix A. The Original RRTYPE Allocation Request

付録A.元のRRTYPE割り当て要求

On February 22, 2011 IANA assigned RRTYPE 256 for the URI resource record based on a request that followed the procedure documented in [BCP42] (which was RFC 6195 at the time but has since been replaced by RFC 6895). The DNS RRTYPE PARAMETER ALLOCATION form as submitted to IANA at that time is replicated below for reference.

2011年2月22日、IANAは、[BCP42]に文書化されている手順（当時はRFC 6195でしたが、RFC 6895に置き換えられました）に準拠した要求に基づいて、URIリソースレコードにRRTYPE 256を割り当てました。そのときにIANAに提出されたDNS RRTYPE PARAMETER ALLOCATIONフォームは、参照用に以下に複製されています。

Note: Although "ownername" should be "owner name", "ownername" has been preserved below because it was part of the original request form submitted to IANA.

注：「所有者名」は「所有者名」である必要がありますが、「所有者名」はIANAに送信された元のリクエストフォームの一部であるため、以下に保持されています。

A. Submission Date:

A.提出日：

May 23, 2009

2009年5月23日

B. Submission Type:

B.提出タイプ：

[X] New RRTYPE [ ] Modification to existing RRTYPE

[X]新しいRRTYPE []既存のRRTYPEの変更

C. Contact Information for submitter:

C.提出者の連絡先情報：

Name: Patrik Faltstrom Email Address: paf@cisco.com International telephone number: +46-8-6859131 Other contact handles: (Note: This information will be publicly posted.)

名前：Patrik Faltstrom電子メールアドレス：paf@cisco.com国際電話番号：+ 46-8-6859131その他の連絡先ハンドル：（注：この情報は公開されます。）

D. Motivation for the new RRTYPE application?

D.新しいRRTYPEアプリケーションの動機は？

There is no easy way to get from a domain name to a URI. Some mechanisms exists via use of the NAPTR [RFC3403] resource record. That implies quite complicated rules that are simplified via the S-NAPTR [RFC3958] specification. But, the ability to directly look up a URI still exists. This specification uses a prefix based naming mechanism originated in the definition of the SRV [RFC2782] resource record, and the RDATA is a URI, encoded as one text field.

ドメイン名からURIに取得する簡単な方法はありません。 NAPTR [RFC3403]リソースレコードを使用することにより、いくつかのメカニズムが存在します。これは、S-NAPTR [RFC3958]仕様によって簡略化された非常に複雑なルールを意味します。しかし、URIを直接検索する機能はまだ存在しています。この仕様は、SRV [RFC2782]リソースレコードの定義に由来するプレフィックスベースの命名メカニズムを使用しており、RDATAは、1つのテキストフィールドとしてエンコードされたURIです。