Network Working Group L. Daigle
Request for Comments: 3958 A. Newton
Category: Standards Track VeriSign, Inc.
January 2005
Network Working Group L. Daigle
Request for Comments: 3958 A. Newton
Category: Standards Track VeriSign, Inc.
January 2005
Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)
使用SRV RRs和动态委派发现服务（DDDS）的基于域的应用程序服务定位
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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS) Application to map domain name, application service name, and application protocol dynamically to target server and port.
此备忘录定义了应用程序服务命名的通用机制，该机制允许服务定位，而不依赖于严格的域命名约定（所谓的名称破解）。该方案定义了一个动态委托发现系统（DDDS）应用程序，将域名、应用程序服务名称和应用程序协议动态映射到目标服务器和端口。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 3
2.1. Key Terms. . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. S-NAPTR DDDS Application Usage . . . . . . . . . . . . . 4
2.2.1. Ordering and Preference. . . . . . . . . . . . . 4
2.2.2. Matching and Non-matching NAPTR Records. . . . . 4
2.2.3. Terminal and Non-terminal NAPTR Records. . . . . 5
2.2.4. S-NAPTR and Successive Resolution. . . . . . . . 5
2.2.5. Clients Supporting Multiple Protocols. . . . . . 6
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Guidelines for Application Protocol Developers . . . . . 6
3.1.1. Registration of Application Service and
Protocol Tags. . . . . . . . . . . . . . . . . . 7
3.1.2. Definition of Conditions for Retry/Failure . . . 7
3.1.3. Server Identification and Handshake . . . . . . 8
3.2. Guidelines for Domain Administrators . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Straightforward-NAPTR (S-NAPTR) Specification . . . . . . . . 3
2.1. Key Terms. . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. S-NAPTR DDDS Application Usage . . . . . . . . . . . . . 4
2.2.1. Ordering and Preference. . . . . . . . . . . . . 4
2.2.2. Matching and Non-matching NAPTR Records. . . . . 4
2.2.3. Terminal and Non-terminal NAPTR Records. . . . . 5
2.2.4. S-NAPTR and Successive Resolution. . . . . . . . 5
2.2.5. Clients Supporting Multiple Protocols. . . . . . 6
3. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Guidelines for Application Protocol Developers . . . . . 6
3.1.1. Registration of Application Service and
Protocol Tags. . . . . . . . . . . . . . . . . . 7
3.1.2. Definition of Conditions for Retry/Failure . . . 7
3.1.3. Server Identification and Handshake . . . . . . 8
3.2. Guidelines for Domain Administrators . . . . . . . . . . 8
3.3. Guidelines for Client Software Writers . . . . . . . . . 8
4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Service Discovery within a Domain . . . . . . . . . . . 9
4.3. Multiple Protocols . . . . . . . . . . . . . . . . . . . 10
4.4. Remote Hosting . . . . . . . . . . . . . . . . . . . . . 11
4.5. Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . 12
4.6. Sample Sequence Diagram . . . . . . . . . . . . . . . . 13
5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 14
5.1. So Why Not Just SRV Records? . . . . . . . . . . . . . . 15
5.2. So Why Not Just NAPTR Records? . . . . . . . . . . . . . 15
6. Formal Definition of <Application Service Location>
Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16
6.1. Application-Unique String . . . . . . . . . . . . . . . 16
6.2. First Well-Known Rule . . . . . . . . . . . . . . . . . 16
6.3. Expected Output . . . . . . . . . . . . . . . . . . . . 16
6.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Service Parameters . . . . . . . . . . . . . . . . . . . 17
6.5.1. Application Services . . . . . . . . . . . . . . 17
6.5.2. Application Protocols . . . . . . . . . . . . . 17
6.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Valid Databases . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Application Service Tag IANA Registry . . . . . . . . . 18
7.2. Application Protocol Tag IANA Registry . . . . . . . . . 18
7.3. Registration Process . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Pseudo-pseudocode for S-NAPTR. . . . . . . . . . . . . . . 22
A.1. Finding the First (Best) Target. . . . . . . . . . . 22
A.2. Finding Subsequent Targets . . . . . . . . . . . . . 23
B. Availability of Sample Code. . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 25
3.3. Guidelines for Client Software Writers . . . . . . . . . 8
4. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Service Discovery within a Domain . . . . . . . . . . . 9
4.3. Multiple Protocols . . . . . . . . . . . . . . . . . . . 10
4.4. Remote Hosting . . . . . . . . . . . . . . . . . . . . . 11
4.5. Sets of NAPTR RRs . . . . . . . . . . . . . . . . . . . 12
4.6. Sample Sequence Diagram . . . . . . . . . . . . . . . . 13
5. Motivation and Discussion . . . . . . . . . . . . . . . . . . 14
5.1. So Why Not Just SRV Records? . . . . . . . . . . . . . . 15
5.2. So Why Not Just NAPTR Records? . . . . . . . . . . . . . 15
6. Formal Definition of <Application Service Location>
Application of DDDS . . . . . . . . . . . . . . . . . . . . . 16
6.1. Application-Unique String . . . . . . . . . . . . . . . 16
6.2. First Well-Known Rule . . . . . . . . . . . . . . . . . 16
6.3. Expected Output . . . . . . . . . . . . . . . . . . . . 16
6.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Service Parameters . . . . . . . . . . . . . . . . . . . 17
6.5.1. Application Services . . . . . . . . . . . . . . 17
6.5.2. Application Protocols . . . . . . . . . . . . . 17
6.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . 17
6.7. Valid Databases . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. Application Service Tag IANA Registry . . . . . . . . . 18
7.2. Application Protocol Tag IANA Registry . . . . . . . . . 18
7.3. Registration Process . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
10.1. Normative References . . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
A. Pseudo-pseudocode for S-NAPTR. . . . . . . . . . . . . . . 22
A.1. Finding the First (Best) Target. . . . . . . . . . . 22
A.2. Finding Subsequent Targets . . . . . . . . . . . . . 23
B. Availability of Sample Code. . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 25
This memo defines a generalized mechanism for application service naming that allows service location without relying on rigid domain naming conventions (so-called name hacks). The proposal defines a Dynamic Delegation Discovery System (DDDS -- see [4]) Application to map domain name, application service name, and application protocol dynamically to target server and port.
此备忘录定义了应用程序服务命名的通用机制，该机制允许服务定位，而不依赖于严格的域命名约定（所谓的名称破解）。该提案定义了一个动态委托发现系统（DDDS——请参见[4]）应用程序，将域名、应用程序服务名称和应用程序协议动态映射到目标服务器和端口。
As discussed in section 5, existing approaches to using DNS records for dynamically determining the current host for a given application service are limited in terms of the use cases supported. To address some of the limitations, this document defines a DDDS Application to map service+protocol+domain to specific server addresses by using both NAPTR [5] and SRV ([3]) DNS resource records. This can be viewed as a more general version of the use of SRV and/or a very restricted application of the use of NAPTR resource records.
如第5节所讨论的，使用DNS记录动态确定给定应用程序服务的当前主机的现有方法在支持的用例方面受到限制。为了解决一些限制，本文档定义了一个DDDS应用程序，通过使用NAPTR[5]和SRV（[3]）DNS资源记录，将服务+协议+域映射到特定的服务器地址。这可以看作是SRV使用的更一般版本和/或NAPTR资源记录使用的非常有限的应用。
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 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The precise details of the specification of this DDDS application are given in Section 6. This section defines the usage of the DDDS application.
本DDDS应用规范的具体细节见第6节。本节定义DDDS应用程序的用法。
"Application service" is a generic term for some type of application, independent of the protocol that may be used to offer it. Each application service will be associated with an IANA-registered tag. For example, retrieving mail is a type of application service that can be implemented by different application-layer protocols (e.g., POP3, IMAP4). A tag, such as "RetMail", could be registered for it. (Note that this has not been done, and there are no plans to do so at the time of this writing.)
“应用程序服务”是某种类型的应用程序的通用术语，与提供服务的协议无关。每个应用程序服务都将与IANA注册的标记相关联。例如，检索邮件是一种应用程序服务，可以通过不同的应用程序层协议（例如POP3、IMAP4）实现。可以为它注册一个标签，比如“RetMail”。（请注意，这项工作尚未完成，在撰写本文时也没有这样做的计划。）
An "application protocol" is used to implement the application service. These are also associated with IANA-registered tags. Using the mail example above, "POP3" and "IMAP4" could be registered as application protocol tags. If multiple transports are available for the application, separate tags should be defined for each transport.
“应用程序协议”用于实现应用程序服务。这些标签还与IANA注册的标签相关联。使用上面的邮件示例，“POP3”和“IMAP4”可以注册为应用程序协议标记。如果应用程序有多个传输，则应为每个传输定义单独的标记。
The intention is that the combination of application service and protocol tags should be specific enough that finding a known pair (e.g., "RetMail:POP3" would be sufficient for a client to identify a server with which it can communicate.
其目的是，应用程序服务和协议标记的组合应该足够具体，以便找到一对已知的标记（例如，“RetMail:POP3”）就足以让客户端识别它可以与之通信的服务器。
Some protocols support multiple application services. For example, LDAP is an application protocol and can be found supporting various services (e.g., "whitepages", "directory enabled networking".
一些协议支持多个应用程序服务。例如，LDAP是一种应用程序协议，可以发现它支持各种服务（例如，“白页”、“目录启用网络”）。
As defined in section 6, NAPTR records are used to store application service+protocol information for a given domain. Following the DDDS standard, these records are looked up, and the rewrite rules (contained in the NAPTR records) are used to determine the successive DNS lookups until a desirable target is found.
如第6节所定义，NAPTR记录用于存储给定域的应用程序服务+协议信息。按照DDDS标准，将查找这些记录，并使用重写规则（包含在NAPTR记录中）确定后续DNS查找，直到找到理想的目标。
For the rest of this section, refer to the set of NAPTR resource records for example.com, shown in the figure below, where "WP" is the imagined application service tag for "white pages" and "EM" is the application service tag for an imagined "Extensible Messaging" application service.
对于本节的其余部分，请参考example.com的NAPTR资源记录集，如下图所示，“WP”是“白页”的虚拟应用程序服务标签，“EM”是虚拟“可扩展消息传递”应用程序服务的应用程序服务标签。
example.com.
;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp
bunyip.example. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "" "EM:protA" ( ; service
"" ; regexp
someisp.example. ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)
example.com.
;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp
bunyip.example. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "" "EM:protA" ( ; service
"" ; regexp
someisp.example. ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)
A client retrieves all the NAPTR records associated with the target domain name (example.com, above). These are to be sorted in terms of increasing ORDER and increasing PREF within each ORDER.
客户端检索与目标域名（example.com，上图）关联的所有NAPTR记录。这些将按照递增顺序和每个顺序内递增的优先级进行排序。
Starting with the first sorted NAPTR record, the client examines the SERVICE field to find a match. In the case of the S-NAPTR DDDS application, this means a SERVICE field that includes the tags for the desired application service and a supported application protocol.
从第一个排序的NAPTR记录开始，客户机检查服务字段以查找匹配项。在S-NAPTR DDDS应用程序的情况下，这意味着一个服务字段，其中包括所需应用程序服务的标签和支持的应用程序协议。
If more than one NAPTR record matches, they are processed in increasing sort order.
如果有多条NAPTR记录匹配，则按递增排序顺序处理这些记录。
A NAPTR record with an empty FLAG field is "non-terminal" -- that is, more NAPTR RR lookups are to be performed. Thus, to process a NAPTR record with an empty FLAG field in S-NAPTR, the REPLACEMENT field is used as the target of the next DNS lookup -- for NAPTR RRs.
带有空标志字段的NAPTR记录为“非终端”——即，要执行更多的NAPTR RR查找。因此，要处理S-NAPTR中带有空标志字段的NAPTR记录，替换字段将用作下一次DNS查找的目标——NAPTR RRs。
In S-NAPTR, the only terminal flags are "S" and "A". These are called "terminal" NAPTR lookups because they denote the end of the DDDS/NAPTR processing rules. In the case of an "S" flag, the REPLACEMENT field is used as the target of a DNS query for SRV RRs, and normal SRV processing is applied. In the case of an "A" flag, an address record is sought for the REPLACEMENT field target (and the default protocol port is assumed).
在S-NAPTR中，唯一的终端标志是“S”和“A”。这些被称为“终端”NAPTR查找，因为它们表示DDDS/NAPTR处理规则的结束。在“S”标志的情况下，替换字段用作SRV RRs DNS查询的目标，并应用正常的SRV处理。在“A”标志的情况下，为替换字段目标寻找地址记录（并假定默认协议端口）。
As shown in the example set above, it is possible to have multiple possible targets for a single application service+protocol pair. These are to be pursued in order until a server is successfully contacted or all possible matching NAPTR records have been successively pursued through terminal lookup and server contact. That is, a client must backtrack and attempt other resolution paths in the case of failure.
如上面的示例所示，单个应用程序服务+协议对可能有多个可能的目标。在成功联系服务器或通过终端查找和服务器联系连续查找所有可能匹配的NAPTR记录之前，应依次查找这些记录。也就是说，如果出现故障，客户端必须回溯并尝试其他解决路径。
"Failure" is declared, and backtracking must be used, when
声明“失败”，并且在以下情况下必须使用回溯：
o the designated remote server (host and port) fails to provide appropriate security credentials for the *originating* domain;
o 指定的远程服务器（主机和端口）未能为*原始*域提供适当的安全凭据；
o connection to the designated remote server otherwise fails -- the specifics terms of which are defined when an application protocol is registered; or
o 否则，与指定远程服务器的连接将失败——具体术语在注册应用程序协议时定义；或
o the S-NAPTR-designated DNS lookup fails to yield expected results -- e.g., no A RR for an "A" target, no SRV record for an "S" target, or no NAPTR record with appropriate application service and protocol for a NAPTR lookup. Except in the case of the very first NAPTR lookup, this last is a configuration error: the fact that example.com has a NAPTR record pointing to "bunyip.example" for the "WP:Whois++" service and protocol means the administrator of example.com believes that service exists. If bunyip.example has no "WP:Whois++" NAPTR record, the application client MUST backtrack and try the next available "WP:Whois++" option from example.com. As there is none, the whole resolution fails.
o S-NAPTR指定的DNS查找无法产生预期结果，例如，“A”目标没有RR，“S”目标没有SRV记录，或者NAPTR查找没有具有适当应用程序服务和协议的NAPTR记录。除了第一次NAPTR查找之外，最后一次是配置错误：example.com有一条指向“WP:Whois++”服务和协议的“bunyip.example”的NAPTR记录，这意味着example.com的管理员认为服务存在。如果bunyip.example没有“WP:Whois++”NAPTR记录，则应用程序客户端必须回溯并尝试example.com中下一个可用的“WP:Whois++”选项。由于没有，整个决议都失败了。
An application client first queries for the NAPTR RRs for the domain of a named application service. The first DNS query is for the NAPTR RRs in the original target domain (example.com, above).
应用程序客户端首先查询命名应用程序服务的域的NAPTR RRs。第一个DNS查询是针对原始目标域（example.com，上图）中的NAPTR RRs。
In the case of an application client that supports more than one protocol for a given application service, it MUST pursue S-NAPTR resolution completely for one protocol, exploring all potential terminal lookups in PREF and ORDER ranking, until the application connects successfully or there are no more possibilities for that protocol.
对于支持给定应用程序服务的多个协议的应用程序客户端，它必须为一个协议完全执行S-NAPTR解析，探索PREF和ORDER ranking中的所有潜在终端查找，直到应用程序成功连接或该协议不再存在。
That is, the client MUST NOT start looking for one protocol, observe that a successive NAPTR RR set supports another of its preferred protocols, and continue the S-NAPTR resolution based on that protocol. For example, even if someisp.example offers the "EM" service with protocol "ProtB", there is no reason to believe that it does so on behalf of example.com (as there is no such pointer in example.com's NAPTR RR set).
也就是说，客户端不得开始寻找一个协议，观察一个连续的NAPTR RR集是否支持其首选的另一个协议，并根据该协议继续S-NAPTR解析。例如，即使someisp.example提供了协议为“ProtB”的“EM”服务，也没有理由相信它代表example.com这样做（因为example.com的NAPTR RR集合中没有这样的指针）。
It MAY choose which protocol to try first based on its own preference, or on the PREF ranking in the first set of NAPTR records (i.e., those for the target named domain). However, the chosen protocol MUST be listed in that first NAPTR RR set.
它可以根据自己的偏好，或者根据第一组NAPTR记录（即目标命名域的记录）中的PREF排名，选择首先尝试哪个协议。但是，所选协议必须列在第一个NAPTR集合中。
It MAY choose to run simultaneous DDDS resolutions for more than one protocol, in which case the requirements above apply for each protocol independently. That is, do not switch protocols mid-resolution.
它可以选择为多个协议同时运行DDDS分辨率，在这种情况下，上述要求分别适用于每个协议。也就是说，不要在中分辨率下切换协议。
The purpose of S-NAPTR is to provide application standards developers with a more powerful framework (than SRV RRs alone) for naming service targets, without requiring each application protocol (or service) standard to define a separate DDDS application.
S-NAPTR的目的是为应用程序标准开发人员提供一个更强大的框架（而不仅仅是SRV RRs）来命名服务目标，而不需要每个应用程序协议（或服务）标准定义一个单独的DDDS应用程序。
Note that this approach is intended specifically for use when it makes sense to associate services with particular domain names (e.g., e-mail addresses, SIP addresses, etc). A non-goal is having all manner of label mapped into domain names in order to use this.
请注意，此方法专门用于将服务与特定域名（例如，电子邮件地址、SIP地址等）关联时。一个非目标是将所有形式的标签映射到域名中，以便使用它。
This document does not address how to select the domain for which the service+protocol is being sought. Other conventions will have to define how this might be used (e.g., new messaging standards can define what domain to use from their URIs or how to step down from foobar.example.com to example.com, if applicable).
本文档没有说明如何选择正在寻求服务+协议的域。其他约定必须定义如何使用它（例如，新的消息传递标准可以定义从URI使用哪个域，或者如何从foobar.example.com转到example.com，如果适用）。
Although this document proposes a DDDS application that does not use all the features of NAPTR resource records, it is not intended to imply that DNS resolvers should fail to implement all aspects of the NAPTR RR standard. A DDDS application is a client use convention.
尽管本文档提出的DDDS应用程序未使用NAPTR资源记录的所有功能，但并不意味着DNS解析程序无法实现NAPTR RR标准的所有方面。DDDS应用程序是客户端使用约定。
The rest of this section outlines the specific elements that protocol developers must determine and document to make use of S-NAPTR.
本节其余部分概述了协议开发人员使用S-NAPTR必须确定和记录的特定元素。
Application protocol developers who wish to make use of S-NAPTR must make provisions for registering any relevant application service and application protocol tags, as described in section 7.
如第7节所述，希望使用S-NAPTR的应用程序协议开发人员必须为注册任何相关的应用程序服务和应用程序协议标签做出规定。
One other important aspect that must be defined is the expected behaviour for interacting with the servers that are reached via S-NAPTR. Specifically, under what circumstances should the client retry a target that was found via S-NAPTR? What should it consider a failure that causes it to return to the S-NAPTR process to determine the next serviceable target, which by definition will have a lower preference ranking.
必须定义的另一个重要方面是通过S-NAPTR与服务器交互的预期行为。具体来说，在什么情况下，客户端应该重试通过S-NAPTR找到的目标？它应该考虑什么使它返回到S -NAPTR过程来确定下一个可用的目标，根据定义，它将具有较低的偏好排名。
For example, if the client gets a "connection refused" message from a server, should it retry for some (protocol-dependent) period of time? Or should it try the next-preferred target in the S-NAPTR chain of resolution? Should it only try the next-preferred target if it receives a protocol-specific permanent error message?
例如，如果客户端从服务器收到“连接被拒绝”消息，它是否应该重试一段时间（依赖于协议）？还是应该尝试S-NAPTR解决方案链中的下一个首选目标？如果它收到特定于协议的永久性错误消息，是否应该只尝试下一个首选目标？
The most important thing is to select one expected behaviour and document it as part of the use of S-NAPTR.
最重要的是选择一种预期行为，并将其记录为S-NAPTR使用的一部分。
As noted earlier, failure to provide appropriate credentials to identify the server as being authoritative for the original target domain is always considered a failure condition.
如前所述，未能提供适当的凭据以将服务器标识为原始目标域的权威服务器始终被视为故障条件。
As noted in section 8, use of the DNS for server location increases the importance of using protocol-specific handshakes to determine and confirm the identity of the server that is eventually reached.
如第8节所述，将DNS用于服务器位置增加了使用特定于协议的握手来确定和确认最终到达的服务器身份的重要性。
Therefore, application protocol developers using S-NAPTR should identify the mechanics of the expected identification handshake when the client connects to a server found through S-NAPTR.
因此，当客户端连接到通过S-NAPTR找到的服务器时，使用S-NAPTR的应用程序协议开发人员应该确定预期的身份握手机制。
Although S-NAPTR aims to provide a "straightforward" application of DDDS and use of NAPTR records, it is still possible to create very complex chains and dependencies with the NAPTR and SRV records.
尽管S-NAPTR旨在提供DDD的“直接”应用和NAPTR记录的使用，但仍有可能与NAPTR和SRV记录创建非常复杂的链和依赖关系。
Therefore, domain administrators are called upon to use S-NAPTR with as much restraint as possible while still achieving their service design goals.
因此，域管理员被要求在实现其服务设计目标的同时尽可能克制地使用S-NAPTR。
The complete set of NAPTR, SRV, and A RRs "reachable" through the S-NAPTR process for a particular application service can be thought of as a "tree". Each NAPTR RR that is retrieved points to more NAPTR or SRV records; each SRV record points to several A record lookups. Even though a particular client can "prune" the tree to use only those records referring to application protocols supported by the client, the tree could be quite deep, and retracing the tree to retry other targets can become expensive if the tree has many branches.
对于特定应用程序服务，通过S-NAPTR流程“可访问”的NAPTR、SRV和RRs的完整集合可以被视为一个“树”。检索到的每个NAPTR RR指向更多的NAPTR或SRV记录；每个SRV记录指向多个A记录查找。即使特定客户机可以“修剪”树以仅使用那些引用客户机支持的应用程序协议的记录，树也可能相当深，如果树有许多分支，则回溯树以重试其他目标可能会非常昂贵。
Therefore,
因此
o fewer branches is better: For both NAPTR and SRV records, provide different targets with varying preferences where appropriate (e.g., to provide backup services) but don't look for reasons to provide more; and
o 分支越少越好：对于NAPTR和SRV记录，在适当的情况下为不同的目标提供不同的首选项（例如，提供备份服务），但不要寻找提供更多的理由；和
o shallower is better: Avoid using NAPTR records to "rename" services within a zone. Use NAPTR records to identify services hosted elsewhere (i.e., where you cannot reasonably provide the SRV records in your own zone).
o 浅一点更好：避免使用NAPTR记录“重命名”区域内的服务。使用NAPTR记录识别托管在其他地方的服务（即，您无法在自己的区域中合理提供SRV记录的地方）。
To understand DDDS/NAPTR properly, an implementor must read [4]. However, the most important aspect to keep in mind is that if the application cannot successfully connect to one target, the application will be expected to continue through the S-NAPTR tree to try the (less preferred) alternatives.
为了正确理解DDDS/NAPTR，实现者必须阅读[4]。但是，需要记住的最重要方面是，如果应用程序无法成功连接到一个目标，则应用程序将继续通过S-NAPTR树来尝试（不太首选的）备选方案。
The basic intended use cases for which S-NAPTR has been developed are as follows
S-NAPTR已开发的基本预期用例如下
o Service discovery within a domain. For example, this can be used to find the "authoritative" server for some type of service within a domain (see the specific example in section 4.2).
o 域内的服务发现。例如，这可用于查找域内某种类型服务的“权威”服务器（参见第4.2节中的具体示例）。
o Multiple protocols. This is already common today as new application services are defined, and is increasingly a problem. It includes the case of extensible messaging (a hypothetical service), which can be offered with multiple protocols (see section 4.3).
o 多协议。随着新的应用程序服务的定义，这在今天已经很常见，并且越来越成为一个问题。它包括可扩展消息传递（一种假设的服务）的情况，它可以通过多种协议提供（参见第4.3节）。
o Remote hosting. Each of the above use cases applies within the administration of a single domain. However, one domain operator may elect to engage another organization to provide an application service. See section 4.4 for an example that cannot be served by SRV records alone.
o 远程托管。上述每个用例都适用于单个域的管理。但是，一个域运营商可以选择聘请另一个组织来提供应用程序服务。参见第4.4节了解SRV记录无法单独提供的示例。
There are occasions when it is useful to be able to determine the "authoritative" server for a given application service within a domain. This is "discovery", as there is no a priori knowledge as to whether or where the service is offered; it is therefore important to determine the location and characteristics of the offered service.
有时，能够确定域中给定应用程序服务的“权威”服务器是有用的。这是“发现”，因为对于是否提供服务或在何处提供服务没有先验知识；因此，确定所提供服务的位置和特征非常重要。
For example, there is growing discussion of having a generic mechanism for locating the keys or certificates associated with particular application (servers) operated in (or for) a particular domain. The following is a hypothetical case for storing application key or certificate data for a given domain: the premise is that a credentials registry (CredReg) service has been defined as a leaf node service holding the keys/certs for the servers operated by (or for) the domain. It is assumed that more than one protocol is available to provide the service for a particular domain. This DDDS-based approach is used to find the CredReg server that holds the information.
For example, there is growing discussion of having a generic mechanism for locating the keys or certificates associated with particular application (servers) operated in (or for) a particular domain. The following is a hypothetical case for storing application key or certificate data for a given domain: the premise is that a credentials registry (CredReg) service has been defined as a leaf node service holding the keys/certs for the servers operated by (or for) the domain. It is assumed that more than one protocol is available to provide the service for a particular domain. This DDDS-based approach is used to find the CredReg server that holds the information.translate error, please retry
Thus, the set of NAPTR records for thinkingcat.example might look like this:
因此，thinkingcat.example的NAPTR记录集可能如下所示：
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service
"" ; regexp
theserver.thinkingcat.example. ; replacement
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "" "CREDREG:ldap:iris.beep" ( ; service
"" ; regexp
theserver.thinkingcat.example. ; replacement
Note that the application service might be offered in another domain using a different set of application protocols:
请注意，应用程序服务可能使用一组不同的应用程序协议在另一个域中提供：
anotherdomain.example. ;; order pref flags IN NAPTR 100 10 "" "CREDREG:iris.lwz:iris.beep" ( ; service "" ; regexp foo.anotherdomain.example. ; replacement )
另一个领域。例如；；订购NAPTR 100 10“CREDREG:iris.lwz:iris.beep”中的pref标志（；service”“；regexp foo.anotherdomain.example.；replacement）
Extensible messaging, a hypothetical application service, will be used for illustrative purposes. (For an example of a real application service with multiple protocols, see [9] and [10]). Assuming that "EM" was registered as an application service, this DDDS application could be used to determine the available services for delivery to a target.
可扩展消息传递（一种假设的应用程序服务）将用于说明目的。（有关具有多个协议的实际应用程序服务的示例，请参见[9]和[10]）。假设“EM”已注册为应用程序服务，此DDDS应用程序可用于确定交付给目标的可用服务。
Two particular features of this hypothetical extensible messaging should be noted:
应注意此假设的可扩展消息传递的两个特定功能：
1. Gatewaying is expected to bridge communications across protocols.
1. 网关技术有望跨协议桥接通信。
2. Extensible messaging servers are likely to be operated out of a different domain than that of the extensible messaging address, and servers of different protocols may be offered by independent organizations.
2. 可扩展消息传递服务器可能在不同于可扩展消息传递地址的域之外运行，并且不同协议的服务器可能由独立组织提供。
For example, "thinkingcat.example" may support its own servers for the "ProtA" extensible messaging protocol but rely on outsourcing from "example.com" for "ProtC" and "ProtB" servers.
例如，“thinkingcat.example”可能支持自己的服务器使用“ProtA”可扩展消息传递协议，但“ProtC”和“ProtB”服务器依赖于“example.com”外包。
Using this DDDS-based approach, thinkingcat.example can indicate a preference ranking for the different types of servers for the extensible messaging service, yet the out-sourcer can independently rank the preference and ordering of servers. This independence is not achievable through the use of SRV records alone.
使用这种基于DDDS的方法，thinkingcat.example可以为可扩展消息服务的不同类型的服务器指示首选项排序，而out sourcer可以独立地对服务器的首选项和顺序进行排序。单独使用SRV记录无法实现这种独立性。
Thus, to find the EM services for thinkingcat.example, the NAPTR records for thinkingcat.example are retrieved:
因此，要查找thinkingcat.example的EM服务，将检索thinkingcat.example的NAPTR记录：
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtA" ( ; service "" ; regexp _ProtA._tcp.thinkingcat.example. ; replacement ) IN NAPTR 100 20 "s" "EM:ProtB" ( ; service "" ; regexp _ProtB._tcp.example.com. ; replacement ) IN NAPTR 100 30 "s" "EM:ProtC" ( ; service "" ; regexp _ProtC._tcp.example.com. ; replacement )
以猫为例；；NAPTR 100 20“s”“EM:ProtB”（；service”“；regexp(u tcp.example.com.；replacement）中NAPTR 100 10 10“s”“EM:ProtA.（；service”“；regexp)EM:ProtA.(u tcp.thinkingcat.example.；replacement）中的订单pref标志
Then the administrators at example.com can manage the preference rankings of the servers they use to support the ProtB service:
然后，example.com上的管理员可以管理他们用于支持ProtB服务的服务器的首选项排名：
_ProtB._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com. IN SRV 20 0 10001 backup.em.example.com. IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
_ProtB._tcp.example.com；；SRV 10 0 10001 bigiron.example.com中的Pref Weight端口目标。在SRV 20 0 10001 backup.em.example.com中。在SRV 30 0 10001 nuclearfallout.australia-isp.example中。
In the Instant Message hosting example in Section 4.3, the service owner (thinkingcat.example) had to host pointers to the hosting service's SRV records in the thinkingcat.example domain.
在第4.3节的即时消息托管示例中，服务所有者（thinkingcat.example）必须在thinkingcat.example域中托管指向托管服务SRV记录的指针。
A better approach is to have one NAPTR RR in the thinkingcat.example domain point to all the hosted services. The hosting domain has NAPTR records for each service to map them to whatever local hosts it chooses (this may change from time to time).
更好的方法是在thinkingcat.example域中有一个指向所有托管服务的NAPTR RR。托管域具有每个服务的NAPTR记录，以将它们映射到它选择的任何本地主机（这可能会不时更改）。
thinkingcat.example. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtA" ( ; service "" ; regexp _ProtA._tcp.thinkingcat.example. ; replacement ) IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service "" ; regexp thinkingcat.example.com. ; replacement )
以猫为例；；NAPTR 100 20“EM:ProtB:ProtC”（；service“”；regexp thinkingcat.example.；replacement）中NAPTR 100 10“s”EM:ProtA（；service“”；regexp thinkingcat.example.com.；replacement）中的order pref标志
Then the administrators at example.com can break out the individual application protocols and manage the preference rankings of the servers they use to support the ProtB service (as before):
然后，example.com上的管理员可以分解各个应用程序协议，并管理他们用于支持ProtB服务的服务器的首选项排名（如前所述）：
thinkingcat.example.com. ;; order pref flags IN NAPTR 100 10 "s" "EM:ProtC" ( ; service "" ; regexp _ProtC._tcp.example.com. ; replacement ) IN NAPTR 100 20 "s" "EM:ProtB" ( ; service "" ; regexp _ProtB._tcp.example.com. ; replacement )
thinkingcat.example.com；；NAPTR 100 10“s”“EM:ProtC”（；service”“；regexp _ProtC._tcp.example.com.；replacement）中NAPTR 100 20“s”“EM:ProtB”（；service”“；regexp _ProtB._tcp.example.com.；replacement）中的订单预处理标志
_ProtC._tcp.example.com. ;; Pref Weight Port Target IN SRV 10 0 10001 bigiron.example.com. IN SRV 20 0 10001 backup.em.example.com. IN SRV 30 0 10001 nuclearfallout.australia-isp.example.
_ProtC._tcp.example.com；；SRV 10 0 10001 bigiron.example.com中的Pref Weight端口目标。在SRV 20 0 10001 backup.em.example.com中。在SRV 30 0 10001 nuclearfallout.australia-isp.example中。
Note that the above sections assume that there was one service available (via S-NAPTR) per domain. Often, this will not be the case. Assuming that thinkingcat.example had the CredReg service set up as described in Section 4.2 and had the extensible messaging service set up as described in Section 4.4, then a client querying for the NAPTR RR set from thinkingcat.com would get the following answer:
请注意，以上部分假设每个域有一个可用的服务（通过S-NAPTR）。通常情况下，情况并非如此。假设thinkingcat.example按照第4.2节的说明设置了CredReg服务，并且按照第4.4节的说明设置了可扩展消息服务，那么从thinkingcat.com查询NAPTR RR集的客户端将得到以下答案：
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)
IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" ( ; service
"" ; regexp
bouncer.thinkingcat.example. ; replacement
)
thinkingcat.example.
;; order pref flags
IN NAPTR 100 10 "s" "EM:ProtA" ( ; service
"" ; regexp
_ProtA._tcp.thinkingcat.example. ; replacement
)
IN NAPTR 100 20 "" "EM:ProtB:ProtC" ( ; service
"" ; regexp
thinkingcat.example.com. ; replacement
)
IN NAPTR 200 10 "" "CREDREG:ldap:iris-beep" ( ; service
"" ; regexp
bouncer.thinkingcat.example. ; replacement
)
Sorting them by increasing "ORDER", the client would look through the SERVICE strings to determine whether there was a NAPTR RR that matched the application service it was looking for, with an application protocol it could use. The client would use the first (lowest PREF) record that matched to continue.
通过增加“顺序”对它们进行排序，客户机将查看服务字符串，以确定是否有一个NAPTR RR与它正在寻找的应用程序服务相匹配，以及它可以使用的应用程序协议。客户端将使用匹配的第一条（最低优先级）记录继续。
Consider the example in section 4.3. Visually, the sequence of steps required for the client to reach the final server for a "ProtB" service for EM for the thinkingcat.example domain is as follows:
考虑第4.3节中的例子。从视觉上看，客户端到达thinkingcat.example域EM的“ProtB”服务的最终服务器所需的步骤顺序如下：
Client NS for NS for
thinkingcat.example example.com backup.em.example.com
| | |
1 -------->| | |
2 <--------| | |
3 ------------------------------>| |
4 <------------------------------| |
5 ------------------------------>| |
6 <------------------------------| |
7 ------------------------------>| |
8 <------------------------------| |
9 ------------------------------------------------->|
10 <-------------------------------------------------|
11 ------------------------------------------------->|
12 <-------------------------------------------------|
(...)
Client NS for NS for
thinkingcat.example example.com backup.em.example.com
| | |
1 -------->| | |
2 <--------| | |
3 ------------------------------>| |
4 <------------------------------| |
5 ------------------------------>| |
6 <------------------------------| |
7 ------------------------------>| |
8 <------------------------------| |
9 ------------------------------------------------->|
10 <-------------------------------------------------|
11 ------------------------------------------------->|
12 <-------------------------------------------------|
(...)
1. The name server (NS) for thinkingcat.example is reached with a request for all NAPTR records.
1. thinkingcat.example的名称服务器（NS）会收到所有NAPTR记录的请求。
2. The server responds with the NAPTR records shown in section 4.3.
2. 服务器使用第4.3节所示的NAPTR记录进行响应。
3. The second NAPTR record matches the desired criteria; it has an "s" flag and a replacement fields of "_ProtB._tcp.example.com". So the client looks up SRV records for that target, ultimately making the request of the NS for example.com.
3. 第二条NAPTR记录符合所需标准；它有一个“s”标志和一个替换字段“_ProtB._tcp.example.com”。因此，客户端查找该目标的SRV记录，最终向NS发出请求，例如.com。
4. The response includes the SRV records listed in Section 4.3.
4. 响应包括第4.3节中列出的SRV记录。
5. The client attempts to reach the server with the lowest PREF in the SRV list -- looking up the A record for the SRV record's target (bigiron.example.com).
5. 客户机尝试访问SRV列表中PREF最低的服务器——查找SRV记录目标（bigiron.example.com）的A记录。
6. The example.com NS responds with an error message -- no such machine!
6. example.com NS会响应一条错误消息——没有这样的机器！
7. The client attempts to reach the second server in the SRV list and looks up the A record for backup.em.example.com.
7. 客户端尝试访问SRV列表中的第二台服务器，并为backup.em.example.com查找A记录。
8. The client gets the A record with the IP address for backup.em.example.com from example.com's NS.
8. 客户机从example.com的NS获取具有backup.em.example.com IP地址的A记录。
9. The client connects to that IP address, on port 10001 (from the SRV record), by using ProtB over tcp.
9. 客户端通过使用tcp上的ProtB连接到端口10001上的IP地址（来自SRV记录）。
10. The server responds with an "OK" message.
10. 服务器以“OK”消息响应。
11. The client uses ProtB to challenge that this server has credentials to operate the service for the original domain (thinkingcat.example)
11. 客户机使用ProtB质疑此服务器是否具有操作原始域服务的凭据（thinkingcat.example）
12. The server responds, and the rest is EM.
12. 服务器响应，其余的是EM。
Increasingly, application protocol standards use domain names to identify server targets and stipulate that clients should look up SRV resource records to determine the host and port providing the server. This enables a distinction between naming an application service target and actually hosting the server. It also increases flexibility in hosting the target service, as follows:
越来越多的应用程序协议标准使用域名来识别服务器目标，并规定客户端应查找SRV资源记录以确定提供服务器的主机和端口。这样就可以区分命名应用程序服务目标和实际托管服务器。它还增加了托管目标服务的灵活性，如下所示：
o The server may be operated by a completely different organization without having to list the details of that organization's DNS setup (SRVs).
o 服务器可以由完全不同的组织操作，而不必列出该组织的DNS设置（SRV）的详细信息。
o Multiple instances can be set up (e.g., for load balancing or secondaries).
o 可以设置多个实例（例如，用于负载平衡或辅助）。
o It can be moved from time to time without disrupting clients' access, etc.
o 它可以随时移动，而不会中断客户端的访问等。
This approach is quite useful, but section 5.1 outlines some of its inherent limitations.
这种方法非常有用，但第5.1节概述了它的一些固有局限性。
That is, although SRV records can be used to map from a specific service name and protocol for a specific domain to a specific server, SRV records are limited to one layer of indirection and are focused on server administration rather than on application naming. Furthermore, although the DDDS specification and use of NAPTR allows multiple levels of redirection before the target server machine with an SRV record is located, this proposal requires only a subset of NAPTR strictly bound to domain names, without making use of the REGEXP field of NAPTR. These restrictions make the client's
也就是说，尽管SRV记录可用于从特定域的特定服务名称和协议映射到特定服务器，但SRV记录仅限于一层间接寻址，并侧重于服务器管理，而不是应用程序命名。此外，尽管DDDS规范和NAPTR的使用允许在定位具有SRV记录的目标服务器计算机之前进行多个级别的重定向，但该建议仅要求NAPTR的子集严格绑定到域名，而不使用NAPTR的REGEXP字段。这些限制使客户的
resolution process much more predictable and efficient than it would be with some potential uses of NAPTR records. This is dubbed "S-NAPTR" -- a "S"traightforward use of NAPTR records.
与NAPTR记录的某些潜在用途相比，解析过程更具可预测性和效率。这被称为“S-NAPTR”——NAPTR记录的“S”向前使用。
An expected question at this point is: this is so similar in structure to SRV records, why are we doing this with DDDS/NAPTR?
在这一点上，一个预期的问题是：这在结构上与SRV记录非常相似，为什么我们要用DDDS/NAPTR来做这件事？
Limitations of SRV include the following:
SRV的局限性包括：
o SRV provides a single layer of indirection; the outcome of an SRV lookup is a new domain name for which the A RR is to be found.
o SRV提供了一个单一的间接层；SRV查找的结果是要为其找到RR的新域名。
o the purpose of SRV is to address individual server administration issues, not to provide application naming: As stated in [3], "The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups".
o SRV的目的是解决单个服务器的管理问题，而不是提供应用程序命名：如[3]中所述，“SRV RR允许管理员在单个域中使用多台服务器，在主机之间移动服务而不太麻烦，并将一些主机指定为服务的主服务器，而将其他主机指定为备份”。
o Target servers by "service" (e.g., "ldap") and "protocol" (e.g., "tcp") in a given domain. The definition of these terms implies specific things (e.g., that protocol should be one of UDP or TCP) without being precise. Restriction to UDP and TCP is insufficient for the uses described here.
o 通过给定域中的“服务”（如“ldap”）和“协议”（如“tcp”）来定位服务器。这些术语的定义意味着特定的事情（例如，协议应该是UDP或TCP之一），但并不精确。对UDP和TCP的限制不足以满足此处所述的用途。
The basic answer is that SRV records provide mappings from protocol names to host and port. The use cases described herein require an additional layer -- from some service label to servers that may in be hosted within different administrative domains. We could tweak SRV to say that the next lookup could be something other than an address record, but this is more complex than is necessary for most applications of SRV.
基本答案是，SRV记录提供从协议名称到主机和端口的映射。本文描述的用例需要一个附加层——从一些服务标签到可能托管在不同管理域中的服务器。我们可以调整SRV，说下一次查找可能不是地址记录，但这比大多数SRV应用程序所需的更复杂。
This is a trick question. NAPTR records cannot appear in the wild; see [4]. They must be part of a DDDS application.
这是一个骗人的问题。NAPTR记录不能在野外出现；见[4]。它们必须是DDDS应用程序的一部分。
The purpose here is to define a single, common mechanism (the DDDS application) to use NAPTR when all that is desired is simple DNS-based location of services. This should be easy for applications to use -- a few simple IANA registrations, and it's done.
这里的目的是定义一个单一的通用机制（DDDS应用程序），以便在只需要简单的基于DNS的服务定位时使用NAPTR。这对于应用程序来说应该很容易使用——只需几个简单的IANA注册，就可以了。
Also, NAPTR has very powerful tools for expressing "rewrite" rules. This power (==complexity) makes some protocol designers and service administrators nervous. The concern is that these rewrites can translate into unintelligible, noodle-like rule sets that are difficult to test and administer.
另外，NAPTR有非常强大的工具来表达“重写”规则。这种能力（=复杂性）使一些协议设计者和服务管理员感到紧张。令人担忧的是，这些重写可能会转化为难以理解、难以测试和管理的面条状规则集。
The proposed DDDS application specifically uses a subset of NAPTR's abilities. Only "replacement" expressions are allowed, not "regular expressions".
建议的DDDS应用程序专门使用NAPTR能力的一个子集。只允许使用“替换”表达式，不允许使用“正则表达式”。
6. Formal Definition of <Application Service Location> Application of DDDS
6. <Application Service Location>DDDS应用的正式定义
This section formally defines the DDDS application, as described in [4].
本节正式定义了DDDS应用程序，如[4]所述。
The Application Unique String is domain label for which an authoritative server for a particular service is sought.
应用程序唯一字符串是为其寻找特定服务的权威服务器的域标签。
The "First Well-Known Rule" is identity -- that is, the output of the rule is the Application-Unique String, the domain label for which the authoritative server for a particular service is sought.
“第一条众所周知的规则”是identity——也就是说，该规则的输出是应用程序唯一字符串，即为其寻找特定服务的权威服务器的域标签。
The expected output of this Application is the information necessary for a client to connect to authoritative server(s) (host, port, protocol) for a particular application service within a given domain.
此应用程序的预期输出是客户端连接到给定域内特定应用程序服务的权威服务器（主机、端口、协议）所需的信息。
This DDDS Application uses only 2 of the Flags defined for the URI/ URN Resolution Application ([6]): "S" and "A". No other Flags are valid.
此DDDS应用程序仅使用为URI/URN解析应用程序（[6]）定义的标志中的两个：“S”和“A”。没有其他有效标志。
Both are for terminal lookups. This means that the Rule is the last one and that the flag determines what the next stage should be. The "S" flag means that the output of this Rule is a domain label for which one or more SRV [3] records exist. "A" means that the output of the Rule is a domain name and should be used to lookup address records for that domain.
两者都用于终端查找。这意味着规则是最后一个，标志决定下一个阶段应该是什么。“S”标志表示此规则的输出是存在一个或多个SRV[3]记录的域标签。“A”表示规则的输出是域名，应用于查找该域的地址记录。
Consistent with the DDDS algorithm, if the Flag string is empty the next lookup is for another NAPTR record (for the replacement target).
与DDDS算法一致，如果标志字符串为空，则下一次查找是另一条NAPTR记录（用于替换目标）。
Service Parameters for this Application take the form of a string of characters that follow this ABNF ([2]):
此应用程序的服务参数采用以下ABNF（[2]）后面的字符串形式：
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
Thus, the Service Parameters may consist of an empty string, an app-service, or an app-service with one or more app-protocol specifications separated by the ":" symbol.
因此，服务参数可以由空字符串、应用服务或具有由“：”符号分隔的一个或多个应用协议规范的应用服务组成。
Note that this is similar to, but not the same as the syntax used in the URI DDDS application ([6]). The DDDS DNS database requires each DDDS application to define the syntax of allowable service strings. The syntax here is expanded to allow the characters that are valid in any URI scheme name (see [8]). As "+" (the separator used in the RFC3404 service parameter string) is an allowed character for URI scheme names, ":" is chosen as the separator here.
请注意，这与URI DDDS应用程序（[6]）中使用的语法类似，但不相同。DDDS DNS数据库要求每个DDDS应用程序定义允许的服务字符串的语法。此处的语法已扩展，允许在任何URI方案名称中使用有效字符（请参见[8]）。由于“+”（RFC3404服务参数字符串中使用的分隔符）是URI方案名称允许使用的字符，因此此处选择“：”作为分隔符。
The "app-service" must be an IANA-registered service; see Section 7 for instructions on registering new application service tags.
“应用程序服务”必须是IANA注册的服务；有关注册新应用程序服务标签的说明，请参见第7节。
The protocol identifiers valid for the "app-protocol" production are standard, registered protocols; see section 7 for instructions on registering new application protocol tags.
对“应用程序协议”产品有效的协议标识符是标准的、注册的协议；有关注册新应用程序协议标记的说明，请参见第7节。
Only substitution Rules are permitted for this application. That is, no regular expressions are allowed.
此应用程序只允许使用替换规则。也就是说，不允许使用正则表达式。
At present only one DDDS Database is specified for this Application. [5] specifies that a DDDS Database using the NAPTR DNS resource record contain the rewrite rules. The Keys for this database are encoded as domain-names.
目前，仅为此应用程序指定了一个DDDS数据库。[5] 指定使用NAPTR DNS资源记录的DDDS数据库包含重写规则。此数据库的密钥编码为域名。
The First Well-Known Rule produces a domain name, and this is the Key used for the first look up. The NAPTR records for that domain are requested.
第一条众所周知的规则生成一个域名，这是用于第一次查找的密钥。已请求该域的NAPTR记录。
DNS servers MAY interpret Flag values and use that information to include appropriate NAPTR, SRV, or A 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. See the Additional Information Processing section of [5] for more information on NAPTR records and the Additional Information section of a DNS response packet.
DNS服务器可以解释标志值并使用该信息在DNS分组的附加信息部分中包括适当的NAPTR、SRV或A记录。鼓励客户查看更多信息，但不要求客户查看。有关NAPTR记录和DNS响应数据包的附加信息部分的更多信息，请参阅[5]的附加信息处理部分。
This document calls for two IANA registries: one for application service tags, and one for application protocol tags.
本文档需要两个IANA注册中心：一个用于应用程序服务标记，另一个用于应用程序协议标记。
IANA has established and will maintain a registry for S-NAPTR Application Service Tags, listing at least the following information for each such tag:
IANA已建立并将维护S-NAPTR应用程序服务标签的注册表，至少列出每个此类标签的以下信息：
o Application Service Tag: A string conforming with the IANA-registered-service defined in section 6.5.
o 应用服务标签：符合第6.5节中定义的IANA注册服务的字符串。
o Defining publication: The RFC used to define the Application Service Tag, as defined in the registration process, below.
o 定义发布：用于定义应用程序服务标记的RFC，如下面注册过程中所定义。
An initial Application Service Tag registration is contained in [9].
初始应用程序服务标记注册包含在[9]中。
IANA has established and will maintain a registry for S-NAPTR Application Protocol Tags, listing at least the following information for each such tag:
IANA已建立并将维护S-NAPTR应用程序协议标签的注册表，至少列出每个此类标签的以下信息：
o Application Protocol Tag: A string conforming with the iana-registered-protocol defined in section 6.5.
o 应用协议标签：符合第6.5节中定义的iana注册协议的字符串。
o Defining publication: The RFC used to define the Application Protocol Tag, as defined in the registration process, below.
o 定义发布：用于定义应用程序协议标记的RFC，如下面注册过程中所定义。
An initial Application Protocol Tag registration is defined in [10].
[10]中定义了初始应用协议标签注册。
All application service and protocol tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Implementors use them at their own risk.
所有以“x-”开头的应用程序服务和协议标记都被认为是实验性的，并且没有防止重复使用同一字符串的规定。实施者使用它们的风险自负。
All other application service and protocol tags are registered based on the "specification required" option defined in [7], with the further stipulation that the "specification" is an RFC (of any category).
所有其他应用服务和协议标签均根据[7]中定义的“所需规范”选项进行注册，并进一步规定“规范”为RFC（任何类别）。
No further restrictions are placed on the tags except that they must conform with the syntax defined below (Section 6.5).
除了必须符合下面定义的语法（第6.5节）外，标签上没有其他限制。
The defining RFC must clearly identify and describe, for each tag being registered,
定义RFC必须清楚地识别和描述注册的每个标签，
o application protocol or service tag,
o 应用程序协议或服务标签，
o intended usage,
o 预期用途，
o interoperability considerations,
o 互操作性考虑，
o security considerations (see section 8 of this document for further discussion of the types of considerations that are applicable), and
o 安全注意事项（有关适用注意事项类型的进一步讨论，请参阅本文件第8节），以及
o any relevant related publications.
o 任何相关出版物。
The security of this approach to application service location is only as good as the security of the DNS queries along the way. If any of them is compromised, bogus NAPTR and SRV records could be inserted to redirect clients to unintended destinations. This problem is hardly unique to S-NAPTR (or NAPTR in general). A full discussion of the security threats pertaining to DNS can be found in [11].
这种应用程序服务定位方法的安全性仅与DNS查询的安全性一样好。如果其中任何一个被破坏，可能会插入伪造的NAPTR和SRV记录，以将客户端重定向到意外目的地。这一问题并非S-NAPTR（或一般的NAPTR）所独有。有关DNS的安全威胁的完整讨论可在[11]中找到。
To protect against DNS-vectored attacks, secured DNS (DNSSEC) [12] can be used to ensure the validity of the DNS records received.
为了防止DNS向量攻击，可以使用安全DNS（DNSSEC）[12]来确保收到的DNS记录的有效性。
Whether or not DNSSEC is used, applications should define some form of end-to-end authentication to ensure that the correct destination has been reached. Many application protocols such as HTTPS, BEEP, and IMAP define the necessary handshake mechanisms to accomplish this task. Newly defined application protocols should take this into consideration and incorporate appropriate mechanisms.
无论是否使用DNSSEC，应用程序都应定义某种形式的端到端身份验证，以确保已到达正确的目的地。许多应用程序协议（如HTTPS、BEEP和IMAP）定义了完成此任务所需的握手机制。新定义的应用程序协议应考虑到这一点，并纳入适当的机制。
The basic mechanism works as follows:
基本机制的工作原理如下：
1. During some portion of the protocol handshake, the client sends to the server the original name of the desired destination (i.e., no transformations that may have resulted from NAPTR replacements, SRV targets, or CNAME changes). In certain cases where the application protocol does not have such a feature but TLS may be used, it is possible to use the "server_name" TLS extension.
1. 在协议握手的某些部分期间，客户端向服务器发送所需目的地的原始名称（即，没有可能由NAPTR替换、SRV目标或CNAME更改导致的转换）。在某些情况下，如果应用程序协议没有此类功能，但可以使用TLS，则可以使用“服务器名称”TLS扩展。
2. The server sends back to the client a credential with the appropriate name. For X.509 certificates, the name would be in either the subjectDN or the subjectAltName field. For Kerberos, the name would be a service principle name.
2. 服务器向客户端发回具有适当名称的凭据。对于X.509证书，名称将位于subjectDN或subjectAltName字段中。对于Kerberos，名称将是服务原则名称。
3. Using the matching semantics defined by the application protocol, the client compares the name in the credential with the name sent to the server.
3. 使用应用程序协议定义的匹配语义，客户端将凭据中的名称与发送到服务器的名称进行比较。
4. If the names match and the credentials have integrity, there is reasonable assurance that the correct end point has been reached.
4. 如果名称匹配且凭据具有完整性，则可以合理保证已达到正确的终点。
5. The client and server establish an integrity-protected channel.
5. 客户端和服务器建立一个完整性保护通道。
Note that this document does not define either the handshake mechanism, the specific credential naming fields, nor the name-matching semantics. Definitions of S-NAPTR for particular application protocols MUST define these.
请注意，本文档既没有定义握手机制、特定凭证命名字段，也没有定义名称匹配语义。特定应用协议的S-NAPTR定义必须定义这些。
Many thanks to Dave Blacka, Patrik Faltstrom, Sally Floyd, and Ted Hardie for discussion and input that have (hopefully!) provoked clarifying revisions to this document.
非常感谢Dave Blacka、Patrik Faltstrom、Sally Floyd和Ted Hardie的讨论和意见（希望如此！），这些讨论和意见促使对本文件进行了澄清性修订。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[3] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[4] Mealling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[5] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[6] Mealling，M.“动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）”，RFC34042002年10月。
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[7] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[9] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", RFC 3982, January 2005.
[9] Newton，A.和M.Sanz，“IRIS：互联网注册信息服务（IRIS）的域注册（dreg）类型”，RFC 3982，2005年1月。
[10] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC 3983, January 2005.
[10] Newton，A.和M.Sanz，“通过块可扩展交换协议（BEEP）使用互联网注册信息服务（IRIS）”，RFC 3983，2005年1月。
[11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name System", Work in Progress, April 2004.
[11] Atkins，D.和R.Austein，“域名系统的威胁分析”，正在进行的工作，2004年4月。
[12] Arends, R., Larson, M., Austein, R., and D. Massey, "Protocol Modifications for the DNS Security Extensions", Work in Progress, May 2004.
[12] Arends，R.，Larson，M.，Austein，R.，和D.Massey，“DNS安全扩展的协议修改”，正在进行的工作，2004年5月。
Assuming the client supports 1 protocol for a particular application service, the following pseudocode outlines the expected process to find the first (best) target for the client, using S-NAPTR.
假设客户机支持特定应用程序服务的1个协议，下面的伪代码概述了使用S-NAPTR为客户机找到第一个（最佳）目标的预期过程。
target = [initial domain]
naptr-done = false
target = [initial domain]
naptr-done = false
while (not naptr-done)
{
NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
[sort NAPTR-RRset by ORDER, and PREF within each ORDER]
rr-done = false
cur-rr = [first NAPTR RR]
while (not naptr-done)
{
NAPTR-RRset = [DNSlookup of NAPTR RRs for target]
[sort NAPTR-RRset by ORDER, and PREF within each ORDER]
rr-done = false
cur-rr = [first NAPTR RR]
while (not rr-done)
if ([SERVICE field of cur-rr contains desired application
service and application protocol])
rr-done = true
target= [REPLACEMENT target of NAPTR RR]
else
cur-rr = [next rr in list]
while (not rr-done)
if ([SERVICE field of cur-rr contains desired application
service and application protocol])
rr-done = true
target= [REPLACEMENT target of NAPTR RR]
else
cur-rr = [next rr in list]
if (not empty [FLAG in cur-rr]) naptr-done = true }
if（非空[当前rr中的标志]）naptr done=true}
port = -1
port = -1
if ([FLAG in cur-rr is "S"])
{
SRV-RRset = [DNSlookup of SRV RRs for target]
[sort SRV-RRset based on PREF]
target = [target of first RR of SRV-RRset]
port = [port in first RR of SRV-RRset]
}
if ([FLAG in cur-rr is "S"])
{
SRV-RRset = [DNSlookup of SRV RRs for target]
[sort SRV-RRset based on PREF]
target = [target of first RR of SRV-RRset]
port = [port in first RR of SRV-RRset]
}
; now, whether it was an "S" or an "A" in the NAPTR, we ; have the target for an A record lookup
; 现在，无论是NAPTR中的“S”还是“A”，我们；具有记录查找的目标
host = [DNSlookup of target]
host = [DNSlookup of target]
return (host, port)
返回（主机、端口）
The pseudocode in Appendix A is crafted to find the first, most preferred host-port pair for a particular application service and protocol. If, for any reason, that host-port pair did not work (connection refused, application-level error), the client is expected to try the next host-port in the S-NAPTR tree.
附录A中的伪代码用于查找特定应用程序服务和协议的第一个、最首选的主机端口对。如果出于任何原因，该主机端口对不起作用（连接被拒绝，应用程序级错误），则客户端将尝试S-NAPTR树中的下一个主机端口。
The pseudocode above does not permit retries -- once complete, it sheds all context of where in the S-NAPTR tree it finished. Therefore, client software writers could
上面的伪代码不允许重试——一旦完成，它将放弃它在S-NAPTR树中完成的位置的所有上下文。因此，客户端软件编写人员可以
o entwine the application-specific protocol with the DNS lookup and RRset processing described in the pseudocode and continue the S-NAPTR processing if the application code fails to connect to a located host-port pair;
o 将特定于应用程序的协议与伪代码中描述的DNS查找和RRset处理纠缠在一起，如果应用程序代码未能连接到定位的主机端口对，则继续S-NAPTR处理；
o use callbacks for the S-NAPTR processing; or
o 对S-NAPTR处理使用回调；或
o use an S-NAPTR resolution routine that finds *all* valid servers for the required application service and protocol from the originating domain and that provides them in a sorted order for the application to try.
o 使用S-NAPTR解析例程，从原始域中查找所需应用程序服务和协议的*所有*有效服务器，并按排序顺序提供这些服务器供应用程序尝试。
Sample Python code for S-NAPTR resolution is available from
http://www.verisignlabs.com/pysnaptr-0.1.tgz
Sample Python code for S-NAPTR resolution is available from
http://www.verisignlabs.com/pysnaptr-0.1.tgz
Authors' Addresses
作者地址
Leslie Daigle VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
Leslie Daigle VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21355，邮编20166
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
Andrew Newton VeriSign, Inc. 21355 Ridgetop Circle Dulles, VA 20166 US
Andrew Newton VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21355，邮编20166
EMail: anewton@verisignlabs.com
EMail: anewton@verisignlabs.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。