1 Internet Engineering Task Force (IETF) J. Damas
2 Request for Comments: 6891 Bond Internet Systems
3 STD: 75 M. Graff
4 Obsoletes: 2671, 2673
5 Category: Standards Track P. Vixie
6 ISSN: 2070-1721 Internet Systems Consortium
7 April 2013
8
9
10 Extension Mechanisms for DNS (EDNS(0))
11
12 Abstract
13
14 The Domain Name System's wire protocol includes a number of fixed
15 fields whose range has been or soon will be exhausted and does not
16 allow requestors to advertise their capabilities to responders. This
17 document describes backward-compatible mechanisms for allowing the
18 protocol to grow.
19
20 This document updates the Extension Mechanisms for DNS (EDNS(0))
21 specification (and obsoletes RFC 2671) based on feedback from
22 deployment experience in several implementations. It also obsoletes
23 RFC 2673 ("Binary Labels in the Domain Name System") and adds
24 considerations on the use of extended labels in the DNS.
25
26 Status of This Memo
27
28 This is an Internet Standards Track document.
29
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
35
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc6891.
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Damas, et al. Standards Track [Page 1]
53 RFC 6891 EDNS(0) Extensions April 2013
54
55
56 Copyright Notice
57
58 Copyright (c) 2013 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 This document may contain material from IETF Documents or IETF
72 Contributions published or made publicly available before November
73 10, 2008. The person(s) controlling the copyright in some of this
74 material may not have granted the IETF Trust the right to allow
75 modifications of such material outside the IETF Standards Process.
76 Without obtaining an adequate license from the person(s) controlling
77 the copyright in such materials, this document may not be modified
78 outside the IETF Standards Process, and derivative works of it may
79 not be created outside the IETF Standards Process, except to format
80 it for publication as an RFC or to translate it into languages other
81 than English.
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107 Damas, et al. Standards Track [Page 2]
108 RFC 6891 EDNS(0) Extensions April 2013
109
110
111 Table of Contents
112
113 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
114 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
115 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 5
116 4. DNS Message Changes . . . . . . . . . . . . . . . . . . . . . 5
117 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 5
118 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 5
119 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 6
120 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 6
121 6. The OPT Pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 6
122 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 6
123 6.1.1. Basic Elements . . . . . . . . . . . . . . . . . . . . 6
124 6.1.2. Wire Format . . . . . . . . . . . . . . . . . . . . . 7
125 6.1.3. OPT Record TTL Field Use . . . . . . . . . . . . . . . 9
126 6.1.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . 9
127 6.2. Behaviour . . . . . . . . . . . . . . . . . . . . . . . . 10
128 6.2.1. Cache Behaviour . . . . . . . . . . . . . . . . . . . 10
129 6.2.2. Fallback . . . . . . . . . . . . . . . . . . . . . . . 10
130 6.2.3. Requestor's Payload Size . . . . . . . . . . . . . . . 10
131 6.2.4. Responder's Payload Size . . . . . . . . . . . . . . . 11
132 6.2.5. Payload Size Selection . . . . . . . . . . . . . . . . 11
133 6.2.6. Support in Middleboxes . . . . . . . . . . . . . . . . 11
134 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 12
135 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
136 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
137 9.1. OPT Option Code Allocation Procedure . . . . . . . . . . . 15
138 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
139 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
140 10.2. Informative References . . . . . . . . . . . . . . . . . . 15
141 Appendix A. Changes since RFCs 2671 and 2673 . . . . . . . . . . 16
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162 Damas, et al. Standards Track [Page 3]
163 RFC 6891 EDNS(0) Extensions April 2013
164
165
166 1. Introduction
167
168 DNS [RFC1035] specifies a message format, and within such messages
169 there are standard formats for encoding options, errors, and name
170 compression. The maximum allowable size of a DNS message over UDP
171 not using the extensions described in this document is 512 bytes.
172 Many of DNS's protocol limits, such as the maximum message size over
173 UDP, are too small to efficiently support the additional information
174 that can be conveyed in the DNS (e.g., several IPv6 addresses or DNS
175 Security (DNSSEC) signatures). Finally, RFC 1035 does not define any
176 way for implementations to advertise their capabilities to any of the
177 other actors they interact with.
178
179 [RFC2671] added extension mechanisms to DNS. These mechanisms are
180 widely supported, and a number of new DNS uses and protocol
181 extensions depend on the presence of these extensions. This memo
182 refines and obsoletes [RFC2671].
183
184 Unextended agents will not know how to interpret the protocol
185 extensions defined in [RFC2671] and restated here. Extended agents
186 need to be prepared for handling the interactions with unextended
187 clients in the face of new protocol elements and fall back gracefully
188 to unextended DNS.
189
190 EDNS is a hop-by-hop extension to DNS. This means the use of EDNS is
191 negotiated between each pair of hosts in a DNS resolution process,
192 for instance, the stub resolver communicating with the recursive
193 resolver or the recursive resolver communicating with an
194 authoritative server.
195
196 [RFC2671] specified extended label types. The only such label
197 proposed was in [RFC2673] for a label type called "Bit-String Label"
198 or "Binary Labels", with this latest term being the one in common
199 use. For various reasons, introducing a new label type was found to
200 be extremely difficult, and [RFC2673] was moved to Experimental.
201 This document obsoletes [RFC2673], deprecating Binary Labels.
202 Extended labels remain defined, but their use is discouraged due to
203 practical difficulties with deployment; their use in the future
204 SHOULD only be considered after careful evaluation of the deployment
205 hindrances.
206
207 2. Terminology
208
209 "Requestor" refers to the side that sends a request. "Responder"
210 refers to an authoritative, recursive resolver or other DNS component
211 that responds to questions. Other terminology is used here as
212 defined in the RFCs cited by this document.
213
214
215
216
217 Damas, et al. Standards Track [Page 4]
218 RFC 6891 EDNS(0) Extensions April 2013
219
220
221 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
222 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
223 document are to be interpreted as described in RFC 2119 [RFC2119].
224
225 3. EDNS Support Requirement
226
227 EDNS provides a mechanism to improve the scalability of DNS as its
228 uses get more diverse on the Internet. It does this by enabling the
229 use of UDP transport for DNS messages with sizes beyond the limits
230 specified in RFC 1035 as well as providing extra data space for
231 additional flags and return codes (RCODEs). However, implementation
232 experience indicates that adding new RCODEs should be avoided due to
233 the difficulty in upgrading the installed base. Flags SHOULD be used
234 only when necessary for DNS resolution to function.
235
236 For many uses, an EDNS Option Code may be preferred.
237
238 Over time, some applications of DNS have made EDNS a requirement for
239 their deployment. For instance, DNSSEC uses the additional flag
240 space introduced in EDNS to signal the request to include DNSSEC data
241 in a DNS response.
242
243 Given the increase in DNS response sizes when including larger data
244 items such as AAAA records, DNSSEC information (e.g., RRSIG or
245 DNSKEY), or large TXT records, the additional UDP payload
246 capabilities provided by EDNS can help improve the scalability of the
247 DNS by avoiding widespread use of TCP for DNS transport.
248
249 4. DNS Message Changes
250
251 4.1. Message Header
252
253 The DNS message header's second full 16-bit word is divided into a
254 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see Section
255 4.1.1 of [RFC1035]). Some of these flag values were marked for
256 future use, and most of these have since been allocated. Also, most
257 of the RCODE values are now in use. The OPT pseudo-RR specified
258 below contains extensions to the RCODE bit field as well as
259 additional flag bits.
260
261 4.2. Label Types
262
263 The first 2 bits of a wire format domain label are used to denote the
264 type of the label. [RFC1035] allocates 2 of the 4 possible types and
265 reserves the other 2. More label types were defined in [RFC2671].
266 The use of the 2-bit combination defined by [RFC2671] to identify
267 extended label types remains valid. However, it has been found that
268 deployment of new label types is noticeably difficult and so is only
269
270
271
272 Damas, et al. Standards Track [Page 5]
273 RFC 6891 EDNS(0) Extensions April 2013
274
275
276 recommended after careful evaluation of alternatives and the need for
277 deployment.
278
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
279 4.3. UDP Message Size
280
281 Traditional DNS messages are limited to 512 octets in size when sent
282 over UDP [RFC1035]. Fitting the increasing amounts of data that can
283 be transported in DNS in this 512-byte limit is becoming more
284 difficult. For instance, inclusion of DNSSEC records frequently
285 requires a much larger response than a 512-byte message can hold.
286
287 EDNS(0) specifies a way to advertise additional features such as
288 larger response size capability, which is intended to help avoid
289 truncated UDP responses, which in turn cause retry over TCP. It
290 therefore provides support for transporting these larger packet sizes
291 without needing to resort to TCP for transport.
292
293 5. Extended Label Types
294
295 The first octet in the on-the-wire representation of a DNS label
296 specifies the label type; the basic DNS specification [RFC1035]
297 dedicates the 2 most significant bits of that octet for this purpose.
298
299 [RFC2671] defined DNS label type 0b01 for use as an indication for
300 extended label types. A specific extended label type was selected by
301 the 6 least significant bits of the first octet. Thus, extended
302 label types were indicated by the values 64-127 (0b01xxxxxx) in the
303 first octet of the label.
304
305 Extended label types are extremely difficult to deploy due to lack of
306 support in clients and intermediate gateways, as described in
307 [RFC3363], which moved [RFC2673] to Experimental status; and
308 [RFC3364], which describes the pros and cons. As such, proposals
309 that contemplate extended labels SHOULD weigh this deployment cost
310 against the possibility of implementing functionality in other ways.
311
312 Finally, implementations MUST NOT generate or pass Binary Labels in
313 their communications, as they are now deprecated.
314
315 6. The OPT Pseudo-RR
316
317 6.1. OPT Record Definition
318
319 6.1.1. Basic Elements
320
321 An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the
322 additional data section of a request.
323
324
325
326
327 Damas, et al. Standards Track [Page 6]
328 RFC 6891 EDNS(0) Extensions April 2013
329
330
331 The OPT RR has RR type 41.
332
333 If an OPT record is present in a received request, compliant
334 responders MUST include an OPT record in their respective responses.
335
336 An OPT record does not carry any DNS data. It is used only to
337 contain control information pertaining to the question-and-answer
338 sequence of a specific transaction. OPT RRs MUST NOT be cached,
339 forwarded, or stored in or loaded from master files.
340
341 The OPT RR MAY be placed anywhere within the additional data section.
342 When an OPT RR is included within any DNS message, it MUST be the
343 only OPT RR in that message. If a query message with more than one
344 OPT RR is received, a FORMERR (RCODE=1) MUST be returned. The
345 placement flexibility for the OPT RR does not override the need for
346 the TSIG or SIG(0) RRs to be the last in the additional section
347 whenever they are present.
348
349 6.1.2. Wire Format
350
351 An OPT RR has a fixed part and a variable set of options expressed as
352 {attribute, value} pairs. The fixed part holds some DNS metadata,
353 and also a small collection of basic extension elements that we
354 expect to be so popular that it would be a waste of wire space to
355 encode them as {attribute, value} pairs.
356
357 The fixed part of an OPT RR is structured as follows:
358
359 +------------+--------------+------------------------------+
360 | Field Name | Field Type | Description |
361 +------------+--------------+------------------------------+
362 | NAME | domain name | MUST be 0 (root domain) |
363 | TYPE | u_int16_t | OPT (41) |
364 | CLASS | u_int16_t | requestor's UDP payload size |
365 | TTL | u_int32_t | extended RCODE and flags |
366 | RDLEN | u_int16_t | length of all RDATA |
367 | RDATA | octet stream | {attribute,value} pairs |
368 +------------+--------------+------------------------------+
369
370 OPT RR Format
371
372
373
374
375
376
377
378
379
380
381
382 Damas, et al. Standards Track [Page 7]
383 RFC 6891 EDNS(0) Extensions April 2013
384
385
386 The variable part of an OPT RR may contain zero or more options in
387 the RDATA. Each option MUST be treated as a bit field. Each option
388 is encoded as:
389
390 +0 (MSB) +1 (LSB)
391 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
392 0: | OPTION-CODE |
393 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
394 2: | OPTION-LENGTH |
395 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
396 4: | |
397 / OPTION-DATA /
398 / /
399 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
400
401 OPTION-CODE
402 Assigned by the Expert Review process as defined by the DNSEXT
403 working group and the IESG.
404
405 OPTION-LENGTH
406 Size (in octets) of OPTION-DATA.
407
408 OPTION-DATA
409 Varies per OPTION-CODE. MUST be treated as a bit field.
410
411 The order of appearance of option tuples is not defined. If one
412 option modifies the behaviour of another or multiple options are
413 related to one another in some way, they have the same effect
414 regardless of ordering in the RDATA wire encoding.
415
416 Any OPTION-CODE values not understood by a responder or requestor
417 MUST be ignored. Specifications of such options might wish to
418 include some kind of signaled acknowledgement. For example, an
419 option specification might say that if a responder sees and supports
420 option XYZ, it MUST include option XYZ in its response.
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437 Damas, et al. Standards Track [Page 8]
438 RFC 6891 EDNS(0) Extensions April 2013
439
440
441 6.1.3. OPT Record TTL Field Use
442
443 The extended RCODE and flags, which OPT stores in the RR Time to Live
444 (TTL) field, are structured as follows:
445
446 +0 (MSB) +1 (LSB)
447 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
448 0: | EXTENDED-RCODE | VERSION |
449 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
450 2: | DO| Z |
451 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
452
453 EXTENDED-RCODE
454 Forms the upper 8 bits of extended 12-bit RCODE (together with the
455 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0
456 indicates that an unextended RCODE is in use (values 0 through
457 15).
458
459 VERSION
460 Indicates the implementation level of the setter. Full
461 conformance with this specification is indicated by version '0'.
462 Requestors are encouraged to set this to the lowest implemented
463 level capable of expressing a transaction, to minimise the
464 responder and network load of discovering the greatest common
465 implementation level between requestor and responder. A
466 requestor's version numbering strategy MAY ideally be a run-time
467 configuration option.
468 If a responder does not implement the VERSION level of the
469 request, then it MUST respond with RCODE=BADVERS. All responses
470 MUST be limited in format to the VERSION level of the request, but
471 the VERSION of each response SHOULD be the highest implementation
472 level of the responder. In this way, a requestor will learn the
473 implementation level of a responder as a side effect of every
474 response, including error responses and including RCODE=BADVERS.
475
476 6.1.4. Flags
477
478 DO
479 DNSSEC OK bit as defined by [RFC3225].
480
481 Z
482 Set to zero by senders and ignored by receivers, unless modified
483 in a subsequent specification.
484
485
486
487
488
489
490
491
492 Damas, et al. Standards Track [Page 9]
493 RFC 6891 EDNS(0) Extensions April 2013
494
495
496 6.2. Behaviour
497
498 6.2.1. Cache Behaviour
499
500 The OPT record MUST NOT be cached.
501
502 6.2.2. Fallback
503
504 If a requestor detects that the remote end does not support EDNS(0),
505 it MAY issue queries without an OPT record. It MAY cache this
506 knowledge for a brief time in order to avoid fallback delays in the
507 future. However, if DNSSEC or any future option using EDNS is
508 required, no fallback should be performed, as these options are only
509 signaled through EDNS. If an implementation detects that some
510 servers for the zone support EDNS(0) while others would force the use
511 of TCP to fetch all data, preference MAY be given to servers that
512 support EDNS(0). Implementers SHOULD analyse this choice and the
513 impact on both endpoints.
514
515 6.2.3. Requestor's Payload Size
516
517 The requestor's UDP payload size (encoded in the RR CLASS field) is
518 the number of octets of the largest UDP payload that can be
519 reassembled and delivered in the requestor's network stack. Note
520 that path MTU, with or without fragmentation, could be smaller than
521 this.
522
523 Values lower than 512 MUST be treated as equal to 512.
524
525 The requestor SHOULD place a value in this field that it can actually
526 receive. For example, if a requestor sits behind a firewall that
527 will block fragmented IP packets, a requestor SHOULD NOT choose a
528 value that will cause fragmentation. Doing so will prevent large
529 responses from being received and can cause fallback to occur. This
530 knowledge may be auto-detected by the implementation or provided by a
531 human administrator.
532
533 Note that a 512-octet UDP payload requires a 576-octet IP reassembly
534 buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over
535 Ethernet would be reasonable.
536
537 Where fragmentation is not a concern, use of bigger values SHOULD be
538 considered by implementers. Implementations SHOULD use their largest
539 configured or implemented values as a starting point in an EDNS
540 transaction in the absence of previous knowledge about the
541 destination server.
542
543
544
545
546
547 Damas, et al. Standards Track [Page 10]
548 RFC 6891 EDNS(0) Extensions April 2013
549
550
551 Choosing a very large value will guarantee fragmentation at the IP
552 layer, and may prevent answers from being received due to loss of a
553 single fragment or to misconfigured firewalls.
554
555 The requestor's maximum payload size can change over time. It MUST
556 NOT be cached for use beyond the transaction in which it is
557 advertised.
558
559 6.2.4. Responder's Payload Size
560
561 The responder's maximum payload size can change over time but can
562 reasonably be expected to remain constant between two closely spaced
563 sequential transactions, for example, an arbitrary QUERY used as a
564 probe to discover a responder's maximum UDP payload size, followed
565 immediately by an UPDATE that takes advantage of this size. This is
566 considered preferable to the outright use of TCP for oversized
567 requests, if there is any reason to suspect that the responder
568 implements EDNS, and if a request will not fit in the default
569 512-byte payload size limit.
570
571 6.2.5. Payload Size Selection
572
573 Due to transaction overhead, it is not recommended to advertise an
574 architectural limit as a maximum UDP payload size. Even on system
575 stacks capable of reassembling 64 KB datagrams, memory usage at low
576 levels in the system will be a concern. A good compromise may be the
577 use of an EDNS maximum payload size of 4096 octets as a starting
578 point.
579
580 A requestor MAY choose to implement a fallback to smaller advertised
581 sizes to work around firewall or other network limitations. A
582 requestor SHOULD choose to use a fallback mechanism that begins with
583 a large size, such as 4096. If that fails, a fallback around the
584 range of 1280-1410 bytes SHOULD be tried, as it has a reasonable
585 chance to fit within a single Ethernet frame. Failing that, a
586 requestor MAY choose a 512-byte packet, which with large answers may
587 cause a TCP retry.
588
589 Values of less than 512 bytes MUST be treated as equal to 512 bytes.
590
591 6.2.6. Support in Middleboxes
592
593 In a network that carries DNS traffic, there could be active
594 equipment other than that participating directly in the DNS
595 resolution process (stub and caching resolvers, authoritative
596 servers) that affects the transmission of DNS messages (e.g.,
597 firewalls, load balancers, proxies, etc.), referred to here as
598 "middleboxes".
599
600
601
602 Damas, et al. Standards Track [Page 11]
603 RFC 6891 EDNS(0) Extensions April 2013
604
605
606 Conformant middleboxes MUST NOT limit DNS messages over UDP to 512
607 bytes.
608
609 Middleboxes that simply forward requests to a recursive resolver MUST
610 NOT modify and MUST NOT delete the OPT record contents in either
611 direction.
612
613 Middleboxes that have additional functionality, such as answering
614 queries or acting as intelligent forwarders, SHOULD be able to
615 process the OPT record and act based on its contents. These
616 middleboxes MUST consider the incoming request and any outgoing
617 requests as separate transactions if the characteristics of the
618 messages are different.
619
620 A more in-depth discussion of this type of equipment and other
621 considerations regarding their interaction with DNS traffic is found
622 in [RFC5625].
623
624 7. Transport Considerations
625
626 The presence of an OPT pseudo-RR in a request should be taken as an
627 indication that the requestor fully implements the given version of
628 EDNS and can correctly understand any response that conforms to that
629 feature's specification.
630
631 Lack of presence of an OPT record in a request MUST be taken as an
632 indication that the requestor does not implement any part of this
633 specification and that the responder MUST NOT include an OPT record
634 in its response.
635
636 Extended agents MUST be prepared for handling interactions with
637 unextended clients in the face of new protocol elements and fall back
638 gracefully to unextended DNS when needed.
639
640 Responders that choose not to implement the protocol extensions
641 defined in this document MUST respond with a return code (RCODE) of
642 FORMERR to messages containing an OPT record in the additional
643 section and MUST NOT include an OPT record in the response.
644
645 If there is a problem with processing the OPT record itself, such as
646 an option value that is badly formatted or that includes out-of-range
647 values, a FORMERR MUST be returned. If this occurs, the response
648 MUST include an OPT record. This is intended to allow the requestor
649 to distinguish between servers that do not implement EDNS and format
650 errors within EDNS.
651
652
653
654
655
656
657 Damas, et al. Standards Track [Page 12]
658 RFC 6891 EDNS(0) Extensions April 2013
659
660
661 The minimal response MUST be the DNS header, question section, and an
662 OPT record. This MUST also occur when a truncated response (using
663 the DNS header's TC bit) is returned.
664
665 8. Security Considerations
666
667 Requestor-side specification of the maximum buffer size may open a
668 DNS denial-of-service attack if responders can be made to send
669 messages that are too large for intermediate gateways to forward,
670 thus leading to potential ICMP storms between gateways and
671 responders.
672
673 Announcing very large UDP buffer sizes may result in dropping of DNS
674 messages by middleboxes (see Section 6.2.6). This could cause
675 retransmissions with no hope of success. Some devices have been
676 found to reject fragmented UDP packets.
677
678 Announcing UDP buffer sizes that are too small may result in fallback
679 to TCP with a corresponding load impact on DNS servers. This is
680 especially important with DNSSEC, where answers are much larger.
681
682 9. IANA Considerations
683
684 The IANA has assigned RR type code 41 for OPT.
685
686 [RFC2671] specified a number of IANA subregistries within "DOMAIN
687 NAME SYSTEM PARAMETERS":
688
689 o DNS EDNS(0) Options
690
691 o EDNS Version Number
692
693 o EDNS Header Flags
694
695 Additionally, two entries were generated in existing registries:
696
697 o EDNS Extended Label Type in the DNS Label Types registry
698
699 o Bad OPT Version in the DNS RCODES registry
700
701 IANA has updated references to [RFC2671] in these entries and
702 subregistries to this document.
703
704 [RFC2671] created the DNS Label Types registry. This registry is to
705 remain open.
706
707 The registration procedure for the DNS Label Types registry is
708 Standards Action.
709
710
711
712 Damas, et al. Standards Track [Page 13]
713 RFC 6891 EDNS(0) Extensions April 2013
714
715
716 This document assigns option code 65535 in the DNS EDNS0 Options
717 registry to "Reserved for future expansion".
718
719 The current status of the IANA registry for EDNS Option Codes at the
720 time of publication of this document is
721
722 o 0-4 assigned, per references in the registry
723
724 o 5-65000 Available for assignment, unassigned
725
726 o 65001-65534 Local/Experimental use
727
728 o 65535 Reserved for future expansion
729
730 [RFC2671] expands the RCODE space from 4 bits to 12 bits. This
731 allows more than the 16 distinct RCODE values allowed in [RFC1035].
732 IETF Review is required to add a new RCODE.
733
734 This document assigns EDNS Extended RCODE 16 to "BADVERS" in the DNS
735 RCODES registry.
736
737 [RFC2671] called for the recording of assignment of extended label
738 types 0bxx111111 as "Reserved for future extended label types"; the
739 IANA registry currently contains "Reserved for future expansion".
740 This request implied, at that time, a request to open a new registry
741 for extended label types, but due to the possibility of ambiguity,
742 new text registrations were instead made within the general DNS Label
743 Types registry, which also registers entries originally defined by
744 [RFC1035]. There is therefore no Extended Label Types registry, with
745 all label types registered in the DNS Label Types registry.
746
747 This document deprecates Binary Labels. Therefore, the status for
748 the DNS Label Types registration "Binary Labels" is now "Historic".
749
750 IETF Standards Action is required for assignments of new EDNS(0)
751 flags. Flags SHOULD be used only when necessary for DNS resolution
752 to function. For many uses, an EDNS Option Code may be preferred.
753
754 IETF Standards Action is required to create new entries in the EDNS
755 Version Number registry. Within the EDNS Option Code space, Expert
756 Review is required for allocation of an EDNS Option Code. Per this
757 document, IANA maintains a registry for the EDNS Option Code space.
758
759
760
761
762
763
764
765
766
767 Damas, et al. Standards Track [Page 14]
768 RFC 6891 EDNS(0) Extensions April 2013
769
770
Traditional DNS messages are limited to 512 octets in size when sent over UDP [RFC1035]. Fitting the increasing amounts of data that can be transported in DNS in this 512-byte limit is becoming more difficult. For instance, inclusion of DNSSEC records frequently requires a much larger response than a 512-byte message can hold.
Traditional DNS messages are limited to 512-bytes in size when sent over UDP [RFC1035]. Fitting the increasing amounts of data that can be transported in DNS in this 512-byte limit is becoming more difficult. For instance, inclusion of DNSSEC records frequently requires a much larger response than a 512-byte message can hold.
In the original text, it says: DNS messages are limited to 512 octets in size, but it should be 512 bytes not octets. --VERIFIER NOTES-- Most RFCs use "octets" and "bytes" as equivalent (even if I personally prefer "octets").
771 9.1. OPT Option Code Allocation Procedure
772
773 OPT Option Codes are assigned by Expert Review.
774
775 Assignment of Option Codes should be liberal, but duplicate
776 functionality is to be avoided.
777
778 10. References
779
780 10.1. Normative References
781
782 [RFC1035] Mockapetris, P., "Domain names - implementation and
783 specification", STD 13, RFC 1035, November 1987.
784
785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
786 Requirement Levels", BCP 14, RFC 2119, March 1997.
787
788 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
789 RFC 2671, August 1999.
790
791 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC",
792 RFC 3225, December 2001.
793
794 10.2. Informative References
795
796 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System",
797 RFC 2673, August 1999.
798
799 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
800 Hain, "Representing Internet Protocol version 6 (IPv6)
801 Addresses in the Domain Name System (DNS)", RFC 3363,
802 August 2002.
803
804 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
805 Support for Internet Protocol version 6 (IPv6)", RFC 3364,
806 August 2002.
807
808 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines",
809 BCP 152, RFC 5625, August 2009.
810
811
812
813
814
815
816
817
818
819
820
821
822 Damas, et al. Standards Track [Page 15]
823 RFC 6891 EDNS(0) Extensions April 2013
824
825
826 Appendix A. Changes since RFCs 2671 and 2673
827
828 Following is a list of high-level changes to RFCs 2671 and 2673.
829
830 o Support for the OPT record is now mandatory.
831
832 o Extended label types remain available, but their use is
833 discouraged as a general solution due to observed difficulties in
834 their deployment on the Internet, as illustrated by the work with
835 the "Binary Labels" type.
836
837 o RFC 2673, which defined the "Binary Labels" type and is currently
838 Experimental, is requested to be moved to Historic.
839
840 o Made changes in how EDNS buffer sizes are selected, and provided
841 recommendations on how to select them.
842
843 Authors' Addresses
844
845 Joao Damas
846 Bond Internet Systems
847 Av Albufera 14
848 S.S. Reyes, Madrid 28701
849 ES
850
851 Phone: +1 650.423.1312
852 EMail: joao@bondis.org
853
854
855 Michael Graff
856
857 EMail: explorer@flame.org
858
859
860 Paul Vixie
861 Internet Systems Consortium
862 950 Charter Street
863 Redwood City, California 94063
864 US
865
866 Phone: +1 650.423.1301
867 EMail: vixie@isc.org
868
869
870
871
872
873
874
875
876
877 Damas, et al. Standards Track [Page 16]
878
9.1. OPT Option Code Allocation Procedure OPT Option Codes are assigned by Expert Review. Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided.
9.1. DNS EDNS0 Option Code ChangesOPT Option Codes are assigned by Expert Review.This document modifies the name of the existing registry DNS EDNS0 Options to DNS EDNS0 Option Codes (OPT) and updates the registration procedures to Expert Review. Assignment of Option Codes should be liberal, but duplicate functionality is to be avoided.