Network Working Group M. Mealling
Request for Comments: 2915 Network Solutions, Inc.
Updates: 2168 R. Daniel
Category: Standards Track DATAFUSION, Inc.
September 2000
Network Working Group M. Mealling
Request for Comments: 2915 Network Solutions, Inc.
Updates: 2168 R. Daniel
Category: Standards Track DATAFUSION, Inc.
September 2000
The Naming Authority Pointer (NAPTR) DNS Resource Record
命名机构指针（NAPTR）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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document describes a Domain Name System (DNS) resource record which specifies a regular expression based rewrite rule that, when applied to an existing string, will produce a new domain label or Uniform Resource Identifier (URI). Depending on the value of the flags field of the resource record, the resulting domain label or URI may be used in subsequent queries for the Naming Authority Pointer (NAPTR) resource records (to delegate the name lookup) or as the output of the entire process for which this system is used (a resolution server for URI resolution, a service URI for ENUM style e.164 number to URI mapping, etc).
本文档描述了域名系统（DNS）资源记录，该记录指定了基于正则表达式的重写规则，当应用于现有字符串时，将生成新的域标签或统一资源标识符（URI）。根据资源记录的flags字段的值，生成的域标签或URI可用于命名机构指针（NAPTR）资源记录的后续查询（以委托名称查找），或作为使用此系统的整个过程的输出（用于URI解析的解析服务器，用于枚举样式e.164数字到URI映射的服务URI，等等）。
This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax. Reasons for doing this range from URN Resource Discovery Systems to moving out-of-date services to new domains.
这允许DNS用于查找不在域名语法中的各种资源名称（包括URI）的服务。这样做的原因从URN资源发现系统到将过时的服务迁移到新域。
This document updates the portions of RFC 2168 specifically dealing with the definition of the NAPTR records and how other, non-URI specific applications, might use NAPTR.
本文档更新了RFC 2168中专门涉及NAPTR记录定义以及其他非URI特定应用程序如何使用NAPTR的部分。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 3
3. Substitution Expression Grammar . . . . . . . . . . . . . . 7
4. The Basic NAPTR Algorithm . . . . . . . . . . . . . . . . . 8
5. Concerning How NAPTR Uses SRV Records . . . . . . . . . . . 9
6. Application Specifications . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. DNS Packet Format . . . . . . . . . . . . . . . . . . . . . 13
9. Master File Format . . . . . . . . . . . . . . . . . . . . . 14
10. Advice for DNS Administrators . . . . . . . . . . . . . . . 14
11. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. NAPTR RR Format . . . . . . . . . . . . . . . . . . . . . . 3
3. Substitution Expression Grammar . . . . . . . . . . . . . . 7
4. The Basic NAPTR Algorithm . . . . . . . . . . . . . . . . . 8
5. Concerning How NAPTR Uses SRV Records . . . . . . . . . . . 9
6. Application Specifications . . . . . . . . . . . . . . . . . 10
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. DNS Packet Format . . . . . . . . . . . . . . . . . . . . . 13
9. Master File Format . . . . . . . . . . . . . . . . . . . . . 14
10. Advice for DNS Administrators . . . . . . . . . . . . . . . 14
11. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . 15
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
Full Copyright Statement . . . . . . . . . . . . . . . . . . 18
This RR was originally produced by the URN Working Group [3] as a way to encode rule-sets in DNS so that the delegated sections of a 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. 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.
此RR最初由URN工作组[3]生成，作为在DNS中对规则集进行编码的一种方式，以便可以分解URI的委托部分，从而随着时间的推移对其进行更改和重新委托。结果是一个资源记录，其中包含一个正则表达式，客户端程序将使用该正则表达式将字符串重写为域名。选择正则表达式是因为它们的紧凑性与表现力之比允许在一个相当小的DNS数据包中对大量信息进行编码。
The function of rewriting a string according to the rules in a record has usefulness in several different applications. This document defines the basic assumptions to which all of those applications must adhere to. It does not define the reasons the rewrite is used, what the expected outcomes are, or what they are used for. Those are specified by applications that define how they use the NAPTR record and algorithms within their contexts.
根据记录中的规则重写字符串的功能在几种不同的应用中都很有用。本文件定义了所有这些应用程序必须遵守的基本假设。它没有定义使用重写的原因、预期结果是什么或它们用于什么。这些由应用程序指定，这些应用程序定义如何在其上下文中使用NAPTR记录和算法。
Flags and other fields are also specified in the RR to control the rewrite procedure in various ways or to provide information on how to communicate with the host at the domain name that was the result of the rewrite.
RR中还指定了标志和其他字段，以各种方式控制重写过程，或提供有关如何在重写结果所在的域名上与主机通信的信息。
The final result is a RR that has several fields that interact in a non-trivial but implementable way. This document specifies those fields and their values.
最终的结果是一个RR，它有几个字段，这些字段以一种非平凡但可实现的方式进行交互。本文档指定了这些字段及其值。
This document does not define applications that utilizes this rewrite functionality. Instead it specifies just the mechanics of how it is done. Why its done, what the rules concerning the inputs, and the types of rules used are reserved for other documents that fully specify a particular application. This separation is due to several different applications all wanting to take advantage of the rewrite rule lookup process. Each one has vastly different reasons for why and how it uses the service, thus requiring that the definition of the service be generic.
本文档不定义使用此重写功能的应用程序。相反，它只指定了如何完成的机制。为什么要这样做，关于输入的规则以及使用的规则类型是为完全指定特定应用程序的其他文档保留的。这种分离是由于几个不同的应用程序都希望利用重写规则查找过程。每个人使用服务的原因和方式都有很大的不同，因此要求服务的定义是通用的。
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 RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119中的说明进行解释。
All references to Uniform Resource Identifiers in this document adhere to the 'absoluteURI' production of the "Collected ABNF" found in RFC 2396 [9]. Specifically, the semantics of URI References do not apply since the concept of a Base makes no sense here.
本文件中对统一资源标识符的所有引用均遵循RFC 2396[9]中“收集的ABNF”的“绝对URI”生成。具体来说，URI引用的语义不适用，因为基的概念在这里毫无意义。
The format of the NAPTR RR is given below. The DNS type code [1] for NAPTR is 35.
NAPTR RR的格式如下所示。NAPTR的DNS类型代码[1]为35。
Domain TTL Class Type Order Preference Flags Service Regexp Replacement
域TTL类类型订单首选项标志服务Regexp替换
Domain The domain name to which this resource record refers. This is the 'key' for this entry in the rule database. This value will either be the first well known key (<something>.uri.arpa for example) or a new key that is the output of a replacement or regexp rewrite. Beyond this, it has the standard DNS requirements [1].
域此资源记录引用的域名。这是规则数据库中此项的“键”。该值要么是第一个已知的键（<something>.uri.arpa），要么是替换或regexp重写的输出的新键。除此之外，它还有标准DNS要求[1]。
TTL Standard DNS meaning [1].
TTL标准DNS含义[1]。
Class Standard DNS meaning [1].
类别标准DNS含义[1]。
Type The Type Code [1] for NAPTR is 35.
键入NAPTR的类型代码[1]为35。
Order A 16-bit unsigned integer specifying the order in which the NAPTR records MUST be processed to ensure the correct ordering of rules. Low numbers are processed before high numbers, and once a NAPTR is found whose rule "matches" the target, the client MUST NOT consider any NAPTRs with a higher value for order (except as noted below for the Flags field).
排序一个16位无符号整数，指定必须处理NAPTR记录的顺序，以确保规则的正确排序。低数量在高数量之前被处理，并且一旦发现了其规则与目标匹配的NAPTR，客户机就不必考虑任何具有更高的订单值的NAPTR（除了下面标记的字段）。
Preference 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 understanding the preferred protocol or service.
首选项一个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. I.e., Preference is used to give weight to rules that are considered the same from an authority standpoint but not from a simple load balancing standpoint.
顺序和偏好之间的重要区别是一旦找到匹配，客户就不必考虑不同顺序的记录，但它们可以处理相同顺序但不同偏好的记录。也就是说，首选项用于对从权威角度（而不是从简单的负载平衡角度）认为相同的规则赋予权重。
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-Z0-9]. The case of the alphabetic characters is not significant.
标志<character string>包含控制记录中字段重写和解释方面的标志。标志是集合[A-Z0-9]中的单个字符。字母字符的大小写并不重要。
At this time only four flags, "S", "A", "U", and "P", are defined. The "S", "A" and "U" flags denote a terminal lookup. This means that this NAPTR record is the last one and that the flag determines what the next stage should be. The "S" flag means that the next lookup should be for SRV records [4]. See Section 5 for additional information on how NAPTR uses the SRV record type. "A" means that the next lookup should be for either an A, AAAA, or A6 record. The "U" flag means that the next step is not a DNS lookup but that the output of the Regexp field is an URI that adheres to the 'absoluteURI' production found in the ABNF of RFC 2396 [9]. Since there may be applications that use NAPTR to also lookup aspects of URIs, implementors should be aware that this may cause loop conditions and should act accordingly.
此时仅定义了四个标志“S”、“A”、“U”和“P”。“S”、“A”和“U”标志表示终端查找。这意味着此NAPTR记录是最后一条记录，该标志确定下一阶段应该是什么。“S”标志表示下一次查找应针对SRV记录[4]。有关NAPTR如何使用SRV记录类型的更多信息，请参见第5节。“A”表示下一次查找应针对A、AAAA或A6记录。“U”标志意味着下一步不是DNS查找，而是Regexp字段的输出是一个URI，它遵循RFC 2396[9]的ABNF中找到的“absoluteURI”产品。由于可能有应用程序使用NAPTR来查找URI的各个方面，所以实现者应该知道这可能会导致循环条件，并应相应地采取行动。
The "P" flag says that the remainder of the application side algorithm shall be carried out in a Protocol-specific fashion. The new set of rules is identified by the Protocol specified in the Services field. The record that contains the 'P' flag is the last record that is interpreted by the rules specified in this document. The new rules are dependent on the application for which they are being used and the protocol specified. For example, if the application is a URI RDS and the protocol is WIRE then the new set of rules are governed by the algorithms surrounding the WIRE HTTP specification and not this document.
“P”标志表示应用程序端算法的其余部分应以特定于协议的方式执行。新规则集由服务字段中指定的协议标识。包含“P”标志的记录是由本文档中指定的规则解释的最后一条记录。新规则取决于使用它们的应用程序和指定的协议。例如，如果应用程序是URI RDS，协议是WIRE，那么新的规则集由围绕WIRE HTTP规范的算法控制，而不是由本文档控制。
The remaining alphabetic flags are reserved for future versions of the NAPTR specification. The numeric flags may be used for local experimentation. The S, A, U and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code for assisting in the creation of NAPTRs would be more likely to signal such an error than a client such as a browser). It is anticipated that multiple flags will be allowed in the future, so implementers MUST NOT assume that the flags field can only contain 0 or 1 characters. Finally, if a client encounters a record with an unknown flag, it MUST ignore it and move to the next record. This test takes precedence even over the "order" field. Since flags can control the interpretation placed on fields, a novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a given target.
其余的字母标志保留给NAPTR规范的未来版本。数字标志可用于本地实验。S、A、U和P标志都是互斥的，如果给出了多个标志，则分辨率库可能会发出错误信号。（实验代码和用于协助创建NAPTR的代码比客户端（如浏览器）更可能发出此类错误的信号）。预计将来将允许使用多个标志，因此实现者不得假设标志字段只能包含0或1个字符。最后，如果客户机遇到具有未知标志的记录，它必须忽略该记录并移动到下一个记录。此测试甚至优先于“顺序”字段。由于标志可以控制字段上的解释，因此新标志可能会更改regexp和/或替换字段的解释，从而无法确定记录是否与给定目标匹配。
The "S", "A", and "U" flags are called 'terminal' flags since they halt the looping rewrite algorithm. If those flags are not present, clients may assume that another NAPTR RR exists at the domain name produced by the current rewrite rule. Since the "P" flag specifies a new algorithm, it may or may not be 'terminal'. Thus, the client cannot assume that another NAPTR exists since this case is determined elsewhere.
“S”、“A”和“U”标志称为“终端”标志，因为它们停止循环重写算法。如果这些标志不存在，客户端可能会认为当前重写规则生成的域名上存在另一个NAPTR RR。由于“P”标志指定了一个新的算法，它可能是也可能不是“终端”。因此，客户机不能假设存在另一个NAPTR，因为这种情况是在别处确定的。
DNS servers MAY interpret these flags and values and use that information to include appropriate SRV and A,AAAA, or A6 records in the additional information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so.
DNS服务器可以解释这些标志和值，并使用该信息在DNS数据包的附加信息部分中包括适当的SRV和A、AAAA或A6记录。鼓励客户查看更多信息，但不要求客户查看。
Service Specifies the service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a service. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next
服务指定沿此重写路径可用的服务。它还可以指定用于与服务对话的特定协议。如果标志字段表明NAPTR是终端，则必须指定协议。如果指定了协议，但flags字段未说明NAPTR是终端，则下一个
lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon.
查找必须针对NAPTR。如果协议未知，客户端可以选择不执行下一次查找，但不能依赖该行为。
The service field may take any of the values below (using the Augmented BNF of RFC 2234 [5]):
服务字段可以采用以下任何值（使用RFC 2234[5]的扩充BNF）：
service_field = [ [protocol] *("+" rs)]
protocol = ALPHA *31ALPHANUM
rs = ALPHA *31ALPHANUM
; The protocol and rs fields are limited to 32
; characters and must start with an alphabetic.
service_field = [ [protocol] *("+" rs)]
protocol = ALPHA *31ALPHANUM
rs = ALPHA *31ALPHANUM
; The protocol and rs fields are limited to 32
; characters and must start with an alphabetic.
For example, an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character.
例如，可选协议规范后跟0个或多个解析服务。每个解析服务都由一个初始“+”字符表示。
Note that the empty string is also a valid service field. This will typically be seen at the beginning of a series of rules, when it is impossible to know what services and protocols will be offered by a particular service.
请注意，空字符串也是一个有效的服务字段。这通常出现在一系列规则的开头，此时不可能知道特定服务将提供哪些服务和协议。
The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents. Protocols need not offer all services. The labels for service requests shall be formed from the set of characters [A-Z0-9]. The case of the alphabetic characters is not significant.
服务请求和响应的实际格式将由解决协议确定，并且是其他文档的主题。协议不需要提供所有服务。服务请求标签应由一组字符组成[A-Z0-9]。字母字符的大小写并不重要。
The list of "valid" protocols for any given NAPTR record is any protocol that implements some or all of the services defined for a NAPTR application. Currently, THTTP [6] is the only protocol that is known to make that claim at the time of publication. Any other protocol that is to be used must have documentation specifying:
任何给定NAPTR记录的“有效”协议列表是实现为NAPTR应用程序定义的部分或全部服务的任何协议。目前，THTTP[6]是在发表时已知的唯一提出该声明的协议。要使用的任何其他协议必须有文件说明：
* how it implements the services of the application
* 它如何实现应用程序的服务
* how it is to appear in the NAPTR record (i.e., the string id of the protocol)
* 它在NAPTR记录中的显示方式（即协议的字符串id）
The list of valid Resolution Services is defined by the documents that specify individual NAPTR based applications.
有效的解析服务列表由指定单个基于NAPTR的应用程序的文档定义。
It is worth noting that the interpretation of this field is subject to being changed by new flags, and that the current specification is oriented towards telling clients how to talk with a URN resolver.
值得注意的是，此字段的解释可能会因新标志而改变，并且当前的规范旨在告诉客户如何与URN解析器对话。
Regexp A 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. The grammar of the substitution expression is given in the next section.
Regexp包含替换表达式的字符串，该表达式应用于客户端持有的原始字符串，以便构造下一个要查找的域名。替换表达式的语法将在下一节中给出。
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.
正则表达式不能以累积方式使用，也就是说，它们应该只应用于客户机持有的原始字符串，而不能应用于以前NAPTR重写生成的域名。后者在某些应用程序中很诱人，但经验表明，这种用法对故障非常敏感，非常容易出错，并且极难调试。
Replacement The next NAME to query for NAPTR, SRV, or address records depending on the value of the flags field. This MUST be a fully qualified domain-name. Unless and until permitted by future standards action, name compression is not to be used for this field.
替换根据flags字段的值查询NAPTR、SRV或地址记录的下一个名称。这必须是一个完全限定的域名。除非未来标准行动允许，否则名称压缩不得用于此字段。
The content of the regexp field is a substitution expression. True sed(1) and Perl style substitution expressions are not appropriate for use in this application for a variety of reasons stemming from internationalization requirements and backref limitations, therefore the contents of the regexp field MUST follow the grammar below:
regexp字段的内容是替换表达式。由于国际化要求和backref限制的各种原因，True sed（1）和Perl样式的替换表达式不适合在此应用程序中使用，因此regexp字段的内容必须遵循以下语法：
subst_expr = delim-char ere delim-char repl delim-char *flags
delim-char = "/" / "!" / ... <Any non-digit or non-flag character
other than backslash '\'. All occurances of a delim_char
in a subst_expr must be the same character.>
ere = POSIX Extended Regular Expression
repl = 1 * ( OCTET / backref )
backref = "\" 1POS_DIGIT
flags = "i"
POS_DIGIT = %x31-39 ; 0 is not an allowed backref
subst_expr = delim-char ere delim-char repl delim-char *flags
delim-char = "/" / "!" / ... <Any non-digit or non-flag character
other than backslash '\'. All occurances of a delim_char
in a subst_expr must be the same character.>
ere = POSIX Extended Regular Expression
repl = 1 * ( OCTET / backref )
backref = "\" 1POS_DIGIT
flags = "i"
POS_DIGIT = %x31-39 ; 0 is not an allowed backref
The definition of a POSIX Extended Regular Expression can be found in [8], section 2.8.4.
POSIX扩展正则表达式的定义见[8]，第2.8.4节。
The result of applying the substitution expression to the original URI MUST result in either a string that obeys the syntax for DNS domain-names [1] or a URI [9] if the Flags field contains a 'u'. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain-name can be constructed, client software SHOULD verify that the result is a legal DNS domain-name before making queries on it.
将替换表达式应用于原始URI的结果必须生成一个符合DNS域名[1]语法的字符串，如果标志字段包含“u”，则必须生成一个URI[9]。由于可能不正确地指定regexp字段，从而可以构造不一致的域名，因此客户端软件应在对其进行查询之前验证结果是否为合法的DNS域名。
Backref expressions in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE
替换表达式repl部分中的Backref表达式将替换为替换表达式ERE部分中由“（”和“）”括起的（可能为空）字符串。N是从1到9的一个数字，包括在内。它指定第N个backref表达式，该表达式以第N个'（'并继续到匹配的'）'开头。例如，ERE
(A(B(C)DE)(F)G)
(A(B(C)DE)(F)G)
has backref expressions:
具有backref表达式：
\1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression
\1=ABCDEFG\2=BCDE\3=C\4=F\5..\9=错误-没有匹配的子表达式
The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given.
“i”标志表示应以不区分大小写的方式执行ERE匹配。此外，当给出“i”标志时，任何backref替换都可以标准化为小写。
The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurrences of the delimiter character in a substitution expression. Since escaped occurrences of the delimiter character will be interpreted as occurrences of that character, digits MUST NOT be used as delimiters. Backrefs would be confused with literal digits were this allowed. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character.
替换表达式中的第一个字符应用作分隔替换表达式组成部分的字符。在替换表达式中，分隔符字符必须正好出现三次非转义。由于分隔符字符的转义出现将被解释为该字符的出现，因此不能将数字用作分隔符。如果允许的话，backref将与文本数字混淆。类似地，如果在替换表达式中指定了标志，则分隔符字符也不能是标志字符。
The behavior and meaning of the flags and services assume an algorithm where the output of one rewrite is a new key that points to another rule. This looping algorithm allows NAPTR records to incrementally specify a complete rule. These incremental rules can be delegated which allows other entities to specify rules so that one entity does not need to understand _all_ rules.
标志和服务的行为和意义假定一个算法，其中一次重写的输出是指向另一条规则的新键。这种循环算法允许NAPTR记录以增量方式指定完整的规则。可以委托这些增量规则，这允许其他实体指定规则，以便一个实体不需要理解所有规则。
The algorithm starts with a string and some known key (domain). NAPTR records for this key are retrieved, those with unknown Flags or inappropriate Services are discarded and the remaining records are sorted by their Order field. Within each value of Order, the records are further sorted by the Preferences field.
该算法从一个字符串和一些已知的密钥（域）开始。检索此键的NAPTR记录，丢弃具有未知标志或不适当服务的记录，并按顺序字段对其余记录进行排序。在Order的每个值中，记录按首选项字段进一步排序。
The records are examined in sorted order until a matching record is found. A record is considered a match iff:
将按排序顺序检查记录，直到找到匹配的记录。记录被视为匹配iff：
o it has a Replacement field value instead of a Regexp field value.
o 它具有替换字段值，而不是Regexp字段值。
o or the Regexp field matches the string held by the client.
o 或者Regexp字段与客户端持有的字符串匹配。
The first match MUST be the match that is used. Once a match is found, the Services field is examined for whether or not this rule advances toward the desired result. If so, the rule is applied to the target string. If not, the process halts. The domain that results from the regular expression is then used as the domain of the next loop through the NAPTR algorithm. Note that the same target string is used throughout the algorithm.
第一个匹配项必须是使用的匹配项。找到匹配项后，将检查“服务”字段，以确定此规则是否朝着所需的结果前进。如果是，则将规则应用于目标字符串。否则，该过程将停止。然后通过NAPTR算法将正则表达式生成的域用作下一个循环的域。请注意，在整个算法中使用相同的目标字符串。
This looping is extremely important since it is the method by which complex rules are broken down into manageable delegated chunks. The flags fields simply determine at which point the looping should stop (or other specialized behavior).
这种循环非常重要，因为它是将复杂规则分解为可管理的委托块的方法。flags字段仅确定循环应停止在哪一点（或其他特殊行为）。
Since flags are valid at any level of the algorithm, the degenerative case is to never loop but to look up the NAPTR and then stop. In many specialized cases this is all that is needed. Implementors should be aware that the degenerative case should not become the common case.
由于标志在算法的任何级别都是有效的，退化的情况是从不循环，而是查找NAPTR，然后停止。在许多特殊情况下，这就是所需要的全部。实施者应该意识到退化情况不应该成为常见情况。
When the SRV record type was originally specified it assumed that the client did not know the specific domain-name before hand. The client would construct a domain-name more in the form of a question than the usual case of knowing ahead of time that the domain-name should exist. I.e., if the client wants to know if there is a TCP based HTTP server running at a particular domain, the client would construct the domain-name _http._tcp.somedomain.com and ask the DNS if that records exists. The underscores are used to avoid collisions with potentially 'real' domain-names.
当最初指定SRV记录类型时，它假定客户端事先不知道特定的域名。与通常提前知道域名应该存在的情况相比，客户将以问题的形式构建域名。也就是说，如果客户端想知道特定域上是否有基于TCP的HTTP服务器运行，客户端将构造域名_HTTP._TCP.somedomain.com，并询问DNS是否存在该记录。下划线用于避免与潜在的“真实”域名发生冲突。
In the case of NAPTR, the actual domain-name is specified by the various fields in the NAPTR record. In this case the client isn't asking a question but is instead attempting to get at information that it has been told exists in an SRV record at that particular domain-name. While this usage of SRV is slightly different than the SRV authors originally intended it does not break any of the assumptions concerning what SRV contains. Also, since the NAPTR explicitly spells out the domain-name for which an SRV exists, that domain-name MUST be used in SRV queries with NO transformations. Any given NAPTR record may result in a domain-name to be used for SRV queries that may or may not contain the SRV standardized underscore
对于NAPTR，实际域名由NAPTR记录中的各个字段指定。在这种情况下，客户机不是在问问题，而是在试图获取信息，即它被告知存在于该特定域名的SRV记录中。虽然SRV的这种用法与SRV作者最初的意图略有不同，但它并没有打破任何关于SRV所包含内容的假设。此外，由于NAPTR明确说明了存在SRV的域名，因此必须在SRV查询中使用该域名，而不进行转换。任何给定的NAPTR记录都可能产生一个域名，用于可能包含或不包含SRV标准下划线的SRV查询
characters. NAPTR applications that make use of SRV MUST NOT attempt to understand these domains or use them according to how the SRV specification structures its query domains.
人物。使用SRV的NAPTR应用程序不得试图理解这些域，或根据SRV规范如何构造其查询域来使用这些域。
It should be noted that the NAPTR algorithm is the basic assumption about how NAPTR works. The reasons for the rewrite and the expected output and its use are specified by documents that define what applications the NAPTR record and algorithm are used for. Any document that defines such an application must define the following:
应该注意的是，NAPTR算法是关于NAPTR工作原理的基本假设。重写的原因、预期输出及其使用由定义NAPTR记录和算法用于哪些应用程序的文档指定。定义此类应用程序的任何文档必须定义以下内容：
o The first known domain-name or how to build it
o 第一个已知的域名或如何建立它
o The valid Services and Protocols
o 有效的服务和协议
o What the expected use is for the output of the last rewrite
o 上次重写的输出的预期用途是什么
o The validity and/or behavior of any 'P' flag protocols.
o 任何“P”标志协议的有效性和/或行为。
o The general semantics surrounding why and how NAPTR and its algorithm are being used.
o 关于NAPTR及其算法被使用的原因和方式的一般语义。
NOTE: These are examples only. They are taken from ongoing work and may not represent the end result of that work. They are here for pedagogical reasons only.
注意：这些只是示例。它们取自正在进行的工作，可能并不代表该工作的最终结果。他们来这里只是为了教学目的。
NAPTR was originally specified for use with the a Uniform Resource Name Resolver Discovery System. This example details how a particular URN would use the NAPTR record to find a resolver service.
NAPTR最初指定用于统一资源名称解析程序发现系统。此示例详细说明了特定URN如何使用NAPTR记录查找解析程序服务。
Consider a URN namespace based on MIME Content-Ids. The URN might look like this:
考虑基于MIME内容ID的URN命名空间。骨灰盒可能如下所示：
urn:cid:39CB83F7.A8450130@fake.gatech.edu
urn:cid:39CB83F7.A8450130@fake.gatech.edu
(Note that this example is chosen for pedagogical purposes, and does not conform to the CID URL scheme.)
（请注意，选择此示例是出于教学目的，不符合CID URL方案。）
The first step in the resolution process is to find out about the CID namespace. The namespace identifier [3], 'cid', is extracted from the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first 'known' key in the NAPTR algorithm. The NAPTR records for cid.urn.arpa looked up and return a single record:
解析过程的第一步是了解CID名称空间。命名空间标识符[3]“cid”是从URN中提取的，位于URN.arpa之前然后，“cid.urn.arpa”成为NAPTR算法中的第一个“已知”密钥。查找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”。
There is only one NAPTR response, so 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 "gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records where the new domain is ' gatech.edu' and the string is the same string as before.
只有一个NAPTR响应，因此排序响应不是问题。替换字段为空，因此使用regexp字段中提供的模式。我们将该regexp应用于整个URN，以查看它是否匹配，它确实匹配。替换表达式的\2部分返回字符串“gatech.edu”。由于flags字段不包含“s”或“a”，因此查找不是终端，我们对DNS的下一次探测是查找更多NAPTR记录，其中新域为“gatech.edu”，字符串与以前相同。
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 mordred, could have their very own NAPTR, maintaining those records for all the machines at a site as large as Georgia Tech would 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来自主机并提取其域。虽然所有主机，如mordred，都可以拥有自己的NAPTR，但在乔治亚理工大学这样大的站点上维护所有机器的记录将是一个无法忍受的负担。通配符在这里不合适，因为它们仅在系统中没有完全匹配的名称时返回结果。
The record returned from the query on "gatech.edu" might look like:
“gatech.edu”查询返回的记录可能如下所示：
;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+I2C" "" _rcds._udp.gatech.edu. IN NAPTR 100 50 "s" "http+I2L+I2C+I2R" "" _http._tcp.gatech.edu.
;; order pref标志NAPTR 100 50“s”“z3950+I2L+I2C”“中的服务regexp替换。\u z3950.\u tcp.gatech.edu。在NAPTR 100 50“s”中的“RCD+I2C”\u RCD.\u udp.gatech.edu。在NAPTR 100 50中的“http+I2L+I2C+I2R”\u http.\u tcp.gatech.edu。
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 flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service.
继续示例，请注意，所有记录中的order和preference字段的值都是相等的，因此客户机可以自由选择任何记录。flags字段告诉我们，这些是我们应该看到的最后一个NAPTR模式，在重写（本例中是一个简单的替换）之后，我们应该查找SRV记录，以获取有关可以提供必要服务的主机的信息。
Assuming we prefer the Z39.50 protocol, our lookup might return:
假设我们更喜欢Z39.50协议，我们的查找可能会返回：
;; Pref Weight Port Target _z3950._tcp.gatech.edu. IN SRV 0 0 1000 z3950.gatech.edu. IN SRV 0 0 1000 z3950.cc.gatech.edu. IN SRV 0 0 1000 z3950.uga.edu.
;; 预加权端口目标_z3950._tcp.gatech.edu。在SRV 0 0 1000 z3950.gatech.edu中。在SRV 0 0 1000 z3950.cc.gatech.edu中。在SRV 0 0 1000 z3950.uga.edu中。
telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server.
告诉我们三台主机实际上可以进行解析，并给我们应该用来与他们的Z39.50服务器通信的端口。
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
回想一下，正则表达式使用\2从CID中提取域名，以及\。用于匹配分隔域名组件的文本“.”字符。因为“\”是逃逸
character, literal occurances 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".
字符，反斜杠的文字出现必须由另一个反斜杠转义。对于上面的cid.urn.arpa记录，输入主文件的正则表达式应为“/urn:cid:.+@（[^\.]+\\）（.*）$/\\2/i”。当客户机代码实际收到记录时，模式将被转换为“/urn:cid:.+@（[^\.]+\）（.*）$/\2/i”。
Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement that URNs be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc.
即使URN系统现在已经就位，仍然会有大量的URL。应该可以开发一个URN解析系统，该系统还可以为这些URL提供位置独立性。这与要求URN能够从其他命名系统（如ISO正式公共标识符、国会图书馆电话号码、ISBN、ISSN等）中输入名称有关。
The NAPTR RR could also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world:
NAPTR还可以用于已分配的URL。假设我们有一个非常流行的软件的URL，出版商希望在世界各地的多个站点上镜像该软件：
Using the rules specified for this application we extract the prefix, "http", and lookup NAPTR records for http.uri.arpa. This might return a record of the form
使用为此应用程序指定的规则，我们提取前缀“http”，并查找http.uri.arpa的NAPTR记录。这可能会返回表单的记录
http.uri.arpa. IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "!http://([^/:]+)!\1!i" .
http.uri.arpa。在NAPTR；；order pref flags service regexp replacement 100 90“”！http:/（[^/：]+）！\1！i”。
This expression returns everything after the first double slash and before the next slash or colon. (We use the '!' character to delimit the parts of the substitution expression. Otherwise we would have to use backslashes to escape the forward slashes and would have a regexp in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
此表达式返回第一个双斜杠之后和下一个斜杠或冒号之前的所有内容。（我们使用“！”字符来分隔替换表达式的各个部分。否则，我们将不得不使用反斜杠来转义正斜杠，并且区域文件中的regexp类似于“/http:\/\\/（[^\\/：]+）/\\1/i”。）。
Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return:
将此模式应用于URL提取“www.foo.com”。查找可能返回的NAPTR记录：
www.foo.com. ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "http+I2R" "" _http._tcp.foo.com. IN NAPTR 100 100 "s" "ftp+I2R" "" _ftp._tcp.foo.com.
www.foo.com；；order pref标志NAPTR 100 100“s”“http+I2R”“”\u http.\u tcp.foo.com中的服务regexp替换。在NAPTR 100 100中的“ftp+I2R”\u ftp.\u tcp.foo.com。
Looking up SRV records for http.tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user.
查找http.tcp.foo.com的SRV记录将返回有关foo.com指定为其镜像站点的主机的信息。然后，客户端可以为用户选择一个。
A non-URI example is the ENUM application which uses a NAPTR record to map an e.164 telephone number to a URI. In order to convert the phone number to a domain name for the first iteration all characters other than digits are removed from the the telephone number, the entire number is inverted, periods are put between each digit and the string ".e164.arpa" is put on the left-hand side. For example, the E.164 phone number "+1-770-555-1212" converted to a domain-name it would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
一个非URI示例是ENUM应用程序，它使用NAPTR记录将e.164电话号码映射到URI。为了在第一次迭代中将电话号码转换为域名，电话号码中除数字以外的所有字符都被删除，整个号码被颠倒，每个数字和字符串之间都有句点“.e164.arpa”放在左侧。例如，将E.164电话号码“+1-770-555-1212”转换为域名，即“2.1.2.1.5.5.5.0.7.7.1.e164.arpa”
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@tele2.se!" . IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!" .
$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa。在NAPTR 100 10“u”sip+E2U“！^.*$！sip中：information@tele2.se!" . 在NAPTR 102 10“u”mailto+E2U“！^.*$！mailto中：information@tele2.se!" .
This application uses the same 'u' flag as the URI Resolution application. 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 field except that it defines the 'E2U' service instead of the 'I2*' services that URI resolution uses. The example above states that the available protocols used to access that telephone's service are either the Session Initiation Protocol or SMTP mail.
此应用程序使用与URI解析应用程序相同的“u”标志。此标志表示规则是终端，输出是一个URI，其中包含联系该电话服务所需的信息。ENUM的服务字段也使用相同的格式，只是它定义了“E2U”服务，而不是URI解析使用的“I2*”服务。上面的示例说明，用于访问该电话服务的可用协议是会话启动协议或SMTP邮件。
The packet format for the NAPTR record is:
NAPTR记录的数据包格式为：
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 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
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 /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
哪里：
FLAGS A <character-string> which contains various flags.
标记包含各种标记的<character string>。
SERVICES A <character-string> which contains protocol and service identifiers.
服务包含协议和服务标识符的<character string>。
REGEXP A <character-string> which contains a regular expression.
REGEXP包含正则表达式的<character string>。
REPLACEMENT A <domain-name> which specifies the new value in the case where the regular expression is a simple replacement operation.
替换A<domain name>，在正则表达式是简单替换操作的情况下指定新值。
<character-string> and <domain-name> as used here are defined in RFC1035 [1].
此处使用的<character string>和<domain name>在RFC1035[1]中定义。
The master file format follows the standard rules in RFC-1035 [1]. 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 10 for how to correctly enter and escape the regular expression.
主文件格式遵循RFC-1035[1]中的标准规则。顺序和首选项为16位无符号整数，应为介于0和65535之间的整数。标志、服务和Regexp字段都是带引号的<character string>s。由于Regexp字段可能包含许多反斜杠，因此应小心处理。有关如何正确输入和转义正则表达式，请参见第10节。
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服务器的所有实现者可能都没有测试过对双反斜杠的需求。
The "a" flag allows the next lookup to be for address records (A, AAAA, A6) rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port.
“a”标志允许下一次查找地址记录（a、AAAA、A6），而不是SRV记录。由于NAPTR记录中没有端口规范的位置，因此当使用“a”标志时，指定的协议必须在其默认端口上运行。
The URN Syntax draft defines a canonical form for each URN, which requires %encoding characters outside a limited repertoire. The regular expressions MUST be written to operate on that canonical form. Since international character sets will end up with extensive use of %encoded characters, regular expressions operating on them will be essentially impossible to read or write by hand.
URN语法草案为每个URN定义了一个规范形式，它要求在有限的指令集之外有%的编码字符。必须编写正则表达式才能对该规范形式进行操作。由于国际字符集最终将大量使用%编码字符，因此对其进行操作的正则表达式基本上不可能手动读取或写入。
o 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 protocol and service combination.
o 客户机必须按照“订单”字段指定的顺序处理多条NAPTR记录，而不能简单地使用提供已知协议和服务组合的第一条记录。
o 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.
o 当多个RRS具有相同的“订单”和所有其他标准相等时，客户端应该使用偏好字段的值来选择下一个考虑的NAPTR。但是，由于通常情况下存在首选协议或服务，因此客户机可以使用此附加标准对记录进行排序。
o If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths.
o 如果重写后的查找失败，强烈建议客户端报告失败，而不是备份以执行其他重写路径。
o Note that SRV RRs impose additional requirements on clients.
o 请注意，SRV RRs对客户提出了附加要求。
The only registration function that impacts the IANA is for the values that are standardized for the Services and Flags fields. To extend the valid values of the Flags field beyond what is specified in this document requires a published specification that is approved by the IESG.
影响IANA的唯一注册函数是服务和标志字段标准化的值。若要将Flags字段的有效值扩展到本文档中指定的范围之外，则需要IESG批准的已发布规范。
The values for the Services field will be determined by the application that makes use of the NAPTR record. Those values must be specified in a published specification and approved by the IESG.
服务字段的值将由使用NAPTR记录的应用程序确定。这些值必须在发布的规范中指定，并由IESG批准。
The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed.
目前正在研究与DNSSEC的相互作用。预计一旦部署DNSSEC工作，NAPTR记录将与SIG记录一起签名。
The rewrite rules make 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.
应该检查正则表达式是否健全，而不是盲目地传递给PERL之类的东西。
This document has discussed a way of locating a service, but has not discussed any detail of how the communication with that service takes place. There are significant security considerations attached to the
本文档讨论了一种定位服务的方法，但没有讨论与该服务进行通信的任何细节。有重要的安全考虑附加到
communication with a service. Those considerations are outside the scope of this document, and must be addressed by the specifications for particular communication protocols.
与服务的通信。这些注意事项不在本文件的范围内，必须通过特定通信协议的规范加以解决。
The editors would like to thank Keith Moore for all his consultations during the development of this memo. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. Finally, we would like to acknowledge our enormous intellectual debt to the participants in the Knoxville series of meetings, as well as to the participants in the URI and URN working groups.
编辑们要感谢Keith Moore在编写本备忘录期间进行的所有咨询。我们还要感谢Paul Vixie在调试我们的实现过程中提供的帮助，以及他对我们问题的回答。最后，我们要感谢我们对诺克斯维尔系列会议与会者以及URI和URN工作组与会者的巨大知识债务。
References
工具书类
[1] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[1] Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[2] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[3] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] 护城河，R.，“瓮语法”，RFC 21411997年5月。
[4] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[4] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[5] Crocker，D.，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[6] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.
[6] Daniel，R.，“在URN解析中使用HTTP的简单约定”，RFC 2169，1997年6月。
[7] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
[7] Daniel，R.和M.Mealling，“使用域名系统解析统一资源标识符”，RFC 2168，1997年6月。
[8] 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.
[8] IEEE，“IEEE信息技术标准-便携式操作系统接口（POSIX）-第2部分：外壳和实用程序（第1卷）”，IEEE Std 1003.2-1992，1993年1月。
[9] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9] Berners Lee，T.，Fielding，R.T.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
Authors' Addresses
作者地址
Michael Mealling Network Solutions, Inc. 505 Huntmar Park Drive Herndon, VA 22070 US
迈克尔·米林网络解决方案公司，美国弗吉尼亚州亨特马公园大道505号，邮编：22070
Phone: +1 770 921 2251
EMail: michaelm@netsol.com
URI: http://www.netsol.com
Phone: +1 770 921 2251
EMail: michaelm@netsol.com
URI: http://www.netsol.com
Ron Daniel DATAFUSION, Inc. 139 Townsend Street, Ste. 100 San Francisco, CA 94107 US
罗恩·丹尼尔数据融合有限公司，地址：圣路易斯市汤森德街139号。100旧金山，CA 94107美国
Phone: +1 415 222 0100
EMail: rdaniel@datafusion.net
URI: http://www.datafusion.net
Phone: +1 415 222 0100
EMail: rdaniel@datafusion.net
URI: http://www.datafusion.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。