564 lines
19 KiB
Plaintext
564 lines
19 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group A. Gulbrandsen
|
||
Request for Comments: 2052 Troll Technologies
|
||
Updates: 1035, 1183 P. Vixie
|
||
Category: Experimental Vixie Enterprises
|
||
October 1996
|
||
|
||
|
||
A DNS RR for specifying the location of services (DNS SRV)
|
||
|
||
Status of this Memo
|
||
|
||
This memo defines an Experimental Protocol for the Internet
|
||
community. This memo does not specify an Internet standard of any
|
||
kind. Discussion and suggestions for improvement are requested.
|
||
Distribution of this memo is unlimited.
|
||
|
||
Abstract
|
||
|
||
This document describes a DNS RR which specifies the location of the
|
||
server(s) for a specific protocol and domain (like a more general
|
||
form of MX).
|
||
|
||
Overview and rationale
|
||
|
||
Currently, one must either know the exact address of a server to
|
||
contact it, or broadcast a question. This has led to, for example,
|
||
ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
|
||
level broadcasts to locate servers.
|
||
|
||
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.
|
||
|
||
Introductory example
|
||
|
||
When a SRV-cognizant web-browser wants to retrieve
|
||
|
||
http://www.asdf.com/
|
||
|
||
it does a lookup of
|
||
|
||
http.tcp.www.asdf.com
|
||
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 1]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
and retrieves the document from one of the servers in the reply. The
|
||
example zone file near the end of the memo contains answering RRs for
|
||
this query.
|
||
|
||
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 or locally.
|
||
|
||
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. Only locally defined services may be named locally.
|
||
The Service is case insensitive.
|
||
|
||
Proto
|
||
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.
|
||
|
||
Class
|
||
Standard DNS meaning.
|
||
|
||
Priority
|
||
As for MX, 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 pseudorandom order. The range is 0-65535.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 2]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
Weight
|
||
Load balancing mechanism. When selecting a target host among
|
||
the those that have the same priority, the chance of trying this
|
||
one first SHOULD be proportional to its weight. The range of
|
||
this number is 1-65535. Domain administrators are urged to use
|
||
Weight 0 when there isn't any load balancing to do, to make the
|
||
RR easier to read for humans (less noisy).
|
||
|
||
Port
|
||
The port on this target host of this service. The range is
|
||
0-65535. This is often as specified in Assigned Numbers but
|
||
need not be.
|
||
|
||
Target
|
||
As for MX, the domain name of the target host. There MUST be
|
||
one or more A records for this name. Implementors are urged, but
|
||
not required, to return the A record(s) in the Additional Data
|
||
section. Name compression is to be used for this field.
|
||
|
||
A Target of "." means that the service is decidedly not
|
||
available at this domain.
|
||
|
||
Domain administrator advice
|
||
|
||
Asking everyone to update their telnet (for example) clients when the
|
||
first internet site adds a SRV RR for Telnet/TCP is futile (even if
|
||
desirable). Therefore SRV will have to coexist with A record lookups
|
||
for a long time, and DNS administrators should try to provide A
|
||
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 A RRs at the same
|
||
DNS node as the SRV RR, listing reasonable (if perhaps
|
||
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 behaviour is.
|
||
|
||
- Where one service is provided by several hosts, one can either
|
||
provide A 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 A
|
||
records.
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 3]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
- Hosts that are referenced by backup A records must use the port
|
||
number specified in Assigned Numbers for the service.
|
||
|
||
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 ("telnet.tcp.asdf.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 e.g. "dig" to look at the actual answer is a good idea.
|
||
|
||
The "Weight" field
|
||
|
||
Weight, the load balancing 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.
|
||
|
||
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 like SMTP an extra step in the
|
||
connection establishment seems too expensive, and for long-lived
|
||
services like telnet, the load figure may well be thrown off a minute
|
||
after the connection is established when someone else starts or
|
||
finishes a heavy job.
|
||
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 4]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
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.
|
||
|
||
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 randomly, with probability
|
||
Weight, and move it to the tail of the new list
|
||
|
||
For each element in the new list
|
||
|
||
query the DNS for A RR's for the Target or use any
|
||
RR's found in the Additional Data secion of the
|
||
earlier SRV query.
|
||
|
||
for each A RR found, try to connect to the (protocol,
|
||
address, service).
|
||
|
||
else if the service desired is SMTP
|
||
|
||
skip to RFC 974 (MX).
|
||
|
||
else
|
||
|
||
Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
|
||
|
||
for each A RR found, try to connect to the (protocol,
|
||
address, service)
|
||
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 5]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
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, and the
|
||
Additional Data section has at least one complete RR in it, the
|
||
answer MUST be considered complete and the client resolver
|
||
SHOULD NOT retry the query using TCP, but use normal UDP queries
|
||
for A RR's missing from the Additional Data section.
|
||
|
||
- A client MAY use means other than Weight to choose among target
|
||
hosts with equal Priority.
|
||
|
||
- A client MUST parse all of the RR's in the reply.
|
||
|
||
- If the Additional Data section doesn't contain A RR's 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 A RR(s). (This
|
||
happens quite often when the A RR has shorter TTL than the SRV
|
||
or NS RR's.)
|
||
|
||
- A future standard could specify that a SRV RR whose Protocol was
|
||
TCP and whose Service was SMTP would override RFC 974's rules
|
||
with regard to the use of an MX RR. This would allow firewalled
|
||
organizations with several SMTP relays to control the load
|
||
distribution using the Weight field.
|
||
|
||
- Future protocols could be designed to use SRV RR lookups as the
|
||
means by which clients locate their servers.
|
||
|
||
Fictional example
|
||
|
||
This is (part of) the zone file for asdf.com, a still-unused domain:
|
||
|
||
$ORIGIN asdf.com.
|
||
@ SOA server.asdf.com. root.asdf.com. (
|
||
1995032001 3600 3600 604800 86400 )
|
||
NS server.asdf.com.
|
||
NS ns1.ip-provider.net.
|
||
NS ns2.ip-provider.net.
|
||
ftp.tcp SRV 0 0 21 server.asdf.com.
|
||
finger.tcp SRV 0 0 79 server.asdf.com.
|
||
; telnet - use old-slow-box or new-fast-box if either is
|
||
; available, make three quarters of the logins go to
|
||
; new-fast-box.
|
||
telnet.tcp SRV 0 1 23 old-slow-box.asdf.com.
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 6]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
SRV 0 3 23 new-fast-box.asdf.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 23 sysadmins-box.asdf.com.
|
||
SRV 1 0 23 server.asdf.com.
|
||
; HTTP - server is the main server, new-fast-box is the backup
|
||
; (On new-fast-box, the HTTP daemon runs on port 8000)
|
||
http.tcp SRV 0 0 80 server.asdf.com.
|
||
SRV 10 0 8000 new-fast-box.asdf.com.
|
||
; since we want to support both http://asdf.com/ and
|
||
; http://www.asdf.com/ we need the next two RRs as well
|
||
http.tcp.www SRV 0 0 80 server.asdf.com.
|
||
SRV 10 0 8000 new-fast-box.asdf.com.
|
||
; SMTP - mail goes to the server, and to the IP provider if
|
||
; the net is down
|
||
smtp.tcp SRV 0 0 25 server.asdf.com.
|
||
SRV 1 0 25 mailhost.ip-provider.net.
|
||
@ MX 0 server.asdf.com.
|
||
MX 1 mailhost.ip-provider.net.
|
||
; NNTP - use the IP providers's NNTP server
|
||
nntp.tcp SRV 0 0 119 nntphost.ip-provider.net.
|
||
; IDB is an locally defined protocol
|
||
idb.tcp SRV 0 0 2025 new-fast-box.asdf.com.
|
||
; addresses
|
||
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
|
||
; backup A records - new-fast-box and old-slow-box are
|
||
; included, naturally, and server is too, but might go
|
||
; if the load got too bad
|
||
@ A 172.30.79.10
|
||
A 172.30.79.11
|
||
A 172.30.79.13
|
||
; backup A RR for www.asdf.com
|
||
www A 172.30.79.10
|
||
; NO other services are supported
|
||
*.tcp SRV 0 0 0 .
|
||
*.udp SRV 0 0 0 .
|
||
|
||
In this example, a telnet connection to "asdf.com." needs an SRV
|
||
lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
|
||
fast-box.asdf.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, "telnet.tcp.asdf.com."
|
||
130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 7]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
fast-box", "old-slow-box", "server" and "sysadmins-box" -
|
||
"asdf.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 A RR's mentioned by the SRV and NS RR's.
|
||
|
||
Refererences
|
||
|
||
RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
|
||
and E. Lear, "Address Allocation for Private Internets",
|
||
RFC 1918, February 1996.
|
||
|
||
RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
|
||
"Enterprise Renumbering: Experience and Information
|
||
Solicitation", RFC 1916, February 1996.
|
||
|
||
RFC 1912 Barr, D., "Common DNS Operational and Configuration
|
||
Errors", RFC 1912, February 1996.
|
||
|
||
RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
|
||
RFC 1900, February 1996.
|
||
|
||
RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
|
||
STD 1, RFC 1920, March 1996.
|
||
|
||
RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
|
||
1995.
|
||
|
||
RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
|
||
|
||
RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
|
||
|
||
RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
|
||
"DNS Encoding of Geographical Location", RFC 1712, November
|
||
1994.
|
||
|
||
RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
|
||
RFC 1706, October 1994.
|
||
|
||
RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
|
||
STD 2, RFC 1700, October 1994.
|
||
|
||
RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
|
||
C. Everhart, "New DNS RR Definitions", RFC 1183, November
|
||
1990.
|
||
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 8]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
RFC 1101: Mockapetris, P., "DNS encoding of network names and other
|
||
types", RFC 1101, April 1989.
|
||
|
||
RFC 1035: Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
RFC 1034: Mockapetris, P., "Domain names - concepts and
|
||
facilities", STD 13, RFC 1034, November 1987.
|
||
|
||
RFC 1033: Lottor, M., "Domain administrators operations guide",
|
||
RFC 1033, November 1987.
|
||
|
||
RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
|
||
November 1987.
|
||
|
||
RFC 974: Partridge, C., "Mail routing and the domain system",
|
||
STD 14, RFC 974, January 1986.
|
||
|
||
Security Considerations
|
||
|
||
The authors believes 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
|
||
unautorised 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 (as, indeed, some sites become unwilling secondary
|
||
MXes today). This could lead to denial of service.
|
||
|
||
- With SRV, DNS spoofers can supply false port numbers, as well as
|
||
host names and addresses. The authors do not see any practical
|
||
effect of this.
|
||
|
||
We assume that as the DNS-security people invent new features, DNS
|
||
servers will return the relevant RRs in the Additional Data section
|
||
when answering an SRV query.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 9]
|
||
|
||
RFC 2052 DNS SRV RR October 1996
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Arnt Gulbrandsen
|
||
Troll Tech
|
||
Postboks 6133 Etterstad
|
||
N-0602 Oslo
|
||
Norway
|
||
|
||
Phone: +47 22646966
|
||
EMail: agulbra@troll.no
|
||
|
||
|
||
Paul Vixie
|
||
Vixie Enterprises
|
||
Star Route 159A
|
||
Woodside, CA 94062
|
||
|
||
Phone: (415) 747-0204
|
||
EMail: paul@vix.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Gulbrandsen & Vixie Experimental [Page 10]
|
||
|