diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2782.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2782.txt | 675 |
1 files changed, 0 insertions, 675 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2782.txt b/contrib/bind9/doc/rfc/rfc2782.txt deleted file mode 100644 index 1827f10..0000000 --- a/contrib/bind9/doc/rfc/rfc2782.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group A. Gulbrandsen -Request for Comments: 2782 Troll Technologies -Obsoletes: 2052 P. Vixie -Category: Standards Track Internet Software Consortium - L. Esibov - Microsoft Corp. - February 2000 - - - A DNS RR for specifying the location of services (DNS SRV) - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This document describes a DNS RR which specifies the location of the - server(s) for a specific protocol and domain. - -Overview and rationale - - Currently, one must either know the exact address of a server to - contact it, or broadcast a question. - - 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. - - Note that where this document refers to "address records", it means A - RR's, AAAA RR's, or their most modern equivalent. - - - - - - - -Gulbrandsen, et al. Standards Track [Page 1] - -RFC 2782 DNS SRV RR February 2000 - - -Definitions - - The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" - used in this document are to be interpreted as specified in [BCP 14]. - Other terms used in this document are defined in the DNS - specification, RFC 1034. - -Applicability Statement - - In general, it is expected that SRV records will be used by clients - for applications where the relevant protocol specification indicates - that clients should use the SRV record. Such specification MUST - define the symbolic name to be used in the Service field of the SRV - record as described below. It also MUST include security - considerations. Service SRV records SHOULD NOT be used in the absence - of such specification. - -Introductory example - - If a SRV-cognizant LDAP client wants to discover a LDAP server that - supports TCP protocol and provides LDAP service for the domain - example.com., it does a lookup of - - _ldap._tcp.example.com - - as described in [ARM]. The example zone file near the end of this - memo contains answering RRs for an SRV query. - - Note: LDAP is chosen as an example for illustrative purposes only, - and the LDAP examples used in this document should not be considered - a definitive statement on the recommended way for LDAP to use SRV - records. As described in the earlier applicability section, consult - the appropriate LDAP documents for the recommended procedures. - -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 [STD 2] or locally. An underscore (_) is prepended to - the service identifier to avoid collisions with DNS labels that - occur in nature. - - - - -Gulbrandsen, et al. Standards Track [Page 2] - -RFC 2782 DNS SRV RR February 2000 - - - 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. The Service is case insensitive. - - Proto - The symbolic name of the desired protocol, with an underscore - (_) prepended to prevent collisions with DNS labels that occur - in nature. _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 [RFC 1035]. - - Class - Standard DNS meaning [RFC 1035]. SRV records occur in the IN - Class. - - Priority - 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 an - order defined by the weight field. The range is 0-65535. This - is a 16 bit unsigned integer in network byte order. - - Weight - A server selection mechanism. The weight field specifies a - relative weight for entries with the same priority. Larger - weights SHOULD be given a proportionately higher probability of - being selected. The range of this number is 0-65535. This is a - 16 bit unsigned integer in network byte order. Domain - administrators SHOULD use Weight 0 when there isn't any server - selection to do, to make the RR easier to read for humans (less - noisy). In the presence of records containing weights greater - than 0, records with weight 0 should have a very small chance of - being selected. - - In the absence of a protocol whose specification calls for the - use of other weighting information, a client arranges the SRV - RRs of the same Priority in the order in which target hosts, - - - - -Gulbrandsen, et al. Standards Track [Page 3] - -RFC 2782 DNS SRV RR February 2000 - - - specified by the SRV RRs, will be contacted. The following - algorithm SHOULD be used to order the SRV RRs of the same - priority: - - To select a target to be contacted next, arrange all SRV RRs - (that have not been ordered yet) in any order, except that all - those with weight 0 are placed at the beginning of the list. - - Compute the sum of the weights of those RRs, and with each RR - associate the running sum in the selected order. Then choose a - uniform random number between 0 and the sum computed - (inclusive), and select the RR whose running sum value is the - first in the selected order which is greater than or equal to - the random number selected. The target host specified in the - selected SRV RR is the next one to be contacted by the client. - Remove this SRV RR from the set of the unordered SRV RRs and - apply the described algorithm to the unordered SRV RRs to select - the next target host. Continue the ordering process until there - are no unordered SRV RRs. This process is repeated for each - Priority. - - Port - The port on this target host of this service. The range is 0- - 65535. This is a 16 bit unsigned integer in network byte order. - This is often as specified in Assigned Numbers but need not be. - - Target - The domain name of the target host. There MUST be one or more - address records for this name, the name MUST NOT be an alias (in - the sense of RFC 1034 or RFC 2181). Implementors are urged, but - not required, to return the address record(s) in the Additional - Data section. Unless and until permitted by future standards - action, name compression is not to be used for this field. - - A Target of "." means that the service is decidedly not - available at this domain. - -Domain administrator advice - - Expecting everyone to update their client applications when the first - server publishes a SRV RR is futile (even if desirable). Therefore - SRV would have to coexist with address record lookups for existing - protocols, and DNS administrators should try to provide address - 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 address records at - the same DNS node as the SRV RR, listing reasonable (if perhaps - - - -Gulbrandsen, et al. Standards Track [Page 4] - -RFC 2782 DNS SRV RR February 2000 - - - 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 behavior is. - - - Where one service is provided by several hosts, one can either - provide address 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 - address records. - - - Hosts that are referenced by backup address records must use the - port number specified in Assigned Numbers for the service. - - - Designers of future protocols for which "secondary servers" is - not useful (or meaningful) may choose to not use SRV's support - for secondary servers. Clients for such protocols may use or - ignore SRV RRs with Priority higher than the RR with the lowest - Priority for a domain. - - 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 ("_ldap._tcp.example.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 a DNS query tool (e.g. "dig") to look at the actual - answer is a good idea. - -The "Weight" field - - Weight, the server selection 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. - - - - -Gulbrandsen, et al. Standards Track [Page 5] - -RFC 2782 DNS SRV RR February 2000 - - - 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 an extra step in the - connection establishment seems too expensive, and for long-lived - services, the load figure may well be thrown off a minute after the - connection is established when someone else starts or finishes a - heavy job. - - Note: There are currently various experiments at providing relative - network proximity estimation, available bandwidth estimation, and - similar services. Use of the SRV record with such facilities, and in - particular the interpretation of the Weight field when these - facilities are used, is for further study. Weight is only intended - for static, not dynamic, server selection. Using SRV weight for - dynamic server selection would require assigning unreasonably short - TTLs to the SRV RRs, which would limit the usefulness of the DNS - caching mechanism, thus increasing overall network load and - decreasing overall reliability. Server selection via SRV is only - intended to express static information such as "this server has a - faster CPU than that one" or "this server has a much better network - connection than that one". - -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. - -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. - - - - - -Gulbrandsen, et al. Standards Track [Page 6] - -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: +47 22806380 - Phone: +47 22806390 - EMail: arnt@troll.no - - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - - Phone: +1 650 779 7001 - - - Levon Esibov - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - - EMail: levone@microsoft.com - - - - - - - - - - - - - - - - - - - - -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] - |
