idnits 2.17.1 draft-ietf-dnsind-edns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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 74 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 125 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 246 looks like a reference -- Missing reference section? 'CRAW98' on line 250 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSIND Working Group Paul Vixie 3 INTERNET-DRAFT Vixie Enterprises 4 March, 1998 6 Extensions to DNS (EDNS) 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 Abstract 28 The Domain Name System's wire protocol includes a number of fixed 29 fields whose range has been or soon will be exhausted. This document 30 describes backward compatible mechanisms for allowing the protocol to 31 grow. 33 1 - Rationale and Scope 35 1.1. DNS (see [RFC1035]) specifies a Message Format and within such 36 messages there are standard formats for encoding options, errors, and 37 name compression. The maximum allowable size of a DNS Message is fixed. 38 Many of DNS's protocol limits are too small for uses which are or which 39 are desired to become common. 41 1.2. Existing clients will not know how to interpret the protocol 42 extensions detailed here. In practice, these clients will be upgraded 43 when they have need of a new feature, and only new features will make 44 use of the extensions. We must however take account of client behaviour 45 in the face of extra fields, and design a fallback scheme for 46 interoperability with these clients. 48 2 - Affected Protocol Elements 50 2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit 51 word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of 52 1-bit flags. The original reserved Z bits have been allocated to 53 various purposes, and most of the RCODE values are now in use. More 54 types and more possible RCODEs are needed. 56 2.2. The first two bits of a wire format domain label are used to denote 57 the type of the label. [RFC1035 4.1.4] allocates two of the four 58 possible types and reserves the other two. Proposals for use of the 59 remaining types far outnumber those available. More label types are 60 needed. 62 2.3. Compression pointers are 14 bits in size and are relative to the 63 start of the DNS Message, which can be 64KB in length. 14 bits restrict 64 pointers to the first 16KB of the message, which makes labels introduced 65 in the last 48KB of the message unreachable by compression pointers. A 66 longer pointer format is needed. 68 2.4. DNS Messages are limited to 512 octets in size when sent over UDP. 69 While the minimum maximum reassembly buffer size is still 512 bytes, 70 most of the hosts now connected to the Internet are able to reassemble 71 larger datagrams. Some mechanism must be created to allow requestors to 72 advertise larger buffer sizes to responders. 74 2.5. DNS Messages are limited to 65535 octets in size when sent over 75 TCP. This acts as an effective maximum on RRset size and on RR size, 76 since multiple TCP messages are only possible in the case of zone 77 transfers. Some mechanism must be created to allow normal DNS responses 78 (other than zone transfers) to span multiple DNS Messages when TCP is 79 used. 81 2.6. Multiple queries in a question section have not been supported in 82 DNS due the applicability of some DNS Message Header flags (such as AA) 83 and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. 84 Multiple questions per request are desirable, and some way of asking 85 them must be made available. 87 3 - Extended Label Types 89 3.1. The ``1 0'' label type will now indicate an extended label type, 90 whose value is encoded in the lower six bits of the first octet of a 91 label. All subsequently developed label types should be encoded using 92 an extended label type. The ``0 1'' label type should be permanently 93 reserved. 95 3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended 96 compression pointer, such that the following two octets comprise a 97 16-bit compression pointer in network byte order. Like the normal 98 compression pointer, this pointer is relative to the start of the DNS 99 Message. 101 3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit 102 string label with interior longest-match query matching semantics as 103 described in [CRAW98]. 105 3.4. XXX Any other former contenders for the unextended label types? XXX 107 4 - OPT pseudo-RR 109 4.1. The OPT pseudo-RR can be added to the additional data section of 110 either a request or a response. An OPT is called a pseudo-RR because it 111 pertains to a particular transport level message and not to any actual 112 DNS data. OPT RRs shall never be cached, forwarded, or stored in or 113 loaded from master files. 115 4.2. An OPT RR has a fixed part and a variable set of options expressed 116 as {attribute, value} pairs. The fixed part holds some DNS meta data 117 and also a small collection of new protocol elements which we expect to 118 be so popular that it would be a waste of wire space to encode them as 119 {attribute, value} pairs. 121 4.3. The fixed part of an OPT RR is structured as follows: 123 Field Name Field Type Description 124 ----------------------------------------------------- 125 NAME domain name empty (root domain) 126 TYPE u_int16_t OPT (XXX code) 127 CLASS u_int16_t sender's UDP buffer size 128 TTL u_int32_t extended RCODE and flags 129 RDLEN u_int16_t describes RDATA 130 RDATA octet stream {attribute,value} pairs 131 4.4. The variable part of an OPT RR is encoded in its RDATA and is 132 structured as zero or more of the following: 134 +0 (MSB) +1 (LSB) 135 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 136 0: | OPTION-LENGTH | OPTION-CODE | 137 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 138 2: | | 139 / OPTION-DATA / 140 / / 141 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 143 OPTION-LENGTH Size (in octets) of OPTION-DATA. 145 OPTION-CODE Assigned by the IANA. Value 255 is reserved for future 146 expansion. 148 OPTION-DATA Varies per OPTION-CODE. 150 4.5. The sender's UDP buffer size is the number of octets of the largest 151 UDP payload that is reassemblable and deliverable in the sender's 152 network stack. Note that path MTU, with or without fragmentation, may 153 be smaller than this. Also note that a 512-octet UDP payload requires a 154 576-octet IP reassembly buffer. Choosing 1436 on an Ethernet connected 155 requestor would be reasonable. 157 4.6. The extended RCODE and flags are structured as follows: 159 +0 (MSB) +1 (LSB) 160 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 161 0: | EXTENDED-RCODE | VERSION | 162 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 163 2: |MD |FM | Z | 164 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 166 EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. 167 (Meaningless in requests.) 169 VERSION Indicates the implementation level of whoever sets it. 170 Full conformance with the draft standard version of this 171 specification is version ``0.'' 173 Z Set to zero by senders and ignored by receivers, unless 174 modified in a subsequent specification. 176 MD ``More data'' flag. Valid only in TCP streams where 177 message ordering is reliable. This flag indicates that 178 the current message is not the complete response, and 179 should be aggregated with the following message(s) 180 before being considered complete. Such responses are 181 called ``segmented responses.'' It is an error for the 182 RCODE (including the EXTENDED-RCODE), AA flag, or DNS 183 Message ID to differ among messages in a segmented 184 response. It is an error for TC to be set on any 185 message in a segmented response. 187 FM ``First match'' flag. Notable only when multiple 188 questions are sent. If set, questions will be processed 189 in wire order and the first question whose answer would 190 be NOERROR AND ANCOUNT>0 is treated as if it were the 191 only question in the query message. If not set, 192 questions can be processed in any order and all possible 193 answer records will be included in the response. 195 5 - Multiple Questions 197 5.1. If QDCOUNT>1, multiple questions are present. All questions must 198 be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It 199 is an error for QDCOUNT>1 and any QTYPE=ANY. 201 5.2. RCODE and AA apply to all RRs in the answer section having the 202 QNAME that is shared by all questions in the question section. 204 5.3. QCLASS=ANY is deprecated, for all queries including those with 205 QDCOUNT=1. 207 5.4. QTYPE=IQUERY is deprecated, for all queries including those with 208 QDCOUNT=1. 210 6 - Transport Considerations 212 6.1. The presence of an OPT pseudo-RR or any new label type, or 213 QDCOUNT>1 in a request should be taken as an indication that the 214 requestor fully implements this specification and can correctly 215 understand any response that conforms to this specification. If a new 216 label type or QDCOUNT>1 is used in a message that does not have an OPT 217 RR, a VERSION of ``0'' shall be imputed. 219 6.2. Lack of use of these features in a request must be taken as an 220 indication that the requestor does not implement any part of this 221 specification and that the responder may make no use of any protocol 222 extension described here in its response. 224 6.2. Responders who do not understand these protocol extensions are 225 expected to send a respose with RCODE=NOTIMPL or RCODE=FORMERR or even 226 RCODE=SERVFAIL. Therefore use of these extensions should be ``probed'' 227 such that a responder who isn't known to support them be allowed a retry 228 with no extensions in use if it responds with one of the above mentioned 229 RCODEs. Responder capability with respect to these extensions ought to 230 be cached by requestors, but a new probe should be sent periodically to 231 test for upgrades to responder capability. 233 7 - Security Considerations 235 No new problems are added to DNS's security model by this specification. 236 Correspondingly, no old problems in DNS security are resolved by this 237 specification. 239 8 - Acknowledgements 241 Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, and 242 Donald Eastlake were each instrumental in creating this specification. 244 9 - References 246 [RFC1035] P. Mockapetris, ``Domain Names - Implementation and 247 Specification,'' RFC 1035, USC/Information Sciences 248 Institute, November 1987. 250 [CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,'' 251 Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March 252 1998. 254 10 - Author's Address 256 Paul Vixie 257 Vixie Enterprises 258 950 Charter Street 259 Redwood City, CA 94063 260 +1 650 779 7001 261