[要約] RFC 3832は、Service Location Protocol（SLP）を介したDNS SRVを使用したリモートサービスの検出に関するものであり、その目的は、ネットワーク上のサービスを自動的に検出し、利用可能なサービスのリストを提供することです。
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）The Internet Society（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 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).
SLPは、ローカルサービスの発見と選択のためのスケーラブルなフレームワークを提供します。SLPでは、ユーザーエージェント（UAS）は、マルチキャストを介してすべてのサービスエージェント（SAS）をクエリするか、ユニキャストを介してディレクトリエージェント（DA）をクエリすることにより、ローカル管理ドメインで望ましいサービスを発見します。ユニキャストを使用してDAを照会するには、UAは最初にDHCP、静的構成、またはマルチキャストを介してDAについて学習する必要があります（DaAdvertマルチキャストのリスニング、またはDA Discovery SRVRQSTマルチキャストの発行）。
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を使用してそれらのDAの1つを照会して、目的のサービスを発見します。このようにして、SLPとDNS SRVを個別に使用することの制限を回避できます。一方では、DNS SRVがなければ、SLP UAは、DHCPとマルチキャストDA発見が一般にローカル管理ドメインを超えて適用されないため、リモートDASについて学習するための静的構成に依存する必要があります。一方、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ドメインをリモートにアクセスできる（つまり、インターネットからアクセス可能）そのドメインの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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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クラス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 = _SLPDA._TCP.EXAMPLE.com（またはQNAME = _SLPDA._UDP.EXAMPLE.com）のDNSクエリ[RFC1034、RFC1035]を作成します。、qclass = in、およびqtype = srv。次に、UAはDNS応答でDNS SRV RRSのリストを受け取ります。
;; 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
;;優先ウェイトポートターゲット_slpda._tcp.example.com in srv 0 0 427 da1.example.com _slpda._tcp.example.com in 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を使用して、2つの方法で発見できます。2番目のアプローチは、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 DAが登録されているドメインの知識が必要です。リモートサービスの発見の場合、関心のある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でリモートDAを探している場合、_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は、そのドメイン内のDASへのリクエストをユニカストすることにより、特定のリモートDNSドメインで望ましいサービスを発見します。UAは、これらの優先順位付けされたルールに従ってリモートDAを使用します。（1）構成されたDASを使用し、（2）DNS SRVを介して発見したDAを使用します。
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スコープは1つの管理ドメイン内でのみ使用することを目的としているため、管理ドメイン以外のユーザーにとっては理解できない可能性があります。したがって、リモートでアクセス可能なサービスは「デフォルト」スコープに登録する必要がありますが、他のスコープに同時に登録される場合があります。同様に、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 = _slpda._tcp.d（またはqname = _slpda._udp.d）、qclass = in、およびqtype = srvのdnsクエリを作成します。次に、uはDNS応答でDNS SRV RRS（Lと呼ばれる）のリストを取得します。
(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 xがDで望ましいサービスを発見するためにXをクエリします
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.
リモートサービスの発見をサポートするために、ドメインはそのサービス情報をインターネットに公開します。標準のSLP認証は、貴重なサービス情報を保護するために使用する必要があります。まず、SAがインターネットからアクセス可能なDAでサービスを宣伝できるリスクがあります。このようなDAは、認証できないすべての登録と登録廃止を拒否する必要があります。第二に、意図しないサービス情報をリモートユーザーに開示しないようにするために、インターネットからアクセスできる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ドメインでサービスの発見を容易にします。ただし、インターネット全体のサービス発見の問題を解決するつもりはありません。
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を発見する際の2つの制約に注意する必要があります。（1）DNS SRVのみを使用して「デフォルト」範囲でDASを発見する必要があります。DNS SRVを介した「デフォルト」スコープのDAS。したがって、ローカルDASを発見するには、実装はRFC 2608ごとに標準のSLPメカニズムを使用する必要があります。さらに、この仕様をサポートする実装では、DNS SRVを使用して「デフォルト」範囲でローカルDAを発見する場合があります。
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]
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.
著者は、Bernard Aboba、Kevin Arnold、Steven Bellovin、Ted Hardie、James Kempf、Thomas Narten、Erik Nordmark、Jon Petersonに貴重なコメントに感謝したいと思います。
[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。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年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。and 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 2535、1999年3月。
Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
ワイビンZhaoコンピュータサイエンスコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027-7003
EMail: zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
ヘニングシュルツリンコンピュータサイエンスコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027-7003
EMail: hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
Erik Guttman Sun Microsystems Eichhoelzelstr。7 74915 Waibstadtドイツ
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
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
ウィリアムF.ジェロームIBM Corp.トーマスJ.ワトソンリサーチセンター19スカイラインドライブホーソーン、ニューヨーク10532、米国
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。