diff --git a/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt b/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt new file mode 100644 index 0000000000..574b5f2940 --- /dev/null +++ b/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt @@ -0,0 +1,221 @@ +INTERNET-DRAFT M. Sawyer + B. Wellington + M. Graff + Nominum + 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] +