diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2052.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2052.txt | 563 |
1 files changed, 0 insertions, 563 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2052.txt b/contrib/bind9/doc/rfc/rfc2052.txt deleted file mode 100644 index 46ba362..0000000 --- a/contrib/bind9/doc/rfc/rfc2052.txt +++ /dev/null @@ -1,563 +0,0 @@ - - - - - - -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] - |
