[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/