]>
Commit | Line | Data |
---|---|---|
57a86a53 GS |
1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group O. Gudmundsson | |
8 | Request for Comments: 3226 December 2001 | |
9 | Updates: 2874, 2535 | |
10 | Category: Standards Track | |
11 | ||
12 | ||
13 | DNSSEC and IPv6 A6 aware server/resolver message size requirements | |
14 | ||
15 | Status of this Memo | |
16 | ||
17 | This document specifies an Internet standards track protocol for the | |
18 | Internet community, and requests discussion and suggestions for | |
19 | improvements. Please refer to the current edition of the "Internet | |
20 | Official Protocol Standards" (STD 1) for the standardization state | |
21 | and status of this protocol. Distribution of this memo is unlimited. | |
22 | ||
23 | Copyright Notice | |
24 | ||
25 | Copyright (C) The Internet Society (2001). All Rights Reserved. | |
26 | ||
27 | Abstract | |
28 | ||
29 | This document mandates support for EDNS0 (Extension Mechanisms for | |
30 | DNS) in DNS entities claiming to support either DNS Security | |
31 | Extensions or A6 records. This requirement is necessary because | |
32 | these new features increase the size of DNS messages. If EDNS0 is | |
33 | not supported fall back to TCP will happen, having a detrimental | |
34 | impact on query latency and DNS server load. This document updates | |
35 | RFC 2535 and RFC 2874, by adding new requirements. | |
36 | ||
37 | 1. Introduction | |
38 | ||
39 | Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions | |
40 | [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful. | |
41 | ||
42 | STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP | |
43 | have a data payload of 512 octets or less. Most DNS software today | |
44 | will not accept larger UDP datagrams. Any answer that requires more | |
45 | than 512 octets, results in a partial and sometimes useless reply | |
46 | with the Truncation Bit set; in most cases the requester will then | |
47 | retry using TCP. Furthermore, server delivery of truncated responses | |
48 | varies widely and resolver handling of these responses also varies, | |
49 | leading to additional inefficiencies in handling truncation. | |
50 | ||
51 | Compared to UDP, TCP is an expensive protocol to use for a simple | |
52 | transaction like DNS: a TCP connection requires 5 packets for setup | |
53 | and tear down, excluding data packets, thus requiring at least 3 | |
54 | round trips on top of the one for the original UDP query. The DNS | |
55 | ||
56 | ||
57 | ||
58 | Gudmundsson Standards Track [Page 1] | |
59 | \f | |
60 | RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 | |
61 | ||
62 | ||
63 | server also needs to keep a state of the connection during this | |
64 | transaction. Many DNS servers answer thousands of queries per | |
65 | second, requiring them to use TCP will cause significant overhead and | |
66 | delays. | |
67 | ||
68 | 1.1. Requirements | |
69 | ||
70 | The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" | |
71 | in this document are to be interpreted as described in RFC 2119. | |
72 | ||
73 | 2. Motivating factors | |
74 | ||
75 | 2.1. DNSSEC motivations | |
76 | ||
77 | DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each | |
78 | RR set. These signatures range in size from about 80 octets to 800 | |
79 | octets, most are going to be in the range of 80 to 200 octets. The | |
80 | addition of signatures on each or most RR sets in an answer | |
81 | significantly increases the size of DNS answers from secure zones. | |
82 | ||
83 | For performance reasons and to reduce load on DNS servers, it is | |
84 | important that security aware servers and resolvers get all the data | |
85 | in Answer and Authority section in one query without truncation. | |
86 | Sending Additional Data in the same query is helpful when the server | |
87 | is authoritative for the data, and this reduces round trips. | |
88 | ||
89 | DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that | |
90 | it is interested in receiving DNSSEC records. The OK bit does not | |
91 | eliminate the need for large answers for DNSSEC capable clients. | |
92 | ||
93 | 2.1.1. Message authentication or TSIG motivation | |
94 | ||
95 | TSIG [RFC2845] allows for the light weight authentication of DNS | |
96 | messages, but increases the size of the messages by at least 70 | |
97 | octets. DNSSEC specifies for computationally expensive message | |
98 | authentication SIG(0) using a standard public key signature. As only | |
99 | one TSIG or SIG(0) can be attached to each DNS answer the size | |
100 | increase of message authentication is not significant, but may still | |
101 | lead to a truncation. | |
102 | ||
103 | 2.2. IPv6 Motivations | |
104 | ||
105 | IPv6 addresses [RFC2874] are 128 bits and can be represented in the | |
106 | DNS by multiple A6 records, each consisting of a domain name and a | |
107 | bit field. The domain name refers to an address prefix that may | |
108 | require additional A6 RRs to be included in the answer. Answers | |
109 | where the queried name has multiple A6 addresses may overflow a 512- | |
110 | octet UDP packet size. | |
111 | ||
112 | ||
113 | ||
114 | Gudmundsson Standards Track [Page 2] | |
115 | \f | |
116 | RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 | |
117 | ||
118 | ||
119 | 2.3. Root server and TLD server motivations | |
120 | ||
121 | The current number of root servers is limited to 13 as that is the | |
122 | maximum number of name servers and their address records that fit in | |
123 | one 512-octet answer for a SOA record. If root servers start | |
124 | advertising A6 or KEY records then the answer for the root NS records | |
125 | will not fit in a single 512-octet DNS message, resulting in a large | |
126 | number of TCP query connections to the root servers. Even if all | |
127 | client resolver query their local name server for information, there | |
128 | are millions of these servers. Each name server must periodically | |
129 | update its information about the high level servers. | |
130 | ||
131 | For redundancy, latency and load balancing reasons, large numbers of | |
132 | DNS servers are required for some zones. Since the root zone is used | |
133 | by the entire net, it is important to have as many servers as | |
134 | possible. Large TLDs (and many high-visibility SLDs) often have | |
135 | enough servers that either A6 or KEY records would cause the NS | |
136 | response to overflow the 512 byte limit. Note that these zones with | |
137 | large numbers of servers are often exactly those zones that are | |
138 | critical to network operation and that already sustain fairly high | |
139 | loads. | |
140 | ||
141 | 2.4. UDP vs TCP for DNS messages | |
142 | ||
143 | Given all these factors, it is essential that any implementation that | |
144 | supports DNSSEC and or A6 be able to use larger DNS messages than 512 | |
145 | octets. | |
146 | ||
147 | The original 512 restriction was put in place to reduce the | |
148 | probability of fragmentation of DNS responses. A fragmented UDP | |
149 | message that suffers a loss of one of the fragments renders the | |
150 | answer useless and the query must be retried. A TCP connection | |
151 | requires a larger number of round trips for establishment, data | |
152 | transfer and tear down, but only the lost data segments are | |
153 | retransmitted. | |
154 | ||
155 | In the early days a number of IP implementations did not handle | |
156 | fragmentation well, but all modern operating systems have overcome | |
157 | that issue thus sending fragmented messages is fine from that | |
158 | standpoint. The open issue is the effect of losses on fragmented | |
159 | messages. If connection has high loss ratio only TCP will allow | |
160 | reliable transfer of DNS data, most links have low loss ratios thus | |
161 | sending fragmented UDP packet in one round trip is better than | |
162 | establishing a TCP connection to transfer a few thousand octets. | |
163 | ||
164 | ||
165 | ||
166 | ||
167 | ||
168 | ||
169 | ||
170 | Gudmundsson Standards Track [Page 3] | |
171 | \f | |
172 | RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 | |
173 | ||
174 | ||
175 | 2.5. EDNS0 and large UDP messages | |
176 | ||
177 | EDNS0 [RFC2671] allows clients to declare the maximum size of UDP | |
178 | message they are willing to handle. Thus, if the expected answer is | |
179 | between 512 octets and the maximum size that the client can accept, | |
180 | the additional overhead of a TCP connection can be avoided. | |
181 | ||
182 | 3. Protocol changes: | |
183 | ||
184 | This document updates RFC 2535 and RFC 2874, by adding new | |
185 | requirements. | |
186 | ||
187 | All RFC 2535 compliant servers and resolvers MUST support EDNS0 and | |
188 | advertise message size of at least 1220 octets, but SHOULD advertise | |
189 | message size of 4000. This value might be too low to get full | |
190 | answers for high level servers and successor of this document may | |
191 | require a larger value. | |
192 | ||
193 | All RFC 2874 compliant servers and resolver MUST support EDNS0 and | |
194 | advertise message size of at least 1024 octets, but SHOULD advertise | |
195 | message size of 2048. The IPv6 datagrams should be 1024 octets, | |
196 | unless the MTU of the path is known. (Note that this is smaller than | |
197 | the minimum IPv6 MTU to allow for some extension headers and/or | |
198 | encapsulation without exceeding the minimum MTU.) | |
199 | ||
200 | All RFC 2535 and RFC 2874 compliant entities MUST be able to handle | |
201 | fragmented IPv4 and IPv6 UDP packets. | |
202 | ||
203 | All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger | |
204 | required value in EDNS0 advertisements. | |
205 | ||
206 | 4. Acknowledgments | |
207 | ||
208 | Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas | |
209 | Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis | |
210 | Michael Patton and Kazu Yamamoto were instrumental in motivating and | |
211 | shaping this document. | |
212 | ||
213 | 5. Security Considerations: | |
214 | ||
215 | There are no additional security considerations other than those in | |
216 | RFC 2671. | |
217 | ||
218 | 6. IANA Considerations: | |
219 | ||
220 | None | |
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Gudmundsson Standards Track [Page 4] | |
227 | \f | |
228 | RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 | |
229 | ||
230 | ||
231 | 7. References | |
232 | ||
233 | [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", | |
234 | STD 13, RFC 1034, November 1987. | |
235 | ||
236 | [RFC1035] Mockapetris, P., "Domain Names - Implementation and | |
237 | Specification", STD 13, RFC 1035, November 1987. | |
238 | ||
239 | [RFC2535] Eastlake, D. "Domain Name System Security Extensions", RFC | |
240 | 2535, March 1999. | |
241 | ||
242 | [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC | |
243 | 2671, August 1999. | |
244 | ||
245 | [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. | |
246 | Wellington, "Secret Key Transaction Authentication for DNS | |
247 | (TSIG)", RFC 2845, May 2000. | |
248 | ||
249 | [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support | |
250 | IPv6 Address Aggregation and Renumbering", RFC 2874, July | |
251 | 2000. | |
252 | ||
253 | [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC | |
254 | 3225, December 2001. | |
255 | ||
256 | 8. Author Address | |
257 | ||
258 | Olafur Gudmundsson | |
259 | 3826 Legation Street, NW | |
260 | Washington, DC 20015 | |
261 | USA | |
262 | ||
263 | EMail: ogud@ogud.com | |
264 | ||
265 | ||
266 | ||
267 | ||
268 | ||
269 | ||
270 | ||
271 | ||
272 | ||
273 | ||
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | ||
280 | ||
281 | ||
282 | Gudmundsson Standards Track [Page 5] | |
283 | \f | |
284 | RFC 3226 DNSSEC and IPv6 A6 requirements December 2001 | |
285 | ||
286 | ||
287 | 9. Full Copyright Statement | |
288 | ||
289 | Copyright (C) The Internet Society (2001). All Rights Reserved. | |
290 | ||
291 | This document and translations of it may be copied and furnished to | |
292 | others, and derivative works that comment on or otherwise explain it | |
293 | or assist in its implementation may be prepared, copied, published | |
294 | and distributed, in whole or in part, without restriction of any | |
295 | kind, provided that the above copyright notice and this paragraph are | |
296 | included on all such copies and derivative works. However, this | |
297 | document itself may not be modified in any way, such as by removing | |
298 | the copyright notice or references to the Internet Society or other | |
299 | Internet organizations, except as needed for the purpose of | |
300 | developing Internet standards in which case the procedures for | |
301 | copyrights defined in the Internet Standards process must be | |
302 | followed, or as required to translate it into languages other than | |
303 | English. | |
304 | ||
305 | The limited permissions granted above are perpetual and will not be | |
306 | revoked by the Internet Society or its successors or assigns. | |
307 | ||
308 | This document and the information contained herein is provided on an | |
309 | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |
310 | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |
311 | BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | |
312 | HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |
313 | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
314 | ||
315 | Acknowledgement | |
316 | ||
317 | Funding for the RFC Editor function is currently provided by the | |
318 | Internet Society. | |
319 | ||
320 | ||
321 | ||
322 | ||
323 | ||
324 | ||
325 | ||
326 | ||
327 | ||
328 | ||
329 | ||
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
338 | Gudmundsson Standards Track [Page 6] | |
339 | \f |