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]