RFC 2782 (rfc2782) - Page 2 of 12

A DNS RR for specifying the location of services (DNS SRV)

Alternative Format: Original Text Document
< Previous
Next >
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
< Previous
Next >