INTERNET-DRAFT Eric A. Hall Document: draft-hall-resolver-config-00.txt July 2003 Expires: February, 2004 Category: Standards-Track DNS Resolver Configuration via Multicast Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document specifies a mechanism whereby DNS resolvers can automatically locate the DNS servers which are available for use, by way of a special DNS query message, a CONFIG opcode, a reserved multicast address, and some behavioral rules. Internet Draft draft-hall-resolver-config-00.txt July 2003 1. Introduction This specification is intended to address the narrow scenario where a host needs to determine the DNS servers which are willing to provide DNS resolution services to that host. This document does not define any additional services. The mechanism proposed in this document makes use of a CONFIG opcode, a dedicated administratively-scoped multicast address, and certain behavioral rules. In essence, the model proposed herein has the "client" host issuing a CONFIG query to the specified multicast address, with each available and willing server returning unicast response messages which describe that server's capabilities. The client examines the various response messages and their characteristics, and uses this information to determine the "best" servers from among the available set. 2. Prerequisites and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Multicast Address and Listeners This specification uses the well-known, administratively-scoped multicast address of . Network administrators who choose to provide this service MUST ensure that packets with this address do not leak beyond the boundaries of the organization's network, unless intentionally desired. For example, if an end-user organization wishes to use the DNS servers at their service provider, then clearly the edge devices on that network will need to allow these messages to pass into the provider's network, although the provider would need to ensure that the messages went no further. Clients which need to obtain server lists MUST issue queries to this address. Clients SHOULD NOT bind to this address, but if they are required to do so, they MUST unbind from the address immediately after sending the query. In any event, clients MUST NOT respond to CONFIG queries received at this address. Servers which are willing to provide resolution services to hosts within the administrative scope MUST bind to this address. Hall I-D Expires: February 2004 [page 2] Internet Draft draft-hall-resolver-config-00.txt July 2003 However, responses to CONFIG queries MUST be returned via unicast datagrams, using one of the server's local addresses as the source, and the client's originator address as the destination. All IP packets containing query and response messages MUST have an initial IP time-to-live of 255. 4. The CONFIG Operation Code This specification uses the DNS CONFIG operation code, with the value of . All DNS configuration request and response messages MUST use the CONFIG operation code. Unless otherwise specified in another specification, servers which receive messages on the multicast address with any other operation code SHOULD return NOTIMPL responses via unicast. Clients which receive responses with other operation codes MUST apply usual logic to those messages, as specified in [STD13] and its updates. 5. Message Formatting CONFIG request and response messages MUST use the CONFIG operation code value of . No other flags or values in the request message have any defined meaning in this service, and their settings MUST be ignored by servers which are providing this service. CONFIG response messages MUST have the Recursion Available flag enabled or disabled according to the capabilities of the server. Apart from the Truncation flag (as described below), no other flags or values in the response message have any defined meaning in this service, and their settings MUST be ignored by clients which are using this service. CONFIG request messages MUST NOT contain any entries in the Question, Answer, Authority, and Additional-Data sections, and the presence of any entries in these sections MUST be ignored by servers which are providing this service. If the server has been specifically configured as a replica for any zones, the Answer section of CONFIG response messages MUST Hall I-D Expires: February 2004 [page 3] Internet Draft draft-hall-resolver-config-00.txt July 2003 contain the Start-of-Authority resource records for each of those zones. In those cases where the message would be truncated, the server SHOULD provide as many resource records as will fit in the message, giving preference to the higher-level zones (such as providing the SOA resource record example.com. before providing the SOA resource record for ny.corp.example.com.), and MUST enable the Truncation flag. If a server has not been configured as a replica for any zones, the Answer section MUST be empty. CONFIG response message MUST NOT contain any entries in the Question, Authority, and Additional-Data sections. 6. Weighting Algorithm Given multiple choices, clients SHOULD choose either two or three servers from the resulting response messages and SHOULD discard any additional servers. In order to ensure predictable behavior among implementations, the following weighting algorithm MUST be used: a. Wait five seconds for all responses to arrive, and time their arrival. b. Sort the response messages, with messages that have the Recursion Available flag enabled the highest preference. c. Perform a secondary sort of the response messages according to the available zones, giving preference to those servers which advertise the client's local domain, if known. d. Give additional preference to servers which report the largest number of zones, with truncated responses having the highest preference. e. Perform an additional sort according to the response-time of the response messages, with the fastest responses having the highest preference. f. Optional: Use network-mask logic to determine if any of the server addresses are on the same subnet as the client, and give higher preference to those servers. g. Optional: Sort the response messages by the IP TTL of the response message, and give preference to the responses with Hall I-D Expires: February 2004 [page 4] Internet Draft draft-hall-resolver-config-00.txt July 2003 the highest TTL value. This will produce the servers which are "closest" to the client in terms of hop-count. h. Choose from any remaining servers at random. In the usual case, most clients are likely to produce the two or three "winning" servers within the first few steps. 7. Security Considerations TBD. 8. IANA Considerations IANA would need to assign a DNS opcode for CONFIG. IANA would need to delegate a multicast address. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [STD13] Mockapetris, P. "Domain Names - Concepts and Facilities", STD 13, RFC 1034 and "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. 10. Author's Addresses Eric A. Hall ehall@ehsco.com 11. Acknowledgments Funding for the RFC editor function is currently provided by the Internet Society. 12. Full Copyright Statement Copyright (C) The Internet Society (2003). 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, Hall I-D Expires: February 2004 [page 5] Internet Draft draft-hall-resolver-config-00.txt July 2003 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. Hall I-D Expires: February 2004 [page 6]