INTERNET-DRAFT M. Sawyer B. Wellington M. Graff Nominum 23 February 2001 Bind VIEW 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 what view of the DNS space should be used in query messages to a remote DNS server on servers which support such a concept, such as Bind version 9. 1.1 - Introduction Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms [RFC2671] is helpful. There exists at least one DNS server (for example, BIND version 9) 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 INFORMATIONAL - Expires August 2001 [Page 1] INTERNET-DRAFT VIEW option records October 2000 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 VIEW option record is intended as an optional feature; servers which have the concept of different views of the DNS space MAY support this option. 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. If such a mechanism is provided, it SHOULD allow a view name to be used in the request different than the view used on the server otherwise. Note that there is no global namespace for views, and servers under different administrative control may use a different naming scheme for views. Servers SHOULD NOT use the VIEW option in queries other than zone transfers in normal usage. Servers which support VIEW SHOULD support the option for all types of queries and administrators MAY use the VIEW option in queries for debugging purposes. Clients such as resolvers SHOULD NOT use the VIEW option in normal operations. 3.2 - VIEW option The VIEW OPTION contains a DNS name, as specified in [RFC1035] Section 3.3, which is used to match the name of the view in the server's configuration. Wildcards are not permitted in VIEW options. When a server receives a query with a VIEW option, it MUST reply with a REFUSED reply if it understands the VIEW option 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 option 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. INFORMATIONAL - Expires August 2001 [Page 2] INTERNET-DRAFT VIEW option records October 2000 4 - IANA considerations We request IANA assign option codes for the VIEW 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 this option, as it may provide outside users the ability to retrieve information otherwise not available. Servers SHOULD NOT use the VIEW option in any way in deciding if access to data is allowed, only if it is the preferred data being requested by the client. VIEW options SHOULD NOT be used in security policies determining who has access to data. Software developers SHOULD provide a mechanism of limiting who can make use of the VIEW option for security-conscious administrators. Sending a REFUSED reply for all possible VIEW option failures in an intentional feature of the protocol, specified for security reasons; this prevents an unauthorized client from learning whether a server is using views, what names are used for views, and what views it has access to. 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. INFORMATIONAL - Expires August 2001 [Page 3] INTERNET-DRAFT VIEW option records October 2000 [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 INFORMATIONAL - Expires August 2001 [Page 4]