idnits 2.17.1 draft-ietf-dnsext-rfc2671bis-edns0-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2671]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC2671, but the abstract doesn't seem to directly say this. It does mention RFC2671 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2673, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The requestor SHOULD place a value in this field that it can actually receive. For example, if a requestor sits behind a firewall which will block fragmented IP packets, a requestor SHOULD not choose a value which will cause fragmentation. Doing so will prevent large responses from being received, and can cause fallback to occur. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The requestor's maximum payload size can change over time. It MUST not be cached for use beyond the transaction in which it is advertised. -- 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 (March 7, 2011) is 4798 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Downref: Normative reference to an Informational RFC: RFC 3363 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSEXT Working Group J. Damas 3 Internet-Draft M. Graff 4 Obsoletes: 2671, 2673 P. Vixie 5 (if approved) Internet Systems Consortium 6 Intended status: Standards Track March 7, 2011 7 Expires: September 8, 2011 9 Extension Mechanisms for DNS (EDNS0) 10 draft-ietf-dnsext-rfc2671bis-edns0-05 12 Abstract 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. 20 This document updates the EDNS0 specification [RFC2671] based on 10 21 years of deployment experience. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 8, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. EDNS Support Requirement . . . . . . . . . . . . . . . . . . . 3 60 4. DNS Message changes . . . . . . . . . . . . . . . . . . . . . 4 61 4.1. Message Header . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Label Types . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.3. UDP Message Size . . . . . . . . . . . . . . . . . . . . . 4 64 5. Extended Label Types . . . . . . . . . . . . . . . . . . . . . 4 65 6. The OPT pseudo-RR . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. OPT Record Definition . . . . . . . . . . . . . . . . . . 5 67 6.2. OPT Record Wire Format . . . . . . . . . . . . . . . . . . 5 68 6.3. Cache behaviour . . . . . . . . . . . . . . . . . . . . . 7 69 6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.5. Requestor's Payload Size . . . . . . . . . . . . . . . . . 7 71 6.6. Responder's Payload Size . . . . . . . . . . . . . . . . . 7 72 6.7. Payload Size Selection . . . . . . . . . . . . . . . . . . 8 73 6.8. Middleware Boxes . . . . . . . . . . . . . . . . . . . . . 8 74 6.9. OPT Record TTL Field Use . . . . . . . . . . . . . . . . . 8 75 6.10. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.11. OPT Options Code Allocation Procedure . . . . . . . . . . 9 77 7. Transport Considerations . . . . . . . . . . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 Appendix A. Document Editing History . . . . . . . . . . . . . . 11 81 Appendix A.1. Changes since RFC2671 . . . . . . . . . . . . . . . 11 82 Appendix A.2. Changes since -02 . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 DNS [RFC1035] specifies a Message Format and within such messages 91 there are standard formats for encoding options, errors, and name 92 compression. The maximum allowable size of a DNS Message is limited 93 to 512 bytes. Many of DNS's protocol limits are too small for uses 94 which are commom or desired to become common. RFC 1035 does not 95 define any way for implementations to advertise their capabilities. 97 [RFC2671] added extension mechanism to DNS, this mechanism is widely 98 supported and number of new DNS uses and protocol extensions depend 99 on the presence of these extensions. This memo refines that 100 specification and obsoletes [RFC2671]. 102 Unextended agents will not know how to interpret the protocol 103 extensions defined in [RFC2671] and restated here. Extended agents 104 must be prepared for handling the interactions with unextended 105 clients in the face of new protocol elements, and fall back 106 gracefully to unextended DNS. [RFC2671] proposed extensions to the 107 basic DNS protocol to overcome these deficiencies. This memo refines 108 that specification and obsoletes [RFC2671]. 110 [RFC2671] specified extended label types. The only one proposed was 111 in RFC2673 for a label type called "Bitstring Labels." For various 112 reasons introducing a new label type was found to be extremely 113 difficult, and RFC2673 was moved to Experimental. This document 114 Obsoletes Extended Labels. 116 2. Terminology 118 "Requestor" is the side which sends a request. "Responder" is an 119 authoritative, recursive resolver, or other DNS component which 120 responds to questions. 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. EDNS Support Requirement 128 EDNS support is practically mandatory in a modern world. DNSSEC 129 requires EDNS support, and many other features are made possible only 130 by EDNS support to request or advertise them. Many organizations are 131 requiring DNSSEC. Without common interoperability, DNSSEC cannot be 132 as easily deployed. 134 DNS publishers are wanting to put more data in answers. DNSSEC 135 DNSKEY records, negative answers, and many other DNSSEC queries cause 136 larger answers to be returned. In order to support this, DNS 137 servers, middleware, and stub resolvers MUST support larger packet 138 sizes advertised via EDNS0. 140 4. DNS Message changes 142 4.1. Message Header 144 The DNS Message Header's second full 16-bit word is divided into a 145 4-bit OPCODE, a 4-bit RCODE, and a number of 1-bit flags (see , 146 section 4.1.1 [RFC1035]). Some of these were marked for future use, 147 and most these have since been allocated. Also, most of the RCODE 148 values are now in use. The OPT pseudo-RR specified below contains 149 extensions to the RCODE bit field as well as additional flag bits. 151 4.2. Label Types 153 The first two bits of a wire format domain label are used to denote 154 the type of the label. [RFC1035] allocates two of the four possible 155 types and reserves the other two. More label types were defined in 156 [RFC2671]. This document obsoletes the use of the 2-bit combination 157 defined by [RFC2671] to identify extended label types. 159 4.3. UDP Message Size 161 Traditional DNS Messages are limited to 512 octets in size when sent 162 over UDP ([RFC1035]). Today, many organizations wish to return many 163 records in a single reply, and special tricks are needed to make the 164 responses fit in this 512-byte limit. Additionally, inclusion of 165 DNSSEC records frequently requires a much larger response than a 512 166 byte message can hold. 168 EDNS0 is intended to address these larger packet sizes and continue 169 to use UDP. It specifies a way to advertise additional features such 170 as larger response size capability, which is intended to help avoid 171 truncated UDP responses which then cause retry over TCP. 173 5. Extended Label Types 175 The first octet in the on-the-wire representation of a DNS label 176 specifies the label type; the basic DNS specification [RFC1035] 177 dedicates the two most significant bits of that octet for this 178 purpose. 180 [RFC2671] defined DNS label type 0b01 for use as an indication for 181 Extended Label Types. A specific Extended Label Type is selected by 182 the 6 least significant bits of the first octet. Thus, Extended 183 Label Types are indicated by the values 64-127 (0b01xxxxxx) in the 184 first octet of the label. 186 Extended Label Types are difficult to use due to support in clients 187 and intermediate gateways as described in [RFC3364] which moves them 188 to experimental status and [RFC3363], which describes the pros and 189 cons. 191 Therefore, this document moves them from experimental to historical, 192 making them obsoleted. Additionally, the registry of Extended Label 193 Types is requested to be closed. 195 6. The OPT pseudo-RR 197 6.1. OPT Record Definition 199 An OPT pseudo-RR (sometimes called a meta-RR) MAY be added to the 200 additional data section of a request. 202 The OPT RR has RR type 41. 204 If present in requests, compliant responders MUST include an OPT 205 record in their respective responses. 207 An OPT record does not carry any DNS data. It is used only to 208 contain control information pertaining to the question and answer 209 sequence of a specific transaction. OPT RRs MUST NOT be cached, 210 forwarded, or stored in or loaded from master files. 212 The OPT RR MAY be placed anywhere within the additional data section. 213 Only one OPT RR MAY be included within any DNS message. If a message 214 with more than one OPT RR is received, a FORMERR (RCODE=1) MUST be 215 returned. The placement flexibility for the OPT RR does not override 216 the need for the TSIG or SIG(0) RRs to be the last in the additional 217 section whenever they are present. 219 6.2. OPT Record Wire Format 221 An OPT RR has a fixed part and a variable set of options expressed as 222 {attribute, value} pairs. The fixed part holds some DNS meta data 223 and also a small collection of basic extension elements which we 224 expect to be so popular that it would be a waste of wire space to 225 encode them as {attribute, value} pairs. 227 The fixed part of an OPT RR is structured as follows: 229 +------------+--------------+------------------------------+ 230 | Field Name | Field Type | Description | 231 +------------+--------------+------------------------------+ 232 | NAME | domain name | Must be 0 (root domain) | 233 | TYPE | u_int16_t | OPT (42) | 234 | CLASS | u_int16_t | requestor's UDP payload size | 235 | TTL | u_int32_t | extended RCODE and flags | 236 | RDLEN | u_int16_t | length of all RDATA | 237 | RDATA | octet stream | {attribute,value} pairs | 238 +------------+--------------+------------------------------+ 240 OPT RR Format 242 The variable part of an OPT RR may contain zero or more options in 243 the RDATA. Each option must be treated as binary. Each option is 244 encoded as: 246 +0 (MSB) +1 (LSB) 247 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 248 0: | OPTION-CODE | 249 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 250 2: | OPTION-LENGTH | 251 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 252 4: | | 253 / OPTION-DATA / 254 / / 255 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 257 OPTION-CODE 258 Assigned by Expert Review. 260 OPTION-LENGTH 261 Size (in octets) of OPTION-DATA. 263 OPTION-DATA 264 Varies per OPTION-CODE. MUST be treated as binary. 266 The order of appearance of option tuples is not defined. If one 267 option modifies the behavior of another or multiple options are 268 related to one another in some way, they have the same effect 269 regardless of ordering in the RDATA wire encoding. 271 Any OPTION-CODE values not understood by a responder or requestor 272 MUST be ignored. Specifications of such options might wish to 273 include some kind of signaled acknowledgement. For example, an 274 option specification might say that if a responder sees option XYZ, 275 it MUST include option XYZ in its response. 277 6.3. Cache behaviour 279 The OPT record MUST NOT be cached. 281 6.4. Fallback 283 If a requestor detects that the remote end does not support EDNS0, it 284 MAY issue queries without an OPT record. It MAY cache this knowledge 285 for a brief time in order to avoid fallback delays in the future. 286 However, if DNSSEC or any future option using EDNS is required, no 287 fallback should be performed as they are only signaled through EDNS0. 288 If an implementation detects that some servers for the zone support 289 EDNS(0) while others would force the use of TCP to fetch all data, 290 preference SHOULD be given to those support EDNS(0). 292 6.5. Requestor's Payload Size 294 The requestor's UDP payload size (encoded in the RR CLASS field) is 295 the number of octets of the largest UDP payload that can be 296 reassembled and delivered in the requestor's network stack. Note 297 that path MTU, with or without fragmentation, could be smaller than 298 this. Values lower than 512 MUST be treated as equal to 512. 300 The requestor SHOULD place a value in this field that it can actually 301 receive. For example, if a requestor sits behind a firewall which 302 will block fragmented IP packets, a requestor SHOULD not choose a 303 value which will cause fragmentation. Doing so will prevent large 304 responses from being received, and can cause fallback to occur. 306 Note that a 512-octet UDP payload requires a 576-octet IP reassembly 307 buffer. Choosing between 1280 and 1410 bytes for IP (v4 or v6) over 308 Ethernet would be reasonable. Choosing a very large value will 309 guarantee fragmentation at the IP layer, and may prevent answers from 310 being received due to a single fragment loss or misconfigured 311 firewalls. 313 The requestor's maximum payload size can change over time. It MUST 314 not be cached for use beyond the transaction in which it is 315 advertised. 317 6.6. Responder's Payload Size 319 The responder's maximum payload size can change over time, but can be 320 reasonably expected to remain constant between two closely spaced 321 sequential transactions; for example, a meaningless QUERY to discover 322 a responder's maximum UDP payload size, followed immediately by an 323 UPDATE which takes advantage of this size. This is considered 324 preferable to the outright use of TCP for oversized requests, if 325 there is any reason to suspect that the responder implements EDNS, 326 and if a request will not fit in the default 512 payload size limit. 328 6.7. Payload Size Selection 330 Due to transaction overhead, it is unwise to advertise an 331 architectural limit as a maximum UDP payload size. Just because your 332 stack can reassemble 64KB datagrams, don't assume that you want to 333 spend more than about 4KB of state memory per ongoing transaction. 335 A requestor MAY choose to implement a fallback to smaller advertised 336 sizes to work around firewall or other network limitations. A 337 requestor SHOULD choose to use a fallback mechanism which begins with 338 a large size, such as 4096. If that fails, a fallback around the 339 1280-1410 byte range SHOULD be tried, as it has a reasonable chance 340 to fit within a single Ethernet frame. Failing that, a requestor MAY 341 choose a 512 byte packet, which with large answers may cause a TCP 342 retry. 344 6.8. Middleware Boxes 346 Middleware boxes (e.g. firewalls, SOHO routers, load balancers, etc) 347 MUST NOT limit DNS messages over UDP to 512 bytes. 349 Middleware boxes which simply forward requests to a recursive 350 resolver MUST NOT modify and MUST NOT delete the OPT record contents 351 in either direction. 353 Middleware boxes which have additional functionality, such as 354 answering certain queries or acting like an intelligent forwarder, 355 MUST understand the OPT record. These boxes MUST consider the 356 incoming request and any outgoing requests as separate transactions 357 if the characteristics of the messages are different. 359 A complete discussion of middleware boxes acting as DNS proxies and 360 the impact of EDNS in those implementations is described in 361 [RFC5625]. 363 6.9. OPT Record TTL Field Use 365 The extended RCODE and flags (which OPT stores in the RR TTL field) 366 are structured as follows: 368 +0 (MSB) +1 (LSB) 369 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 370 0: | EXTENDED-RCODE | VERSION | 371 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 372 2: | DO| Z | 373 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 375 EXTENDED-RCODE 376 Forms upper 8 bits of extended 12-bit RCODE (together with the 377 4 bits defined in [RFC1035]. Note that EXTENDED-RCODE value 0 378 indicates that an unextended RCODE is in use (values 0 through 379 15). 381 VERSION 382 Indicates the implementation level of whoever sets it. Full 383 conformance with this specification is indicated by version 384 ``0.'' Requestors are encouraged to set this to the lowest 385 implemented level capable of expressing a transaction, to 386 minimize the responder and network load of discovering the 387 greatest common implementation level between requestor and 388 responder. A requestor's version numbering strategy MAY 389 ideally be a run time configuration option. 390 If a responder does not implement the VERSION level of the 391 request, then it answers with RCODE=BADVERS. All responses 392 MUST be limited in format to the VERSION level of the request, 393 but the VERSION of each response SHOULD be the highest 394 implementation level of the responder. In this way a requestor 395 will learn the implementation level of a responder as a side 396 effect of every response, including error responses and 397 including RCODE=BADVERS. 399 6.10. Flags 401 DO 402 DNSSEC OK bit as defined by [RFC3225]. 404 Z 405 Set to zero by senders and ignored by receivers, unless 406 modified in a subsequent specification. 408 6.11. OPT Options Code Allocation Procedure 410 Allocations assigned by expert review. Assignment of Option Codes 411 should be liberal, but duplicate functionality is to be avoided. 413 7. Transport Considerations 415 The presence of an OPT pseudo-RR in a request should be taken as an 416 indication that the requestor fully implements the given version of 417 EDNS, and can correctly understand any response that conforms to that 418 feature's specification. 420 Lack of presence of an OPT record in a request MUST be taken as an 421 indication that the requestor does not implement any part of this 422 specification and that the responder MUST NOT include an OPT record 423 in its response. 425 Responders who do not implement these protocol extensions MUST 426 respond with FORMERR messages without any OPT record. 428 If there is a problem with processing the OPT record itself, such as 429 an option value that is badly formatted or includes out of range 430 values, a FORMERR MUST be returned. If this occurs the response MUST 431 include an OPT record. This is intended to allow the requestor to to 432 distinguish between servers which do not implement EDNS and format 433 errors within EDNS. 435 The minimal response must be the DNS header, question section, and an 436 OPT record. This must also occur when an truncated response (using 437 the DNS header's TC bit) is returned. 439 8. Security Considerations 441 Requestor-side specification of the maximum buffer size may open a 442 DNS denial of service attack if responders can be made to send 443 messages which are too large for intermediate gateways to forward, 444 thus leading to potential ICMP storms between gateways and 445 responders. 447 Announcing very large UDP buffer sizes may result in dropping by 448 middleboxes (see Section 6.8). This could cause retransmissions with 449 no hope of success. Some devices have been found to reject 450 fragmented UDP packets. 452 Announcing too small UDP buffer sizes may result in fallback to TCP 453 with a corresponding load impact on DNS servers. This is especially 454 important with DNSSEC, where answers are much larger. 456 9. IANA Considerations 458 The IANA has assigned RR type code 41 for OPT. 460 [RFC2671] specified a number of IANA sub-registries within "DOMAIN 461 NAME SYSTEM PARAMETERS:" 463 o EDNS Extended Label Type 465 o EDNS Option Codes 467 o EDNS Version Numbers 469 o Domain System Response Code 471 IANA is advised to re-parent these sub-registries to this document. 473 [RFC2671] created the "EDNS Extended Label Type Registry". We 474 request that this registry be closed. 476 This document assigns option code 65535 in the "EDNS Option Codes" 477 registry to "Reserved for future expansion." 479 [RFC2671] expands the RCODE space from 4 bits to 12 bits. This 480 allows more than the 16 distinct RCODE values allowed in [RFC1035]. 481 IETF Standards Action is required to add a new RCODE. Adding new 482 RCODEs should be avoided due to the difficulty in upgrading the 483 installed base. 485 This document assigns EDNS Extended RCODE 16 to "BADVERS". 487 IETF Standards Action is required for assignments of new EDNS0 flags. 488 Flags SHOULD be used only when necessary for DNS resolution to 489 function. For many uses, a EDNS Option Code may be preferred. 491 IETF Standards Action is required to create new entries in the EDNS 492 Version Number registry. Expert Review is required for allocation of 493 an EDNS Option Code. 495 Appendix A. Document Editing History 497 Following is a list of high-level changes made to the original 498 RFC2671. 500 Appendix A.1. Changes since RFC2671 502 o Support for the OPT record is now mandatory. 504 o Extended label types obsoleted and the registry is closed. 506 o The bitstring label type, which was already moved from draft to 507 experimental, is requested to be moved to historical. 509 o Changes in how EDNS buffer sizes are selected, with 510 recommendations on how to select them. 512 o Front material (IPR notice and such) was updated to current 513 requirements. 515 Appendix A.2. Changes since -02 517 o Specified the method for allocation of constants. 519 o Cleaned up a lot of wording, along with quite a bit of document 520 structure changes. 522 10. References 524 10.1. Normative References 526 [RFC1035] Mockapetris, P., "Domain names - implementation and 527 specification", STD 13, RFC 1035, November 1987. 529 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 530 RFC 2671, August 1999. 532 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 533 RFC 3225, December 2001. 535 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 536 Hain, "Representing Internet Protocol version 6 (IPv6) 537 Addresses in the Domain Name System (DNS)", RFC 3363, 538 August 2002. 540 10.2. Informative References 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, March 1997. 545 [RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS) 546 Support for Internet Protocol version 6 (IPv6)", RFC 3364, 547 August 2002. 549 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", 550 BCP 152, RFC 5625, August 2009. 552 Authors' Addresses 554 Joao Damas 555 Internet Systems Consortium 556 950 Charter Street 557 Redwood City, California 94063 558 US 560 Phone: +1 650.423.1312 561 Email: joao@isc.org 563 Michael Graff 564 Internet Systems Consortium 565 950 Charter Street 566 Redwood City, California 94063 567 US 569 Phone: +1 650.423.1304 570 Email: mgraff@isc.org 572 Paul Vixie 573 Internet Systems Consortium 574 950 Charter Street 575 Redwood City, California 94063 576 US 578 Phone: +1 650.423.1301 579 Email: vixie@isc.org