idnits 2.17.00 (12 Aug 2021) /tmp/idnits44807/draft-wouters-edns-tcp-chain-query-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2013) is 3175 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: 'TBD' is mentioned on line 552, but not defined -- Looks like a reference, but probably isn't: '1' on line 221 -- Looks like a reference, but probably isn't: '01' on line 527 ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsext P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track September 10, 2013 5 Expires: March 14, 2014 7 TCP chain query requests in DNS 8 draft-wouters-edns-tcp-chain-query-00 10 Abstract 12 This document defines an EDNS0 extension that can be used by a DNSSEC 13 enabled Recursive Nameserver configured as a forwarder to send a 14 single query over TCP requesting to receive a complete validation 15 path along with the regular query answer. Additionally, use of this 16 option is considered a request to keep the TCP connection open to 17 serve additional DNS requests. Use of this option significantly 18 reduces DNS latency for hosts deploying DNSSEC. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 14, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 60 5.1. Generating a Query . . . . . . . . . . . . . . . . . . . 5 61 5.2. Generating a Response . . . . . . . . . . . . . . . . . . 6 62 5.3. Sending the Option . . . . . . . . . . . . . . . . . . . 6 63 5.4. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7 64 5.5. NS record Considerations . . . . . . . . . . . . . . . . 7 65 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 8 68 7.2. Denial of service Chains . . . . . . . . . . . . . . . . 8 69 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.1. Simple Query for example.com . . . . . . . . . . . . . . 8 71 8.2. Out-of-path query for example.com . . . . . . . . . . . . 10 72 8.3. non-existent data . . . . . . . . . . . . . . . . . . . . 11 73 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 9.1. EDNS0 option code for edns-tcp-chain-query . . . . . . . 12 75 9.2. Extended RCODE for NXPROOF . . . . . . . . . . . . . . . 12 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Introduction 82 Traditionally, clients operate in stub-mode for DNS. For each DNS 83 question the client only needs to send a single query to an upstream 84 DNS resolver to obtain a DNS answer. When DNSSEC [RFC4033] is 85 deployed on such clients, validation requires that the client obtains 86 all the (intermediate) information from the DNS root down to the 87 queried-for hostname for the DNSSEC validation of the complete chain 88 of trust. 90 For example, the validated answer for the question of the A record 91 for the zone "example.com" requires over a hundred DNS queries. That 92 many queries adds a significant number of round-trip delays that is 93 considered unusable by current user expectation. It especially 94 affects web browsers which usually need to lookup dozens of hostnames 95 to render a single web page. 97 This document specifies an EDNS0 extension that allows a validating 98 recursive name server running as a forwarder to open a TCP connection 99 to another recursive name server, to request a DNS chain answer in 100 one DNS query. This reduces the number of round-trip times ("RTT") 101 to one. While the upstream DNS resolver still needs to perform all 102 these queries, it usually has a much bigger cache and does not 103 experience significant slowdown from last-mile latency problems. 105 This EDNS0 extension allows the Forwarder to indicate which part of 106 the DNS hierarchy it already contains in its cache. This reduces the 107 amount of data required to be transferred and reduces the work the 108 upstream Resolving Nameserver has to perform. 110 This EDNS0 extension is only intended for Forwarders. It can (and 111 should be) ignored by Authoritative Nameservers and by Recursive 112 Nameservers that do not support this EDNS0 option. 114 1.1. Requirements Notation 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [RFC2119]. 120 2. Terminology 122 Stub Resolver: A simple DNS protocol implementation on the client 123 side as described in [RFC1034] section 5.3.1. 125 Authoritative Nameserver: A nameserver that has authority over one 126 or more DNS zones. These are normally not contacted by clients 127 directly but by Recursive Resolvers. Described in [RFC1035] 128 chapter 6. 130 Recursive Resolver: A nameserver that is responsible for resolving 131 domain names for clients by following the domain's delegation 132 chain, starting at the root. Recursive Resolvers frequently use 133 caches to be able to respond to client queries quickly. Described 134 in [RFC1035] chapter 7. 136 Validating Resolver: A recursive nameserver that also performs 137 DNSSEC [RFC4033] validation. 139 Forwarder: A Recursive Resolver that is using another (upstream) 140 Recursive Resolver instead of querying Authoritative Nameservers 141 directly. It still performs validation. 143 3. Overview 144 When DNSSEC is deployed on the client, it can no longer delegate all 145 DNS work to the upstream Resolving Nameserer. Obtaining just the DNS 146 answer itself is not enough to validate that answer using DNSSEC. 147 For DNSSEC validation, all the intermediate work performed by the 148 upstream Resolving Nameserver is work the client itself needs to 149 perform as well. The client needs a locally running DNS server 150 configured as Resolving Nameserver so it can confirm DNSSEC 151 validation of the DNS answer. It can configure itself as a Forwarder 152 if the DHCP server has indicated that one or more Resolving 153 Nameservers are available. Regardless, generating the required 154 queries for validation adds a significant delay in answering the DNS 155 question of the locally running applications. The application has to 156 wait while the Forwarder on the client is querying for all the 157 intermediate work. Each round-trip adds to the total time waiting on 158 DNS resolving to complete. This makes DNSSEC resolving as a 159 Forwarder very slow, especially on networks with a high latency. 161 The edns-tcp-chain-query option allows the client to ask for all 162 intermediate DNS data it requires to resolve and validate a 163 particular DNS answer in a single round-trip DNS query. Since this 164 data is practically guaranteed to be larger then the common UDP 165 packet size (and to avoid DNS amplification attacks) the client must 166 use TCP when it wants to use this EDNS0 option. To reduce the round- 167 trip times required for the three-way TCP handshake, servers and 168 clients supporting this option can choose to keep the TCP connection 169 open for re-use of additional TCP queries. 171 The format of this option is described in Section 4. 173 As described in Section 5.2, a recursive nameserver could use this 174 EDNS0 option to include additional data required by the client in the 175 Authority Section of the DNS answer packet. The Answer 176 Section remains unchanged from a traditional DNS answer and contains 177 the answer and related DNSSEC entries. 179 Its reply would contain an EDNS0 edns-tcp-chain-query option, clearly 180 indicating that (1) the server supports this EDNS0 option and (2) it 181 was willing to add the additional data into the DNS Authority section 182 and (3) it is willing to keep the TCP connection open for the client 183 to send another DNS query. 185 The mechanisms provided by edns-tcp-chain-query raise various 186 security related concerns, related to the additional work and 187 bandwidth as well as privacy issues with the cache. These concerns 188 are described in Section 7. 190 Failure to support this option or its improper handling will at worst 191 case waste the time of a single TCP DNS request, at which point the 192 recursive resolver on the client will fall back to traditional DNS 193 queries towards the upstream recursive resolver. 195 4. Option Format 197 This draft uses an EDNS0 ([RFC2671]) option to include client IP 198 information in DNS messages. The option is structured as follows: 200 1 2 3 201 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 202 +-------------------------------+-------------------------------+ 203 ! OPTION-CODE ! OPTION-LENGTH ! 204 +-------------------------------+-------------------------------+ 205 ~ Last Known Query Name (FQDN) ~ 206 +---------------------------------------------------------------+ 208 o (Defined in [RFC2671]) OPTION-CODE, 2 octets, for edns-tcp-chain- 209 query is [TBD]. 211 o (Defined in [RFC2671]) OPTION-LENGTH, 2 octets, contains the 212 length of the payload (everything after Option-length) in octets. 214 o Last Known Query Name, a variable length FDQN of the requested 215 start point of the chain. This entry is the 'lowest' known entry 216 in the DNS chain known by the recursive server seeking a edns-tcp- 217 chain-query answer. The end point of the chain is obtained from 218 the DNS Query Section itself. No compression is allowed for this 219 value. 221 o Assigned by IANA in IANA-AFI [1]. 223 5. Protocol Description 225 5.1. Generating a Query 227 The edns-tcp-chain-query option should generally be added by 228 Forwarders, as described in Section 5.3. 230 In this option value, the Forwarder sets the last known entry point 231 in the chain - furthest from the root - that it already has a 232 validated (secure or not) answer for in its cache. The upstream 233 Recursive Resolver does not need to include any part of the chain 234 from the root down to this option's FQDN. A complete example is 235 described in Section 8. 237 5.2. Generating a Response 239 When a query containing an edns-tcp-chain-query option is received 240 over a TCP connection from a Forwarder, the upstream Recursive 241 Resolver supporting edns-tcp-chain-query MAY respond by confirming 242 the edns-tcp-chain-query option with an OPTION-LENGTH of zero. It 243 extends the Authority Section for the DNS answer packet with the 244 required DNS RRSets resulting in an Authority Section that contains a 245 complete chain of DNS RRsets that start with the first chain element 246 below the received Last Known Query Name upto and including the NS 247 and DS RRsets that represent the zone cut (authoritative servers) of 248 the QNAME. The actual DNS answer to the question in the Query 249 Section is placed in the DNS Answer Section identical to traditional 250 DNS answers. If the received query has the DNSSEC OK flag set, all 251 required DNSSEC related records must be added to their appropriate 252 sections. This includes records required for proof of non-existence 253 of regular and/or wildcard records, such as NSEC or NSEC3 records. 255 Recursive Resolvers that have not implemented or enabled support for 256 the edns-tcp-chain-query option may safely ignore the option within 257 incoming queries. Such a server MUST NOT include an edns-tcp-chain- 258 query option when sending DNS answer replies, thus indicating lack of 259 support for the option. 261 Requests with wrongly formatted options (i.e. bogus FQDN) MUST be 262 rejected and a FORMERR response must be returned to the sender, as 263 described by [RFC2671], Transport Considerations. 265 Requests resulting in chains that the receiving resolver is unwilling 266 to serve can be rejected by sending a REFUSED response to the sender, 267 as described by [RFC2671], Transport Considerations. This refusal 268 can be used for chains that would be too big or chains that would 269 reveal too much information considered private. 271 In any case, the response from the receiving resolver to the client 272 resolver MUST NOT contain the edns-tcp-chain-query option if none was 273 present in the client's resolver original request. 275 5.3. Sending the Option 277 When edns-tcp-chain-querys is available, the downstream Resolving 278 Nameserver can adjust its query strategy based on the desired query 279 and its cache contents. 281 A Forwarder can send the edns-tcp-chain-query option with every 282 outgoing TCP query. However, it is RECOMMENDED that Forwarders 283 remember which upstream Resolving Nameservers did not return the 284 option (and additional data) with their response. The Forwarder 285 SHOULD fallback to regular DNS for subsequent queries to those 286 Recursive Nameservers. It MAY switch to another Resolving Nameserver 287 that does support the edns-tcp-chain-query option. 289 A Forwarder should not open many TCP connections to an upstream 290 resolver if that upstream resolver supports edns-tcp-chain-query. 291 Instead, it should chain its TCP queries over a limited number of TCP 292 connections. 294 A Forwarder that does not use its TCP connection for 300 seconds 295 SHOULD close its TCP connection. Recursive Resolvers MAY close the 296 TCP connection to a Forwarder at any time. 298 5.4. DNSSEC Considerations 300 The presence or absence of an OPT resource record containing an edns- 301 tcp-chain-query option in a DNS query does not change the usage of 302 those resource records and mechanisms used to provide data origin 303 authentication and data integrity to the DNS, as described in 304 [RFC4033], [RFC4034] and [RFC4035]. 306 5.5. NS record Considerations 308 When a DNSSEC chain is supplied via edns-tcp-chain-query, the 309 Forwarder no longer requires to use the NS RRset, as it can construct 310 the validation path via the DNSKEY and DS RRsets without using the NS 311 RRset. However, the Forwarder might be instructed via a device 312 manager to change from Forwarder to Recursive Resolver. At this 313 point it would require the NS RRsets to perform additional work. 314 Therefor, edns-tcp-chain-query responses MUST include the NS RRset 315 from the child zone, which includes DNSSEC RRSIG records required for 316 validation. 318 6. Implementation Status 320 This section records the status of known implementations of the 321 protocol defined by this specification at the time of posting of this 322 Internet-Draft, and is based on a proposal described in [RFC6982]. 323 The description of implementations in this section is intended to 324 assist the IETF in its decision processes in progressing drafts to 325 RFCs. Please note that the listing of any individual implementation 326 here does not imply endorsement by the IETF. Furthermore, no effort 327 has been spent to verify the information presented here that was 328 supplied by IETF contributors. This is not intended as, and must not 329 be construed to be, a catalog of available implementations or their 330 features. Readers are advised to note that other implementations may 331 exist. 333 According to [RFC6982], "this will allow reviewers and working groups 334 to assign due consideration to documents that have the benefit of 335 running code, which may serve as evidence of valuable experimentation 336 and feedback that have made the implemented protocols more mature. 337 It is up to the individual working groups to use this information as 338 they see fit". 340 [While there is some interest, no work has started yet] 342 7. Security Considerations 344 7.1. Amplification Attacks 346 edns-tcp-chain-query can potentially send very large answers. A 347 recursive nameserver MUST NOT offer the edns-tcp-chain-query option 348 to clients over UDP. Otherwise, a single spoofed packet could 349 generate extremely large UDP packets back to the spoofed victim's IP 350 address. Such Distributed Denial of Service attacks using other DNS 351 amplification mechanisms are fairly common. It is important that 352 this EDNS option does not give attackers an alternative method of 353 amplification. 355 7.2. Denial of service Chains 357 It is possible for a malicious Authoritative Nameserver to respond to 358 a regular DNS query with an an excessively long or even infinite 359 chain of delegations. Recursive Resolvers already have code 360 detecting such malicious delegations, and abort such queries after a 361 maximum amount of delegations has been reached. Recursive Resolvers 362 supporting the edns-tcp-chain-query option should not send a partial 363 chain back to the client if such an abort happened, but instead 364 return a REFUSED RCode. 366 8. Examples 368 8.1. Simple Query for example.com 370 1. A web browser on a client machine asks the Forwarder running on 371 localhost to resolve the A record of "www.example.com." by 372 sending a regular DNS UDP query on port 53 to 127.0.0.1. 374 2. The Forwarder on the client machine checks its cache, and 375 notices it already has a validated entry of "com." in its cache. 376 This includes the DNSKEY RRset with its RRSIG records. In other 377 words, according to its cache, ".com" is DNSSEC validated as 378 "secure" and can be used to continue a DNSSEC validated chain 379 on. 381 3. The Forwarder on the client opens a TCP connection to its 382 upstream Recursive Resolver on port 53. It adds the edns-tcp- 383 chain-query option as follows: 385 * Option-code, set to [TBD] 387 * Option-length, set to 0x00 0x04 389 * Last Known Query Name set to "com." 391 4. The upstream Recursive Resolver receives a DNS query over TCP 392 with the edns-tcp-chain-query Last Known Query Name set to 393 "com.". After accepting the query it starts constructing a DNS 394 reply packet over TCP. 396 5. The upstream Recursive Resolver performs all the regular work to 397 ensure it has all the answers to the query for the A record of 398 "www.example.com.". It does so without using the edns-tcp- 399 chain-query option - unless it is also configured as a 400 Forwarder. The answer to the original DNS question could be the 401 actual A record, the DNSSEC proof of non-existence, or an 402 insecure NXDOMAIN response. 404 6. The upstream Recursive Resolver adds the edns-tcp-chain-query 405 option to the DNS answer reply as follows: 407 * Option-code, set to [TBD] 409 * Option-length, set to 0x00 0x00 411 * The Last Known Query Name is ommited (zero length) 413 7. The upstream Recursive Resolver constructs the DNS Authority 414 Section and fills it with: 416 * The DS RRset for "example.com." and its corresponding RRSIGs 417 (made by the "com." DNSKEY(s)) 419 * The DNSKEY RRset for "example.com." and its corresponding 420 RRSIGs (made by the "example.com" DNSKEY(s)) 422 * The authoritative NS RRset for "example.com." and its 423 corresponding RRSIGs (from the child zone) 425 If the answer does not exist, and the zone uses DNSSEC, it also 426 adds the proof of non-existance, such as NSEC or NSEC3 records, 427 to the Authority Section. 429 8. The upstream Recursive Resolver constructs the DNS Answer 430 Section and fills it with: 432 * The A record of "www.example.com." and its corresponding 433 RRSIGs 435 If the answer does not exist (no-data or NXDOMAIN), the Answer 436 Section remains empty. For the NXDOMAIN case, the RCode of the 437 DNS answer packet is set to NXDOMAIN. Otherwise it remains 438 NOERROR. 440 9. The upstream Recursive Resolver returns the DNS answer over the 441 existing TCP connection. When all data is sent, it SHOULD keep 442 the TCP connection open to allow for additional incoming DNS 443 queries - provided it has enough resources to do so. 445 10. The Forwarder receives the DNS answer over TCP. It processes 446 the Authority Section and the Answer Section and places the 447 information in its local cache. If it is a DNSSEC validating 448 resolver, it ensures that no unvalidated data or out of baliwick 449 data is accepted into the cache without having proper DNSSEC 450 validation. It MAY do so by looping over the entries in the 451 Authority and Answer Sections. When an entry is validated for 452 its cache, it is removed from the processing list. If an entry 453 cannot be validated it is left in the process list. When the 454 end of the list is reached, the list is processed again until 455 either all entries are placed in the cache, or the remaining 456 items cannot be placed in the cache due to lack of validation. 457 Those entries are then disgarded. 459 11. If the cache contains a valid answer to the application's query, 460 this answer is returned to the application via a regular DNS 461 answer packet. This packet MUST NOT contain an edns-tcp-chain- 462 query option. If no valid answer can be returned, normal error 463 processing is done. For example, an NXDOMAIN or an empty Answer 464 Section could be returned depending on the error condition. 466 8.2. Out-of-path query for example.com 468 A Recursive Resolver receives a query for the A record for 469 example.com. It includes the edns-tcp-chain-query option with the 470 following parameters: 472 o Option-code, set to [TBD] 474 o Option-length, set to 0x00 0x0D 476 o The Last Known Query Name set to 'unrelated.ca.' 477 As there is no chain that leads from "unrelated.ca." to 478 "example.com", the Resolving Nameserver answers with RCODE "FormErr". 479 It includes the edns-tcp-chain-query with the following parameters: 481 o Option-code, set to [TBD] 483 o Option-length, set to 0x00 0x00 485 o The Last Known Query Name is ommited (zero length) 487 8.3. non-existent data 489 A Recursive Resolver receives a query for the A record for 490 "ipv6.toronto.redhat.ca". It includes the edns-tcp-chain-query 491 option with the following parameters: 493 o Option-code, set to [TBD] 495 o Option-length, set to 0x00 0x03 497 o The Last Known Query Name set to 'ca.' 499 Using regular UDP queries towards Authoritative Nameservers, it 500 locates the NS RRset for "toronto.redhat.ca.". When querying for the 501 A record it receives a reply with RCODE "NoError" and an empty Answer 502 Section. The Authority Section contains NSEC3 and RRSIG records 503 proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca". 505 The Recursive Resolver constructs a DNS reply with the following 506 edns-tcp-chain-query option parameters: 508 o Option-code, set to [TBD] 510 o Option-length, set to 0x00 0x00 512 o The Last Known Query Name is ommited (zero length) 514 The RCODE is set to "NoError". The Authority Section is filled in 515 with: 517 o The DS RRset for "redhat.ca." plus RRSIGs 519 o The DNSKEY RRset for "redhat.ca." plus RRSIGs 521 o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca) 523 o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs 524 o The DS RRset for "toronto.redhat.ca." plus RRSIGs 526 o The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg 527 ns[01].toronto.redhat.ca) 529 o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs 531 o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and 532 "ns1.toronto.redhat.ca." plus RRSIGs 534 o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs 535 do exist, does not include A) 537 o The NSEC record for "toronto.redhat.ca." (proves no wildcard 538 exists) 540 The Answer Section is empty. The RCode is set to NOERROR. 542 9. IANA Considerations 544 9.1. EDNS0 option code for edns-tcp-chain-query 546 IANA has assigned option code [TBD] in the "DNS EDNS0 Option Codes 547 (OPT)" registry to edns-tcp-chain-query. 549 9.2. Extended RCODE for NXPROOF 551 [No longer needed?] IANA has assigned the Extended RCODE number 552 [TBD] in the "DNS RCODEs" registry to NXPROOF 554 10. Acknowledgements 556 Andrew Sullivan pointed out that we do not need any new data formats 557 to support DNS chains. Olafur Gudmundsson ensured the RRsets are 558 returned in the proper Sections. 560 11. Normative References 562 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 563 STD 13, RFC 1034, November 1987. 565 [RFC1035] Mockapetris, P., "Domain names - implementation and 566 specification", STD 13, RFC 1035, November 1987. 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 572 2671, August 1999. 574 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 575 Rose, "DNS Security Introduction and Requirements", RFC 576 4033, March 2005. 578 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 579 Rose, "Resource Records for the DNS Security Extensions", 580 RFC 4034, March 2005. 582 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 583 Rose, "Protocol Modifications for the DNS Security 584 Extensions", RFC 4035, March 2005. 586 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 587 Code: The Implementation Status Section", RFC 6982, July 588 2013. 590 Author's Address 592 Paul Wouters 593 Red Hat 595 Email: pwouters@redhat.com