rfc2782.txt

RFC 的详细文档！


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:   [phone]
   Phone: [phone]
   EMail: [e-mail]


   Paul Vixie
   Internet Software Consortium
   950 Charter Street
   Redwood City, CA 94063

   Phone: [phone]


   Levon Esibov
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   EMail: [e-mail]




















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]