contrib/bind9/doc/rfc/rfc2052.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                     A. Gulbrandsen
   8 Request for Comments: 2052                            Troll Technologies
   9 Updates: 1035, 1183                                             P. Vixie
  10 Category: Experimental                                 Vixie Enterprises
  11                                                             October 1996
  12
  13
  14        A DNS RR for specifying the location of services (DNS SRV)
  15
  16 Status of this Memo
  17
  18    This memo defines an Experimental Protocol for the Internet
  19    community.  This memo does not specify an Internet standard of any
  20    kind.  Discussion and suggestions for improvement are requested.
  21    Distribution of this memo is unlimited.
  22
  23 Abstract
  24
  25    This document describes a DNS RR which specifies the location of the
  26    server(s) for a specific protocol and domain (like a more general
  27    form of MX).
  28
  29 Overview and rationale
  30
  31    Currently, one must either know the exact address of a server to
  32    contact it, or broadcast a question.  This has led to, for example,
  33    ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
  34    level broadcasts to locate servers.
  35
  36    The SRV RR allows administrators to use several servers for a single
  37    domain, to move services from host to host with little fuss, and to
  38    designate some hosts as primary servers for a service and others as
  39    backups.
  40
  41    Clients ask for a specific service/protocol for a specific domain
  42    (the word domain is used here in the strict RFC 1034 sense), and get
  43    back the names of any available servers.
  44
  45 Introductory example
  46
  47    When a SRV-cognizant web-browser wants to retrieve
  48
  49       http://www.asdf.com/
  50
  51    it does a lookup of
  52
  53       http.tcp.www.asdf.com
  54
  55
  56
  57
  58 Gulbrandsen & Vixie           Experimental                      [Page 1]
  59 \f
  60 RFC 2052                       DNS SRV RR                   October 1996
  61
  62
  63    and retrieves the document from one of the servers in the reply.  The
  64    example zone file near the end of the memo contains answering RRs for
  65    this query.
  66
  67 The format of the SRV RR
  68
  69    Here is the format of the SRV RR, whose DNS type code is 33:
  70
  71         Service.Proto.Name TTL Class SRV Priority Weight Port Target
  72
  73         (There is an example near the end of this document.)
  74
  75    Service
  76         The symbolic name of the desired service, as defined in Assigned
  77         Numbers or locally.
  78
  79         Some widely used services, notably POP, don't have a single
  80         universal name.  If Assigned Numbers names the service
  81         indicated, that name is the only name which is legal for SRV
  82         lookups.  Only locally defined services may be named locally.
  83         The Service is case insensitive.
  84
  85    Proto
  86         TCP and UDP are at present the most useful values
  87         for this field, though any name defined by Assigned Numbers or
  88         locally may be used (as for Service).  The Proto is case
  89         insensitive.
  90
  91    Name
  92         The domain this RR refers to.  The SRV RR is unique in that the
  93         name one searches for is not this name; the example near the end
  94         shows this clearly.
  95
  96    TTL
  97         Standard DNS meaning.
  98
  99    Class
 100         Standard DNS meaning.
 101
 102    Priority
 103         As for MX, the priority of this target host.  A client MUST
 104         attempt to contact the target host with the lowest-numbered
 105         priority it can reach; target hosts with the same priority
 106         SHOULD be tried in pseudorandom order.  The range is 0-65535.
 107
 108
 109
 110
 111
 112
 113
 114 Gulbrandsen & Vixie           Experimental                      [Page 2]
 115 \f
 116 RFC 2052                       DNS SRV RR                   October 1996
 117
 118
 119    Weight
 120         Load balancing mechanism.  When selecting a target host among
 121         the those that have the same priority, the chance of trying this
 122         one first SHOULD be proportional to its weight.  The range of
 123         this number is 1-65535.  Domain administrators are urged to use
 124         Weight 0 when there isn't any load balancing to do, to make the
 125         RR easier to read for humans (less noisy).
 126
 127    Port
 128         The port on this target host of this service.  The range is
 129         0-65535.  This is often as specified in Assigned Numbers but
 130         need not be.
 131
 132    Target
 133         As for MX, the domain name of the target host.  There MUST be
 134         one or more A records for this name. Implementors are urged, but
 135         not required, to return the A record(s) in the Additional Data
 136         section.  Name compression is to be used for this field.
 137
 138         A Target of "." means that the service is decidedly not
 139         available at this domain.
 140
 141 Domain administrator advice
 142
 143    Asking everyone to update their telnet (for example) clients when the
 144    first internet site adds a SRV RR for Telnet/TCP is futile (even if
 145    desirable).  Therefore SRV will have to coexist with A record lookups
 146    for a long time, and DNS administrators should try to provide A
 147    records to support old clients:
 148
 149       - Where the services for a single domain are spread over several
 150         hosts, it seems advisable to have a list of A RRs at the same
 151         DNS node as the SRV RR, listing reasonable (if perhaps
 152         suboptimal) fallback hosts for Telnet, NNTP and other protocols
 153         likely to be used with this name.  Note that some programs only
 154         try the first address they get back from e.g. gethostbyname(),
 155         and we don't know how widespread this behaviour is.
 156
 157       - Where one service is provided by several hosts, one can either
 158         provide A records for all the hosts (in which case the round-
 159         robin mechanism, where available, will share the load equally)
 160         or just for one (presumably the fastest).
 161
 162       - If a host is intended to provide a service only when the main
 163         server(s) is/are down, it probably shouldn't be listed in A
 164         records.
 165
 166
 167
 168
 169
 170 Gulbrandsen & Vixie           Experimental                      [Page 3]
 171 \f
 172 RFC 2052                       DNS SRV RR                   October 1996
 173
 174
 175       - Hosts that are referenced by backup A records must use the port
 176         number specified in Assigned Numbers for the service.
 177
 178    Currently there's a practical limit of 512 bytes for DNS replies.
 179    Until all resolvers can handle larger responses, domain
 180    administrators are strongly advised to keep their SRV replies below
 181    512 bytes.
 182
 183    All round numbers, wrote Dr. Johnson, are false, and these numbers
 184    are very round: A reply packet has a 30-byte overhead plus the name
 185    of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
 186    20 bytes plus the name of the target host; each NS RR in the NS
 187    section is 15 bytes plus the name of the name server host; and
 188    finally each A RR in the additional data section is 20 bytes or so,
 189    and there are A's for each SRV and NS RR mentioned in the answer.
 190    This size estimate is extremely crude, but shouldn't underestimate
 191    the actual answer size by much.  If an answer may be close to the
 192    limit, using e.g. "dig" to look at the actual answer is a good idea.
 193
 194 The "Weight" field
 195
 196    Weight, the load balancing field, is not quite satisfactory, but the
 197    actual load on typical servers changes much too quickly to be kept
 198    around in DNS caches.  It seems to the authors that offering
 199    administrators a way to say "this machine is three times as fast as
 200    that one" is the best that can practically be done.
 201
 202    The only way the authors can see of getting a "better" load figure is
 203    asking a separate server when the client selects a server and
 204    contacts it.  For short-lived services like SMTP an extra step in the
 205    connection establishment seems too expensive, and for long-lived
 206    services like telnet, the load figure may well be thrown off a minute
 207    after the connection is established when someone else starts or
 208    finishes a heavy job.
 209
 210 The Port number
 211
 212    Currently, the translation from service name to port number happens
 213    at the client, often using a file such as /etc/services.
 214
 215    Moving this information to the DNS makes it less necessary to update
 216    these files on every single computer of the net every time a new
 217    service is added, and makes it possible to move standard services out
 218    of the "root-only" port range on unix
 219
 220
 221
 222
 223
 224
 225
 226 Gulbrandsen & Vixie           Experimental                      [Page 4]
 227 \f
 228 RFC 2052                       DNS SRV RR                   October 1996
 229
 230
 231 Usage rules
 232
 233    A SRV-cognizant client SHOULD use this procedure to locate a list of
 234    servers and connect to the preferred one:
 235
 236         Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
 237         QTYPE=SRV.
 238
 239         If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
 240         RR which specifies the requested Service and Protocol in the
 241         reply:
 242
 243              If there is precisely one SRV RR, and its Target is "."
 244              (the root domain), abort.
 245
 246              Else, for all such RR's, build a list of (Priority, Weight,
 247              Target) tuples
 248
 249              Sort the list by priority (lowest number first)
 250
 251              Create a new empty list
 252
 253              For each distinct priority level
 254                   While there are still elements left at this priority
 255                   level
 256                        Select an element randomly, with probability
 257                        Weight, and move it to the tail of the new list
 258
 259              For each element in the new list
 260
 261                   query the DNS for A RR's for the Target or use any
 262                   RR's found in the Additional Data secion of the
 263                   earlier SRV query.
 264
 265                   for each A RR found, try to connect to the (protocol,
 266                   address, service).
 267
 268         else if the service desired is SMTP
 269
 270              skip to RFC 974 (MX).
 271
 272         else
 273
 274              Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
 275
 276              for each A RR found, try to connect to the (protocol,
 277              address, service)
 278
 279
 280
 281
 282 Gulbrandsen & Vixie           Experimental                      [Page 5]
 283 \f
 284 RFC 2052                       DNS SRV RR                   October 1996
 285
 286
 287    Notes:
 288
 289       - Port numbers SHOULD NOT be used in place of the symbolic service
 290         or protocol names (for the same reason why variant names cannot
 291         be allowed: Applications would have to do two or more lookups).
 292
 293       - If a truncated response comes back from an SRV query, and the
 294         Additional Data section has at least one complete RR in it, the
 295         answer MUST be considered complete and the client resolver
 296         SHOULD NOT retry the query using TCP, but use normal UDP queries
 297         for A RR's missing from the Additional Data section.
 298
 299       - A client MAY use means other than Weight to choose among target
 300         hosts with equal Priority.
 301
 302       - A client MUST parse all of the RR's in the reply.
 303
 304       - If the Additional Data section doesn't contain A RR's for all
 305         the SRV RR's and the client may want to connect to the target
 306         host(s) involved, the client MUST look up the A RR(s).  (This
 307         happens quite often when the A RR has shorter TTL than the SRV
 308         or NS RR's.)
 309
 310       - A future standard could specify that a SRV RR whose Protocol was
 311         TCP and whose Service was SMTP would override RFC 974's rules
 312         with regard to the use of an MX RR.  This would allow firewalled
 313         organizations with several SMTP relays to control the load
 314         distribution using the Weight field.
 315
 316       - Future protocols could be designed to use SRV RR lookups as the
 317         means by which clients locate their servers.
 318
 319 Fictional example
 320
 321    This is (part of) the zone file for asdf.com, a still-unused domain:
 322
 323         $ORIGIN asdf.com.
 324         @               SOA server.asdf.com. root.asdf.com. (
 325                             1995032001 3600 3600 604800 86400 )
 326                         NS  server.asdf.com.
 327                         NS  ns1.ip-provider.net.
 328                         NS  ns2.ip-provider.net.
 329         ftp.tcp         SRV 0 0 21 server.asdf.com.
 330         finger.tcp      SRV 0 0 79 server.asdf.com.
 331         ; telnet - use old-slow-box or new-fast-box if either is
 332         ; available, make three quarters of the logins go to
 333         ; new-fast-box.
 334         telnet.tcp      SRV 0 1 23 old-slow-box.asdf.com.
 335
 336
 337
 338 Gulbrandsen & Vixie           Experimental                      [Page 6]
 339 \f
 340 RFC 2052                       DNS SRV RR                   October 1996
 341
 342
 343                         SRV 0 3 23 new-fast-box.asdf.com.
 344         ; if neither old-slow-box or new-fast-box is up, switch to
 345         ; using the sysdmin's box and the server
 346                         SRV 1 0 23 sysadmins-box.asdf.com.
 347                         SRV 1 0 23 server.asdf.com.
 348         ; HTTP - server is the main server, new-fast-box is the backup
 349         ; (On new-fast-box, the HTTP daemon runs on port 8000)
 350         http.tcp        SRV 0 0 80 server.asdf.com.
 351                         SRV 10 0 8000 new-fast-box.asdf.com.
 352         ; since we want to support both http://asdf.com/ and
 353         ; http://www.asdf.com/ we need the next two RRs as well
 354         http.tcp.www    SRV 0 0 80 server.asdf.com.
 355                         SRV 10 0 8000 new-fast-box.asdf.com.
 356         ; SMTP - mail goes to the server, and to the IP provider if
 357         ; the net is down
 358         smtp.tcp        SRV 0 0 25 server.asdf.com.
 359                         SRV 1 0 25 mailhost.ip-provider.net.
 360         @               MX  0 server.asdf.com.
 361                         MX  1 mailhost.ip-provider.net.
 362         ; NNTP - use the IP providers's NNTP server
 363         nntp.tcp        SRV 0 0 119 nntphost.ip-provider.net.
 364         ; IDB is an locally defined protocol
 365         idb.tcp         SRV  0 0 2025 new-fast-box.asdf.com.
 366         ; addresses
 367         server          A   172.30.79.10
 368         old-slow-box    A   172.30.79.11
 369         sysadmins-box   A   172.30.79.12
 370         new-fast-box    A   172.30.79.13
 371         ; backup A records - new-fast-box and old-slow-box are
 372         ; included, naturally, and server is too, but might go
 373         ; if the load got too bad
 374         @               A   172.30.79.10
 375                         A   172.30.79.11
 376                         A   172.30.79.13
 377         ; backup A RR for www.asdf.com
 378         www             A       172.30.79.10
 379         ; NO other services are supported
 380         *.tcp           SRV  0 0 0 .
 381         *.udp           SRV  0 0 0 .
 382
 383    In this example, a telnet connection to "asdf.com." needs an SRV
 384    lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
 385    fast-box.asdf.com." and/or the other hosts named.  The size of the
 386    SRV reply is approximately 365 bytes:
 387
 388       30 bytes general overhead
 389       20 bytes for the query string, "telnet.tcp.asdf.com."
 390       130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
 391
 392
 393
 394 Gulbrandsen & Vixie           Experimental                      [Page 7]
 395 \f
 396 RFC 2052                       DNS SRV RR                   October 1996
 397
 398
 399         fast-box", "old-slow-box", "server" and "sysadmins-box" -
 400         "asdf.com" in the query section is quoted here and doesn't
 401         need to be counted again.
 402       75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
 403         "server", "ns1.ip-provider.net." and "ns2" - again, "ip-
 404         provider.net." is quoted and only needs to be counted once.
 405       120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
 406
 407 Refererences
 408
 409    RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
 410         and E.  Lear, "Address Allocation for Private Internets",
 411         RFC 1918, February 1996.
 412
 413    RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
 414         "Enterprise Renumbering: Experience and Information
 415         Solicitation", RFC 1916, February 1996.
 416
 417    RFC 1912 Barr, D., "Common DNS Operational and Configuration
 418         Errors", RFC 1912, February 1996.
 419
 420    RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
 421         RFC 1900, February 1996.
 422
 423    RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
 424         STD 1, RFC 1920, March 1996.
 425
 426    RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
 427              1995.
 428
 429    RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
 430
 431    RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
 432
 433    RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
 434         "DNS Encoding of Geographical Location", RFC 1712, November
 435         1994.
 436
 437    RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
 438         RFC 1706, October 1994.
 439
 440    RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
 441         STD 2, RFC 1700, October 1994.
 442
 443    RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
 444         C. Everhart, "New DNS RR Definitions", RFC 1183, November
 445         1990.
 446
 447
 448
 449
 450 Gulbrandsen & Vixie           Experimental                      [Page 8]
 451 \f
 452 RFC 2052                       DNS SRV RR                   October 1996
 453
 454
 455    RFC 1101: Mockapetris, P., "DNS encoding of network names and other
 456         types", RFC 1101, April 1989.
 457
 458    RFC 1035: Mockapetris, P., "Domain names - implementation and
 459         specification", STD 13, RFC 1035, November 1987.
 460
 461    RFC 1034: Mockapetris, P., "Domain names - concepts and
 462         facilities", STD 13, RFC 1034, November 1987.
 463
 464    RFC 1033: Lottor, M., "Domain administrators operations guide",
 465         RFC 1033, November 1987.
 466
 467    RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
 468         November 1987.
 469
 470    RFC 974: Partridge, C., "Mail routing and the domain system",
 471         STD 14, RFC 974, January 1986.
 472
 473 Security Considerations
 474
 475    The authors believes this RR to not cause any new security problems.
 476    Some problems become more visible, though.
 477
 478       - The ability to specify ports on a fine-grained basis obviously
 479         changes how a router can filter packets.  It becomes impossible
 480         to block internal clients from accessing specific external
 481         services, slightly harder to block internal users from running
 482         unautorised services, and more important for the router
 483         operations and DNS operations personnel to cooperate.
 484
 485       - There is no way a site can keep its hosts from being referenced
 486         as servers (as, indeed, some sites become unwilling secondary
 487         MXes today).  This could lead to denial of service.
 488
 489       - With SRV, DNS spoofers can supply false port numbers, as well as
 490         host names and addresses.  The authors do not see any practical
 491         effect of this.
 492
 493    We assume that as the DNS-security people invent new features, DNS
 494    servers will return the relevant RRs in the Additional Data section
 495    when answering an SRV query.
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Gulbrandsen & Vixie           Experimental                      [Page 9]
 507 \f
 508 RFC 2052                       DNS SRV RR                   October 1996
 509
 510
 511 Authors' Addresses
 512
 513    Arnt Gulbrandsen
 514    Troll Tech
 515    Postboks 6133 Etterstad
 516    N-0602 Oslo
 517    Norway
 518
 519    Phone: +47 22646966
 520    EMail: agulbra@troll.no
 521
 522
 523    Paul Vixie
 524    Vixie Enterprises
 525    Star Route 159A
 526    Woodside, CA  94062
 527
 528    Phone: (415) 747-0204
 529    EMail: paul@vix.com
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Gulbrandsen & Vixie           Experimental                     [Page 10]
 563 \f