Network Working Group M. Mealling
Request for Comments: 3403 VeriSign
Obsoletes: 2915, 2168 October 2002
Category: Standards Track
Network Working Group M. Mealling
Request for Comments: 3403 VeriSign
Obsoletes: 2915, 2168 October 2002
Category: Standards Track
Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes a Dynamic Delegation Discovery System (DDDS) Database using the Domain Name System (DNS) as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR).
本文档描述了使用域名系统（DNS）作为分布式规则数据库的动态委派发现系统（DDDS）数据库。密钥是域名，规则使用命名机构指针（NAPTR）资源记录（RR）进行编码。
Since this document obsoletes RFC 2915, it is the official specification for the NAPTR DNS Resource Record. It is also part of a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others.
由于本文档淘汰了RFC 2915，因此它是NAPTR DNS资源记录的官方规范。它也是“动态委托发现系统（DDDS）第一部分：综合DDDS”（RFC 3401）中完全指定的系列的一部分。需要注意的是，如果不阅读其他文档，就不可能阅读和理解本系列中的任何文档。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DDDS Database Specification . . . . . . . . . . . . . . . . 3
4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Additional Information Processing . . . . . . . . . . . . . 7
4.2.1 Additional Section processing by DNS servers . . . . . . . . 7
4.2.2 Additional Section processing by resolver/applications . . . 7
4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 7
5. Application Specifications . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Advice for DNS Administrators . . . . . . . . . . . . . . . 10
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DDDS Database Specification . . . . . . . . . . . . . . . . 3
4. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Packet Format . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 Additional Information Processing . . . . . . . . . . . . . 7
4.2.1 Additional Section processing by DNS servers . . . . . . . . 7
4.2.2 Additional Section processing by resolver/applications . . . 7
4.3 Master File Format . . . . . . . . . . . . . . . . . . . . . 7
5. Application Specifications . . . . . . . . . . . . . . . . . 8
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1 URN Example . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 E164 Example . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Advice for DNS Administrators . . . . . . . . . . . . . . . 10
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . 11
References . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . 14
The Dynamic Delegation Discovery System (DDDS) is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached.
动态委托发现系统（DDDS）用于实现字符串到数据的延迟绑定，以支持动态配置的委托系统。DDDS通过迭代应用字符串转换规则将某些唯一字符串映射到DDDS数据库中存储的数据，直到达到终端条件为止。
This document describes the way in which the Domain Name System (DNS) is used as a data store for the Rules that allow a DDDS Application to function. It does not specify any particular application or usage scenario. The entire series of documents is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401) [1]. It is very important to note that it is impossible to read and understand any document in that series without reading the related documents.
本文档描述了域名系统（DNS）用作允许DDDS应用程序运行的规则的数据存储的方式。它没有指定任何特定的应用程序或使用场景。“动态委托发现系统（DDDS）第一部分：综合DDDS”（RFC 3401）[1]中规定了整个系列的文档。必须注意的是，如果不阅读相关文档，就不可能阅读和理解该系列中的任何文档。
The Naming Authority Pointer (NAPTR) DNS Resource Record (RR) specified here was originally produced by the URN Working Group as a way to encode rule-sets in DNS so that the delegated sections of a Uniform Resource Identifiers (URI) could be decomposed in such a way that they could be changed and re-delegated over time. The result was a Resource Record that included a regular expression that would be used by a client program to rewrite a string into a domain name.
此处指定的命名机构指针（NAPTR）DNS资源记录（RR）最初由URN工作组生成，作为在DNS中对规则集进行编码的一种方式，以便可以分解统一资源标识符（URI）的委派部分，从而随着时间的推移对其进行更改和重新委派。结果是一个资源记录，其中包含一个正则表达式，客户端程序将使用该正则表达式将字符串重写为域名。
Regular expressions were chosen for their compactness to expressivity ratio allowing for a great deal of information to be encoded in a rather small DNS packet.
选择正则表达式是因为它们的紧凑性与表现力之比允许在一个相当小的DNS数据包中对大量信息进行编码。
Over time this process was generalized for other Applications and Rule Databases. This document defines a Rules Database absent any particular Application as there may be several Applications all taking advantage of this particular Rules Database.
随着时间的推移，这个过程被推广到其他应用程序和规则数据库。本文档定义了一个没有任何特定应用程序的规则数据库，因为可能有多个应用程序都利用了这个特定的规则数据库。
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 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[6]中所述进行解释。
All other terminology, especially capitalized terms, is taken from [3].
所有其他术语，尤其是大写术语，摘自[3]。
General Description: This database uses the Domain Name System (DNS) as specified in [8] and [7].
一般说明：此数据库使用[8]和[7]中指定的域名系统（DNS）。
The character set used to specify the various values of the NAPTR records is UTF-8 [17]. Care must be taken to ensure that, in the case where either the input or the output to the substitution expression contains code points outside of the ASCII/Unicode equivalence in UTF-8, any UTF-8 is interpreted as a series of code-points instead of as a series of bytes. This is to ensure that the internationalized features of the POSIX Extended Regular Expressions are able to match their intended code-points. Substitution expressions MUST NOT be written where they depend on a specific POSIX locale since this would cause substitution expressions to loose their ability to be universally applicable.
用于指定NAPTR记录的各种值的字符集是UTF-8[17]。必须注意，如果替换表达式的输入或输出包含UTF-8中ASCII/Unicode等效之外的代码点，则任何UTF-8都被解释为一系列代码点，而不是一系列字节。这是为了确保POSIX扩展正则表达式的国际化特性能够匹配其预期的代码点。不能在依赖于特定POSIX语言环境的地方编写替换表达式，因为这会导致替换表达式失去普遍适用的能力。
All DNS resource records have a Time To Live (TTL) associated with them. When the number of seconds has passed since the record was retrieved the record is no longer valid and a new query must be used to retrieve the new records. Thus, as mentioned in the DDDS Algorithm, there can be the case where a given Rule expires. In the case where an application attempts to fall back to previously retrieved sets of Rules (either in the case of a bad delegation path or some network or server failure) the application MUST ensure that none of the records it is relying on have expired. In the case where even a single record has expired, the application is required to start over at the beginning of the algorithm.
所有DNS资源记录都有与其关联的生存时间（TTL）。当检索到记录后已过秒数时，该记录不再有效，必须使用新查询检索新记录。因此，如DDDS算法中所述，可能存在给定规则过期的情况。如果应用程序试图退回到以前检索到的规则集（在委派路径错误或某些网络或服务器故障的情况下），应用程序必须确保其所依赖的记录均未过期。即使一条记录过期，应用程序也需要在算法开始时重新启动。
Key Format: A Key is a validly constructed DNS domain-name.
密钥格式：密钥是有效构造的DNS域名。
Lookup Request: In order to request a set of rules for a given Key, the client issues a request, following standard DNS rules, for NAPTR Resource Records for the given domain-name.
查找请求：为了为给定的密钥请求一组规则，客户端根据标准DNS规则为给定域名的NAPTR资源记录发出请求。
Lookup Response: The response to a request for a given Key (domain-name) will be a series of NAPTR records. The format of a NAPTR Resource Record can be found in Section 4.
查找响应：对给定密钥（域名）请求的响应将是一系列NAPTR记录。NAPTR资源记录的格式见第4节。
Rule Insertion Procedure: Rules are inserted by adding new records to the appropriate DNS zone. If a Rule produces a Key that exists in a particular zone then only the entity that has administrative control of that zone can specify the Rule associated with that Key.
规则插入过程：通过向适当的DNS区域添加新记录来插入规则。如果规则生成存在于特定区域中的密钥，则只有对该区域具有管理控制权的实体才能指定与该密钥关联的规则。
Collision Avoidance: In the case where two Applications may use this Database (which is actually the case with the ENUM and URI Resolution Applications, Section 6.2), there is a chance of collision between rules where two NAPTR records appear in the same domain but they apply to more than one Application. There are three ways to avoid collisions:
冲突避免：在两个应用程序可能使用此数据库的情况下（事实上，第6.2节中的ENUM和URI解析应用程序就是这种情况），当两个NAPTR记录出现在同一个域中，但它们应用于多个应用程序时，规则之间可能会发生冲突。有三种方法可以避免碰撞：
* create a new zone within the domain in common that contains only NAPTR records that are appropriate for the application. E.g., all URI Resolution records would exist under urires.example.com and all ENUM records would be under enum.example.com. In the case where this is not possible due to lack of control over the upstream delegation the second method is used.
* 在公共域内创建一个新区域，该区域仅包含适用于应用程序的NAPTR记录。例如，所有URI解析记录将存在于urires.example.com下，所有枚举记录将存在于ENUM.example.com下。如果由于缺乏对上游委托的控制而无法实现，则使用第二种方法。
* write the regular expression such that it contains enough of the Application Unique string to disambiguate it from any other. For example, the URI Resolution Application would be able to use the scheme name on the left hand side to anchor the regular expression match to that scheme. An ENUM specific record in that same zone would be able to anchor the left hand side of the match with the "+" character which is defined by ENUM to be at the beginning of every Application Unique String. This way a given Application Unique String can only match one or the other record, not both.
* 编写正则表达式，使其包含足够多的应用程序唯一字符串，以消除它与任何其他字符串之间的歧义。例如，URI解析应用程序将能够使用左侧的方案名称将正则表达式匹配锚定到该方案。同一区域中特定于枚举的记录将能够使用“+”字符锚定匹配的左侧，该字符由枚举定义为位于每个应用程序唯一字符串的开头。这样，给定的应用程序唯一字符串只能匹配一条或另一条记录，而不能同时匹配两条记录。
* if two Application use different Flags or Services values then a record from another Application will be ignored since it doesn't apply to the Services/Flags in question.
* 如果两个应用程序使用不同的标志或服务值，那么来自另一个应用程序的记录将被忽略，因为它不适用于所讨论的服务/标志。
The packet format of the NAPTR RR is given below. The DNS type code for NAPTR is 35.
NAPTR RR的数据包格式如下所示。NAPTR的DNS类型代码为35。
The packet format for the NAPTR record is as follows
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ORDER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The packet format for the NAPTR record is as follows
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ORDER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFERENCE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ FLAGS /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ SERVICES /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REGEXP /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ REPLACEMENT /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
<character-string> and <domain-name> as used here are defined in RFC 1035 [7].
此处使用的<character string>和<domain name>在RFC 1035[7]中定义。
ORDER A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed in order to accurately represent the ordered list of Rules. The ordering is from lowest to highest. If two records have the same order value then they are considered to be the same rule and should be selected based on the combination of the Preference values and Services offered.
ORDER一个16位无符号整数，指定NAPTR记录的处理顺序，以便准确表示规则的有序列表。顺序是从最低到最高。如果两个记录具有相同的订单值，则认为它们是相同的规则，应根据首选项值和提供的服务的组合进行选择。
PREFERENCE Although it is called "preference" in deference to DNS terminology, this field is equivalent to the Priority value in the DDDS Algorithm. It is a 16-bit unsigned integer that specifies the order in which NAPTR records with equal Order values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. A client MAY look at records with higher preference values if it has a good reason to do so such as not supporting some protocol or service very well.
首选项尽管根据DNS术语称为“首选项”，但该字段相当于DDDS算法中的优先级值。它是一个16位无符号整数，指定具有相等顺序值的NAPTR记录的处理顺序，低数字在高数字之前处理。这类似于MX记录中的首选项字段，用于使域管理员可以将客户端指向功能更强的主机或更轻量级的协议。如果客户机有很好的理由（例如不很好地支持某些协议或服务），那么它可能会查看具有更高首选值的记录。
The important difference between Order and Preference is that once a match is found the client MUST NOT consider records with a different Order but they MAY process records with the same Order but different Preferences. The only exception to this is noted in the second important Note in the DDDS algorithm specification concerning allowing clients to use more complex Service determination between steps 3 and 4 in the algorithm. Preference is used to give communicate a higher quality of service to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint.
顺序和偏好之间的重要区别是一旦找到匹配，客户就不必考虑不同顺序的记录，但它们可以处理相同顺序但不同偏好的记录。唯一的例外是DDDS算法规范中的第二个重要注释，该注释涉及允许客户端在算法的步骤3和步骤4之间使用更复杂的服务确定。首选项用于向规则提供更高的服务质量，这些规则从权限的角度来看是相同的，但从简单的负载平衡的角度来看是不同的。
It is important to note that DNS contains several load balancing mechanisms and if load balancing among otherwise equal services should be needed then methods such as SRV records or multiple A records should be utilized to accomplish load balancing.
需要注意的是，DNS包含多个负载平衡机制，如果需要在其他相等的服务之间进行负载平衡，则应使用SRV记录或多个A记录等方法来完成负载平衡。
FLAGS A <character-string> containing flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set A-Z and 0-9. The case of the alphabetic characters is not significant. The field can be empty.
标志<character string>包含控制记录中字段重写和解释方面的标志。标志是集合A-Z和0-9中的单个字符。字母字符的大小写并不重要。该字段可以为空。
It is up to the Application specifying how it is using this Database to define the Flags in this field. It must define which ones are terminal and which ones are not.
由应用程序指定如何使用此数据库来定义此字段中的标志。它必须定义哪些是终端，哪些不是终端。
SERVICES A <character-string> that specifies the Service Parameters applicable to this this delegation path. It is up to the Application Specification to specify the values found in this field.
服务指定适用于此委派路径的服务参数的<character string>。由应用程序规范指定此字段中的值。
REGEXP A <character-string> containing a substitution expression that is applied to the original string held by the client in order to construct the next domain name to lookup. See the DDDS Algorithm specification for the syntax of this field.
REGEXP一个<character string>包含替换表达式，该表达式应用于客户端持有的原始字符串，以便构造下一个要查找的域名。有关此字段的语法，请参阅DDDS算法规范。
As stated in the DDDS algorithm, The regular expressions MUST NOT be used in a cumulative fashion, that is, they should only be applied to the original string held by the client, never to the domain name produced by a previous NAPTR rewrite. The latter is tempting in some applications but experience has shown such use to be extremely fault sensitive, very error prone, and extremely difficult to debug.
正如DDDS算法中所述，正则表达式不得以累积方式使用，也就是说，它们应仅应用于客户端持有的原始字符串，而不应应用于先前NAPTR重写生成的域名。后者在某些应用程序中很诱人，但经验表明，这种用法对故障非常敏感，非常容易出错，并且极难调试。
REPLACEMENT A <domain-name> which is the next domain-name to query for depending on the potential values found in the flags field. This field is used when the regular expression is a simple replacement operation. Any value in this field MUST be a fully qualified domain-name. Name compression is not to be used for this field.
替换一个<domain name>，它是下一个要查询的域名，具体取决于在flags字段中找到的潜在值。当正则表达式是简单的替换操作时，使用此字段。此字段中的任何值都必须是完全限定的域名。此字段不使用名称压缩。
This field and the REGEXP field together make up the Substitution Expression in the DDDS Algorithm. It is simply a historical optimization specifically for DNS compression that this field exists. The fields are also mutually exclusive. If a record is returned that has values for both fields then it is considered to be in error and SHOULD be either ignored or an error returned.
此字段和REGEXP字段共同构成DDDS算法中的替换表达式。此字段的存在只是专门针对DNS压缩的历史优化。这些字段也是互斥的。如果返回的记录包含两个字段的值，则认为该记录有错误，应忽略该记录或返回错误。
Additional section processing requires upgraded DNS servers, thus it will take many years before applications can expect to see relevant records in the additional information section.
附加部分处理需要升级DNS服务器，因此应用程序需要很多年才能在附加信息部分看到相关记录。
DNS servers MAY add RRsets to the additional information section that are relevant to the answer and have the same authenticity as the data in the answer section. Generally this will be made up of A and SRV records but the exact records depends on the application.
DNS服务器可以将RRSET添加到与应答相关的附加信息部分，并与应答部分中的数据具有相同的真实性。通常，这将由A和SRV记录组成，但具体记录取决于应用程序。
Applications MAY inspect the Additional Information section for relevant records but Applications MUST NOT require that records of any type be in the Additional Information section of any DNS response in order for clients to function. All Applications must be capable of handling responses from nameservers that never fill in the Additional Information part of a response.
应用程序可以检查附加信息部分的相关记录，但应用程序不得要求任何类型的记录位于任何DNS响应的附加信息部分，以便客户端正常工作。所有应用程序都必须能够处理从不填写响应附加信息部分的名称服务器的响应。
The master file format follows the standard rules in RFC-1035. Order and preference, being 16-bit unsigned integers, shall be an integer between 0 and 65535. The Flags and Services and Regexp fields are all quoted <character-string>s. Since the Regexp field can contain numerous backslashes and thus should be treated with care. See Section 7 for how to correctly enter and escape the regular expression.
主文件格式遵循RFC-1035中的标准规则。顺序和首选项为16位无符号整数，应为介于0和65535之间的整数。标志、服务和Regexp字段都是带引号的<character string>s。由于Regexp字段可能包含许多反斜杠，因此应小心处理。有关如何正确输入和转义正则表达式，请参见第7节。
This DDDS Database is usable by any application that makes use of the DDDS algorithm. In addition to the items required to specify a DDDS Application, an application wishing to use this Database must also define the following values:
此DDDS数据库可供任何使用DDDS算法的应用程序使用。除了指定DDDS应用程序所需的项目外，希望使用此数据库的应用程序还必须定义以下值：
o What domain the Key that is produced by the First Well Known Rule belongs to. Any application must ensure that its rules do not collide with rules used by another application making use of this Database. For example, the 'foo' application might have all of its First Well Known Keys be found in the 'foo.net' zone.
o 由第一条已知规则生成的密钥属于哪个域。任何应用程序都必须确保其规则不会与使用此数据库的其他应用程序使用的规则冲突。例如，“foo”应用程序可能会在“foo.net”区域中找到它的所有已知密钥。
o What the allowed values for the Services and Protocols fields are.
o 服务和协议字段的允许值是多少。
o What the expected output is of the terminal rewrite rule in addition to how the Flags are actually encoded and utilized.
o 除了如何实际编码和使用标志外，终端重写规则的预期输出是什么。
The NAPTR record was originally created for use with the Uniform Resource Name (URN) Resolver Discovery Service (RDS) [15]. This example details how a particular URN would use the NAPTR record to find a resolver service that can answer questions about the URN. See [2] for the definitive specification for this Application.
NAPTR记录最初创建用于统一资源名称（URN）解析器发现服务（RDS）[15]。此示例详细说明了特定URN如何使用NAPTR记录查找可以回答有关URN问题的解析程序服务。有关此应用的最终规范，请参见[2]。
Consider a URN namespace based on MIME Content-Ids (this is very hypothetical so do not rely on this). The URN might look like this:
考虑基于MIME内容ID的URN命名空间（这是非常假设的，所以不要依赖于此）。骨灰盒可能如下所示：
urn:cid:199606121851.1@bar.example.com
urn:cid:199606121851.1@bar.example.com
This Application's First Well Known Rule is to extract the characters between the first and second colon. For this URN that would be 'cid'. The Application also specifies that, in order to build a Database-valid Key, the string 'urn.arpa' should be appended to the result of the First Well Known Rule. The result is 'cid.urn.arpa'. Next, the client queries the DNS for NAPTR records for the domain-name 'cid.urn.arpa'. The result is a single record:
这个应用程序的第一条众所周知的规则是提取第一个冒号和第二个冒号之间的字符。对于这个骨灰盒，应该是“cid”。应用程序还指定，为了构建数据库有效密钥，字符串“urn.arpa”应该附加到第一条已知规则的结果中。结果是“cid.urn.arpa”。接下来，客户端在DNS中查询域名“cid.urn.arpa”的NAPTR记录。结果是一条记录：
cid.urn.arpa. ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i" .
cid.urn.arpa；；订单预处理标志NAPTR 100 10“”中的服务regexp替换！^urn:cid:.+@（[^\.]+\）（.*）$！\2！i”。
Since there is only one record, ordering the responses is not a problem. The replacement field is empty, so the pattern provided in the regexp field is used. We apply that regexp to the entire URN to see if it matches, which it does. The \2 part of the substitution expression returns the string "example.com". Since the flags field is empty, the lookup is not terminal and our next probe to DNS is for more NAPTR records where the new domain is 'example.com'.
因为只有一条记录，所以排序响应不是问题。替换字段为空，因此使用regexp字段中提供的模式。我们将该regexp应用于整个URN，以查看它是否匹配，它确实匹配。替换表达式的\2部分返回字符串“example.com”。由于flags字段为空，因此查找不是终端，我们对DNS的下一个探测是查找更多NAPTR记录，其中新域为“example.com”。
Note that the rule does not extract the full domain name from the CID, instead it assumes the CID comes from a host and extracts its domain. While all hosts, such as 'bar', could have their very own NAPTR, maintaining those records for all the machines at a site could be an intolerable burden. Wildcards are not appropriate here since they only return results when there is no exactly matching names already in the system.
请注意，该规则不会从CID中提取完整域名，而是假定CID来自主机并提取其域。虽然所有主机（如“bar”）都可以有自己的NAPTR，但维护站点中所有机器的记录可能是一个无法忍受的负担。通配符在这里不合适，因为它们仅在系统中没有完全匹配的名称时返回结果。
The record returned from the query on "example.com" might look like:
从“example.com”上的查询返回的记录可能如下所示：
example.com. ;; order pref flags service regexp replacement IN NAPTR 100 50 "a" "z3950+N2L+N2C" "" cidserver.example.com. IN NAPTR 100 50 "a" "rcds+N2C" "" cidserver.example.com. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" www.example.com.
example.com；；order pref标志NAPTR 100 50“a”“z3950+N2L+N2C”“cidserver.example.com中的服务regexp替换。在NAPTR 100 50“a”rcds+N2C“cidserver.example.com中。在NAPTR 100 50中的“http+N2L+N2C+N2R”www.example.com。
Continuing with the example, note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The Application defines the flag 'a' to mean a terminal lookup and that the output of the rewrite will be a domain-name for which an A record should be queried. Once the client has done that, it has the following information: the host, its IP address, the protocol, and the services available via that protocol. Given these bits of information the client has enough to be able to contact that server and ask it questions about the URN.
继续示例，请注意，所有记录中的order和preference字段的值都是相等的，因此客户机可以自由选择任何记录。应用程序定义标志“a”表示终端查找，重写的输出将是一个域名，应查询该域名的a记录。一旦客户端完成了这项工作，它就拥有以下信息：主机、其IP地址、协议以及通过该协议可用的服务。给定这些信息，客户机就有足够的能力与服务器联系并向其询问有关URN的问题。
Recall that the regular expression used \2 to extract a domain name from the CID, and \. for matching the literal '.' characters separating the domain name components. Since '\' is the escape character, literal occurrences of a backslash must be escaped by another backslash. For the case of the cid.urn.arpa record above, the regular expression entered into the master file should be "!^urn:cid:.+@([^\\.]+\\.)(.*)$!\\2!i". When the client code actually receives the record, the pattern will have been converted to "!^urn:cid:.+@([^\.]+\.)(.*)$!\2!i".
回想一下，正则表达式使用\2从CID中提取域名，以及\。用于匹配分隔域名组件的文本“.”字符。由于“\”是转义字符，因此反斜杠的文字引用必须由另一个反斜杠转义。对于上面的cid.urn.arpa记录，输入主文件的正则表达式应为“！^urn:cid:.+@（[^\.]+\\）（.*）$！\\2！i”。当客户端代码实际接收到记录时，模式将被转换为“！^urn:cid:.+@（[^\.]+\）（.*）$！\2！i”。
The ENUM Working Group in the IETF has specified a service that allows a telephone number to be mapped to a URI [18]. The Application Unique String for the ENUM Application is the E.164 telephone number with the dashes removed. The First Well Known Rule is to remove all characters from the the telephone number and then use the entire number as the first Key. For example, the phone number "770-555-1212" represented as an E.164 number would be "+1- 770-555-1212". Converted to the Key it would be "17705551212".
IETF中的ENUM工作组指定了一种服务，允许将电话号码映射到URI[18]。枚举应用程序的应用程序唯一字符串是删除破折号的E.164电话号码。第一条众所周知的规则是删除电话号码中的所有字符，然后使用整个号码作为第一个键。例如，表示为E.164号码的电话号码“770-555-1212”将是“+1-770-555-1212”。转换为密钥时，它将是“17705551212”。
The ENUM Application at present only uses this Database. It specifies that, in order to convert the first Key into a form valid for this Database, periods are inserted between each digit, the entire Key is inverted and then "e164.arpa" is appended to the end. The above telephone number would then read "2.1.2.1.5.5.5.0.7.7.1.e164.arpa.". This domain-name is then used to retrieve Rewrite Rules as NAPTR records.
ENUM应用程序目前仅使用此数据库。它指定，为了将第一个键转换为对该数据库有效的形式，在每个数字之间插入句点，将整个键反转，然后在末尾追加“e164.arpa”。然后，上述电话号码将显示为“2.1.2.1.5.5.5.0.7.7.1.e164.arpa”。然后使用此域名将重写规则检索为NAPTR记录。
For this example telephone number we might get back the following NAPTR records:
对于此示例电话号码，我们可能会返回以下NAPTR记录：
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa. IN NAPTR 100 10 "u" "sip+E2U" "!^.*$!sip:information@foo.se!i" . IN NAPTR 102 10 "u" "smtp+E2U" "!^.*$!mailto:information@foo.se!i" .
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa。在NAPTR 100 10“u”sip+E2U“！^.*$！sip中：information@foo.se“我”。在NAPTR 102 10“u”smtp+E2U“！^.*$！mailto中：information@foo.se“我”。
Both the ENUM [18] and URI Resolution [4] Applications use the 'u' flag. This flag states that the Rule is terminal and that the output is a URI which contains the information needed to contact that telephone service. ENUM also uses the same format for its Service Parameters. These state that the available protocols used to access that telephone's service are either the Session Initiation Protocol or SMTP mail.
枚举[18]和URI解析[4]应用程序都使用“u”标志。此标志表示规则是终端，输出是一个URI，其中包含联系该电话服务所需的信息。ENUM的服务参数也使用相同的格式。这些说明用于访问电话服务的可用协议是会话启动协议或SMTP邮件。
Beware of regular expressions. Not only are they difficult to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers.
小心正则表达式。不仅他们自己很难得到正确的答案，而且还有前面提到的与DNS的交互。regexp中的任何反斜杠必须在区域文件中输入两次，才能在查询响应中显示一次。更严重的是，DNS服务器的所有实现者可能都没有测试过对双反斜杠的需求。
In order to mitigate zone file problems, administrators should encourage those writing rewrite rules to utilize the 'default delimiter' feature of the regular expression. In the DDDS specification the regular expression starts with the character that is to be the delimiter. Hence if the first character of the regular expression is an exclamation mark ('!') for example then the regular expression can usually be written with fewer backslashes.
为了缓解区域文件问题，管理员应该鼓励编写重写规则的人利用正则表达式的“默认分隔符”特性。在DDDS规范中，正则表达式以作为分隔符的字符开头。因此，如果正则表达式的第一个字符是感叹号（“！”），则正则表达式通常可以使用较少的反斜杠来编写。
A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known Service Parameter combination.
客户机必须按照“订单”字段指定的顺序处理多条NAPTR记录，而不能简单地使用提供已知服务参数组合的第一条记录。
When multiple RRs have the same "order" and all other criteria being equal, the client should use the value of the preference field to select the next NAPTR to consider. However, because it will often be the case where preferred protocols or services exist, clients may use this additional criteria to sort the records.
当多个RRS具有相同的“订单”和所有其他标准相等时，客户端应该使用偏好字段的值来选择下一个考虑的NAPTR。但是，由于通常情况下存在首选协议或服务，因此客户机可以使用此附加标准对记录进行排序。
If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths.
如果重写后的查找失败，强烈建议客户端报告失败，而不是备份以执行其他重写路径。
The values for the Services and Flags fields will be determined by the Application that makes use of this DDDS Database. Those values may require a registration mechanism and thus may need some IANA resources. This specification by itself does not.
服务和标志字段的值将由使用此DDDS数据库的应用程序确定。这些值可能需要注册机制，因此可能需要一些IANA资源。本规范本身并不适用。
The NAPTR record, like any other DNS record, can be signed and validated according to the procedures specified in DNSSEC.
与任何其他DNS记录一样，NAPTR记录可以根据DNSSEC中指定的程序进行签名和验证。
This Database makes identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem.
此数据库使来自其他名称空间的标识符受到与普通域名相同的攻击。由于它们以前不容易解决，这可能被认为是问题，也可能不被认为是问题。
Regular expressions should be checked for sanity, not blindly passed to something like PERL since arbitrary code can be included and subsequently processed.
应该检查正则表达式是否健全，而不是盲目地传递给PERL之类的东西，因为可以包含任意代码并随后进行处理。
References
工具书类
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[1] Mealling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[2] Mealling，M.，“动态委托发现系统（DDDS）第二部分：算法”，RFC3402，2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[3] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[4] Mealling，M.“动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）解析应用”，RFC3404，2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[5] Mealling，M.“动态委托发现系统（DDDS）第五部分：URI.ARPA分配程序”，RFC 3405，2002年10月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[7] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[8] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[8] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[9] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[10] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[10] Crocker，D.，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[11] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[11] Daniel，R.，“在URN解析中使用HTTP的简单约定”，RFC 2169，1997年6月。
[12] IEEE, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
[12] IEEE，“IEEE信息技术标准-便携式操作系统接口（POSIX）-第2部分：外壳和实用程序（第1卷）”，IEEE Std 1003.2-1992，1993年1月。
[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[13] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[14] Moats, R., "URN Syntax", RFC 2141, May 1997.
[14] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[15] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[15] Sollins，K.，“统一资源名称解析的体系结构原则”，RFC 2276，1998年1月。
[16] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[16] Daniel，R.和M.Mealling，“使用域名系统解析统一资源标识符”，RFC 2168，1997年6月。
[17] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[17] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[18] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[18] Faltstrom，P.，“E.164号码和域名系统”，RFC 29162000年9月。
Author's Address
作者地址
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling，弗吉尼亚州，美国20166
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。