INTERNET-DRAFT M. Sawyer B. Wellington M. Graff Nominum 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 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]