idnits 2.17.1 draft-ietf-dnsext-edns-zone-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 8456 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 126 looks like a reference -- Missing reference section? 'RFC1035' on line 129 looks like a reference -- Missing reference section? 'RFC2671' on line 135 looks like a reference -- Missing reference section? 'RFC2119' on line 132 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 ZONE 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 the zone 37 from which a remote DNS server should answer queries. 39 1.1 - Introduction 41 Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms 42 [RFC2671] is helpful. 44 Domain Concepts and Facilities [RFC1034] Section 3.7 shows a typical 45 reply to a DNS query, containing the answer as well as additional 46 data related to the answer provided. The server's zone database may 47 contain out-of-zone data glue which is internally used but is never 48 returned in a reply to a query. If recursion is requested by the 49 client and available in the server, or if the data is available in 50 the server's cache, the additional information will be taken from 51 these sources on most servers. 53 There is no method currently available for an administrator to query 54 a server specifying that only data from a specific zone should be 55 used in formulating the reply and that all available data from that 56 zone's database should be used, including out-of-zone glue. As such, 57 there is no mechanism for an administrator to ensure that out-of-zone 58 data in the zone's database is correct except through direct 59 manipulation of the zone database files. The ZONE option code is 60 provided to specify directly which zone database should be queried. 62 1.2 - Requirements 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 2 - Protocol changes: 70 This document updates [RFC2671]. The ZONE option is intended as an 71 optional feature, server support is fully optional. Servers SHOULD 72 provide configuration options to enable or disable this option as 73 needed. 75 Servers and clients SHOULD NOT use the ZONE option code in normal 76 use. Servers SHOULD NOT use the ZONE option in zone transfers under 77 any configuration. 79 3.1 - ZONE option 81 The ZONE OPTION-DATA MUST contain a standard uncompressed wire-format 82 name in the format specified by [RFC1035] Section 3.3. Wildcards are 83 not permitted in ZONE options. 85 When a server receives a query with a ZONE option, it MUST reply with 86 a REFUSED reply if it understands the ZONE option but is not 87 configured to allow ZONE specific requests, if the specified zone 88 does not exist on the server, or if the client is not authorized to 89 use the ZONE option. If the ZONE option is allowed, it MUST return a 90 normally formatted reply with a ZONE option, containing the same zone 91 as the one queried. If the server allows the ZONE option to be used, 92 it MUST use only data from the specified zone's database in 93 generating the reply. 95 Servers SHOULD treat ZONE options in zone transfer requests as an 96 unauthorized request and return FORMERR. Servers SHOULD NOT allow 97 ZONE options in recursive queries, and return FORMERR in such cases. 99 4 - IANA considerations 101 We request IANA assign option codes for the ZONE option. We further 102 request that these numbers be assigned as "required options" (in the 103 number space 0x8000 through 0xEFFF) should be advanced to an RFC. Because there is currently no 105 meaning assigned to where in the option space an option code falls 106 and it will be difficult to renumber these options at a later date 107 should the edns-attributes draft be promoted, we request that the 108 numbers be assigned in the above-named space even if the above draft 109 has yet to advance. 111 5 - Security considerations 113 This document provides a mechanism for users to override the default 114 behavior of the server when accessing data from its internal zone 115 databases. Software developers and administrators should use some 116 care when enabling these options, as they may provide outside users 117 the ability to retrieve information otherwise not available. 119 6 - Acknowledgments 121 The authors would like to thank Olafur Gudmundsson, Cricket Liu, and 122 Harald Alvestrand for their input on this draft. 124 7 - References 126 [RFC1034] P. Mockapetris, ``Domain Names - Concepts and 127 Facilities,'' RFC 1034, ISI, November 1987. 129 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 130 Specification,'' RFC 1035, ISI, November 1987. 132 [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate 133 Requirement Levels,'' RFC 2119, ISI, November 1997. 135 [RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC 136 2671, ISI, August, 1999 138 Author's Address 140 Michael Sawyer 141 Nominum, Inc. 142 950 Charter St. 143 Redwood City, CA 94063 144 Phone: +1-650-779-6021 145 michael.sawyer@nominum.com 147 Brian Wellington 148 Nominum, Inc. 149 950 Charter St. 150 Redwood City, CA 94063 151 Phone: +1-650-779-6022 152 brian.wellington@nominum.com 154 Michael Graff 155 Nominum, Inc. 156 950 Charter St. 157 Redwood City, CA 94063 158 Phone: +1-650-779-6034 159 michael.graff@nominum.com