--- /dev/null
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / thirdparty / bind9.git / commitdiff
