draft-sawyer-dnsext-edns0-zone-option-00.txt

bind-3.2.

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: [phone]
   [e-mail]

   Brian Wellington
   Nominum, Inc.
   950 Charter St.
   Redwood City, CA  94063
   Phone: [phone]
   [e-mail]

   Michael Graff
   Nominum, Inc.
   950 Charter St.
   Redwood City, CA  94063
   Phone: [phone]
   [e-mail]






















Expires April 2001                                             [Page 4]