A DNS RR for specifying the location of services (DNS SRV)
RFC 2782
Document | Type |
RFC - Proposed Standard
(February 2000; No errata)
Obsoletes RFC 2052
|
|
---|---|---|---|
Authors | Arnt Gulbrandsen , Levon Esibov | ||
Last updated | 2020-07-29 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2782 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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) 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. 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. 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. Note that where this document refers to "address records", it means A RR's, AAAA RR's, or their most modern equivalent. Gulbrandsen, et al. Standards Track [Page 1] RFC 2782 DNS SRV RR February 2000 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. 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. 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 _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. 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. The format of the SRV RR Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target (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. Gulbrandsen, et al. Standards Track [Page 2] RFC 2782 DNS SRV RR February 2000 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. 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. 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. TTL Standard DNS meaning [RFC 1035]. Class Standard DNS meaning [RFC 1035]. SRV records occur in the IN Class.Show full document text