Internet DRAFT - draft-hall-resolver-config
draft-hall-resolver-config
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]
