idnits 2.17.1 draft-andrews-dns-more-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.) ** There are 33 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 63: '...n a multi message response MUST be the...' RFC 2119 keyword, line 71: '...s message. MORE MUST cleared in the r...' RFC 2119 keyword, line 120: '... The server MUST clear the MORE flag...' RFC 2119 keyword, line 122: '... The server SHOULD disable path MTU ...' 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 (June 1996) is 10177 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) No issues found here. Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mark Andrews (CSIRO) 2 INTERNET-DRAFT Paul Vixie (ISC) 3 June 1996 5 Updates: RFC 1035 7 Large Responses to DNS Queries (DNS MORE) 9 Status of This Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other docu- 18 ments at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as ``work in 20 progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), 25 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 26 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 DNS messages are limited to 64 kilobytes in size. At times it is 31 necessary to send a message that is greater that 64 kilobytes. 32 This is currently not possible. AXFR is the one exception. This 33 document describes how to send a sequence of messages, the total 34 length which may be greater than 64 kilobytes, by extending the 35 protocol. 37 In addition average message sizes are increasing and the 512 38 byte payload limit for UDP is now too small. This document 39 describes how servers can identify when they can send bigger 40 messages without necessarily resorting to TCP. 42 1 - Protocol 44 This extension uses one of the RESERVED flags bits from DNS header 45 [RFC1035 4.1.1] to indicate when a server can send the extended 46 response. This flag bit shall be known as MORE. 48 The MORE flag's semantics depend upon the underlying transport protocol. 50 This document only defines the use of the MORE flag with the opcode 51 QUERY. 53 1.1 - TCP Usage 55 When using TCP a resolver sets the MORE flag to indicate that it is 56 capable of receiving a multi message response (which we call a ``message 57 sequence''). 59 To indicate that the message sequence is not complete the server shall 60 set the RCODE to CONTINUED (TBA) in all but the last message of the mes- 61 sage sequence. 63 The order of resource records in a multi message response MUST be the 64 same as if the response could have been sent is a single response. The 65 Questions first followed by, the Answer RRs, Authority RRs and Addi- 66 tional RRs. 68 Each message in a sequence will contain a header with the same ID value, 69 flags, opcode. Only the count fields and the rcode are permitted to 70 change. The counts shall represent the number of resource records in 71 this message. MORE MUST cleared in the response. 73 1.1.1 - TCP Example 75 The following example show how to send an answer with one question, 10 76 answer records, 14 authority records and 5 additional records. The 77 answer is split up across 3 messages. 79 MESSAGE 1: QCOUNT=1, ANCOUNT=10, AUCOUNT=0, 80 ADCOUNT=0, RCODE=CONTINUED 81 MESSAGE 2: QCOUNT=0, ANCOUNT=0, AUCOUNT=11, 82 ADCOUNT=0. RCODE=CONTINUED 83 MESSAGE 3: QCOUNT=0, ANCOUNT=0, AUCOUNT=3, 84 ADCOUNT=5, RCODE=NOERROR 86 1.2 - UDP Usage 88 When using UDP, a resolver may set the MORE flag in a QUERY request to 89 indicate that its receive buffer is greater than 512 bytes in size, 90 rather than the 512 byte size given in [RFC1035 3.2.4]. The resolver is 91 expected to set this flag only if it knows that the host's reassembly 92 buffer is large enough to accommodate datagrams of the size indicated. 94 The new size is indicated by the RCODE is the query. The receive buffer 95 is 512 * (2 ^ RCODE) bytes in size. 97 RCODE SIZE 98 0 512 99 1 1024 100 2 2048 101 3 4096 102 4 8192 103 5 16384 104 6 32768 105 7 65536 106 8 131072 107 9 262144 108 10 524288 109 11 1048576 110 12 2097152 111 13 4194304 112 14 8388608 113 15 16777216 115 A server receiving a QUERY request with the MORE flag set is allowed to 116 transmit a response of up to the size indicated. If the response will 117 not fit in size indicated, then the rules given in [RFC1035 4.1.1, 118 4.2.1, 6.2] apply. 120 The server MUST clear the MORE flag in the response. 122 The server SHOULD disable path MTU discovery on the UDP response packet 123 resulting in host fragmentation. 125 2 - Header Format 127 The header format is that described in [RFC1035 4.1.1] with the MORE 128 flag added: 130 1 1 1 1 1 1 131 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 132 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 133 | ID | 134 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 135 |QR| Opcode |AA|TC|RD|RA|MO| Z | RCODE | 136 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 137 | QDCOUNT | 138 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 139 | ANCOUNT | 140 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 141 | NSCOUNT | 142 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 143 | ARCOUNT | 144 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 146 Where MO is the MORE flag. 148 3 - Security Considerations 150 Though DNS is related to several security problems, no attempt is made 151 to fix them in this document. 153 This document is believed to introduce no additional security problems 154 to the current DNS protocol. 156 References 158 [RFC1035]P. Mockapetris, ``Domain Names - Implementation and Specifica- 159 tion,'' RFC 1035, USC/Information Sciences Institute, November 160 1987. 162 Authors' Addresses 164 Mark Andrews 165 CSIRO - Division of Mathematics and Statistics 166 Locked Bag 17 167 North Ryde NSW 2113 168 AUSTRALIA 169 +61 2 325 3148 170 172 Paul Vixie 173 Internet Software Consortium 174 Star Route Box 159A 175 Woodside, CA 94062 176 USA 177 +1 415 747 0204 178