RFC 7553: The Uniform Resource Identifier (URI) DNS Resource Record 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc7553
标题 : RFC 7553
翻译类型 : 自动生成

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

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

统一资源标识符（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.

本文档描述了已注册的DNS资源记录（RR）类型，称为统一资源标识符（URI）RR，用于发布从主机名到URI的映射。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。

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）的产品。它代表了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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。

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

本文档说明了使用域名系统（DNS）存储URI[RFC3986]，以及如何将主机名解析为可由使用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]，然后依赖于动态委派发现系统（DDDS）[RFC3401]应用程序框架，DNS作为数据库，如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记录相同的操作。这是可能的，因为NAPTR记录的服务字段中的数据包含在URI资源记录类型的所有者部分中。由于URI资源记录类型直接将目标URI作为RDATA的一部分包含在内，因此提取正确的目标URI非常容易，而不是像NAPTR那样应用重写规则。

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

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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所述），需要额外的抽象。这种情况的一个例子是，一个组织有许多域名，但只有一个官方网页。

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.

应用程序需要知道在主机名前面加上的特定服务。根据NAPTR（DDDS）或S-NAPTR算法，对URI记录使用重复查询不能替代对NAPTR记录的查询。NAPTR记录用于发现各种服务或URI（用于查找给定服务的访问点）。这是两种截然不同的需求。

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 RRs上下文中开发的委托结构也用于其他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

与SRV-RR[RFC2782]一样，URI-RR具有以其所有者名称编码的服务信息。为了为特定所有者名称编码服务，可以使用服务参数。有效的服务参数是IANA在“服务名称和传输协议端口号注册表”[RFC6335]或作为“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).

注册[RFC6117]。Enumservice注册参数是反向的（即，类型之前的子类型），以下划线（389;）作为前缀，并在单独的标签中作为所有者名称的前缀。在服务参数前面加下划线是为了避免与自然界中发生的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").

例如，假设我们正在为host example.com查找带有枚举服务参数“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").

作为另一个示例，假设我们正在寻找一个服务名为“a”的服务的URI，以及主机example.com的传输协议“B”。然后我们将查询（QNAME，QTYPE）=（“\u A.\u 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。

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不会被编码为<character string>（参见RFC 1035[RFC1035]的第3.3节），因此没有255个字符的大小限制。

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

目标不能是空URI（“”）。

4.5. URI RDATA Wire Format

4.5. URI RDATA有线格式

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中的其余数据包含目标字段。目标字段以八位字节序列的形式包含URI（不包含表示格式中使用的封闭双引号字符）。

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

目标字段的长度必须大于零。

                        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                            /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        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“服务名称和传输协议端口号注册表”），可以在相应区域（example.com和example.net）中提供以下URI资源记录：

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

   $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"

   $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解析的第二步可以解析URI资源记录，而不是使用SRV记录，以及另一个关于如何为特定协议使用SRV记录的算法。

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

$ORIGIN example.com；；NAPTR 100 10“D”EM:ProtA（；service“”；regexp_http._tcp.example.com.）中的订单优先标志；替换

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

   _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资源记录之前的一个步骤。

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为注册中心中名为“资源记录（RR）类型”的URI资源记录类型分配了RRTYPE 256（如[BCP42]中所定义），该注册中心位于<http://www.iana.org/assignments/dns-parameters>.

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.

将URI资源记录与依赖于主机名身份验证的安全机制（如TLS）一起使用，这使得在进行比较时选择正确的域名变得非常重要，并确保要使用的主机名的更改由DNSSEC进行保护，以便以类似于HTTP中使用TLS的重定向的方式对其进行信任。

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.

例如，如果未在DNSSEC的帮助下对URI资源记录进行签名并成功验证，则信任未签名的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.

在URI资源记录中使用的URI中不应包含userinfo（参见RFC 3986[RFC3986]第3.2.1节“用户信息”），因为DNS数据必须视为公开可用信息。

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 68952013年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，“统一资源标识符（URI）：通用语法”，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]Hoenesen，B.，Mayrhofer，A.，和J.Livingood，“Enumservices的IANA注册：指南，模板和IANA注意事项”，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]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（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 SRV）的DNS RR”，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，“命名机构指针（NAPTR）DNS资源记录”，RFC 2915，DOI 10.17487/RFC29152000年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]Melling，M，“动态委托发现系统（DDDS）第一部分：综合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，“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，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.“动态委托发现系统（DDDS）第四部分：统一资源标识符（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.，“未知DNS资源记录（RR）类型的处理”，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 RRs和动态委托发现服务（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]Lewis，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.，Ed.，Austein，R.，Ed.，和P.Koch，Ed.，“扩展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参数分配表复制如下，以供参考。

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

注：尽管“ownername”应为“ownername”，但下文保留了“ownername”，因为它是提交给IANA的原始申请表的一部分。

A. Submission Date:

A.提交日期：

May 23, 2009

2009年5月23日

B. Submission Type:

B.提交类型：

[X] New RRTYPE [ ] Modification to existing RRTYPE

[十] 新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是一个URI，编码为一个文本字段。