Network Working Group A. Gulbrandsen
Request for Comments: 2782 Troll Technologies
Obsoletes: 2052 P. Vixie
Category: Standards Track Internet Software Consortium
L. Esibov
Microsoft Corp.
February 2000
Network Working Group A. Gulbrandsen
Request for Comments: 2782 Troll Technologies
Obsoletes: 2052 P. Vixie
Category: Standards Track Internet Software Consortium
L. Esibov
Microsoft Corp.
February 2000
A DNS RR for specifying the location of services (DNS SRV)
用于指定服务位置的DNS RR（DNS SRV）
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 DNS RR which specifies the location of the server(s) for a specific protocol and domain.
本文档描述了一个DNS RR，用于指定特定协议和域的服务器位置。
Overview and rationale
概述和理由
Currently, one must either know the exact address of a server to contact it, or broadcast a question.
目前，您必须知道服务器的确切地址才能与之联系，或者广播问题。
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.
SRV RR允许管理员为单个域使用多台服务器，轻松地将服务从主机移动到主机，并将一些主机指定为服务的主服务器，而将其他主机指定为备份。
Clients ask for a specific service/protocol for a specific domain (the word domain is used here in the strict RFC 1034 sense), and get back the names of any available servers.
客户机要求特定域的特定服务/协议（此处使用严格意义上的RFC1034术语“域”），并获取任何可用服务器的名称。
Note that where this document refers to "address records", it means A RR's, AAAA RR's, or their most modern equivalent.
请注意，本文件所指的“地址记录”是指RR、AAAA RR或其最现代的等效文件。
Definitions
定义
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" used in this document are to be interpreted as specified in [BCP 14]. Other terms used in this document are defined in the DNS specification, RFC 1034.
本文件中使用的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[BCP 14]中的规定进行解释。本文档中使用的其他术语在DNS规范RFC 1034中定义。
Applicability Statement
适用性声明
In general, it is expected that SRV records will be used by clients for applications where the relevant protocol specification indicates that clients should use the SRV record. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV records SHOULD NOT be used in the absence of such specification.
一般来说，如果相关协议规范指示客户机应使用SRV记录，则客户机将使用SRV记录。此类规范必须定义要在SRV记录的服务字段中使用的符号名，如下所述。它还必须包括安全考虑。在没有此类规范的情况下，不应使用维修SRV记录。
Introductory example
介绍性示例
If a SRV-cognizant LDAP client wants to discover a LDAP server that supports TCP protocol and provides LDAP service for the domain example.com., it does a lookup of
如果SRV认知LDAP客户端希望发现支持TCP协议并为domain example.com提供LDAP服务的LDAP服务器，它将查找
_ldap._tcp.example.com
_ldap._tcp.example.com
as described in [ARM]. The example zone file near the end of this memo contains answering RRs for an SRV query.
如[ARM]中所述。本备忘录末尾的示例区域文件包含SRV查询的应答RRs。
Note: LDAP is chosen as an example for illustrative purposes only, and the LDAP examples used in this document should not be considered a definitive statement on the recommended way for LDAP to use SRV records. As described in the earlier applicability section, consult the appropriate LDAP documents for the recommended procedures.
注意：选择LDAP作为示例仅用于说明目的，本文档中使用的LDAP示例不应被视为LDAP使用SRV记录的推荐方式的最终声明。如前面的适用性部分所述，请参阅适当的LDAP文档以了解推荐的过程。
The format of the SRV RR
SRV-RR的格式
Here is the format of the SRV RR, whose DNS type code is 33:
以下是SRV RR的格式，其DNS类型代码为33：
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
_服务._Proto.Name TTL Class SRV优先级权重端口目标
(There is an example near the end of this document.)
（本文档末尾有一个示例。）
Service The symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature.
服务所需服务的符号名称，如分配编号[STD 2]或本地所定义。在服务标识符前面加上下划线（41;，以避免与自然界中发生的DNS标签发生冲突。
Some widely used services, notably POP, don't have a single universal name. If Assigned Numbers names the service indicated, that name is the only name which is legal for SRV lookups. The Service is case insensitive.
一些广泛使用的服务，尤其是POP，没有一个通用名称。如果指定的号码为所指示的服务命名，则该名称是SRV查找的唯一合法名称。该服务不区分大小写。
Proto The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive.
Proto所需协议的符号名，前面加下划线（ux），以防止与自然界中发生的DNS标签发生冲突_TCP和_UDP目前是该字段最有用的值，尽管可以使用由指定号码或本地定义的任何名称（如服务）。Proto不区分大小写。
Name The domain this RR refers to. The SRV RR is unique in that the name one searches for is not this name; the example near the end shows this clearly.
命名此RR引用的域。SRV RR是唯一的，因为搜索的名称不是此名称；最后的例子清楚地说明了这一点。
TTL Standard DNS meaning [RFC 1035].
TTL标准DNS含义[RFC 1035]。
Class Standard DNS meaning [RFC 1035]. SRV records occur in the IN Class.
类别标准DNS含义[RFC 1035]。SRV记录出现在课堂上的课堂上。
Priority The priority of this target host. A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16 bit unsigned integer in network byte order.
优先级此目标主机的优先级。客户端必须尝试以其能够达到的最低编号优先级与目标主机联系；应按照权重字段定义的顺序尝试具有相同优先级的目标主机。范围是0-65535。这是网络字节顺序的16位无符号整数。
Weight A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. This is a 16 bit unsigned integer in network byte order. Domain administrators SHOULD use Weight 0 when there isn't any server selection to do, to make the RR easier to read for humans (less noisy). In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected.
加权服务器选择机制。权重字段为具有相同优先级的条目指定相对权重。权重越大，被选中的概率就越高。这个数字的范围是0-65535。这是网络字节顺序的16位无符号整数。当没有任何服务器选择可供选择时，域管理员应使用权重0，以使RR更易于人类阅读（噪音更小）。在存在权重大于0的记录的情况下，权重为0的记录被选中的几率应该很小。
In the absence of a protocol whose specification calls for the use of other weighting information, a client arranges the SRV RRs of the same Priority in the order in which target hosts,
在缺少其规范要求使用其他加权信息的协议的情况下，客户端按照目标主机，
specified by the SRV RRs, will be contacted. The following algorithm SHOULD be used to order the SRV RRs of the same priority:
将联系SRV RRs指定的。应使用以下算法来订购具有相同优先级的SRV RRs：
To select a target to be contacted next, arrange all SRV RRs (that have not been ordered yet) in any order, except that all those with weight 0 are placed at the beginning of the list.
要选择下一步要联系的目标，请按任意顺序排列所有SRV RRs（尚未订购），但所有权重为0的SRV RRs都放在列表的开头。
Compute the sum of the weights of those RRs, and with each RR associate the running sum in the selected order. Then choose a uniform random number between 0 and the sum computed (inclusive), and select the RR whose running sum value is the first in the selected order which is greater than or equal to the random number selected. The target host specified in the selected SRV RR is the next one to be contacted by the client. Remove this SRV RR from the set of the unordered SRV RRs and apply the described algorithm to the unordered SRV RRs to select the next target host. Continue the ordering process until there are no unordered SRV RRs. This process is repeated for each Priority.
计算这些RR的权重之和，并与每个RR按所选顺序关联运行总和。然后在0和计算的总和（包括）之间选择一个统一的随机数，并选择其运行总和值是所选顺序中第一个大于或等于所选随机数的RR。选定SRV RR中指定的目标主机是客户端要联系的下一个主机。从无序SRV RRs集中删除此SRV RR，并将所述算法应用于无序SRV RRs，以选择下一个目标主机。继续订购过程，直到没有未订购的SRV RRs。对每个优先级重复此过程。
Port The port on this target host of this service. The range is 0- 65535. This is a 16 bit unsigned integer in network byte order. This is often as specified in Assigned Numbers but need not be.
端口此服务的目标主机上的端口。范围是0-65535。这是网络字节顺序的16位无符号整数。这通常是在指定的编号中指定的，但不需要指定。
Target The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standards action, name compression is not to be used for this field.
目标主机的域名。此名称必须有一个或多个地址记录，该名称不能是别名（在RFC 1034或RFC 2181的意义上）。敦促实施者（但不要求）在附加数据部分返回地址记录。除非未来标准行动允许，否则名称压缩不得用于此字段。
A Target of "." means that the service is decidedly not available at this domain.
目标为“.”意味着服务在此域中肯定不可用。
Domain administrator advice
域管理员建议
Expecting everyone to update their client applications when the first server publishes a SRV RR is futile (even if desirable). Therefore SRV would have to coexist with address record lookups for existing protocols, and DNS administrators should try to provide address records to support old clients:
期望每个人在第一台服务器发布SRV RR时更新其客户机应用程序是徒劳的（即使是可取的）。因此，SRV必须与现有协议的地址记录查找共存，DNS管理员应尝试提供地址记录以支持旧客户端：
- Where the services for a single domain are spread over several hosts, it seems advisable to have a list of address records at the same DNS node as the SRV RR, listing reasonable (if perhaps
- 如果单个域的服务分布在多个主机上，则建议在与SRV RR相同的DNS节点上有一个地址记录列表，列出合理的（如果可能的话）
suboptimal) fallback hosts for Telnet, NNTP and other protocols likely to be used with this name. Note that some programs only try the first address they get back from e.g. gethostbyname(), and we don't know how widespread this behavior is.
Telnet、NNTP和其他可能使用此名称的协议的次优）回退主机。请注意，有些程序只尝试从gethostbyname（）返回的第一个地址，我们不知道这种行为有多普遍。
- Where one service is provided by several hosts, one can either provide address records for all the hosts (in which case the round-robin mechanism, where available, will share the load equally) or just for one (presumably the fastest).
- 如果一个服务由多个主机提供，则可以为所有主机提供地址记录（在这种情况下，循环机制（如果可用）将平均分担负载），也可以仅为一个主机提供地址记录（可能是最快的）。
- If a host is intended to provide a service only when the main server(s) is/are down, it probably shouldn't be listed in address records.
- 如果主机打算仅在主服务器关闭时提供服务，则可能不应将其列在地址记录中。
- Hosts that are referenced by backup address records must use the port number specified in Assigned Numbers for the service.
- 备份地址记录引用的主机必须使用在为服务分配的编号中指定的端口号。
- Designers of future protocols for which "secondary servers" is not useful (or meaningful) may choose to not use SRV's support for secondary servers. Clients for such protocols may use or ignore SRV RRs with Priority higher than the RR with the lowest Priority for a domain.
- 对于“辅助服务器”没有用处（或意义）的未来协议，设计者可以选择不使用SRV对辅助服务器的支持。此类协议的客户端可以使用或忽略优先级高于域最低优先级的RR的SRV RRs。
Currently there's a practical limit of 512 bytes for DNS replies. Until all resolvers can handle larger responses, domain administrators are strongly advised to keep their SRV replies below 512 bytes.
目前，DNS回复的实际限制为512字节。在所有解析程序都可以处理较大的响应之前，强烈建议域管理员将其SRV响应保持在512字节以下。
All round numbers, wrote Dr. Johnson, are false, and these numbers are very round: A reply packet has a 30-byte overhead plus the name of the service ("_ldap._tcp.example.com" for instance); each SRV RR adds 20 bytes plus the name of the target host; each NS RR in the NS section is 15 bytes plus the name of the name server host; and finally each A RR in the additional data section is 20 bytes or so, and there are A's for each SRV and NS RR mentioned in the answer. This size estimate is extremely crude, but shouldn't underestimate the actual answer size by much. If an answer may be close to the limit, using a DNS query tool (e.g. "dig") to look at the actual answer is a good idea.
约翰逊博士写道，所有的整数都是假的，而且这些数字都是非常圆的：一个应答包有30字节的开销加上服务的名称（例如“ldap.\tcp.example.com”）；每个SRV RR添加20个字节加上目标主机的名称；NS部分中的每个NS RR是15个字节加上名称服务器主机的名称；最后，附加数据部分中的每个A RR大约是20个字节，答案中提到的每个SRV和NS RR都有A。这个大小估计非常粗略，但不应该低估实际答案的大小太多。如果答案可能接近极限，使用DNS查询工具（例如“dig”）查看实际答案是一个好主意。
The "Weight" field
“权重”字段
Weight, the server selection field, is not quite satisfactory, but the actual load on typical servers changes much too quickly to be kept around in DNS caches. It seems to the authors that offering administrators a way to say "this machine is three times as fast as that one" is the best that can practically be done.
服务器选择字段“权重”不是很令人满意，但典型服务器上的实际负载变化太快，无法保留在DNS缓存中。在作者看来，向管理员提供一种方式来表示“这台机器的速度是那台机器的三倍”，这是实际上可以做到的最好的方式。
The only way the authors can see of getting a "better" load figure is asking a separate server when the client selects a server and contacts it. For short-lived services an extra step in the connection establishment seems too expensive, and for long-lived services, the load figure may well be thrown off a minute after the connection is established when someone else starts or finishes a heavy job.
作者能看到的获得“更好”负载数字的唯一方法是在客户端选择服务器并与之联系时询问单独的服务器。对于短命服务，建立连接的额外步骤似乎过于昂贵，而对于长命服务，当其他人开始或完成一项繁重的工作时，在建立连接后一分钟，负载数据可能会被抛出。
Note: There are currently various experiments at providing relative network proximity estimation, available bandwidth estimation, and similar services. Use of the SRV record with such facilities, and in particular the interpretation of the Weight field when these facilities are used, is for further study. Weight is only intended for static, not dynamic, server selection. Using SRV weight for dynamic server selection would require assigning unreasonably short TTLs to the SRV RRs, which would limit the usefulness of the DNS caching mechanism, thus increasing overall network load and decreasing overall reliability. Server selection via SRV is only intended to express static information such as "this server has a faster CPU than that one" or "this server has a much better network connection than that one".
注：目前在提供相对网络接近度估计、可用带宽估计和类似服务方面有各种实验。在此类设施中使用SRV记录，尤其是在使用这些设施时解释重量场，供进一步研究。权重仅用于静态而非动态服务器选择。使用SRV权重进行动态服务器选择需要为SRV RRs分配不合理的短TTL，这将限制DNS缓存机制的可用性，从而增加总体网络负载并降低总体可靠性。通过SRV选择服务器仅用于表示静态信息，如“此服务器的CPU比该服务器快”或“此服务器的网络连接比该服务器好得多”。
The Port number
端口号
Currently, the translation from service name to port number happens at the client, often using a file such as /etc/services.
目前，从服务名称到端口号的转换在客户端进行，通常使用/etc/services等文件。
Moving this information to the DNS makes it less necessary to update these files on every single computer of the net every time a new service is added, and makes it possible to move standard services out of the "root-only" port range on unix.
将此信息移动到DNS可以减少每次添加新服务时在网络的每台计算机上更新这些文件的必要性，并且可以将标准服务移出unix上的“仅根”端口范围。
Usage rules
使用规则
A SRV-cognizant client SHOULD use this procedure to locate a list of servers and connect to the preferred one:
认知SRV的客户应使用此过程定位服务器列表并连接到首选服务器：
Do a lookup for QNAME=_service._protocol.target, QCLASS=IN, QTYPE=SRV.
查找QNAME=_服务。_protocol.target，QCLASS=IN，QTYPE=SRV。
If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV RR which specifies the requested Service and Protocol in the reply:
如果回复为NOERROR，ANCOUNT>0，并且至少有一个SRV RR在回复中指定请求的服务和协议：
If there is precisely one SRV RR, and its Target is "." (the root domain), abort.
如果正好有一个SRV RR，且其目标为“.”（根域），则中止。
Else, for all such RR's, build a list of (Priority, Weight, Target) tuples
否则，对于所有这样的RR，构建一个（优先级、权重、目标）元组列表
Sort the list by priority (lowest number first)
按优先级对列表排序（首先是最低的数字）
Create a new empty list
创建一个新的空列表
For each distinct priority level While there are still elements left at this priority level
对于每个不同的优先级，同时仍有元素保留在此优先级
Select an element as specified above, in the description of Weight in "The format of the SRV RR" Section, and move it to the tail of the new list
在“SRV RR格式”部分的“权重描述”中，选择上面指定的元素，并将其移动到新列表的尾部
For each element in the new list
对于新列表中的每个元素
query the DNS for address records for the Target or use any such records found in the Additional Data section of the earlier SRV response.
在DNS中查询目标的地址记录，或使用在先前SRV响应的附加数据部分中找到的任何此类记录。
for each address record found, try to connect to the (protocol, address, service).
对于找到的每个地址记录，请尝试连接到（协议、地址、服务）。
else
其他的
Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
for each address record found, try to connect to the (protocol, address, service)
对于找到的每个地址记录，尝试连接到（协议、地址、服务）
Notes:
笔记：
- Port numbers SHOULD NOT be used in place of the symbolic service or protocol names (for the same reason why variant names cannot be allowed: Applications would have to do two or more lookups).
- 不应使用端口号代替符号服务或协议名称（原因与不允许使用变体名称的原因相同：应用程序必须进行两次或多次查找）。
- If a truncated response comes back from an SRV query, the rules described in [RFC 2181] shall apply.
- 如果从SRV查询返回被截断的响应，[RFC 2181]中描述的规则应适用。
- A client MUST parse all of the RR's in the reply.
- 客户端必须解析回复中的所有RR。
- If the Additional Data section doesn't contain address records for all the SRV RR's and the client may want to connect to the target host(s) involved, the client MUST look up the address record(s). (This happens quite often when the address record has shorter TTL than the SRV or NS RR's.)
- 如果附加数据部分不包含所有SRV RR的地址记录，并且客户端可能希望连接到所涉及的目标主机，则客户端必须查找地址记录。（当地址记录的TTL比SRV或NS RR短时，这种情况经常发生。）
- Future protocols could be designed to use SRV RR lookups as the means by which clients locate their servers.
- 未来的协议可以设计为使用SRV RR查找作为客户端定位其服务器的手段。
Fictional example
虚构的例子
This example uses fictional service "foobar" as an aid in understanding SRV records. If ever service "foobar" is implemented, it is not intended that it will necessarily use SRV records. This is (part of) the zone file for example.com, a still-unused domain:
这个例子使用虚构的服务“foobar”来帮助理解SRV记录。如果实现了服务“foobar”，则并不意味着它必须使用SRV记录。这是区域文件example.com的一部分，它是一个尚未使用的域：
$ORIGIN example.com.
@ SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400 )
NS server.example.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
; foobar - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_foobar._tcp SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin's box and the server
SRV 1 0 9 sysadmins-box.example.com.
SRV 1 0 9 server.example.com.
server A 172.30.79.10
old-slow-box A 172.30.79.11
sysadmins-box A 172.30.79.12
new-fast-box A 172.30.79.13
; NO other services are supported
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
$ORIGIN example.com.
@ SOA server.example.com. root.example.com. (
1995032001 3600 3600 604800 86400 )
NS server.example.com.
NS ns1.ip-provider.net.
NS ns2.ip-provider.net.
; foobar - use old-slow-box or new-fast-box if either is
; available, make three quarters of the logins go to
; new-fast-box.
_foobar._tcp SRV 0 1 9 old-slow-box.example.com.
SRV 0 3 9 new-fast-box.example.com.
; if neither old-slow-box or new-fast-box is up, switch to
; using the sysdmin's box and the server
SRV 1 0 9 sysadmins-box.example.com.
SRV 1 0 9 server.example.com.
server A 172.30.79.10
old-slow-box A 172.30.79.11
sysadmins-box A 172.30.79.12
new-fast-box A 172.30.79.13
; NO other services are supported
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
In this example, a client of the "foobar" service in the "example.com." domain needs an SRV lookup of "_foobar._tcp.example.com." and possibly A lookups of "new-fast-box.example.com." and/or the other hosts named. The size of the SRV reply is approximately 365 bytes:
在本例中，“example.com.”域中“foobar”服务的客户端需要SRV查找“\u foobar.\u tcp.example.com.”，可能还需要查找“new fast box.example.com.”和/或指定的其他主机。SRV回复的大小约为365字节：
30 bytes general overhead 20 bytes for the query string, "_foobar._tcp.example.com." 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-fast-box", "old-slow-box", "server" and "sysadmins-box" - "example.com" in the query section is quoted here and doesn't need to be counted again. 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server", "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is quoted and only needs to be counted once. 120 bytes for the 6 address records (assuming IPv4 only) mentioned by the SRV and NS RR's.
30字节一般开销20字节用于查询字符串“\u foobar.\u tcp.example.com”。130字节用于4个SRV RR，每个20字节加上查询部分中“新快速框”、“旧慢速框”、“服务器”和“系统管理员框”-“example.com”的长度在此处引用，无需再次计数。对于3 NS RRs，75个字节，每个15个字节加上“server”、“ns1.ip provider.net.”和“ns2”的长度，再次引用“ip provider.net.”，只需计算一次。SRV和NS RR提及的6个地址记录（假设仅IPv4）的120字节。
IANA Considerations
IANA考虑
The IANA has assigned RR type value 33 to the SRV RR. No other IANA services are required by this document.
IANA已将RR类型值33分配给SRV RR。本文件不需要其他IANA服务。
Changes from RFC 2052
RFC 2052的变更
This document obsoletes RFC 2052. The major change from that previous, experimental, version of this specification is that now the protocol and service labels are prepended with an underscore, to lower the probability of an accidental clash with a similar name used for unrelated purposes. Aside from that, changes are only intended to increase the clarity and completeness of the document. This document especially clarifies the use of the Weight field of the SRV records.
本文件废除了RFC 2052。与此规范以前的实验版本相比，主要的变化是，现在协议和服务标签前面加了下划线，以降低与用于不相关目的的类似名称发生意外冲突的可能性。除此之外，更改仅旨在提高文件的清晰度和完整性。本文件特别说明了SRV记录的重量字段的使用。
Security Considerations
安全考虑
The authors believe this RR to not cause any new security problems. Some problems become more visible, though.
作者相信这种RR不会引起任何新的安全问题。不过，一些问题变得更加明显。
- The ability to specify ports on a fine-grained basis obviously changes how a router can filter packets. It becomes impossible to block internal clients from accessing specific external services, slightly harder to block internal users from running unauthorized services, and more important for the router operations and DNS operations personnel to cooperate.
- 在细粒度基础上指定端口的能力显然改变了路由器过滤数据包的方式。阻止内部客户端访问特定的外部服务变得不可能，阻止内部用户运行未经授权的服务变得更加困难，更重要的是路由器操作和DNS操作人员的合作。
- There is no way a site can keep its hosts from being referenced as servers. This could lead to denial of service.
- 站点无法阻止其主机被引用为服务器。这可能导致拒绝服务。
- With SRV, DNS spoofers can supply false port numbers, as well as host names and addresses. Because this vulnerability exists already, with names and addresses, this is not a new vulnerability, merely a slightly extended one, with little practical effect.
- 使用SRV，DNS欺骗者可以提供错误的端口号以及主机名和地址。由于此漏洞已经存在，并且具有名称和地址，因此这不是一个新的漏洞，只是一个稍微扩展的漏洞，几乎没有实际效果。
References
工具书类
STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
标准2:Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
RFC 1034:Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
RFC 1035: Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, November 1987.
RFC 1035:Mockapetris，P.，“域名-实现和规范”，标准13，RFC 1035，1987年11月。
RFC 974: Partridge, C., "Mail routing and the domain system", STD 14, RFC 974, January 1986.
RFC 974:Partridge，C.，“邮件路由和域系统”，STD 14，RFC 974，1986年1月。
BCP 14: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
BCP 14:Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
RFC 2181:Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，1997年7月。
RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997.
RFC 2219:Hamilton，M.和R.Wright，“网络服务中DNS别名的使用”，BCP 17，RFC 2219，1997年10月。
BCP 14: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
BCP 14:Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP Services with DNS", Work in Progress.
ARM:Armijo，M.，Esibov，L.和P.Leach，“使用DNS发现LDAP服务”，工作正在进行中。
KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and Realm Information with DNS", Work in Progress.
KDC-DNS:Hornstein，K.和J.Altman，“使用DNS分发Kerberos KDC和领域信息”，工作正在进行中。
Acknowledgements
致谢
The algorithm used to select from the weighted SRV RRs of equal priority is adapted from one supplied by Dan Bernstein.
用于从同等优先级的加权SRV RRs中进行选择的算法采用Dan Bernstein提供的算法。
Authors' Addresses
作者地址
Arnt Gulbrandsen Troll Tech Waldemar Thranes gate 98B N-0175 Oslo, Norway
Arnt Gulbrandsen Troll Tech Waldemar Thranes 98B门N-0175挪威奥斯陆
Fax: +47 22806380
Phone: +47 22806390
EMail: arnt@troll.no
Fax: +47 22806380
Phone: +47 22806390
EMail: arnt@troll.no
Paul Vixie Internet Software Consortium 950 Charter Street Redwood City, CA 94063
Paul Vixie互联网软件联合体950 Charter Street Redwood City，加利福尼亚州94063
Phone: +1 650 779 7001
电话：+16507797001
Levon Esibov Microsoft Corporation One Microsoft Way Redmond, WA 98052
Levon Esibov微软公司华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: levone@microsoft.com
EMail: levone@microsoft.com
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编辑功能的资金目前由互联网协会提供。