idnits 2.17.00 (12 Aug 2021) /tmp/idnits17439/draft-ietf-dnsind-udp-size-02.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 (2022-05-14) 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) 2022 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnsind-udp-size-02.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnsind-udp-size-02.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnsind-udp-size-02.txt,', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-dnsind-udp-size-02.txt,', but the file name used is 'draft-ietf-dnsind-udp-size-02' == 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 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 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 150: '... with a non-zero RCODE, MUST limit its...' RFC 2119 keyword, line 152: '...uffer space available. It SHOULD also...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (June 1998) is 8734 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? 'RFC 2065' on line 205 looks like a reference -- Missing reference section? 'RFC 1886' on line 91 looks like a reference Summary: 11 errors (**), 1 flaw (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake, 3rd 2 Updates RFC 1035 CyberCash 3 Expires December 1998 June 1998 5 Bigger Domain Name System UDP Replies 6 ------ ------ ---- ------ --- ------- 8 Donald E. Eastlake 3rd 10 Status of This Document 12 This draft, file name draft-ietf-dnsind-udp-size-02.txt, is intended 13 to be become a Proposed Standard RFC. Distribution of this document 14 is unlimited. Comments should be sent to the DNS mailing list 15 or to the author. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months. Internet-Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet- 25 Drafts as reference material or to cite them other than as a 26 ``working draft'' or ``work in progress.'' 28 To view the entire list of current Internet-Drafts, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 31 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 32 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 The Domain Name System defaults to using UDP for queries and replies 37 with a DNS payload limit of 512 bytes. Larger replies cause an 38 initial truncation indication leading to a subsequent handling via 39 TCP with substantially higher overhead. An extension to DNS UDP 40 requests is specified which frequently permits larger UDP responses 41 thus reducing the need for use of TCP. 43 Acknowledgements 45 Paul Vixie originated the basic idea specified herein. 47 Some errors notice by Chris Thompson in version -00 have been fixed. 49 Additional suggestions were made by James Gilroy. 51 Table of Contents 53 Status of This Document....................................1 54 Abstract...................................................1 56 Acknowledgements...........................................2 57 Table of Contents..........................................2 59 1. Introduction............................................3 60 2. Permitting Larger DNS UDP Packets.......................3 61 3. Compatibility Discussion................................5 62 4. Security Considerations.................................5 64 References.................................................6 65 Author's Addresses.........................................6 66 Expiration and File Name...................................6 68 1. Introduction 70 The global Internet Domain Name System (DNS) is documented in RFC 71 1034, 1035, and numerous additional Requests for Comment. It 72 provides a distributed hierarchical database with redundant servers. 73 Recently security features have been added to the DNS [RFC 2065]. 75 DNS can transfer data via both UDP and TCP. Some requests that are 76 very likely to have big responses, most commonly zone transfers, just 77 use TCP. However, the vast majority of requests are initially sent 78 via UDP which causes the response to be via UDP. 80 DNS over UDP is constrained to one packet for the request, which is 81 normally no problem as requests are usually small, and one packet for 82 response, which can be a problem. The DNS data portion of DNS UDP 83 packets is currently limited to 512 bytes. The standard states that 84 if the data required to be in the response to a UDP request does not 85 fit in 512 bytes, a truncation flag bit is set in the response and 86 the resolver must try again using TCP with TCP's substantially higher 87 set up and tear down overhead. 89 As signatures and/or keys are included in more responses due to DNS 90 security [RFC 2065] and average domain names get longer and larger 91 addresses for IPv6 [RFC 1886] come into use and there are increasing 92 numbers of instances of larger RRsets, the old UDP response size 93 limit will increasingly be exceeded. Yet the bulk of the network has 94 MTUs on the order of the Ethernet MTU or larger (in some cases 95 simulated by link adaptation layers that disguise a smaller physical 96 MTU) and all modern IP stacks can handle buffering of that size or 97 larger. 99 2. Permitting Larger DNS UDP Packets 101 Efforts are under way to define an additional information resource 102 record that can be used to communicate exact buffer sizes and many 103 other options and extensions. However, many older DNS servers ignore 104 any request with a non-empty additional information section resulting 105 in a requirement for probing and maintaining per server state for 106 optimal performance. Pending deployment of some such more exact and 107 comprehensive solution, the following change is made in the DNS over 108 UDP protocol. 110 No change is made in the size limit on UDP queries. It remains at 111 512 bytes. 113 The presently unused RCODE field in UDP queries is redefined to 114 specify the resolver imposed limit on the DNS data in the UDP 115 response. This four bit field is presently specified as zero. Such 116 non-zero RCODE values in requests will be ignored by older DNS 117 servers that will continue to use the old UDP size limit for 118 responses. Thus server probing and state maintenance are not 119 required. Values from 0 through 10 are defined as follows: 121 RCODE DNS reply data limit in bytes 123 0 512 (old default) 124 1 768 125 2 1,280 (new default) 126 3 1,920 127 4 3,200 (appropriate for UDP entirely via FDDI) 128 5 4,800 129 6 8,000 130 7 12,000 131 8 20,000 132 9 30,000 133 10 50,000 134 11-15 -reserved 136 A resolver should take into account its local buffer space and any 137 knowledge it has about the local network MTU (maximum transmission 138 unit) or the PMTU (path MTU) to the server it is querying. Making a 139 reasonable allowance for IP headers that may be added by the server, 140 the resolver should then pick an RCODE value from the above table. A 141 value that might be expected to cause a reply packet to fragment into 142 two pieces is still preferable to using TCP. In the absence of any 143 information, the value 2 should be used. 145 The resolver should not do PMTU discovery just to provide a more 146 accurate RCODE. The additional packets that might be required for 147 PMTU discovery would defeat the purpose of avoiding the additional 148 packets required by TCP. 150 A server, on receiving a query with a non-zero RCODE, MUST limit its 151 DNS response message to the size specified but may need to limit it 152 to a lower amount due to buffer space available. It SHOULD also 153 limit it based on local network MTU or the PMTU to the resolver, if 154 known, less a reasonable allowance for IP headers. 156 1280 bytes of DNS data is chosen as the new default to provide a 157 generous allowance for IP headers and still be within the highly 158 prevalent approximately Ethernet size or larger MTU and buffering 159 generally available today. 161 An IPv6 server should enable fragmentation on UDP replies. While 162 fragmentation will not be frequent if the above guidelines are 163 followed, it may occur on occasion. In principle, IPv6 headers and 164 options could be huge, resulting in a very large UDP packet even 165 though the DNS payload is limited, but this should not occur in 166 practice. 168 3. Compatibility Discussion 170 No cases are known where the above change will cause a problem for 171 non-recursive queries. Old servers will ignore the RCODE field of 172 the UDP query and should return 512 or fewer bytes, possibly with a 173 truncation indication. Servers with this feature included should use 174 the RCODE value to determine a ceiling on the size of response they 175 will send. Non-zero values of RCODE will permit them to send larger 176 UDP responses if local conditions are appropriate. 178 There is a potential problem with recursive queries. If (1) an 179 updated recursive query specifies bigger UDP responses with a non- 180 zero RCODE to an old server and (2) that server in turn issues a 181 corresponding query into which it blindly copies the RCODE field and 182 (3) this corresponding query goes to an updated server that honors 183 the non-zero RCODE field and (4) the updated server response DNS data 184 is actually larger than 512 bytes as permitted by the RCODE in the 185 query, then the intermediate old DNS server may be confused by the 186 larger than 512 byte DNS response it receives. However, there are 187 already DNS implementations out there on the Internet that send back 188 larger than 512 byte responses in violation of the old standard and 189 DNS implementations are being deployed which protect themselves 190 against and are not confused by larger than expected responses. 192 Should the above problem manifest itself, it can be cured by making 193 the queries be TCP based or non-recursive or by upgrading the 194 intermediate DNS server to which the recursive queries are being sent 195 to implement this bigger UDP packet feature. There are cases, such 196 as resolvers behind a firewall that can only get outside DNS 197 information via a recursive server and changing to non-recursive 198 queries is not possible. Upgrading the DNS server is the strongly 199 recommended solution. 201 4. Security Considerations 203 General DNS security issues are considered in RFC 2065. 205 In the absence of request security [RFC 2065], the request RCODE 206 could be modified in transit. If set lower, this might result in 207 unnecessary TCP. If set higher, this might result in unnecessary 208 fragmentation. 210 Larger packets may make it easier to cause some forms of denial of 211 service due to fragment loss. 213 References 215 RFC 1034 - P. Mockapetris, "Domain names - concepts and facilities", 216 11/01/1987. 218 RFC 1035 - P. Mockapetris, "Domain names - implementation and 219 specification", 11/01/1987. 221 RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security 222 Extensions", 01/03/1997. 224 Author's Addresses 226 Donald E. Eastlake 3rd 227 CyberCash, Inc. 228 318 Acton Street 229 Carlisle, MA 01741 USA 231 Telephone: +1 978 287 4877 232 +1 703 620-4200 (main office, Reston, Virginia) 233 FAX: +1 978 371 7148 234 EMail: dee@cybercash.com 236 Expiration and File Name 238 This draft expires December 1998. 240 Its file name is draft-ietf-dnsind-udp-size-02.txt.