contrib/bind9/doc/rfc/rfc2782.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                     A. Gulbrandsen
   8 Request for Comments: 2782                            Troll Technologies
   9 Obsoletes: 2052                                                 P. Vixie
  10 Category: Standards Track                   Internet Software Consortium
  11                                                                L. Esibov
  12                                                          Microsoft Corp.
  13                                                            February 2000
  14
  15
  16        A DNS RR for specifying the location of services (DNS SRV)
  17
  18 Status of this Memo
  19
  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.
  25
  26 Copyright Notice
  27
  28    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  29
  30 Abstract
  31
  32    This document describes a DNS RR which specifies the location of the
  33    server(s) for a specific protocol and domain.
  34
  35 Overview and rationale
  36
  37    Currently, one must either know the exact address of a server to
  38    contact it, or broadcast a question.
  39
  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
  43    backups.
  44
  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.
  48
  49    Note that where this document refers to "address records", it means A
  50    RR's, AAAA RR's, or their most modern equivalent.
  51
  52
  53
  54
  55
  56
  57
  58 Gulbrandsen, et al.         Standards Track                     [Page 1]
  59 \f
  60 RFC 2782                       DNS SRV RR                  February 2000
  61
  62
  63 Definitions
  64
  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.
  69
  70 Applicability Statement
  71
  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.
  79
  80 Introductory example
  81
  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
  85
  86       _ldap._tcp.example.com
  87
  88    as described in [ARM].  The example zone file near the end of this
  89    memo contains answering RRs for an SRV query.
  90
  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.
  96
  97 The format of the SRV RR
  98
  99    Here is the format of the SRV RR, whose DNS type code is 33:
 100
 101         _Service._Proto.Name TTL Class SRV Priority Weight Port Target
 102
 103         (There is an example near the end of this document.)
 104
 105    Service
 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
 109         occur in nature.
 110
 111
 112
 113
 114 Gulbrandsen, et al.         Standards Track                     [Page 2]
 115 \f
 116 RFC 2782                       DNS SRV RR                  February 2000
 117
 118
 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.
 123
 124    Proto
 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
 130         insensitive.
 131
 132    Name
 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
 135         shows this clearly.
 136
 137    TTL
 138         Standard DNS meaning [RFC 1035].
 139
 140    Class
 141         Standard DNS meaning [RFC 1035].   SRV records occur in the IN
 142         Class.
 143
 144    Priority
 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.
 150
 151    Weight
 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
 161         being selected.
 162
 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,
 166
 167
 168
 169
 170 Gulbrandsen, et al.         Standards Track                     [Page 3]
 171 \f
 172 RFC 2782                       DNS SRV RR                  February 2000
 173
 174
 175         specified by the SRV RRs, will be contacted. The following
 176         algorithm SHOULD be used to order the SRV RRs of the same
 177         priority:
 178
 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.
 182
 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
 194         Priority.
 195
 196    Port
 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.
 200
 201    Target
 202         The domain name of the target host.  There MUST be one or more
 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.
 208
 209         A Target of "." means that the service is decidedly not
 210         available at this domain.
 211
 212 Domain administrator advice
 213
 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:
 219
 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
 223
 224
 225
 226 Gulbrandsen, et al.         Standards Track                     [Page 4]
 227 \f
 228 RFC 2782                       DNS SRV RR                  February 2000
 229
 230
 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.
 235
 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).
 240
 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
 243         address records.
 244
 245       - Hosts that are referenced by backup address records must use the
 246         port number specified in Assigned Numbers for the service.
 247
 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.
 253
 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
 257    512 bytes.
 258
 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.
 270
 271 The "Weight" field
 272
 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.
 278
 279
 280
 281
 282 Gulbrandsen, et al.         Standards Track                     [Page 5]
 283 \f
 284 RFC 2782                       DNS SRV RR                  February 2000
 285
 286
 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
 293    heavy job.
 294
 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".
 308
 309 The Port number
 310
 311    Currently, the translation from service name to port number happens
 312    at the client, often using a file such as /etc/services.
 313
 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.
 318
 319 Usage rules
 320
 321    A SRV-cognizant client SHOULD use this procedure to locate a list of
 322    servers and connect to the preferred one:
 323
 324         Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
 325         QTYPE=SRV.
 326
 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
 329         the reply:
 330
 331             If there is precisely one SRV RR, and its Target is "."
 332             (the root domain), abort.
 333
 334
 335
 336
 337
 338 Gulbrandsen, et al.         Standards Track                     [Page 6]
 339 \f
 340 RFC 2782                       DNS SRV RR                  February 2000
 341
 342
 343             Else, for all such RR's, build a list of (Priority, Weight,
 344             Target) tuples
 345
 346             Sort the list by priority (lowest number first)
 347
 348             Create a new empty list
 349
 350             For each distinct priority level
 351                 While there are still elements left at this priority
 352                 level
 353
 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
 357                     list
 358
 359             For each element in the new list
 360
 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.
 364
 365                 for each address record found, try to connect to the
 366                (protocol, address, service).
 367
 368         else
 369
 370             Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
 371
 372             for each address record found, try to connect to the
 373            (protocol, address, service)
 374
 375 Notes:
 376
 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).
 380
 381    - If a truncated response comes back from an SRV query, the rules
 382      described in [RFC 2181] shall apply.
 383
 384    - A client MUST parse all of the RR's in the reply.
 385
 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.)
 391
 392
 393
 394 Gulbrandsen, et al.         Standards Track                     [Page 7]
 395 \f
 396 RFC 2782                       DNS SRV RR                  February 2000
 397
 398
 399    - Future protocols could be designed to use SRV RR lookups as the
 400      means by which clients locate their servers.
 401
 402 Fictional example
 403
 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:
 408
 409       $ORIGIN example.com.
 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
 417       ; new-fast-box.
 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
 429       *._tcp          SRV  0 0 0 .
 430       *._udp          SRV  0 0 0 .
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Gulbrandsen, et al.         Standards Track                     [Page 8]
 451 \f
 452 RFC 2782                       DNS SRV RR                  February 2000
 453
 454
 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:
 460
 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.
 472
 473 IANA Considerations
 474
 475    The IANA has assigned RR type value 33 to the SRV RR.  No other IANA
 476    services are required by this document.
 477
 478 Changes from RFC 2052
 479
 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
 487    records.
 488
 489 Security Considerations
 490
 491    The authors believe this RR to not cause any new security problems.
 492    Some problems become more visible, though.
 493
 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.
 500
 501    - There is no way a site can keep its hosts from being referenced
 502      as servers.  This could lead to denial of service.
 503
 504
 505
 506 Gulbrandsen, et al.         Standards Track                     [Page 9]
 507 \f
 508 RFC 2782                       DNS SRV RR                  February 2000
 509
 510
 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
 515      practical effect.
 516
 517 References
 518
 519    STD 2:    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
 520              1700, October 1994.
 521
 522    RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
 523              STD 13, RFC 1034, November 1987.
 524
 525    RFC 1035: Mockapetris, P., "Domain names - Implementation and
 526              Specification", STD 13, RFC 1035, November 1987.
 527
 528    RFC 974:  Partridge, C., "Mail routing and the domain system", STD
 529              14, RFC 974, January 1986.
 530
 531    BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
 532              Requirement Levels", BCP 14, RFC 2119, March 1997.
 533
 534    RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
 535              Specification", RFC 2181, July 1997.
 536
 537    RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
 538              Services", BCP 17, RFC 2219, October 1997.
 539
 540    BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
 541              Requirement Levels", BCP 14, RFC 2119, March 1997.
 542
 543    ARM:      Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
 544              Services with DNS", Work in Progress.
 545
 546    KDC-DNS:  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
 547              Realm Information with DNS", Work in Progress.
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Gulbrandsen, et al.         Standards Track                    [Page 10]
 563 \f
 564 RFC 2782                       DNS SRV RR                  February 2000
 565
 566
 567 Acknowledgements
 568
 569    The algorithm used to select from the weighted SRV RRs of equal
 570    priority is adapted from one supplied by Dan Bernstein.
 571
 572 Authors' Addresses
 573
 574    Arnt Gulbrandsen
 575    Troll Tech
 576    Waldemar Thranes gate 98B
 577    N-0175 Oslo, Norway
 578
 579    Fax:   +47 22806380
 580    Phone: +47 22806390
 581    EMail: arnt@troll.no
 582
 583
 584    Paul Vixie
 585    Internet Software Consortium
 586    950 Charter Street
 587    Redwood City, CA 94063
 588
 589    Phone: +1 650 779 7001
 590
 591
 592    Levon Esibov
 593    Microsoft Corporation
 594    One Microsoft Way
 595    Redmond, WA 98052
 596
 597    EMail: levone@microsoft.com
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Gulbrandsen, et al.         Standards Track                    [Page 11]
 619 \f
 620 RFC 2782                       DNS SRV RR                  February 2000
 621
 622
 623 Full Copyright Statement
 624
 625    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 626
 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
 639    English.
 640
 641    The limited permissions granted above are perpetual and will not be
 642    revoked by the Internet Society or its successors or assigns.
 643
 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.
 650
 651 Acknowledgement
 652
 653    Funding for the RFC Editor function is currently provided by the
 654    Internet Society.
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Gulbrandsen, et al.         Standards Track                    [Page 12]
 675 \f