idnits 2.17.1 draft-ietf-dnsind-edns0-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 expiration date. The document expiration date should appear on the first and last page. == 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 7 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.) ** The document seems to lack an Authors' Addresses Section. ** There are 70 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 102 has weird spacing: '...in name emp...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'RFC1035' on line 262 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND Working Group Paul Vixie 2 INTERNET-DRAFT ISC 3 June, 1999 5 Extension mechanisms for DNS (EDNS0) 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The Domain Name System's wire protocol includes a number of fixed 31 fields whose range has been or soon will be exhausted and does not 32 allow clients to advertise their capabilities to servers. This 33 document describes backward compatible mechanisms for allowing the 34 protocol to grow. 36 1 - Rationale and Scope 38 1.1. DNS (see [RFC1035]) specifies a Message Format and within such 39 messages there are standard formats for encoding options, errors, and 40 name compression. The maximum allowable size of a DNS Message is fixed. 41 Many of DNS's protocol limits are too small for uses which are or which 42 are desired to become common. There is no way for implementations to 43 advertise their capabilities. 45 1.2. Existing clients will not know how to interpret the protocol 46 extensions detailed here. In practice, these clients will be upgraded 47 when they have need of a new feature, and only new features will make 48 use of the extensions. We must however take account of client behaviour 49 in the face of extra fields, and design a fallback scheme for 50 interoperability with these clients. 52 2 - Affected Protocol Elements 54 2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit 55 word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of 56 1-bit flags. The original reserved Z bits have been allocated to 57 various purposes, and most of the RCODE values are now in use. More 58 flags and more possible RCODEs are needed. 60 2.2. The first two bits of a wire format domain label are used to denote 61 the type of the label. [RFC1035 4.1.4] allocates two of the four 62 possible types and reserves the other two. Proposals for use of the 63 remaining types far outnumber those available. More label types are 64 needed. 66 2.3. DNS Messages are limited to 512 octets in size when sent over UDP. 67 While the minimum maximum reassembly buffer size still allows a limit of 68 512 octets of UDP payload, most of the hosts now connected to the 69 Internet are able to reassemble larger datagrams. Some mechanism must 70 be created to allow requestors to advertise larger buffer sizes to 71 responders. 73 3 - Extended Label Types 75 3.1. The ``0 1'' label type will now indicate an extended label type, 76 whose value is encoded in the lower six bits of the first octet of a 77 label. All subsequently developed label types should be encoded using 78 an extended label type. 80 3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future 81 expansion of the extended label type code space. 83 4 - OPT pseudo-RR 85 4.1. One OPT pseudo-RR can be added to the additional data section of 86 either a request or a response. An OPT is called a pseudo-RR because it 87 pertains to a particular transport level message and not to any actual 88 DNS data. OPT RRs shall never be cached, forwarded, or stored in or 89 loaded from master files. The quantity of OPT pseudo-RRs per message 90 shall be either zero or one, but not greater. 92 4.2. An OPT RR has a fixed part and a variable set of options expressed 93 as {attribute, value} pairs. The fixed part holds some DNS meta data 94 and also a small collection of new protocol elements which we expect to 95 be so popular that it would be a waste of wire space to encode them as 96 {attribute, value} pairs. 98 4.3. The fixed part of an OPT RR is structured as follows: 100 Field Name Field Type Description 101 ------------------------------------------------------ 102 NAME domain name empty (root domain) 103 TYPE u_int16_t OPT 104 CLASS u_int16_t sender's UDP payload size 105 TTL u_int32_t extended RCODE and flags 106 RDLEN u_int16_t describes RDATA 107 RDATA octet stream {attribute,value} pairs 109 4.4. The variable part of an OPT RR is encoded in its RDATA and is 110 structured as zero or more of the following: 112 +0 (MSB) +1 (LSB) 113 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 114 0: | OPTION-CODE | 115 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 116 2: | OPTION-LENGTH | 117 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 118 4: | | 119 / OPTION-DATA / 120 / / 121 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 123 OPTION-CODE (Assigned by IANA.) 125 OPTION-LENGTH Size (in octets) of OPTION-DATA. 127 OPTION-DATA Varies per OPTION-CODE. 129 4.5. The sender's UDP payload size (which OPT stores in the RR CLASS 130 field) is the number of octets of the largest UDP payload that can be 131 reassembled and delivered in the sender's network stack. Note that path 132 MTU, with or without fragmentation, may be smaller than this. 134 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP 135 reassembly buffer. Choosing 1280 on an Ethernet connected requestor 136 would be reasonable. The consequence of choosing too large a value may 137 be an ICMP message from an intermediate gateway, or even a silent drop 138 of the response message. 140 4.5.2. Both requestors and responders are advised to take account of the 141 path's discovered MTU (if already known) when considering message sizes. 143 4.5.3. The requestor's maximum payload size can change over time, and 144 should therefore not be cached for use beyond the transaction in which 145 it is advertised. 147 4.5.4. The responder's maximum payload size can change over time, but 148 can be reasonably expected to remain constant between two sequential 149 transactions; for example, a meaningless QUERY to discover a responder's 150 maximum UDP payload size, followed immediately by an UPDATE which takes 151 advantage of this size. (This is considered preferrable to the outright 152 use of TCP for oversized requests, if there is any reason to suspect 153 that the responder implements EDNS, and if a request will not fit in the 154 default 512 payload size limit.) 156 4.5.5. Due to transaction overhead, it is unwise to advertise an 157 architectural limit as a maximum UDP payload size. Just because your 158 stack can reassemble 64KB datagrams, don't assume that you want to spend 159 more than about 4KB of state memory per ongoing transaction. 161 4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) 162 are structured as follows: 164 +0 (MSB) +1 (LSB) 165 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 166 0: | EXTENDED-RCODE | VERSION | 167 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 168 2: | Z | 169 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 171 EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that 172 EXTENDED-RCODE value "0" indicates that an unextended 173 RCODE is in use (values "0" through "15"). 175 VERSION Indicates the implementation level of whoever sets it. 176 Full conformance with this specification is indicated by 177 version ``0.'' Requestors are encouraged to set this to 178 the lowest implemented level capable of expressing a 179 transaction, to minimize the responder and network load 180 of discovering the greatest common implementation level 181 between requestor and responder. A requestor's version 182 numbering strategy should ideally be a run time 183 configuration option. 185 If a responder does not implement the VERSION level of 186 the request, then it answers with RCODE=BADVERS. All 187 responses will be limited in format to the VERSION level 188 of the request, but the VERSION of each response will be 189 the highest implementation level of the responder. In 190 this way a requestor will learn the implementation level 191 of a responder as a side effect of every response, 192 including error responses, including RCODE=BADVERS. 194 Z Set to zero by senders and ignored by receivers, unless 195 modified in a subsequent specification. 197 5 - Transport Considerations 199 5.1. The presence of an OPT pseudo-RR in a request should be taken as an 200 indication that the requestor fully implements the given version of 201 EDNS, and can correctly understand any response that conforms to that 202 feature's specification. 204 5.2. Lack of use of these features in a request must be taken as an 205 indication that the requestor does not implement any part of this 206 specification and that the responder may make no use of any protocol 207 extension described here in its response. 209 5.3. Responders who do not understand these protocol extensions are 210 expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. 211 Therefore use of extensions should be ``probed'' such that a responder 212 who isn't known to support them be allowed a retry with no extensions if 213 it responds with such an RCODE. If a responder's capability level is 214 cached by a requestor, a new probe should be sent periodically to test 215 for changes to responder capability. 217 6 - Security Considerations 219 Requestor-side specification of the maximum buffer size may open a new 220 DNS denial of service attack if responders can be made to send messages 221 which are too large for intermediate gateways to forward, thus leading 222 to potential ICMP storms between gateways and responders. 224 7 - IANA Considerations 226 IANA is hereby requested to assign an RR type code for OPT. 228 It is the recommendation of this document and its working group that 229 IANA create a registry for EDNS Extended Label Types, for EDNS Option 230 Codes, and for EDNS Version Numbers. 232 This document assigns label type 0b01xxxxxx as "EDNS Extended Label 233 Type." We request that IANA record this assignment. 235 This document assigns extended label type 0bxx111111 as "Reserved for 236 future extended label types." We request that IANA record this 237 assignment. 239 This document assigns option code 65535 to "Reserved for future 240 expansion." 242 This document expands the RCODE space from 4 bits to 12 bits. This will 243 allow IANA to assign more than the 16 distinct RCODE values allowed in 244 [RFC1035]. 246 This document assigns EDNS Extended RCODE "16" to "BADVERS". 248 IESG approval should be required to create new entries in the EDNS 249 Extended Label Type or EDNS Version Number registries, while any 250 published RFC (including Informational, Experimental, or BCP) should be 251 grounds for allocation of an EDNS Option Code. 253 8 - Acknowledgements 255 Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, 256 Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas 257 Narten were each instrumental in creating and refining this 258 specification. 260 9 - References 262 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 263 Specification,'' RFC 1035, USC/Information Sciences 264 Institute, November 1987. 266 10 - Author's Address 268 Paul Vixie 269 Internet Software Consortium 270 950 Charter Street 271 Redwood City, CA 94063 272 +1 650 779 7001 273