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 <TBD>. 
      
     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 <TBD>. 
      
     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 <TBD> 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 <TBD>. 
      
     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]