idnits 2.17.1 draft-ietf-dnsext-edns0dot5-02.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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '... - MUST include all FEATUREs that th...' RFC 2119 keyword, line 138: '... - MAY include all FEATURES that the...' RFC 2119 keyword, line 155: '... are relevant or useful, a server MUST...' 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 (November 2000) is 8560 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: 'TBD' is mentioned on line 117, but not defined == Unused Reference: 'DNS-CONCEPTS' is defined on line 227, but no explicit reference was found in the text == Unused Reference: 'DNS-IMPLEMENTATION' is defined on line 230, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (ref. 'EDNS0') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2673 (ref. 'BINARY-LABELS') (Obsoleted by RFC 6891) Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Austein 3 draft-ietf-dnsext-edns0dot5-02.txt InterNetShare.com, Inc. 4 H. Alvestrand 5 Cisco Systems 6 November 2000 8 A Proposed Enhancement to the EDNS0 Version Mechanism 10 Status of this document 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 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 28 The list of Internet-Draft Shadow Directories can be accessed at 29 31 Distribution of this document is unlimited. Please send comments to 32 the Namedroppers mailing list . 34 Motivation and Scope 36 EDNS0 [EDNS0] specifies a general framework for extending the packet 37 format used by the Domain Name System protocols. The framework 38 includes a simple version numbering scheme to allow the parties in a 39 DNS protocol exchange to determine which extension features the other 40 party understands. While having the advantage of simplicity, the 41 version numbering scheme as specified has drawbacks: 43 - It provides no way to deprecate a protocol feature; 45 - It provides no way to deploy experimental protocol features. 47 This note proposes to augument the monolithic version numbering 48 mechanism with a mechanism for listing an explicit set of protocol 49 features that a particular implementation supports. We retain 50 version numbering as a way of abbreviating the feature sets that we 51 expect to see in common use. 53 Model 55 Our revised extension model for the DNS is designed with three goals 56 in mind: 58 - We want the protocol to be as simple as possible for the common 59 case of a client or server that implements "mainstream standard 60 DNS"; 62 - We want to provide a safe way to experiment with new protocol 63 features, both inside and outside the deployed DNS; 65 - We want to provide a safe way to deprecate protocol features. 67 Our revised extension model has two parts, both of which are carried 68 in the OPT pseudo-RR: the VERSION, which stored in the second octet 69 of the TTL field of the OPT RR, and a variable-length list of 70 FEATURES, stored in the variable part of the OPT RR. 72 All FEATUREs are extensions of the DNS. We reserve the range of 73 FEATURE numbers from 1 to 100 for describing features of the original 74 RFC 1034/1035 DNS specification that we might eventually choose to 75 deprecate. 77 Any query/response pair can be described as using a set of DNS 78 FEATUREs. Such features might for instance be: 80 - Domain binary labels according to [BINARY-LABELS]; 82 - Extended RCODEs (the general principle, not specific values); 84 - Multi-packet UDP response; 86 - Increased maximum UDP payload size; 88 - Character set identification in DNS labels; 90 - SIG record parsing and checking; 92 FEATURE numbers are handed out by IANA on a first-come-first-served 93 basis within their appropriate ranges. Any revised specification of 94 a format or function should have its own FEATURE number; in the IETF 95 process, any significantly changed Internet-Draft should have a new 96 FEATURE number assigned for experimentation. 98 An assigned VERSION number names a set of FEATUREs. VERSION numbers 99 are assigned by the IETF through a standards action. 101 Normally, any VERSION number encompasses every FEATURE of all lower 102 VERSION numbers, but the possibility of removing FEATUREs exists for 103 two reasons: 105 - To remove the need for supporting FEATUREs that turned out to be a 106 Really Bad Idea; 108 - To allow replacing a badly specified FEATURE with a better 109 specified FEATURE performing the same function that has a new 110 FEATURE number. 112 Mechanism 114 We transport explicit feature sets as lists of integers carried in 115 the variable RDATA portion of the EDNS0 OPT pseudo-RR. 117 The OPTION-CODE for FEATURES is [TBD]. 119 The OPTION-DATA for FEATURES is an ordered list of "feature numbers"; 120 a feature number is represented as a big-endian 16-bit unsigned 121 integer, and the list is sorted into numerically increasing order. 123 Each feature number names a particular protocol feature that is 124 supported by the implementation that generated this OPT pseudo-RR. 126 Usage 128 In most respects, the FEATURE mechanism is used symmetrically by 129 clients and servers; exceptions to this rule are stated after the 130 general explanation. 132 When composing a DNS message, a client or server includes an OPT 133 record indicating a set of FEATUREs that: 135 - MUST include all FEATUREs that the client or server believes are 136 relevant to this message; 138 - MAY include all FEATURES that the client or server is prepared to 139 receive. 141 This set is expressed as a VERSION and any additional FEATURES 142 required. 144 In general, we expect that a client or server will include an OPT 145 pseudo-RR that indicates: 147 - The highest VERSION number that the entity generating the message 148 supports; and 150 - A small (possibly empty) set of additional FEATUREs not encompassed 151 by the VERSION that the entity deems necessary or desirable. 153 The above symmetry notwithstanding, we impose one important 154 constraint on the server: while a server is allowed to indicate 155 whatever FEATUREs it believes are relevant or useful, a server MUST 156 NOT make use of any FEATURE in a response that is not within the set 157 of FEATUREs indicated by the client that generated the corresponding 158 request. That is, a response may say "I support FEATURE FOO" 159 regardless of what the client supports, but the rest of the response 160 must not use FEATURE FOO unless the client also supports it. 162 As a special case, if a client explicitly queries for the OPT RR of 163 the root zone, the server returns an OPT record including all 164 FEATUREs that the server supports. This functionality is provided 165 strictly for diagnostic purposes. 167 Life Cycle 169 We expect the life cycle of new features to proceed as follows: 171 - VERSION X is defined and deployed. 173 - A new FEATURE is defined and experimentally implemented. All 174 clients and servers taking part in the experiment use FEATURE to 175 indicate support. 177 - Community consensus is reached that this FEATURE is genuinely 178 useful. 180 - VERSION X+1 is defined, encompassing all FEATUREs from VERSION X, 181 plus the new FEATURE (and perhaps others). 183 - The next generation of DNS software supports VERSION X+1, and never 184 use FEATURE. 186 Risks 188 While we have tried to provide the ability to deprecate old bad 189 protocol features, such an ability should be used only rarely, if at 190 all, since by any realistic estimate it takes years (decades?) to 191 upgrade all the DNS implementations already in the field. 193 A flexible extension mechanism of this type increases the risk that 194 some implementors might chose to deploy features designed to hinder 195 interoperability (so-called "labeled noninteroperability"). 197 Security Considerations 199 We do not believe that this protocol enhancement adds any major new 200 security risks, but we do believe that it would be helpful in getting 201 complicated DNS extensions such as [DNSSEC] deployed more quickly. 203 As with any enhancement to or complication of the DNS protocol, this 204 enhancement offers attackers yet another way to increase the load on 205 a name server. Root, TLD and other "major" name servers should view 206 excessively complicated FEATURE sets with suspicion, and should not 207 allow themselves to be tricked into performing more work than is 208 really necessary. 210 IANA Considerations 212 IANA will need to allocate an EDNS0 option code for FEATURES. 214 IANA will need to create a new registry of feature numbers. 216 Acknowledgments 218 The authors would like to thank the following people for their help 219 in improving this document: Randy Bush, Patrik Faltstrom, Olafur 220 Gudmundsson, Bob Halley, and XXX. 222 References 224 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 225 2535, March 1999. 227 [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and 228 facilities", RFC 1034, November 1987. 230 [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation 231 and specification", RFC 1035, November 1987. 233 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 234 August 1999. 236 [BINARY-LABELS] Crawford, M., "Binary Labels in the Domain Name 237 System", RFC 2673 August 1999. 239 Author's addresses: 241 Rob Austein 242 InterNetShare.com, Inc. 243 505 West Olive Ave., Suite 321 244 Sunnyvale, CA 94086 245 USA 247 sra@hactrn.net 249 Harald Tveit Alvestrand 250 Cisco Systems 251 Weidemanns vei 27 252 N-7043 Trondheim 253 NORWAY 255 +47 73 50 33 52 256 Harald@Alvestrand.no