INTERNET-DRAFT M. Sawyer
B. Wellington
M. Graff
Nominum
<draft-sawyer-dnsext-edns0-zone-option-00.txt> 9 October 2000
ZONE and VIEW option records 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 April 9, 2001.
Abstract
This document defines two new EDNS option codes used to specify what
zone and view should be used in query messages to a remote DNS
server.
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
client and available in the server, or if the data is available in
Expires April 2001 [Page 1]
INTERNET-DRAFT ZONE and VIEW option records October 2000
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. In addition, zone transfers
via AXFR or IXFR do not include out-of-zone glue. The ZONE option
code is provided to specify directly which zone database should be
queried.
In addition, DNS server software exists which may present different
"views" of the DNS space to different clients. In some cases, a
query may match the criteria of multiple views, and a user may wish
to specify which of the acceptable views match the query. The VIEW
option code is provided to specify which view should be searched for
the appropriate zone database.
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 and VIEW option records
are intended as optional features. Servers MAY support either or
both of these options. Servers SHOULD provide configuration options
to enable or disable these optional records as needed.
Servers and clients SHOULD NOT use the ZONE or VIEW option codes in
normal use.
Servers SHOULD NOT use the VIEW option record in zone transfers
unless the administrator has specifically configured the server to
use these records. Servers MAY provide a mechanism for such
configuration. Servers SHOULD NOT use the ZONE option record in zone
transfers under any configuration.
3 - ZONE option record
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 option records.
Expires April 2001 [Page 2]
INTERNET-DRAFT ZONE and VIEW option records October 2000
When a server receives a query with a ZONE option record, it MUST
reply with a REFUSED reply if it understands the ZONE record 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 optional record, containing the
same zone as the one queried. When replying to AXFR or IXFR queries
with ZONE options, the entire zone, including out-of-zone glue,
should be returned to the client.
Servers SHOULD treat ZONE options in zone transfer requests as an
unauthorized request and return REFUSED.
3.2 - VIEW option record
The VIEW OPTION-RECORD contains an arbitrary length text field, which
is used to match the name of the view in the server's configuration.
When a server receives a query with a VIEW option record, it MUST
reply with a REFUSED reply if it understands the VIEW record but is
not configured to allow VIEW specific requests, the specified view
does not exist, or the client is not authorized to access the
specified view. If a VIEW option is allowed, it MUST return a
normally formatted reply with a VIEW optional record containing the
same view as the one queried. The information used in generating the
reply should contain only information from the specified view of the
DNS space.
4 - IANA considerations
We request IANA assign option codes for the ZONE and VIEW options.
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 - 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.
Expires April 2001 [Page 3]
INTERNET-DRAFT ZONE and VIEW option records October 2000
[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
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
Expires April 2001 [Page 4]