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 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).
AbstractRemote 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. 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. 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
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). 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. 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. 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. RFC2119]. RFC2782], the DNS SRV RRs for SLP DA services are defined as follows: _slpda._Proto.Name TTL Class SRV Priority Weight Port Target 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.
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: ;; 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 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.
RFC 2782. (3) U queries X in the "default" scope to discover desired services in D. Note that the services discovered in the above steps may not necessarily be remotely accessible. 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.
RFC 2608. In addition, implementations supporting this specification MAY use DNS SRV to discover local DAs in the "default" scope. 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. Note that the services discovered via DNS SRV and remote SLP DAs may not necessarily be remotely accessible. [RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2 ", RFC 2608, June 1999. [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
Dr. Chatschik Bisdikian IBM T. J. Watson Research Center 30 Saw Mill River Road, M/S 3S-B34 Hawthorne, NY 10532, USA Phone: +1 914 784 7439 Fax: +1 914 784 6225 EMail: email@example.com William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA EMail: firstname.lastname@example.org
BCP 78, and except as set forth therein, the authors retain all their rights. 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. 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. 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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.