idnits 2.17.1 draft-ietf-dnsind-udp-size-00.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-23) 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. ** Bad filename characters: the document name given in the document, 'draft-ietf-dnsind-udp-size-00.txt,', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-dnsind-udp-size-00.txt,', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-dnsind-udp-size-00.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-00.txt,', but the file name used is 'draft-ietf-dnsind-udp-size-00' == 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. 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 (November 1997) is 9656 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 84 looks like a reference -- Missing reference section? 'RFC 1886' on line 87 looks like a reference Summary: 10 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 May 1998 November 1997 5 Larger 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-00.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 learn the current status of any Internet-Draft, please check the 29 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), 31 nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), 32 munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). 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. A upward compatible 40 extension to DNS requests is specified which frequently permits 41 larger UDP responses reducing the need for use of TCP. 43 Acknowledgement 45 Paul Vixie originated the basic idea specified herein. 47 Table of Contents 49 Status of This Document....................................1 50 Abstract...................................................1 52 Acknowledgement............................................2 53 Table of Contents..........................................2 55 1. Introduction............................................3 56 2. Permitting Larger DNS UDP Packets.......................3 57 3. Security Considerations.................................4 59 References.................................................5 60 Author's Addresses.........................................5 61 Expiration and File Name...................................5 63 1. Introduction 65 The global Internet Domain Name System (DNS) is documented in RFC 66 1034, 1035, and numerous additional Requests for Comment. It 67 provides a distributed hierarchical database with redundant servers. 68 Recently security features have been added to the DNS [RFC 2065]. 70 DNS can transfer data via both UDP and TCP. Some requests that are 71 very likely to have big responses, most commonly zone transfers, just 72 use TCP. However, the vast majority of requests are initially sent 73 via UDP which causes the response to be via UDP. 75 DNS over UDP is constrained to one packet for the request, which is 76 normally no problem as requests are usually small, and one packet for 77 response, which can be a problem. The DNS data portion of DNS UDP 78 packets is currently limited to 512 bytes. If data required to be in 79 the response does not fit, a truncation flag bit is set and the 80 resolver must try again using TCP with its substantially higher set 81 up and tear down overhead. 83 As signatures and/or keys are included in more responses due to DNS 84 security [RFC 2065], especially large modulus RSA signatures/keys, 85 and average domain names get longer and there are increasing numbers 86 of instances of larger RRsets including larger addresses for IPv6 87 [RFC 1886], the UDP response size limit will increasingly be 88 exceeded. Yet the bulk of the network has MTUs on the order of the 89 Ethernet MTU or larger. Consideration is being given to increasing 90 the minimum MTU for IPv6 networks to 1280 bytes from 576 bytes. 91 (Links with a smaller MTU would simply need a link adaptation layer, 92 as is currently required for ATM with its tiny MTU.) 94 2. Permitting Larger DNS UDP Packets 96 No change is proposed in the size limit on UDP queries. It remains 97 at 512 bytes 99 However, the presently unused RCODE field in UDP queries is redefined 100 to specify the resolver imposed limit on the DNS data in the UDP 101 response. This four bit field is presently zero. Values from 1 102 through 7 are defined as follows: 104 RCODE DNS data limit in bytes 106 0 512 (current default) 107 1 768 108 2 1280 (new default) 109 3 1720 110 4 3200 111 5 4800 112 6 8000 113 7 12000 114 8-14 -reserved 116 A resolver should take into account its local buffer space and any 117 knowledge it has about the local network MTU (maximum transmission 118 unit) or the PMTU (path MTU) to the server it is querying. Making a 119 reasonable allowance for IP headers that may be added by the server, 120 the resolver should then pick an RCODE value from the above table. 121 In the absence of any information, the value 2 should be used. 123 It is not intended that the resolver do any sort of PMTU discovery 124 just to provide a more accurate RCODE. The packets required for PMTU 125 discovery would defeat the purpose of avoiding the additional packets 126 required by TCP. 128 A server, on receiving a query with a non-zero RCODE, should limit 129 its DNS response message to that size but may need to limit it to a 130 lower amount due to buffer space available. It should also limit it 131 to the local network MTU or the PMTU to the resolver, if known, less 132 a reasonable allowance for IP headers. 134 An IPv6 server should enable fragmentation on UDP replies. While 135 fragmentation will not be frequent if the above guidelines are 136 followed, it may occur on occasion. 138 3. Security Considerations 140 In the absence of request security, the request RCODE could be 141 modified in transit. If set lower, this might result in unnecessary 142 TCP. If set higher, this might result in unnecessary fragmentation. 144 References 146 RFC 1034 - P. Mockapetris, "Domain names - concepts and facilities", 147 11/01/1987. 149 RFC 1035 - P. Mockapetris, "Domain names - implementation and 150 specification", 11/01/1987. 152 RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security 153 Extensions", 01/03/1997. 155 Author's Addresses 157 Donald E. Eastlake 3rd 158 CyberCash, Inc. 159 318 Acton Street 160 Carlisle, MA 01741 USA 162 Telephone: +1 978 287 4877 163 +1 703 620-4200 (main office, Reston, VA) 164 FAX: +1 978 371 7148 165 EMail: dee@cybercash.com 167 Expiration and File Name 169 This draft expires May 1998. 171 Its file name is draft-ietf-dnsind-udp-size-00.txt.