222 lines
7.5 KiB
Plaintext
222 lines
7.5 KiB
Plaintext
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]
|
||
|