doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2052.txt b/doc/rfc/rfc2052.txt
new file mode 100644
index 0000000..9fbccb6
--- /dev/null
+++ b/doc/rfc/rfc2052.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+