idnits 2.17.1 draft-ietf-dnsext-edns-bind-view-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (23 February 2001) is 8435 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC1034' on line 138 looks like a reference -- Missing reference section? 'RFC1035' on line 141 looks like a reference -- Missing reference section? 'RFC2671' on line 147 looks like a reference -- Missing reference section? 'RFC2119' on line 144 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Sawyer 3 B. Wellington 4 M. Graff 5 Nominum 6 23 February 2001 8 Bind VIEW option in DNS messages 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This draft expires on August 23, 2001. It is intended as an 32 informational document. 34 Abstract 36 This document defines a new EDNS option code used to specify what 37 view of the DNS space should be used in query messages to a remote 38 DNS server on servers which support such a concept, such as Bind 39 version 9. 41 1.1 - Introduction 43 Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms 44 [RFC2671] is helpful. 46 There exists at least one DNS server (for example, BIND version 9) 47 software exists which may present different "views" of the DNS space 48 to different clients. In some cases, a query may match the criteria 49 of multiple views, and a user may wish to specify which of the 50 acceptable views match the query. The VIEW option code is provided 51 to specify which view should be searched for the appropriate zone 52 database. 54 1.2 - Requirements 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 2 - Protocol changes: 62 This document updates [RFC2671]. The VIEW option record is intended 63 as an optional feature; servers which have the concept of different 64 views of the DNS space MAY support this option. 66 Servers SHOULD NOT use the VIEW option record in zone transfers 67 unless the administrator has specifically configured the server to 68 use these records. Servers MAY provide a mechanism for such 69 configuration. If such a mechanism is provided, it SHOULD allow a 70 view name to be used in the request different than the view used on 71 the server otherwise. Note that there is no global namespace for 72 views, and servers under different administrative control may use a 73 different naming scheme for views. 75 Servers SHOULD NOT use the VIEW option in queries other than zone 76 transfers in normal usage. Servers which support VIEW SHOULD support 77 the option for all types of queries and administrators MAY use the 78 VIEW option in queries for debugging purposes. 80 Clients such as resolvers SHOULD NOT use the VIEW option in normal 81 operations. 83 3.2 - VIEW option 85 The VIEW OPTION contains a DNS name, as specified in [RFC1035] 86 Section 3.3, which is used to match the name of the view in the 87 server's configuration. Wildcards are not permitted in VIEW options. 89 When a server receives a query with a VIEW option, it MUST reply with 90 a REFUSED reply if it understands the VIEW option but is not 91 configured to allow VIEW specific requests, the specified view does 92 not exist, or the client is not authorized to access the specified 93 view. If a VIEW option is allowed, it MUST return a normally 94 formatted reply with a VIEW option containing the same view as the 95 one queried. The information used in generating the reply should 96 contain only information from the specified view of the DNS space. 98 4 - IANA considerations 100 We request IANA assign option codes for the VIEW option. We further 101 request that these numbers be assigned as "required options" (in the 102 number space 0x8000 through 0xEFFF) should be advanced to an RFC. Because there is 104 currently no meaning assigned to where in the option space an option 105 code falls and it will be difficult to renumber these options at a 106 later date should the edns-attributes draft be promoted, we request 107 that the numbers be assigned in the above-named space even if the 108 above draft has yet to advance. 110 5 - Security considerations 112 This document provides a mechanism for users to override the default 113 behavior of the server when accessing data from its internal zone 114 databases. Software developers and administrators should use some 115 care when enabling this option, as it may provide outside users the 116 ability to retrieve information otherwise not available. 118 Servers SHOULD NOT use the VIEW option in any way in deciding if 119 access to data is allowed, only if it is the preferred data being 120 requested by the client. VIEW options SHOULD NOT be used in security 121 policies determining who has access to data. Software developers 122 SHOULD provide a mechanism of limiting who can make use of the VIEW 123 option for security-conscious administrators. 125 Sending a REFUSED reply for all possible VIEW option failures in an 126 intentional feature of the protocol, specified for security reasons; 127 this prevents an unauthorized client from learning whether a server 128 is using views, what names are used for views, and what views it has 129 access to. 131 6 - Acknowledgments 133 The authors would like to thank Olafur Gudmundsson, Cricket Liu, and 134 Harald Alvestrand for their input on this draft. 136 7 - References 138 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and 139 Facilities,'' RFC 1034, ISI, November 1987. 141 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 142 Specification,'' RFC 1035, ISI, November 1987. 144 [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate 145 Requirement Levels,'' RFC 2119, ISI, November 1997. 147 [RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC 148 2671, ISI, August, 1999 150 Author's Address 152 Michael Sawyer 153 Nominum, Inc. 154 950 Charter St. 155 Redwood City, CA 94063 156 Phone: +1-650-779-6021 157 michael.sawyer@nominum.com 159 Brian Wellington 160 Nominum, Inc. 161 950 Charter St. 162 Redwood City, CA 94063 163 Phone: +1-650-779-6022 164 brian.wellington@nominum.com 166 Michael Graff 167 Nominum, Inc. 168 950 Charter St. 169 Redwood City, CA 94063 170 Phone: +1-650-779-6034 171 michael.graff@nominum.com