[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                                 M. Sawyer
                                                           B. Wellington
                                                                M. Graff
<draft-ietf-dnsext-edns-bind-view-option-00.txt>        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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This draft expires on August 23, 2001.  It is intended as an
   informational document.


   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

1.2 - Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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

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 <draft-msawyer-dnsext-
   edns-attributes-01> 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

   Brian Wellington
   Nominum, Inc.
   950 Charter St.
   Redwood City, CA  94063
   Phone: +1-650-779-6022

   Michael Graff
   Nominum, Inc.
   950 Charter St.
   Redwood City, CA  94063
   Phone: +1-650-779-6034

INFORMATIONAL - Expires August 2001                            [Page 4]