动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）解析应用

本备忘录的状态

本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参阅当前版本的“互联网官方协议标准”（STD 1）。这份备忘录的分发是无限的。

版权声明

版权所有（C）互联网协会（2002）。保留所有权利。

摘要

本文档描述了获取统一资源标识符（Uniform Resource Identifiers，URI）并查找有关该URI信息的权威服务器的规范。用于定位该授权服务器的方法是动态委派发现系统。

本文档是“动态委托发现系统（DDDS）第一部分：综合DDDS”（RFC 3401）中指定的系列的一部分。需要注意的是，如果不阅读其他文件，就不可能阅读和理解本系列中的任何文件。

1、 简介

动态委派发现系统（Dynamic Delegation Discovery System，DDDS）用于实现字符串到数据的延迟绑定，以支持动态配置的委派系统。DDDS的功能是通过迭代应用字符串转换规则，将一些唯一字符串映射到存储在DDDS数据库中的数据，直到达到终端条件。

本文档描述了用于解析统一资源标识符（URI）的DDDS应用程序。它没有定义DDDS算法或数据库。这样做的整个系列文档在“动态委托发现系统（DDDS）第一部分：综合DDDS”（RFC 3401）[1]中有详细说明。需要注意的是，如果不阅读相关文件，就不可能阅读和理解该系列中的任何文件。

统一资源标识符（URI）在检索互联网可访问资源方面取得了重大进展。然而，随着时间的推移，它们的脆性已经被人们认识到好几年了。统一资源标识符工作组建议开发统一资源名称[8]，作为互联网资源的持久、独立于位置的标识符，以克服URI的大多数问题。RFC 1737[6]规定了对URNs的要求。

在URI-WG的生命周期内，产生了许多URN提案。其中几项提案的开发者在一系列会议上进行了会面，达成了一项被称为诺克斯维尔框架的妥协。Knoxville框架背后的主要原则是解析系统必须与名称的分配方式分开。这与大多数URI形成了鲜明对比，后者标识要联系的主机和要使用的协议。读者可参考[7]了解诺克斯维尔框架的背景，以及有关本提案背景和目的的更多信息。

将解析名称的方式与构造名称的方式分开提供了几个好处。它允许多种命名方法和解析方法进行竞争，因为它允许使用不同的协议和解析器。这种分离只有一个问题——当一个名称无法向我们提供解析程序的指示时，我们如何解析它？

从短期来看，域名系统（Domain Name System，DNS）显然是解决框架的候选者，因为它被广泛部署和理解。但是，使用DNS来维护每个资源的信息是不合适的。首先，DNS从未打算处理那么多记录。其次，有限的记录大小不适合目录信息。第三，域名不适合作为URN。

因此，我们的方法是使用DDDS来定位“解析器”，这些解析器可以提供有关单个资源的信息，可能包括资源本身。为了实现这一点，我们按照DDDS中的规则将URI“重写”为Key。本文档将URI解析描述为DDDS的一个应用程序，并指定至少使用一个基于DNS的数据库。

2、 术语

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可能”和“可选”应按照RFC 2119中的描述进行解释。

所有大写术语均取自RFC 3403[动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库]中DDDS算法规范中的词汇表。

3、 URNs和URI的区别

从这个系统的角度来看，在一般情况下解析URI和在特定情况下解析URNs在理论上没有区别。然而，在操作上，有一个差异源于URI解析可能没有得到广泛使用。如果将URN解析分解为通用URI解析，则URN可能会因缺乏URI解析而受到影响。

解决方案是允许对URN解析进行快捷操作。在以下规范中，通用URI解析首先将已知URI方案的规则插入到“URI.arpa.”注册表中。对于“URN:”URI方案，在“URI.arpa.”中找到的规则之一将用于“URN”URI方案。此规则将简单地委托给基于urn命名空间的附加NAPTR的“urn.arpa.”区域。从本质上讲，“URN:”的URI解析重写规则是URN解析应用程序的第一个众所周知的规则。

因此，本文件规定了两个DDDS申请。一个用于URI解析，另一个用于URN解析。两者在技术上是相同的，但通过将两个URN分离，解决方案仍然可以在没有依赖性的情况下进行。

4、 URI和URN解析应用规范

该模板根据[3]中的规则和要求定义URI和URN解析DDDS应用程序。本应用程序使用的DDDS数据库可在[4]中找到，[4]是定义命名机构指针（Naming Authority Pointer，NAPTR）DNS资源记录（Resource Record，RR）类型的文档。

4.1、 应用程序唯一字符串

应用程序唯一字符串是权威服务器所在的URI或URN。此URI或URN必须根据RFC 2396[15]中收集的ABNF中的“绝对URI”生成进行规范化和十六进制编码。

4.2、 第一条众所周知的规则

在URI的情况下，通过采用URI方案来创建第一个已知密钥。在URN的情况下，第一个已知的关键字是命名空间标识符。例如，URI“http://www.example.com/’将有一个“http”作为其密钥。URN“URN:foo:foospace”将使用“foo”作为其第一个Key。

4.3、 标志

此时，只定义了四个标志，“S”、“A”、“U”和“P”。“S”、“A”和“U”标志用于终端查找。这意味着规则是最后一个，标志决定了下一阶段应该是什么。“S”标志意味着此规则的输出是存在一个或多个SRV[9]记录的域名。有关URI和URN解析如何使用SRV记录类型的更多信息，请参阅第5节。“A”表示规则的输出是域名，应用于查找该域的A、AAAA或A6记录。“U”标志表示规则的输出是一个URI[15]。

“P”标志表示DDDS算法的其余部分被忽略，该过程的其余部分是特定于应用程序的，不在本文档的范围内。应用程序可以使用“服务”字段中的“协议”部分来确定下一步应遵循的特定于应用程序的规则集。包含“P”标志的记录是本文档中规则解释的最后一条记录。有人可能会认为，这也会使“P”标志成为终端查找的指示符，但这是不正确的，因为“终端”规则是DDDS概念，而该标志表示该规则之后的任何内容都根本不符合DDDS概念。

剩下的字母标志是为本规范的未来版本保留的。数字标志可以用于局部实验。S、A、U和P标志都是互斥的，如果给定多个，解析库可能会发出错误信号。（与浏览器等客户端相比，实验代码和用于帮助创建重写规则的代码更有可能发出这样的错误信号。）预计未来将允许使用多个标志，因此实现者不得假设标志字段只能包含0或1个字符。最后，如果客户端遇到一个带有未知标志的记录，它必须忽略它并转到下一个规则。此测试优先于任何排序，因为标志可以控制字段上的解释。一个新颖的标志可能会改变正则表达式和/或替换字段的解释，从而无法确定记录是否与给定目标匹配。

“S”、“A”和“U”标志被称为“终端”标志，因为它们停止了循环DDDS算法。如果这些标志不存在，客户端可能会认为当前重写规则生成的密钥中存在另一个规则。

4.4、 服务参数

此应用程序的服务参数采用以下ABNF后面的字符串形式：

service_field = [ [protocol] *("+" rs)]protocol = ALPHA *31ALPHANUMrs = ALPHA *31ALPHANUM; 协议和rs字段限制为32个字符，并且必须以字母开头。

换句话说，一个可选的协议规范，后面跟着0个或多个解析服务。每个解析服务都由一个初始的“+”字符表示。

空字符串也是有效的。这通常会出现在一系列规则的开头，当时不可能知道在特定授权路径的末尾将提供什么服务和协议。

4.4.1、 服务

组成“rs”产品的服务标识符对于URI和URN解析都是通用的，因为输入值本身的类型是基于URI方案的。[11]中定义了有效服务的列表。

其中一些服务包括：

I2L：给定一个URI，返回一个标识可以找到原始URI的位置的URI。

I2Ls：给定的URI返回一个或多个URI，这些URI标识可以找到原始URI的多个位置。

I2R：给定一个URI，返回由该URI标识的资源的一个实例。

I2Rs：给定的URI返回由该URI标识的资源的一个或多个实例。

I2C：给定一个URI，返回该资源描述的一个实例。

I2N：给定一个URI，返回一个命名资源的URN（注意：与URNs相等是非平凡的。有关原因的示例，请参阅[6]。）

4.4.2、 协议

对于“protocol”生产有效的协议标识符必须由特定于URI解析的文档定义。目前，THTTP[10]协议是唯一这样的规范。

非常重要的是要认识到，仅仅在服务字段中指定任何协议都是不够的，因为协议中没有定义URI解析的附加语义。例如，如果Z39.50被指定为一个有效的协议，那么它必须另外定义它将如何对特定服务的请求进行编码，如何对URI进行编码，以及返回什么信息。

4.4.3、 服务的适用性

由于可能存在一组复杂的可能协议和服务，因此客户端应用程序可能经常需要将更复杂的决策过程应用于一组记录，而不是简单地在协议的有序列表上进行匹配。例如，如果有4个规则适用，则最后一个规则可能比第一个规则具有更理想的服务字段。但由于客户可能会对第一个感到满意，因此永远不会知道第四个可能会“更好”。

为了缓解这种情况，客户端可能希望稍微修改DDDS算法（仅适用于此应用程序！），以确定是否存在更适用的协议/服务。这可以通过在DDDS算法的步骤3和4之间使用更复杂的交互来安全地完成，以便找到要遵循的最佳路径。例如，一旦客户找到了一个规则，谁的替代表达式产生了结果，谁的服务描述是可以接受的，它可能会注意到这一点，但会继续查看适用的进一步规则（同时遵守顺序！），以找到更好的规则。如果没有找到，它可以使用它记录的那个。

请记住，为了保持安全，步骤3的输入和步骤4的输出必须与基本算法相同。客户端软件不得试图在特定的重写规则集之外（即，跨委托路径）进行此优化。

4.5、 有效数据库

目前，仅为该应用程序指定了一个DDDS数据库。“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”（RFC 3403）[4]指定了一个DDDS数据库，该数据库使用NAPTR DNS资源记录来包含重写规则。此数据库的密钥被编码为域名。

URI解析应用程序的第一个众所周知的规则的输出是URI的方案。为了将其转换为此数据库中的唯一密钥，字符串“.ui.arpa.”被附加到末尾。该域名用于请求NAPTR记录，该记录以域名的形式生成新密钥。

URN解析应用程序的第一个已知规则的输出是URN的命名空间id。为了将其转换为此数据库中的唯一密钥，字符串’.URN.arpa.’被附加到末尾。该域名用于请求NAPTR记录，该记录以域名的形式生成新密钥。

DNS服务器可以解释标志值，并使用该信息在DNS数据包的附加信息部分中包括适当的SRV和A记录。鼓励客户端检查附加信息，但不要求这样做。有关NAPTR记录的更多信息，请参阅RFC 3404的附加信息处理部分和DNS响应数据包的附加信息部分。

用于对替换表达式进行编码的字符集是UTF-8。允许的输入字符是URI中任何位置都允许的所有字符。密钥中允许的字符是当前为DNS域名定义的字符。替换表达式的“i”标志用于表示，在适用于所讨论的代码点的情况下，任何匹配都应以不区分大小写的方式进行。

5、 示例

5.1、 使用URN的示例

考虑一个使用假设的FOO名称空间的URN。FOO编号是世界各地约3000万注册企业的标识符，由Fred、Otto和Orvil股份有限公司分配和维护。URN可能如下所示：

urn:foo:002372413:annual-report-1997

解析过程的第一步是了解FOO名称空间。命名空间标识符[8]“foo”是从URN中提取的，并以“.un.arpa.”为前缀，生成“foo.un.arpa.”。DNS会查询此域的NAPTR记录，从而生成以下结果：

foo.urn.arpa.;; order pref flags service regexp replacementIN NAPTR 100 10 "s" "foolink+I2L+I2C" "" foolink.udp.example.com.IN NAPTR 100 20 "s" "rcds+I2C" "" rcds.udp.example.com.IN NAPTR 100 30 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.example.com.

顺序字段包含相等的值，表示不必遵循任何顺序。首选项字段表示提供商希望客户端使用特殊的“傻瓜链接”协议，然后是RCDS协议，并且THTTP是作为最后手段提供的。所有记录都指定了“s”标志，这意味着该记录是终端记录，下一步是从DNS中检索给定域名的SRV记录。

服务字段表示，如果我们谈论傻瓜链接，我们将能够发出I2L、I2C或I2R请求来获得URI，或者询问一些关于资源的复杂问题。资源编目和分发服务（Resource Cataloging and Distribution Service，RCDS）[12]可用于获取资源的一些元数据，而THTTP可用于获取该资源当前位置的URI。

假设我们的客户端不知道傻瓜链接协议，但知道RCDS协议，我们的下一步操作是查找RCDS.udp.example.com的SRV RR，它将告诉我们可以提供必要解析服务的主机。该查找可能会返回：

;; Pref Weight Port Targetrcds.udp.example.com IN SRV 0 0 1000 deffoo.example.com.IN SRV 0 0 1000 dbexample.com.au.IN SRV 0 0 1000 ukexample.com.uk.

告诉我们三个实际上可以进行解析的主机，并给我们应该用来与他们的RCDS服务器通信的端口。（读者可参考SRV规范[9]来了解上述字段的解释。）

这里有进行重大优化的机会。RFC 3404定义了附加信息部分可以是可用的。在这种情况下，SRV记录可以作为用于终端NAPTR查找的附加信息（以及用于那些SRV的A记录）而返回。这是一个重要的优化。再加上*.urn.arpa.records的长TTL，解析大多数URI的DNS平均探测数将接近1。

注意，上面的示例NAPTR记录旨在表示使用诸如nslookup之类的一些客户端软件的NAPTR查找的结果；区域管理员应查阅域名服务器附带的文档，以验证区域文件应使用的确切语法。

还要注意的是，可能还有一个额外的第一步，通过查找URN.URI.arpa将URN解析为通用URI。生成的规则将指定从URN中提取NID，并在其后面附加“.un.arpa.”，从而生成新密钥“foo.un.arpa.”，这是上面的第一步。

5.2、 CID URI方案示例

考虑一个基于MIME内容ID的URI方案。URI可能如下所示：

cid:199606121851.1@bar.example.com

（请注意，选择此示例是出于教学目的，不符合CID URI方案。）

解决过程的第一步是了解CID方案。该方案是从URI中提取的，前缀为“.ui.arpa.”，并在DNS中查找“cid.URI.arpa.”的NAPTR。它可能会返回以下表格的记录：

cid.uri.arpa.;; order pref flags service regexp replacementIN NAPTR 100 10 "" "" "!^cid:.+@([^.]+.)(.*)$!2!i" .

由于只有一个记录，因此对响应进行排序不是问题。替换字段为空，因此使用regexp字段中提供的模式。我们将正则表达式应用于整个URI，看看它是否匹配，它确实匹配。替换表达式的2部分返回字符串“example.com”。由于flags字段为空，因此查找不是终端，我们对DNS的下一个探测是查找更多NAPTR记录，其中新域为“example.com’”。

请注意，该规则不会从CID中提取完整的域名，而是假设CID来自主机并提取其域。虽然所有主机，如“bar”，都可以有自己的NAPTR，但维护一个站点上所有机器的这些记录可能是一个无法忍受的负担。这里不适合使用通配符，因为只有当系统中没有完全匹配的名称时，通配符才会返回结果。

从“example.com”上的查询返回的记录可能如下所示：

example.com.;; order pref flags service regexp replacementIN NAPTR 100 50 "s" "z3950+I2L+I2C" "" z3950.tcp.example.com.IN NAPTR 100 50 "s" "rescap+I2C" "" rescap.udp.example.com.IN NAPTR 100 50 "s" "thttp+I2L+I2C+I2R" "" thttp.tcp.example.com.

继续示例，请注意，所有记录的顺序字段的值都是相等的，因此客户端可以自由选择任何记录。应用程序将标志“s”定义为表示终端查找，并且重写的输出将是应查询其SRV记录的域名。一旦客户端完成了这一操作，它就拥有以下信息：主机、端口、协议以及通过该协议可用的服务。给定这些信息，客户端就有足够的信息来联系该服务器，并向其询问有关cid URI的问题。

回想一下，正则表达式使用 2从CID中提取域名，以及.用于匹配文字“.”分隔域名组件的字符。由于“”是转义符，因此反斜杠的文字出现必须由另一个反斜杠转义。对于上面的cid.uri.arpa记录，输入到主文件中的正则表达式应该是“!^cid:.+@([^\.]+\.)(.*)$!\2!i”。当客户端代码实际接收到该记录时，模式将转换为“!^cid:.+@([^.]+.)(.*)$!2!i”。

5.3、 解析HTTP URI方案

即使URN系统现在已经就位，仍然会有大量基于主机的URI。应该可以开发一个URI解析系统，该系统还可以为这些URI提供位置独立性。

假设我们有一个非常流行的软件的URI，发行商希望在世界各地的多个网站上镜像该软件：

http://www.example.com/software/latest-beta.exe

我们提取前缀“http”，并查找“http.ui.arpa.”的NAPTR记录。这可能会返回以下形式的记录：

http.uri.arpa. IN NAPTR;; order pref flags service regexp replacement100 90 "" "" "!^http://([^/:]+)!1!i" .

此表达式返回第一个双斜杠之后、下一个斜杠或冒号之前的所有内容。（我们使用“！”字符来分隔替换表达式的各个部分。否则，我们将不得不使用反斜杠来转义正斜杠，并且在区域文件中会有一个regexp，如下所示：

"/^http:\/\/([^\/:]+)/\1/i").

将此模式应用于URI会提取“www.example.com”。查找其NAPTR记录可能会返回：

www.example.com.;; order pref flags service regexp replacementIN NAPTR 100 100 "s" "thttp+L2R" "" thttp.example.com.IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.example.com.

查找http.example.com的SRV记录将返回example.com指定为其镜像站点的主机的信息。然后客户端可以为用户选择一个。

6、 注意事项

“动态委派发现系统（DDDS）第五部分：uri.arpa分配过程”（RFC 3405[5]）中规定了’urn.arpa.’和’uri.arpa.’DNS区域的注册过程。

如果特定顺序的记录与URI匹配，但客户端不知道指定的协议和服务，则客户端应继续检查具有相同顺序的记录。客户不得考虑顺序价值较高的记录。这对于使名称空间的部分委派起作用是必要的。order字段允许站点管理员说“所有对匹配模式x的URI的请求都将转到服务器1，所有其他请求都将转至服务器2”。

请注意，SRV RR对客户端提出了额外的要求。

7、 IANA注意事项

使用“urn.arpa.”和“uri.arpa.”区域需要遵守注册策略和程序，并维护这些DNS区域的操作。这些策略和过程在“动态委派发现系统（DDDS）第五部分：URI.ARPA分配过程（RFC 3405）”[5]中有详细说明。这些区域的运作使IANA承担了运作和行政责任。

用于“服务”和“标志”字段中的值的注册方法用于由IESG批准并作为信息或标准跟踪RFC发布的规范。

URI的注册策略可在RFC 2717[17]中找到。URN NID注册策略可在RFC 2611[16]中找到。

8、 安全注意事项

使用“urn.arpa.”和“uri.arpa..”作为命名空间的注册表会受到拒绝服务攻击以及其他DNS欺骗攻击。目前正在研究与DNSSEC的相互作用。一旦DNSSEC工作部署完成，预计NAPTR记录将与SIG记录签署。

重写规则使来自其他名称空间的标识符受到与普通域名相同的攻击。由于它们以前不容易解决，这可能被认为是一个问题，也可能不是一个问题。

应该检查正则表达式的健全性，而不是盲目地将其传递给PERL之类的东西。

本文档讨论了定位解析器的方法，但没有讨论如何与解析器进行通信的任何细节。与冲突解决程序的通信附带了重要的安全注意事项。这些注意事项不在本文档的范围内，必须通过特定解析器通信协议的规范来解决。

9、 鸣谢

编辑们要感谢Keith Moore在编写本文件期间提供的所有咨询。我们还要感谢Paul Vixie在调试我们的实现过程中提供的帮助，以及他对我们问题的回答。最后，我们要承认，我们对诺克斯维尔系列会议的参与者以及URI和URN工作组的参与者负有巨大的智力责任。

罗恩·丹尼尔是这些文件原始版本的合著者，他得到了特别的认可。他早期的实现和清晰的思维在清除许多潜在的边界案例方面是非常宝贵的。

10、 参考文献

[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405y, October 2002.[6] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.[7] Arms, B., "The URN Implementors, Uniform Resource Names: A Progress Report", D-Lib Magazine, February 1996.[8] Moats, R., "URN Syntax", RFC 2141, May 1997.[9] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.[10] Daniel, R., "A Trivial Convention for using HTTP in URN Resolution", RFC 2169, June 1997.[11] Mealling, M., "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999.[12] Moore, K., Browne, S., Cox, J. and J. Gettler, "Resource Cataloging and Distribution System", Technical Report CS-97-346, December 1996.[13] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.[14] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.[15] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.[16] Daigle, L., van Gulik, D., Iannella, R. and P. Falstrom, "URN Namespace Definition Mechanisms", RFC 2611, BCP 33, June 1999.[17] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", RFC 2717, BCP 35, November 1999.[18] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, August 2000.

附录A.伪代码

为了启发实现者，下面给出了使用NAPTR的客户端例程的伪代码。提供此代码只是为了方便，它作为处理NAPTR记录的标准方式没有任何分量。此外，与伪代码的情况一样，它从未被执行过，并且可能包含逻辑错误。您已收到警告。

//// findResolver(URN)//给定一个URN，请找到一个可以解析它的主机。//findResolver(string URN) { // prepend prefix to ".urn.arpa." sprintf(key, "%s.urn.arpa.", extractNS(URN)); do {  rewrite_flag = false;  terminal = false;  if (key has been seen) {   quit with a loop detected error  }  add key to list of "seens"  records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'  discard any records with an unknown value in the "flags" field.  sort NAPTR records by "order" field and "preference" field    (with "order" being more significant than "preference").  n_naptrs = number of NAPTR records in response.  curr_order = records[0].order;  max_order = records[n_naptrs-1].order;  //根据“订单”字段处理当前批次的NAPTR。  for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {   if (unknown_flag) //跳过这条记录转到下一条    continue;   newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);   if (!newkey) // Skip to next record if the rewrite didn't    match continue;   //我们确实进行了重写，将max_order缩小到当前值，以便委派正常工作   max_order = naptr[j].order;   //我们知道如何处理NAPTR中指定的协议和服务吗？如果没有，请尝试下一张记录。   if(!isKnownProto(naptr[j].services)) {    continue;   }   if(!isKnownService(naptr[j].services)) {    continue;   }   //在这一点上，我们已经成功地重写了，我们将知道如何使用协议并请求已知的解析服务。在我们进行下一次查找之前，请检查标志以查看是否已完成。   //注意：可以重写此内容，以便将此有效记录记为有效记录，但为了找到“更好”的记录，请继续。但是，该代码将是大量的和具体的应用程序，以便于说明。   if (strcasecmp(flags, "S")    || strcasecmp(flags, "P"))    || strcasecmp(flags, "A")) {     terminal = true;     services = naptr[j].services;     addnl = any SRV and/or A records returned as additional info for naptr[j].   }   key = newkey;   rewriteflag = true;   break;  } } while (rewriteflag && !terminal); //我们没有找到解决方案的方法吗？ if (!rewrite_flag) {  report an error  return NULL; } //剩下的留给另一个协议？ if (strcasecmp(flags, "P")) {  return key as host to talk to; } //如果没有，继续堵塞 if (!addnl) { //没有SRV作为附加信息进入，请查找它们  srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... for each (SRV record) { //按照偏好的顺序，尝试使用协议和来自上一个NAPTR记录的“服务”字段的一个解析服务请求联系srv[j].target。  if (successful)   return (target, protocol, service);   //事实上，我们可能会返回一个结果，但这个代码应该只是告诉我们一个可以与之对话的好主机。  } die with an "unable to find a host" error;}

完整版权声明

版权所有（C）互联网协会（2002）。保留所有权利。

本文件及其译文可复制并提供给他人，对其进行评论或以其他方式解释或协助其实施的衍生作品可全部或部分制作、复制、出版和分发，不受任何形式的限制，前提是上述版权声明和本段包含在所有此类复制品和衍生作品中。然而，本文件本身不得以任何方式进行修改，例如删除版权声明或提及互联网协会或其他互联网组织，除非是为了制定互联网标准而需要，在这种情况下，必须遵守互联网标准流程中定义的版权程序，或者根据需要将其翻译成英语以外的语言。

上述授予的有限权限是永久性的，互联网协会或其继承人或受让人不会撤销。

本文件及其包含的信息以“原样”为基础提供，互联网协会和互联网工程工作组不承担任何明示或暗示的保证，包括但不限于任何保证，即使用本文件中的信息不会侵犯任何权利或对适销性或特定用途适用性的任何暗示保证。

鸣谢

RFC编辑器功能的资金目前由互联网协会提供。