Network Working Group W. Zhao
Request for Comments: 3832 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
C. Bisdikian
W. Jerome
IBM
July 2004
Network Working Group W. Zhao
Request for Comments: 3832 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
C. Bisdikian
W. Jerome
IBM
July 2004
Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV
通过DNS SRV在服务位置协议（SLP）中进行远程服务发现
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains.
远程服务发现是指在给定的远程（即非本地）DNS域中发现所需的服务。本文档描述了通过DNS SRV在服务位置协议（SLP）中进行的远程服务发现。它定义了SLP目录代理服务的DNS SRV资源记录，讨论了将SLP和DNS SRV一起用于远程服务发现的各种问题，并给出了在远程DNS域中发现所需服务的步骤。
This document describes remote service discovery in the Service Location Protocol (SLP) [RFC2608] via DNS SRV [RFC2782]. We consider remote service discovery as discovering desired services in given remote DNS domains, and local service discovery as discovering desired services within the local administrative domain.
本文档描述了通过DNS SRV[RFC2782]在服务位置协议（SLP）[RFC2608]中进行的远程服务发现。我们认为远程服务发现在给定的远程DNS域中发现期望的服务，并且本地服务发现在本地管理域内发现期望的服务。
SLP provides a scalable framework for local service discovery and selection. In SLP, User Agents (UAs) discover desired services in the local administrative domain by querying all Service Agents (SAs) via multicast or querying a Directory Agent (DA) via unicast. To
SLP为本地服务发现和选择提供了一个可扩展的框架。在SLP中，用户代理（UAs）通过多播查询所有服务代理（SA）或通过单播查询目录代理（DA），在本地管理域中发现所需的服务。到
query a DA using unicast, a UA needs to first learn about the DA via DHCP, static configuration or multicast (listening for DAAdvert multicast or issuing DA discovery SrvRqst multicast).
使用单播查询DA，UA需要首先通过DHCP、静态配置或多播（侦听DAAD多播或发出DA发现SrvRqst多播）了解DA。
DNS SRV provides good support for remote service discovery. However, if multiple servers are discovered via DNS SRV for a service, only priority and weight can be used to make a selection. If additional service properties (such as cost, speed and service quality) need to be considered in the selection process, DNS SRV becomes insufficient.
DNS SRV为远程服务发现提供了良好的支持。但是，如果通过DNS SRV发现一个服务的多个服务器，则只能使用优先级和权重进行选择。如果在选择过程中需要考虑其他服务属性（如成本、速度和服务质量），则DNS SRV将不足。
We propose that using SLP and DNS SRV together can provide better support for remote service discovery. First, a UA uses DNS SRV to find SLP DAs at a remote DNS domain. Then, the UA uses SLP to query one of those DAs to discover desired services. In this way, we can avoid the limitations in using SLP and DNS SRV separately. On one hand, without DNS SRV, an SLP UA needs to depend on static configuration to learn about remote DAs because DHCP and multicast DA discovery are not generally applicable beyond the local administrative domain. On the other hand, without SLP, DNS SRV has limited support for service selection.
我们建议结合使用SLP和DNS SRV可以为远程服务发现提供更好的支持。首先，UA使用DNS SRV在远程DNS域中查找SLP DAs。然后，UA使用SLP查询其中一个DAs以发现所需的服务。这样，我们可以避免单独使用SLP和DNS SRV的限制。一方面，如果没有DNS SRV，SLP UA需要依靠静态配置来了解远程DAs，因为DHCP和多播DA发现通常不适用于本地管理域之外。另一方面，没有SLP，DNS SRV对服务选择的支持有限。
In this document, we first define the DNS SRV Resource Records (RRs) for SLP DA services, which are used to map a given DNS domain to remotely accessible (i.e., accessible from the Internet) DAs in that domain. Then, we discuss various issues in using SLP and DNS SRV together for remote service discovery. Finally, we give the steps for discovering services in remote DNS domains.
在本文档中，我们首先为SLP DA服务定义DNS SRV资源记录（RRs），用于将给定DNS域映射到该域中的远程可访问（即，可从Internet访问）DAs。然后，我们讨论了同时使用SLP和DNS SRV进行远程服务发现的各种问题。最后，我们给出了在远程DNS域中发现服务的步骤。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
According to RFC 2782 [RFC2782], the DNS SRV RRs for SLP DA services are defined as follows:
根据RFC 2782[RFC2782]，SLP DA服务的DNS SRV RRs定义如下：
_slpda._Proto.Name TTL Class SRV Priority Weight Port Target
_slpda._Proto.Name TTL Class SRV优先级权重端口目标
where "slpda" is the symbolic name for SLP DA services, the Proto field is either "tcp" or "udp", and the Target field is the domain name of an SLP DA. Please refer to [RFC2782] for detailed explanation of each field in DNS SRV RRs.
其中“slpda”是SLP DA服务的符号名，Proto字段为“tcp”或“udp”，目标字段为SLP DA的域名。有关DNS SRV RRs中每个字段的详细说明，请参阅[RFC2782]。
Next we show an example of using DNS SRV RRs to map a given DNS domain to remotely accessible DAs in that domain. To discover remotely accessible DAs in a remote domain (say, example.com), a UA makes a DNS query [RFC1034,RFC1035] for QNAME=_slpda._tcp.example.com (or QNAME=_slpda._udp.example.com), QCLASS=IN, and QTYPE=SRV. Then the UA will receive a list of DNS SRV RRs in a DNS reply, which gives all remotely accessible DAs in the domain example.com, such as:
接下来，我们将展示一个使用DNS SRV RRs将给定DNS域映射到该域中可远程访问的DAs的示例。为了在远程域（例如example.com）中发现远程可访问的DAs，UA对QNAME=\u slpda.\u tcp.example.com（或QNAME=\u slpda.\u udp.example.com）、QCLASS=in和QTYPE=SRV进行DNS查询[RFC1034，RFC1035]。然后UA将在DNS回复中收到DNS SRV RRs列表，该列表给出域example.com中所有可远程访问的DAs，例如：
;; Priority Weight Port Target _slpda._tcp.example.com IN SRV 0 0 427 da1.example.com _slpda._tcp.example.com IN SRV 0 0 427 da2.example.com
;; SRV 0 0 427 da1.example.com中的优先级权重端口目标_slpda._tcp.example.com _slpda._tcp.example.com在SRV 0 0 427 da2.example.com中
SLP DAs can be discovered in two ways: (1) using the mechanisms described in RFC 2608, and (2) using DNS SRV RRs as described in this document. The second approach is useful for UAs to acquire service information for remote DNS domains. For example, a mobile node visiting a network (without the use of mobile IP) may want to obtain information about services in its home network.
可以通过两种方式发现SLP DAs：（1）使用RFC 2608中描述的机制，（2）使用本文档中描述的DNS SRV RRs。第二种方法对于UAs获取远程DNS域的服务信息非常有用。例如，访问网络（不使用移动IP）的移动节点可能想要获取关于其家庭网络中的服务的信息。
Using DNS SRV RRs to discover SLP DAs requires knowledge of the domain where SLP DAs are registered. For remote service discovery, it is assumed that the DNS domain of interest is known via a priori knowledge. For example, a UA is configured with a domain name or the user provides the domain name manually.
使用DNS SRV RRs发现SLP DAs需要了解SLP DAs注册的域。对于远程服务发现，假定感兴趣的DNS域通过先验知识已知。例如，UA配置有域名，或者用户手动提供域名。
Note that there is no implied "search order" of DNS domains in finding remote DAs. For instance, if a UA is looking for remote DAs in the domain foo.bar.example.com, it SHOULD only look for _slp._tcp.foo.bar.example.com (or _slp._udp.foo.bar.example.com), and MUST NOT fall back to look for _slp._tcp.bar.example.com, _slp._tcp.example.com, and so on.
请注意，在查找远程DAs时，没有暗示DNS域的“搜索顺序”。例如，如果UA在域foo.bar.example.com中查找远程DAs，它应该只查找_slp._tcp.foo.bar.example.com（或_slp._udp.foo.bar.example.com），而不能回头查找_slp._tcp.bar.example.com、_slp._tcp.example.com等等。
A UA discovers desired services in a given remote DNS domain by unicasting requests to DAs in that domain. The UA uses remote DAs according to these prioritized rules: (1) using DAs which it has been configured with, and (2) using DAs which it has discovered via DNS SRV.
UA通过向给定远程DNS域中的DAs单播请求，在该域中发现所需的服务。UA根据这些优先级规则使用远程DAs：（1）使用已配置的DAs，以及（2）使用通过DNS SRV发现的DAs。
As SLP scopes are intended to be used only within one administrative domain, they are likely incomprehensible to users outside of the administrative domain. Thus, any remotely accessible service MUST be registered in the "default" scope, but it MAY be registered in other scopes at the same time. Similarly, all DAs advertised via DNS SRV MUST serve the "default" scope, but they MAY serve other scopes at the same time. As a result, users wishing to discover services at a remote DNS domain SHOULD only search the "default" scope.
由于SLP作用域旨在仅在一个管理域内使用，因此管理域之外的用户可能无法理解它们。因此，任何远程可访问的服务都必须在“默认”范围内注册，但也可以同时在其他范围内注册。类似地，通过DNS SRV发布的所有DAs必须服务于“默认”作用域，但它们可以同时服务于其他作用域。因此，希望在远程DNS域中发现服务的用户应该只搜索“默认”范围。
The steps for a User Agent U to discover desired services in a remote DNS domain D are as follows.
用户代理U在远程DNS域D中发现所需服务的步骤如下。
(1) U makes a DNS query for QNAME=_slpda._tcp.D (or QNAME=_slpda._udp.D), QCLASS=IN, and QTYPE=SRV. Then, U gets a list of DNS SRV RRs (referred to as L) in a DNS reply, which gives all remotely accessible DAs in D.
(1) U对QNAME=\U slpda.\U tcp.D（或QNAME=\U slpda.\U udp.D）、QCLASS=IN和QTYPE=SRV进行DNS查询。然后，U在DNS应答中获得DNS SRV rr（称为L）的列表，该列表给出了D中所有远程可访问的DAs。
(2) U selects a DA X from L based on the priority and weight information per RFC 2782.
(2) U根据RFC 2782的优先级和权重信息从L中选择DA X。
(3) U queries X in the "default" scope to discover desired services in D.
(3) U在“默认”范围内查询X，以发现D中所需的服务。
Note that the services discovered in the above steps may not necessarily be remotely accessible.
请注意，在上述步骤中发现的服务不一定可以远程访问。
To support remote service discovery, a domain exposes its service information to the Internet. Standard SLP authentication SHOULD be used to protect valuable service information. First, there is a risk that any SA could advertise any service on a DA accessible from the Internet. Such a DA SHOULD reject all registrations and deregistrations that cannot be authenticated. Secondly, to avoid disclosing unintended service information to remote users, a DA accessible from the Internet SHOULD at least authenticate service queries that are not in the "default" scope. In addition, the security considerations for DNS SRV [RFC2782] apply to this document. Also, the DNS security extensions [RFC 2535] SHOULD be used to provide origin authentication and integrity protection for DNS data.
为了支持远程服务发现，域向Internet公开其服务信息。应使用标准SLP身份验证来保护有价值的服务信息。首先，任何SA都有可能在可从互联网访问的DA上宣传任何服务。此类DA应拒绝所有无法认证的注册和注销。其次，为了避免向远程用户透露非预期的服务信息，可从Internet访问的DA应至少对不在“默认”范围内的服务查询进行身份验证。此外，DNS SRV[RFC2782]的安全注意事项适用于本文档。此外，DNS安全扩展[RFC 2535]应用于为DNS数据提供源身份验证和完整性保护。
This specification describes remote service discovery in SLP via DNS SRV. It facilitates discovering services at a remote DNS domain if the domain name is known via a priori knowledge. However, it does not intend to solve the problem of Internet-wide service discovery.
本规范描述了通过DNS SRV在SLP中进行远程服务发现。如果通过先验知识知道域名，则有助于在远程DNS域中发现服务。然而，它并不打算解决Internet范围内的服务发现问题。
Users should be aware of two constraints in using DNS SRV to discover SLP DAs: (1) they SHOULD only use DNS SRV to discover DAs in the "default" scope, and (2) an administrator may choose to register only a subset of all DAs in the "default" scope via DNS SRV. Thus, to discover local DAs, implementations MUST use the standard SLP mechanisms per RFC 2608. In addition, implementations supporting this specification MAY use DNS SRV to discover local DAs in the "default" scope.
用户在使用DNS SRV发现SLP DAs时应注意两个限制：（1）他们应仅使用DNS SRV发现“默认”范围内的DAs，以及（2）管理员可选择通过DNS SRV仅注册“默认”范围内所有DAs的子集。因此，为了发现本地DAs，实现必须按照RFC2608使用标准SLP机制。此外，支持此规范的实现可以使用DNS SRV来发现“默认”范围内的本地DAs。
As SLP scopes are not intended to be used outside the local administrative domain, all remote service discovery in SLP SHOULD be carried only in the "default" scope.
由于SLP作用域不打算在本地管理域之外使用，因此SLP中的所有远程服务发现应仅在“默认”作用域中进行。
Note that the services discovered via DNS SRV and remote SLP DAs may not necessarily be remotely accessible.
请注意，通过DNS SRV和远程SLP DAs发现的服务不一定可以远程访问。
In the DNS SRV RRs for SLP DA services, the symbolic name for the Service field is "slpda", supported protocols are "tcp" and "udp". The following values have been registered with IANA:
在SLP DA服务的DNS SRV RRs中，服务字段的符号名称为“slpda”，支持的协议为“tcp”和“udp”。以下值已在IANA注册：
Service Field Protocol Field Reference
------------- -------------- ---------
slpda tcp [RFC3832]
slpda udp [RFC3832]
Service Field Protocol Field Reference
------------- -------------- ---------
slpda tcp [RFC3832]
slpda udp [RFC3832]
The authors would like to thank Bernard Aboba, Kevin Arnold, Steven Bellovin, Ted Hardie, James Kempf, Thomas Narten, Erik Nordmark, and Jon Peterson for their valuable comments.
作者要感谢伯纳德·阿博巴、凯文·阿诺德、史蒂文·贝洛文、特德·哈迪、詹姆斯·坎普夫、托马斯·纳滕、埃里克·诺德马克和乔恩·彼得森的宝贵评论。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2 ", RFC 2608, June 1999.
[RFC2608]Guttman，E.，Perkins，C.，Veizades，J.和M.Day，“服务位置协议，版本2”，RFC 26081999年6月。
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake 3rd，D.，“域名系统安全扩展”，RFC 25351999年3月。
Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
赵伟斌哥伦比亚大学计算机科学系，地址：纽约州纽约市阿姆斯特丹大道1214号，邮编：0401，邮编：10027-7003
EMail: zwb@cs.columbia.edu
EMail: zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
Henning Schulzrinne哥伦比亚大学计算机科学系，地址：纽约州纽约市阿姆斯特丹大道1214号，邮编：0401，邮编：10027-7003
EMail: hgs@cs.columbia.edu
EMail: hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
埃里克·古特曼太阳微系统公司。74915德国威伯斯塔特
EMail: Erik.Guttman@sun.com
EMail: Erik.Guttman@sun.com
Dr. Chatschik Bisdikian IBM T. J. Watson Research Center 30 Saw Mill River Road, M/S 3S-B34 Hawthorne, NY 10532, USA
Chatschik Bisdikian博士IBM T.J.Watson研究中心美国纽约州霍桑市锯木勒河路30号M/S 3S-B34
Phone: +1 914 784 7439
Fax: +1 914 784 6225
EMail: bisdik@us.ibm.com
Phone: +1 914 784 7439
Fax: +1 914 784 6225
EMail: bisdik@us.ibm.com
William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA
William F.Jerome IBM Corp.Thomas J.Watson研究中心美国纽约州霍桑市天际大道19号，邮编10532
EMail: wfj@us.ibm.com
EMail: wfj@us.ibm.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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编辑功能的资金目前由互联网协会提供。