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