676 lines
24 KiB
Plaintext
676 lines
24 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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.
|
||
|
||
Priority
|
||
The priority of this target host. A client MUST attempt to
|
||
contact the target host with the lowest-numbered priority it can
|
||
reach; target hosts with the same priority SHOULD be tried in an
|
||
order defined by the weight field. The range is 0-65535. This
|
||
is a 16 bit unsigned integer in network byte order.
|
||
|
||
Weight
|
||
A server selection mechanism. The weight field specifies a
|
||
relative weight for entries with the same priority. Larger
|
||
weights SHOULD be given a proportionately higher probability of
|
||
being selected. The range of this number is 0-65535. This is a
|
||
16 bit unsigned integer in network byte order. Domain
|
||
administrators SHOULD use Weight 0 when there isn't any server
|
||
selection to do, to make the RR easier to read for humans (less
|
||
noisy). In the presence of records containing weights greater
|
||
than 0, records with weight 0 should have a very small chance of
|
||
being selected.
|
||
|
||
In the absence of a protocol whose specification calls for the
|
||
use of other weighting information, a client arranges the SRV
|
||
RRs of the same Priority in the order in which target hosts,
|
||
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 3]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
specified by the SRV RRs, will be contacted. The following
|
||
algorithm SHOULD be used to order the SRV RRs of the same
|
||
priority:
|
||
|
||
To select a target to be contacted next, arrange all SRV RRs
|
||
(that have not been ordered yet) in any order, except that all
|
||
those with weight 0 are placed at the beginning of the list.
|
||
|
||
Compute the sum of the weights of those RRs, and with each RR
|
||
associate the running sum in the selected order. Then choose a
|
||
uniform random number between 0 and the sum computed
|
||
(inclusive), and select the RR whose running sum value is the
|
||
first in the selected order which is greater than or equal to
|
||
the random number selected. The target host specified in the
|
||
selected SRV RR is the next one to be contacted by the client.
|
||
Remove this SRV RR from the set of the unordered SRV RRs and
|
||
apply the described algorithm to the unordered SRV RRs to select
|
||
the next target host. Continue the ordering process until there
|
||
are no unordered SRV RRs. This process is repeated for each
|
||
Priority.
|
||
|
||
Port
|
||
The port on this target host of this service. The range is 0-
|
||
65535. This is a 16 bit unsigned integer in network byte order.
|
||
This is often as specified in Assigned Numbers but need not be.
|
||
|
||
Target
|
||
The domain name of the target host. There MUST be one or more
|
||
address records for this name, the name MUST NOT be an alias (in
|
||
the sense of RFC 1034 or RFC 2181). Implementors are urged, but
|
||
not required, to return the address record(s) in the Additional
|
||
Data section. Unless and until permitted by future standards
|
||
action, name compression is not to be used for this field.
|
||
|
||
A Target of "." means that the service is decidedly not
|
||
available at this domain.
|
||
|
||
Domain administrator advice
|
||
|
||
Expecting everyone to update their client applications when the first
|
||
server publishes a SRV RR is futile (even if desirable). Therefore
|
||
SRV would have to coexist with address record lookups for existing
|
||
protocols, and DNS administrators should try to provide address
|
||
records to support old clients:
|
||
|
||
- Where the services for a single domain are spread over several
|
||
hosts, it seems advisable to have a list of address records at
|
||
the same DNS node as the SRV RR, listing reasonable (if perhaps
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 4]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
suboptimal) fallback hosts for Telnet, NNTP and other protocols
|
||
likely to be used with this name. Note that some programs only
|
||
try the first address they get back from e.g. gethostbyname(),
|
||
and we don't know how widespread this behavior is.
|
||
|
||
- Where one service is provided by several hosts, one can either
|
||
provide address records for all the hosts (in which case the
|
||
round-robin mechanism, where available, will share the load
|
||
equally) or just for one (presumably the fastest).
|
||
|
||
- If a host is intended to provide a service only when the main
|
||
server(s) is/are down, it probably shouldn't be listed in
|
||
address records.
|
||
|
||
- Hosts that are referenced by backup address records must use the
|
||
port number specified in Assigned Numbers for the service.
|
||
|
||
- Designers of future protocols for which "secondary servers" is
|
||
not useful (or meaningful) may choose to not use SRV's support
|
||
for secondary servers. Clients for such protocols may use or
|
||
ignore SRV RRs with Priority higher than the RR with the lowest
|
||
Priority for a domain.
|
||
|
||
Currently there's a practical limit of 512 bytes for DNS replies.
|
||
Until all resolvers can handle larger responses, domain
|
||
administrators are strongly advised to keep their SRV replies below
|
||
512 bytes.
|
||
|
||
All round numbers, wrote Dr. Johnson, are false, and these numbers
|
||
are very round: A reply packet has a 30-byte overhead plus the name
|
||
of the service ("_ldap._tcp.example.com" for instance); each SRV RR
|
||
adds 20 bytes plus the name of the target host; each NS RR in the NS
|
||
section is 15 bytes plus the name of the name server host; and
|
||
finally each A RR in the additional data section is 20 bytes or so,
|
||
and there are A's for each SRV and NS RR mentioned in the answer.
|
||
This size estimate is extremely crude, but shouldn't underestimate
|
||
the actual answer size by much. If an answer may be close to the
|
||
limit, using a DNS query tool (e.g. "dig") to look at the actual
|
||
answer is a good idea.
|
||
|
||
The "Weight" field
|
||
|
||
Weight, the server selection field, is not quite satisfactory, but
|
||
the actual load on typical servers changes much too quickly to be
|
||
kept around in DNS caches. It seems to the authors that offering
|
||
administrators a way to say "this machine is three times as fast as
|
||
that one" is the best that can practically be done.
|
||
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 5]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
The only way the authors can see of getting a "better" load figure is
|
||
asking a separate server when the client selects a server and
|
||
contacts it. For short-lived services an extra step in the
|
||
connection establishment seems too expensive, and for long-lived
|
||
services, the load figure may well be thrown off a minute after the
|
||
connection is established when someone else starts or finishes a
|
||
heavy job.
|
||
|
||
Note: There are currently various experiments at providing relative
|
||
network proximity estimation, available bandwidth estimation, and
|
||
similar services. Use of the SRV record with such facilities, and in
|
||
particular the interpretation of the Weight field when these
|
||
facilities are used, is for further study. Weight is only intended
|
||
for static, not dynamic, server selection. Using SRV weight for
|
||
dynamic server selection would require assigning unreasonably short
|
||
TTLs to the SRV RRs, which would limit the usefulness of the DNS
|
||
caching mechanism, thus increasing overall network load and
|
||
decreasing overall reliability. Server selection via SRV is only
|
||
intended to express static information such as "this server has a
|
||
faster CPU than that one" or "this server has a much better network
|
||
connection than that one".
|
||
|
||
The Port number
|
||
|
||
Currently, the translation from service name to port number happens
|
||
at the client, often using a file such as /etc/services.
|
||
|
||
Moving this information to the DNS makes it less necessary to update
|
||
these files on every single computer of the net every time a new
|
||
service is added, and makes it possible to move standard services out
|
||
of the "root-only" port range on unix.
|
||
|
||
Usage rules
|
||
|
||
A SRV-cognizant client SHOULD use this procedure to locate a list of
|
||
servers and connect to the preferred one:
|
||
|
||
Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
|
||
QTYPE=SRV.
|
||
|
||
If the reply is NOERROR, ANCOUNT>0 and there is at least one
|
||
SRV RR which specifies the requested Service and Protocol in
|
||
the reply:
|
||
|
||
If there is precisely one SRV RR, and its Target is "."
|
||
(the root domain), abort.
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 6]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
Else, for all such RR's, build a list of (Priority, Weight,
|
||
Target) tuples
|
||
|
||
Sort the list by priority (lowest number first)
|
||
|
||
Create a new empty list
|
||
|
||
For each distinct priority level
|
||
While there are still elements left at this priority
|
||
level
|
||
|
||
Select an element as specified above, in the
|
||
description of Weight in "The format of the SRV
|
||
RR" Section, and move it to the tail of the new
|
||
list
|
||
|
||
For each element in the new list
|
||
|
||
query the DNS for address records for the Target or
|
||
use any such records found in the Additional Data
|
||
section of the earlier SRV response.
|
||
|
||
for each address record found, try to connect to the
|
||
(protocol, address, service).
|
||
|
||
else
|
||
|
||
Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
|
||
|
||
for each address record found, try to connect to the
|
||
(protocol, address, service)
|
||
|
||
Notes:
|
||
|
||
- Port numbers SHOULD NOT be used in place of the symbolic service
|
||
or protocol names (for the same reason why variant names cannot
|
||
be allowed: Applications would have to do two or more lookups).
|
||
|
||
- If a truncated response comes back from an SRV query, the rules
|
||
described in [RFC 2181] shall apply.
|
||
|
||
- A client MUST parse all of the RR's in the reply.
|
||
|
||
- If the Additional Data section doesn't contain address records
|
||
for all the SRV RR's and the client may want to connect to the
|
||
target host(s) involved, the client MUST look up the address
|
||
record(s). (This happens quite often when the address record
|
||
has shorter TTL than the SRV or NS RR's.)
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 7]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
- Future protocols could be designed to use SRV RR lookups as the
|
||
means by which clients locate their servers.
|
||
|
||
Fictional example
|
||
|
||
This example uses fictional service "foobar" as an aid in
|
||
understanding SRV records. If ever service "foobar" is implemented,
|
||
it is not intended that it will necessarily use SRV records. This is
|
||
(part of) the zone file for example.com, a still-unused domain:
|
||
|
||
$ORIGIN example.com.
|
||
@ SOA server.example.com. root.example.com. (
|
||
1995032001 3600 3600 604800 86400 )
|
||
NS server.example.com.
|
||
NS ns1.ip-provider.net.
|
||
NS ns2.ip-provider.net.
|
||
; foobar - use old-slow-box or new-fast-box if either is
|
||
; available, make three quarters of the logins go to
|
||
; new-fast-box.
|
||
_foobar._tcp SRV 0 1 9 old-slow-box.example.com.
|
||
SRV 0 3 9 new-fast-box.example.com.
|
||
; if neither old-slow-box or new-fast-box is up, switch to
|
||
; using the sysdmin's box and the server
|
||
SRV 1 0 9 sysadmins-box.example.com.
|
||
SRV 1 0 9 server.example.com.
|
||
server A 172.30.79.10
|
||
old-slow-box A 172.30.79.11
|
||
sysadmins-box A 172.30.79.12
|
||
new-fast-box A 172.30.79.13
|
||
; NO other services are supported
|
||
*._tcp SRV 0 0 0 .
|
||
*._udp SRV 0 0 0 .
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 8]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
In this example, a client of the "foobar" service in the
|
||
"example.com." domain needs an SRV lookup of
|
||
"_foobar._tcp.example.com." and possibly A lookups of "new-fast-
|
||
box.example.com." and/or the other hosts named. The size of the SRV
|
||
reply is approximately 365 bytes:
|
||
|
||
30 bytes general overhead
|
||
20 bytes for the query string, "_foobar._tcp.example.com."
|
||
130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
|
||
fast-box", "old-slow-box", "server" and "sysadmins-box" -
|
||
"example.com" in the query section is quoted here and doesn't
|
||
need to be counted again.
|
||
75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
|
||
"ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
|
||
quoted and only needs to be counted once.
|
||
120 bytes for the 6 address records (assuming IPv4 only) mentioned
|
||
by the SRV and NS RR's.
|
||
|
||
IANA Considerations
|
||
|
||
The IANA has assigned RR type value 33 to the SRV RR. No other IANA
|
||
services are required by this document.
|
||
|
||
Changes from RFC 2052
|
||
|
||
This document obsoletes RFC 2052. The major change from that
|
||
previous, experimental, version of this specification is that now the
|
||
protocol and service labels are prepended with an underscore, to
|
||
lower the probability of an accidental clash with a similar name used
|
||
for unrelated purposes. Aside from that, changes are only intended
|
||
to increase the clarity and completeness of the document. This
|
||
document especially clarifies the use of the Weight field of the SRV
|
||
records.
|
||
|
||
Security Considerations
|
||
|
||
The authors believe this RR to not cause any new security problems.
|
||
Some problems become more visible, though.
|
||
|
||
- The ability to specify ports on a fine-grained basis obviously
|
||
changes how a router can filter packets. It becomes impossible
|
||
to block internal clients from accessing specific external
|
||
services, slightly harder to block internal users from running
|
||
unauthorized services, and more important for the router
|
||
operations and DNS operations personnel to cooperate.
|
||
|
||
- There is no way a site can keep its hosts from being referenced
|
||
as servers. This could lead to denial of service.
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 9]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
- With SRV, DNS spoofers can supply false port numbers, as well as
|
||
host names and addresses. Because this vulnerability exists
|
||
already, with names and addresses, this is not a new
|
||
vulnerability, merely a slightly extended one, with little
|
||
practical effect.
|
||
|
||
References
|
||
|
||
STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
|
||
1700, October 1994.
|
||
|
||
RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
|
||
STD 13, RFC 1034, November 1987.
|
||
|
||
RFC 1035: Mockapetris, P., "Domain names - Implementation and
|
||
Specification", STD 13, RFC 1035, November 1987.
|
||
|
||
RFC 974: Partridge, C., "Mail routing and the domain system", STD
|
||
14, RFC 974, January 1986.
|
||
|
||
BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
|
||
Specification", RFC 2181, July 1997.
|
||
|
||
RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
|
||
Services", BCP 17, RFC 2219, October 1997.
|
||
|
||
BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
|
||
Services with DNS", Work in Progress.
|
||
|
||
KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
|
||
Realm Information with DNS", Work in Progress.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 10]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
Acknowledgements
|
||
|
||
The algorithm used to select from the weighted SRV RRs of equal
|
||
priority is adapted from one supplied by Dan Bernstein.
|
||
|
||
Authors' Addresses
|
||
|
||
Arnt Gulbrandsen
|
||
Troll Tech
|
||
Waldemar Thranes gate 98B
|
||
N-0175 Oslo, Norway
|
||
|
||
Fax: +47 22806380
|
||
Phone: +47 22806390
|
||
EMail: arnt@troll.no
|
||
|
||
|
||
Paul Vixie
|
||
Internet Software Consortium
|
||
950 Charter Street
|
||
Redwood City, CA 94063
|
||
|
||
Phone: +1 650 779 7001
|
||
|
||
|
||
Levon Esibov
|
||
Microsoft Corporation
|
||
One Microsoft Way
|
||
Redmond, WA 98052
|
||
|
||
EMail: levone@microsoft.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 11]
|
||
|
||
RFC 2782 DNS SRV RR February 2000
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS 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.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen, et al. Standards Track [Page 12]
|
||
|