INTERNET-DRAFT M. Sawyer
B. Wellington
M. Graff
Nominum
<draft-ietf-dnsext-edns-zone-option-00.txt> 23 February 2001
ZONE option in DNS messages
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
This draft expires on August 23, 2001. It is intended as an
informational document.
Abstract
This document defines a new EDNS option code used to specify the zone
from which a remote DNS server should answer queries.
1.1 - Introduction
Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms
[RFC2671] is helpful.
Domain Concepts and Facilities [RFC1034] Section 3.7 shows a typical
reply to a DNS query, containing the answer as well as additional
data related to the answer provided. The server's zone database may
contain out-of-zone data glue which is internally used but is never
returned in a reply to a query. If recursion is requested by the
INFORMATIONAL - Expires August 2001 [Page 1]
INTERNET-DRAFT ZONE options October 2000
client and available in the server, or if the data is available in
the server's cache, the additional information will be taken from
these sources on most servers.
There is no method currently available for an administrator to query
a server specifying that only data from a specific zone should be
used in formulating the reply and that all available data from that
zone's database should be used, including out-of-zone glue. As such,
there is no mechanism for an administrator to ensure that out-of-zone
data in the zone's database is correct except through direct
manipulation of the zone database files. The ZONE option code is
provided to specify directly which zone database should be queried.
1.2 - Requirements
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].
2 - Protocol changes:
This document updates [RFC2671]. The ZONE option is intended as an
optional feature, server support is fully optional. Servers SHOULD
provide configuration options to enable or disable this option as
needed.
Servers and clients SHOULD NOT use the ZONE option code in normal
use. Servers SHOULD NOT use the ZONE option in zone transfers under
any configuration.
3.1 - ZONE option
The ZONE OPTION-DATA MUST contain a standard uncompressed wire-format
name in the format specified by [RFC1035] Section 3.3. Wildcards are
not permitted in ZONE options.
When a server receives a query with a ZONE option, it MUST reply with
a REFUSED reply if it understands the ZONE option but is not
configured to allow ZONE specific requests, if the specified zone
does not exist on the server, or if the client is not authorized to
use the ZONE option. If the ZONE option is allowed, it MUST return a
normally formatted reply with a ZONE option, containing the same zone
as the one queried. If the server allows the ZONE option to be used,
it MUST use only data from the specified zone's database in
generating the reply.
Servers SHOULD treat ZONE options in zone transfer requests as an
unauthorized request and return FORMERR. Servers SHOULD NOT allow
INFORMATIONAL - Expires August 2001 [Page 2]
INTERNET-DRAFT ZONE options October 2000
ZONE options in recursive queries, and return FORMERR in such cases.
4 - IANA considerations
We request IANA assign option codes for the ZONE option. We further
request that these numbers be assigned as "required options" (in the
number space 0x8000 through 0xEFFF) should <draft-dnsext-edns-
attributes-01> be advanced to an RFC. Because there is currently no
meaning assigned to where in the option space an option code falls
and it will be difficult to renumber these options at a later date
should the edns-attributes draft be promoted, we request that the
numbers be assigned in the above-named space even if the above draft
has yet to advance.
5 - Security considerations
This document provides a mechanism for users to override the default
behavior of the server when accessing data from its internal zone
databases. Software developers and administrators should use some
care when enabling these options, as they may provide outside users
the ability to retrieve information otherwise not available.
6 - Acknowledgments
The authors would like to thank Olafur Gudmundsson, Cricket Liu, and
Harald Alvestrand for their input on this draft.
7 - References
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and
Facilities,'' RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC2119] S. Brander, ``Key words for use in RFCs to Indicate
Requirement Levels,'' RFC 2119, ISI, November 1997.
[RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC
2671, ISI, August, 1999
Author's Address
Michael Sawyer
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
INFORMATIONAL - Expires August 2001 [Page 3]
INTERNET-DRAFT ZONE options October 2000
Phone: +1-650-779-6021
michael.sawyer@nominum.com
Brian Wellington
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1-650-779-6022
brian.wellington@nominum.com
Michael Graff
Nominum, Inc.
950 Charter St.
Redwood City, CA 94063
Phone: +1-650-779-6034
michael.graff@nominum.com
INFORMATIONAL - Expires August 2001 [Page 4]
