7Network Working Group A. Gulbrandsen
8Request for Comments: 2782 Troll Technologies
9Obsoletes: 2052 P. Vixie
10Category: Standards Track Internet Software Consortium
16 A DNS RR for specifying the location of services (DNS SRV)
20 This document specifies an Internet standards track protocol for the
21 Internet community, and requests discussion and suggestions for
22 improvements. Please refer to the current edition of the "Internet
23 Official Protocol Standards" (STD 1) for the standardization state
24 and status of this protocol. Distribution of this memo is unlimited.
28 Copyright (C) The Internet Society (2000). All Rights Reserved.
32 This document describes a DNS RR which specifies the location of the
33 server(s) for a specific protocol and domain.
37 Currently, one must either know the exact address of a server to
38 contact it, or broadcast a question.
40 The SRV RR allows administrators to use several servers for a single
41 domain, to move services from host to host with little fuss, and to
42 designate some hosts as primary servers for a service and others as
45 Clients ask for a specific service/protocol for a specific domain
46 (the word domain is used here in the strict RFC 1034 sense), and get
47 back the names of any available servers.
49 Note that where this document refers to "address records", it means A
50 RR's, AAAA RR's, or their most modern equivalent.
58Gulbrandsen, et al. Standards Track [Page 1]
60RFC 2782 DNS SRV RR February 2000
65 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
66 used in this document are to be interpreted as specified in [BCP 14].
67 Other terms used in this document are defined in the DNS
68 specification, RFC 1034.
70Applicability Statement
72 In general, it is expected that SRV records will be used by clients
73 for applications where the relevant protocol specification indicates
74 that clients should use the SRV record. Such specification MUST
75 define the symbolic name to be used in the Service field of the SRV
76 record as described below. It also MUST include security
77 considerations. Service SRV records SHOULD NOT be used in the absence
78 of such specification.
82 If a SRV-cognizant LDAP client wants to discover a LDAP server that
83 supports TCP protocol and provides LDAP service for the domain
84 example.com., it does a lookup of
86 _ldap._tcp.example.com
88 as described in [ARM]. The example zone file near the end of this
89 memo contains answering RRs for an SRV query.
91 Note: LDAP is chosen as an example for illustrative purposes only,
92 and the LDAP examples used in this document should not be considered
93 a definitive statement on the recommended way for LDAP to use SRV
94 records. As described in the earlier applicability section, consult
95 the appropriate LDAP documents for the recommended procedures.
97The format of the SRV RR
99 Here is the format of the SRV RR, whose DNS type code is 33:
101 _Service._Proto.Name TTL Class SRV Priority Weight Port Target
103 (There is an example near the end of this document.)
106 The symbolic name of the desired service, as defined in Assigned
107 Numbers [STD 2] or locally. An underscore (_) is prepended to
108 the service identifier to avoid collisions with DNS labels that
114Gulbrandsen, et al. Standards Track [Page 2]
116RFC 2782 DNS SRV RR February 2000
119 Some widely used services, notably POP, don't have a single
120 universal name. If Assigned Numbers names the service
121 indicated, that name is the only name which is legal for SRV
122 lookups. The Service is case insensitive.
125 The symbolic name of the desired protocol, with an underscore
126 (_) prepended to prevent collisions with DNS labels that occur
127 in nature. _TCP and _UDP are at present the most useful values
128 for this field, though any name defined by Assigned Numbers or
129 locally may be used (as for Service). The Proto is case
133 The domain this RR refers to. The SRV RR is unique in that the
134 name one searches for is not this name; the example near the end
138 Standard DNS meaning [RFC 1035].
141 Standard DNS meaning [RFC 1035]. SRV records occur in the IN
145 The priority of this target host. A client MUST attempt to
146 contact the target host with the lowest-numbered priority it can
147 reach; target hosts with the same priority SHOULD be tried in an
148 order defined by the weight field. The range is 0-65535. This
149 is a 16 bit unsigned integer in network byte order.
152 A server selection mechanism. The weight field specifies a
153 relative weight for entries with the same priority. Larger
154 weights SHOULD be given a proportionately higher probability of
155 being selected. The range of this number is 0-65535. This is a
156 16 bit unsigned integer in network byte order. Domain
157 administrators SHOULD use Weight 0 when there isn't any server
158 selection to do, to make the RR easier to read for humans (less
159 noisy). In the presence of records containing weights greater
160 than 0, records with weight 0 should have a very small chance of
163 In the absence of a protocol whose specification calls for the
164 use of other weighting information, a client arranges the SRV
165 RRs of the same Priority in the order in which target hosts,
170Gulbrandsen, et al. Standards Track [Page 3]
172RFC 2782 DNS SRV RR February 2000
175 specified by the SRV RRs, will be contacted. The following
176 algorithm SHOULD be used to order the SRV RRs of the same
179 To select a target to be contacted next, arrange all SRV RRs
180 (that have not been ordered yet) in any order, except that all
181 those with weight 0 are placed at the beginning of the list.
183 Compute the sum of the weights of those RRs, and with each RR
184 associate the running sum in the selected order. Then choose a
185 uniform random number between 0 and the sum computed
186 (inclusive), and select the RR whose running sum value is the
187 first in the selected order which is greater than or equal to
188 the random number selected. The target host specified in the
189 selected SRV RR is the next one to be contacted by the client.
190 Remove this SRV RR from the set of the unordered SRV RRs and
191 apply the described algorithm to the unordered SRV RRs to select
192 the next target host. Continue the ordering process until there
193 are no unordered SRV RRs. This process is repeated for each
197 The port on this target host of this service. The range is 0-
198 65535. This is a 16 bit unsigned integer in network byte order.
199 This is often as specified in Assigned Numbers but need not be.
203 address records for this name, the name MUST NOT be an alias (in
204 the sense of RFC 1034 or RFC 2181). Implementors are urged, but
205 not required, to return the address record(s) in the Additional
206 Data section. Unless and until permitted by future standards
207 action, name compression is not to be used for this field.
209 A Target of "." means that the service is decidedly not
210 available at this domain.
212Domain administrator advice
214 Expecting everyone to update their client applications when the first
215 server publishes a SRV RR is futile (even if desirable). Therefore
216 SRV would have to coexist with address record lookups for existing
217 protocols, and DNS administrators should try to provide address
218 records to support old clients:
220 - Where the services for a single domain are spread over several
221 hosts, it seems advisable to have a list of address records at
222 the same DNS node as the SRV RR, listing reasonable (if perhaps
226Gulbrandsen, et al. Standards Track [Page 4]
228RFC 2782 DNS SRV RR February 2000
231 suboptimal) fallback hosts for Telnet, NNTP and other protocols
232 likely to be used with this name. Note that some programs only
233 try the first address they get back from e.g. gethostbyname(),
234 and we don't know how widespread this behavior is.
236 - Where one service is provided by several hosts, one can either
237 provide address records for all the hosts (in which case the
238 round-robin mechanism, where available, will share the load
239 equally) or just for one (presumably the fastest).
241 - If a host is intended to provide a service only when the main
242 server(s) is/are down, it probably shouldn't be listed in
245 - Hosts that are referenced by backup address records must use the
246 port number specified in Assigned Numbers for the service.
248 - Designers of future protocols for which "secondary servers" is
249 not useful (or meaningful) may choose to not use SRV's support
250 for secondary servers. Clients for such protocols may use or
251 ignore SRV RRs with Priority higher than the RR with the lowest
252 Priority for a domain.
254 Currently there's a practical limit of 512 bytes for DNS replies.
255 Until all resolvers can handle larger responses, domain
256 administrators are strongly advised to keep their SRV replies below
259 All round numbers, wrote Dr. Johnson, are false, and these numbers
260 are very round: A reply packet has a 30-byte overhead plus the name
261 of the service ("_ldap._tcp.example.com" for instance); each SRV RR
262 adds 20 bytes plus the name of the target host; each NS RR in the NS
263 section is 15 bytes plus the name of the name server host; and
264 finally each A RR in the additional data section is 20 bytes or so,
265 and there are A's for each SRV and NS RR mentioned in the answer.
266 This size estimate is extremely crude, but shouldn't underestimate
267 the actual answer size by much. If an answer may be close to the
268 limit, using a DNS query tool (e.g. "dig") to look at the actual
269 answer is a good idea.
273 Weight, the server selection field, is not quite satisfactory, but
274 the actual load on typical servers changes much too quickly to be
275 kept around in DNS caches. It seems to the authors that offering
276 administrators a way to say "this machine is three times as fast as
277 that one" is the best that can practically be done.
282Gulbrandsen, et al. Standards Track [Page 5]
284RFC 2782 DNS SRV RR February 2000
287 The only way the authors can see of getting a "better" load figure is
288 asking a separate server when the client selects a server and
289 contacts it. For short-lived services an extra step in the
290 connection establishment seems too expensive, and for long-lived
291 services, the load figure may well be thrown off a minute after the
292 connection is established when someone else starts or finishes a
295 Note: There are currently various experiments at providing relative
296 network proximity estimation, available bandwidth estimation, and
297 similar services. Use of the SRV record with such facilities, and in
298 particular the interpretation of the Weight field when these
299 facilities are used, is for further study. Weight is only intended
300 for static, not dynamic, server selection. Using SRV weight for
301 dynamic server selection would require assigning unreasonably short
302 TTLs to the SRV RRs, which would limit the usefulness of the DNS
303 caching mechanism, thus increasing overall network load and
304 decreasing overall reliability. Server selection via SRV is only
305 intended to express static information such as "this server has a
306 faster CPU than that one" or "this server has a much better network
307 connection than that one".
311 Currently, the translation from service name to port number happens
312 at the client, often using a file such as /etc/services.
314 Moving this information to the DNS makes it less necessary to update
315 these files on every single computer of the net every time a new
316 service is added, and makes it possible to move standard services out
317 of the "root-only" port range on unix.
321 A SRV-cognizant client SHOULD use this procedure to locate a list of
322 servers and connect to the preferred one:
324 Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
327 If the reply is NOERROR, ANCOUNT>0 and there is at least one
328 SRV RR which specifies the requested Service and Protocol in
331 If there is precisely one SRV RR, and its Target is "."
332 (the root domain), abort.
338Gulbrandsen, et al. Standards Track [Page 6]
340RFC 2782 DNS SRV RR February 2000
343 Else, for all such RR's, build a list of (Priority, Weight,
346 Sort the list by priority (lowest number first)
348 Create a new empty list
350 For each distinct priority level
351 While there are still elements left at this priority
354 Select an element as specified above, in the
355 description of Weight in "The format of the SRV
356 RR" Section, and move it to the tail of the new
359 For each element in the new list
361 query the DNS for address records for the Target or
362 use any such records found in the Additional Data
363 section of the earlier SRV response.
365 for each address record found, try to connect to the
366 (protocol, address, service).
370 Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
372 for each address record found, try to connect to the
373 (protocol, address, service)
377 - Port numbers SHOULD NOT be used in place of the symbolic service
378 or protocol names (for the same reason why variant names cannot
379 be allowed: Applications would have to do two or more lookups).
381 - If a truncated response comes back from an SRV query, the rules
382 described in [RFC 2181] shall apply.
384 - A client MUST parse all of the RR's in the reply.
386 - If the Additional Data section doesn't contain address records
387 for all the SRV RR's and the client may want to connect to the
388 target host(s) involved, the client MUST look up the address
389 record(s). (This happens quite often when the address record
390 has shorter TTL than the SRV or NS RR's.)
394Gulbrandsen, et al. Standards Track [Page 7]
396RFC 2782 DNS SRV RR February 2000
399 - Future protocols could be designed to use SRV RR lookups as the
400 means by which clients locate their servers.
404 This example uses fictional service "foobar" as an aid in
405 understanding SRV records. If ever service "foobar" is implemented,
406 it is not intended that it will necessarily use SRV records. This is
407 (part of) the zone file for example.com, a still-unused domain:
410 @ SOA server.example.com. root.example.com. (
411 1995032001 3600 3600 604800 86400 )
412 NS server.example.com.
413 NS ns1.ip-provider.net.
414 NS ns2.ip-provider.net.
415 ; foobar - use old-slow-box or new-fast-box if either is
416 ; available, make three quarters of the logins go to
418 _foobar._tcp SRV 0 1 9 old-slow-box.example.com.
419 SRV 0 3 9 new-fast-box.example.com.
420 ; if neither old-slow-box or new-fast-box is up, switch to
421 ; using the sysdmin's box and the server
422 SRV 1 0 9 sysadmins-box.example.com.
423 SRV 1 0 9 server.example.com.
424 server A 172.30.79.10
425 old-slow-box A 172.30.79.11
426 sysadmins-box A 172.30.79.12
427 new-fast-box A 172.30.79.13
428 ; NO other services are supported
450Gulbrandsen, et al. Standards Track [Page 8]
452RFC 2782 DNS SRV RR February 2000
455 In this example, a client of the "foobar" service in the
456 "example.com." domain needs an SRV lookup of
457 "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
458 box.example.com." and/or the other hosts named. The size of the SRV
459 reply is approximately 365 bytes:
461 30 bytes general overhead
462 20 bytes for the query string, "_foobar._tcp.example.com."
463 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
464 fast-box", "old-slow-box", "server" and "sysadmins-box" -
465 "example.com" in the query section is quoted here and doesn't
466 need to be counted again.
467 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
468 "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
469 quoted and only needs to be counted once.
470 120 bytes for the 6 address records (assuming IPv4 only) mentioned
471 by the SRV and NS RR's.
475 The IANA has assigned RR type value 33 to the SRV RR. No other IANA
476 services are required by this document.
480 This document obsoletes RFC 2052. The major change from that
481 previous, experimental, version of this specification is that now the
482 protocol and service labels are prepended with an underscore, to
483 lower the probability of an accidental clash with a similar name used
484 for unrelated purposes. Aside from that, changes are only intended
485 to increase the clarity and completeness of the document. This
486 document especially clarifies the use of the Weight field of the SRV
489Security Considerations
491 The authors believe this RR to not cause any new security problems.
492 Some problems become more visible, though.
494 - The ability to specify ports on a fine-grained basis obviously
495 changes how a router can filter packets. It becomes impossible
496 to block internal clients from accessing specific external
497 services, slightly harder to block internal users from running
498 unauthorized services, and more important for the router
499 operations and DNS operations personnel to cooperate.
501 - There is no way a site can keep its hosts from being referenced
502 as servers. This could lead to denial of service.
506Gulbrandsen, et al. Standards Track [Page 9]
508RFC 2782 DNS SRV RR February 2000
511 - With SRV, DNS spoofers can supply false port numbers, as well as
512 host names and addresses. Because this vulnerability exists
513 already, with names and addresses, this is not a new
514 vulnerability, merely a slightly extended one, with little
519 STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
522 RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
523 STD 13, RFC 1034, November 1987.
525 RFC 1035: Mockapetris, P., "Domain names - Implementation and
526 Specification", STD 13, RFC 1035, November 1987.
528 RFC 974: Partridge, C., "Mail routing and the domain system", STD
529 14, RFC 974, January 1986.
531 BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
532 Requirement Levels", BCP 14, RFC 2119, March 1997.
534 RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
535 Specification", RFC 2181, July 1997.
537 RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
538 Services", BCP 17, RFC 2219, October 1997.
540 BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
541 Requirement Levels", BCP 14, RFC 2119, March 1997.
543 ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
544 Services with DNS", Work in Progress.
546 KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
547 Realm Information with DNS", Work in Progress.
562Gulbrandsen, et al. Standards Track [Page 10]
564RFC 2782 DNS SRV RR February 2000
569 The algorithm used to select from the weighted SRV RRs of equal
570 priority is adapted from one supplied by Dan Bernstein.
576 Waldemar Thranes gate 98B
585 Internet Software Consortium
587 Redwood City, CA 94063
589 Phone: +1 650 779 7001
593 Microsoft Corporation
597 EMail: levone@microsoft.com
618Gulbrandsen, et al. Standards Track [Page 11]
620RFC 2782 DNS SRV RR February 2000
623Full Copyright Statement
625 Copyright (C) The Internet Society (2000). All Rights Reserved.
627 This document and translations of it may be copied and furnished to
628 others, and derivative works that comment on or otherwise explain it
629 or assist in its implementation may be prepared, copied, published
630 and distributed, in whole or in part, without restriction of any
631 kind, provided that the above copyright notice and this paragraph are
632 included on all such copies and derivative works. However, this
633 document itself may not be modified in any way, such as by removing
634 the copyright notice or references to the Internet Society or other
635 Internet organizations, except as needed for the purpose of
636 developing Internet standards in which case the procedures for
637 copyrights defined in the Internet Standards process must be
638 followed, or as required to translate it into languages other than
641 The limited permissions granted above are perpetual and will not be
642 revoked by the Internet Society or its successors or assigns.
644 This document and the information contained herein is provided on an
645 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
646 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
647 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
648 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
649 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
653 Funding for the RFC Editor function is currently provided by the
674Gulbrandsen, et al. Standards Track [Page 12]