idnits 2.17.00 (12 Aug 2021) /tmp/idnits39163/draft-ietf-dnsop-edns-chain-query-03.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 (October 03, 2015) is 2422 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 624, but not defined -- Looks like a reference, but probably isn't: '01' on line 606 == Unused Reference: 'RFC1034' is defined on line 645, but no explicit reference was found in the text == Outdated reference: draft-ietf-dnsop-cookies has been published as RFC 7873 ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) -- No information found for draft-wouters-edns-tcp-keeaplive - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TCP-KEEPALIVE' Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dnsop P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track October 03, 2015 5 Expires: April 05, 2016 7 Chain Query requests in DNS 8 draft-ietf-dnsop-edns-chain-query-03 10 Abstract 12 This document defines an EDNS0 extension that can be used by a 13 security-aware validating Resolver configured as a Forwarder to send 14 a single query, requesting a complete validation path along with the 15 regular query answer. The reduction in queries lowers the latency. 16 This extension requries the use of source IP verified transport such 17 as TCP or UDP with DNS-COOKIES so it cannot be abused in 18 amplification attacks. 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 April 05, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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. Discovery of Support . . . . . . . . . . . . . . . . . . 5 61 5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 5 62 5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6 63 5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6 64 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7 65 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7 66 6.2. NS record Considerations . . . . . . . . . . . . . . . . 8 67 6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8 68 6.4. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 9 69 6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9 70 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 10 73 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Simple Query for example.com . . . . . . . . . . . . . . 10 75 9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12 76 9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 10.1. EDNS0 option code for edns-chain-query . . . . . . . . . 14 79 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 83 1. Introduction 85 Traditionally, a DNS client operates in stub-mode. For each DNS 86 question the DNS client needs to resolve, it sends a single query to 87 an upstream Recursive Resolver to obtain a single DNS answer. When 88 DNSSEC [RFC4033] is deployed on such DNS clients, validation requires 89 that the client obtains all the intermediate information from the DNS 90 root down to the queried-for hostname so it can perform DNSSEC 91 validation on the complete chain of trust. 93 Currently, applications send out many UDP requests concurrently. 94 This requires more resources on the DNS client with respect to state 95 (cpu, memory, battery) and bandwidth. There is also no guarantee 96 that the initial set of UDP questions will result in all the records 97 required for DNSSEC validation. More round trips could be required 98 depending on the resulting DNS answers. This especially affects 99 high-latency links. 101 This document specifies an EDNS0 extension that allows a validating 102 Resolver running as a Forwarder to open a TCP connection to another 103 Resolver and request a DNS chain answer using one DNS query/answer 104 pair. This reduces the number of round-trip times ("RTT") to two. 105 If combined with long livd TCP or [TCP-KEEPALIVE] there is only 1 106 RTT. While the upstream Resolver still needs to perform all the 107 individual queries required for the complete answer, it usually has a 108 much bigger cache and does not experience significant slowdown from 109 last-mile latency. 111 This EDNS0 extension allows the DNS Forwarder to indicate which part 112 of the DNS hierarchy it already contains in its cache. This reduces 113 the amount of data required to be transferred and reduces the work 114 the upstream Recursive Resolver has to perform. 116 This EDNS0 extension is only intended to be sent by Forwarders to 117 Recursive Resolvers. It can (and should be) ignored by Authoritative 118 Servers. 120 1.1. Requirements Notation 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 [RFC2119]. 126 2. Terminology 128 The DNS terminology used in this document is that of 129 [DNS-TERMINOLOGY]. Additionally, the following terms are used: 130 [edit: which I hope will end up in the terminology document] 132 Recursive Resolver: A nameserver that is responsible for resolving 133 domain names for clients by following the domain's delegation 134 chain, starting at the root. Recursive Resolvers frequently use 135 caches to be able to respond to client queries quickly. Described 136 in [RFC1035] chapter 7. 138 Validating Resolver: A recursive nameserver that also performs 139 DNSSEC [RFC4033] validation. Also known as "security-aware 140 resolver". 142 3. Overview 143 When DNSSEC is deployed on the host, it can no longer delegate all 144 DNS work to the upstream Recursive Resolver. Obtaining just the DNS 145 answer itself is not enough to validate that answer using DNSSEC. 146 For DNSSEC validation, the DNS client requires a locally running 147 validating Resolver so it can confirm DNSSEC validation of all 148 intermediary DNS answers. It can configure itself as a DNS Forwarder 149 if it obtains the IP addresses of one or more Recursive Resolvers 150 that are available, or as a stand-alone Recursive Resolver if no 151 functional Recursive Resolvers were obtained. Generating the 152 required queries for validation adds a significant delay in answering 153 the DNS question of the locally running application. The application 154 must wait while the Resolver validates all intermediate answers. 155 Each round-trip adds to the total time waiting on DNS resolution with 156 validation to complete. This makes DNSSEC resolving impractical for 157 devices on networks with a high latency. 159 The edns-chain-query option allows the Resolver to request all 160 intermediate DNS data it requires to resolve and validate a 161 particular DNS answer in a single round-trip. The Resolver could be 162 part of the application or a Recursive Resolver running on the host. 164 Servers answering with chain query data exceeding 512 bytes should 165 ensure that the transport is TCP or source IP address verified UDP. 166 See Section 8. This avoids abuse in DNS amplification attacks. 168 Applications that support edns-chain-query internally can perform 169 validation without requiring the host the run a Recursive Resolver. 170 This is particularly useful for virtual servers in a cloud or 171 container based deployment where it is undesirable to run a Recursive 172 Resolver per virtual machine. 174 The format of this option is described in Section 4. 176 As described in Section 5.4, a Recursive Resolver could use this 177 EDNS0 option to include additional data required by the Resolver in 178 the Authority Section of the DNS answer packet when using a source IP 179 verified transport. The Answer Section remains unchanged from a 180 traditional DNS answer and contains the answer and related DNSSEC 181 entries. 183 An empty edns-chain-query EDNS0 option MAY be sent over any transport 184 as a discovery method. A DNS server receiving such an empty edns- 185 chain-query option SHOULD add an empty edns-chain-query option in its 186 answer to indicate that it supports edns-chain-query for source IP 187 address verified transports. 189 The mechanisms provided by edns-chain-query raise various security 190 related concerns, related to the additional work, bandwidth, 191 amplification attacks as well as privacy issues with the cache. 192 These concerns are described in Section 8. 194 4. Option Format 196 This draft uses an EDNS0 [RFC6891] option to include client IP 197 information in DNS messages. The option is structured as follows: 199 1 2 3 200 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 201 +-------------------------------+-------------------------------+ 202 ! OPTION-CODE ! OPTION-LENGTH ! 203 +-------------------------------+-------------------------------+ 204 ~ Last Known Query Name (FQDN) ~ 205 +---------------------------------------------------------------+ 207 o OPTION-CODE, 2 octets, for edns-chain-query is [TBD]. 209 o OPTION-LENGTH, 2 octets, contains the length of the payload 210 (everything after Option-length) in octets. 212 o Last Known Query Name, a variable length FDQN of the requested 213 start point of the chain. This entry is the 'lowest' known entry 214 in the DNS chain known by the recursive server seeking a edns- 215 chain-query answer. The end point of the chain is obtained from 216 the DNS Query Section itself. No compression is allowed for this 217 value. 219 5. Protocol Description 221 5.1. Discovery of Support 223 A DNS Forwarder may include a zero-length edns-chain-query option in 224 queries over any transport to discover the DNS server capability for 225 edns-chain-query. Recursive Resolvers that support and are willing 226 to accept chain queries over source IP verified transport respond to 227 a zero-length edns-chain-query received by including a zero-length 228 edns-chain-query option in the answer. A DNS Forwarder MAY then 229 switch to a source IP verified transport and sent a non-zero edns- 230 chain-query value to request a chain-query response from the 231 Recursive Resolver. Examples of source IP verification is the 3-way 232 TCP handshake and UDP with [DNS-COOKIES]. 234 5.2. Generate a Query 235 In this option value, the Forwarder sets the last known entry point 236 in the chain - furthest from the root - that it already has a DNSSEC 237 validated (secure or not) answer for in its cache. The upstream 238 Recursive Resolver does not need to include any part of the chain 239 from the root down to this option's FQDN. A complete example is 240 described in Section 9.1. 242 Depending on the size of the labels of the last known entry point 243 value, a DNS Query packet could be arbitrarily large. If using the 244 last known entry point would result in a query size of more then 512 245 bytes, the last known entry point should be replaced with its parent 246 entry until the query size would be 512 bytes or less. A separate 247 query should be send for the remainder of the validation chain. 249 The edns-chain-query option should generally be sent by system 250 Forwarders and Resolvers within an application that also perform 251 DNSSEC validation. 253 5.3. Send the Option 255 When edns-chain-query is available, the downstream Recursive Resolver 256 can adjust its query strategy based on the desired queries and its 257 cache contents. 259 A DNS Forwarder can request the edns-chain-query option with every 260 outgoing DNS query. However, it is RECOMMENDED that DNS Forwarders 261 remember which upstream Recursive Resolvers did not return the option 262 (and additional data) with their response. The DNS Forwarder SHOULD 263 fallback to regular DNS for subsequent queries to those Recursive 264 Resolvers. It MAY switch to another Resolving Resolver that does 265 support the edns-chain-query option or try again later to see if the 266 server has become less loaded and is now willing to answer with Query 267 Chains. 269 5.4. Generate a Response 271 When a query containing a non-zero edns-chain-query option is 272 received from a DNS Forwarder, the upstream Recursive Resolver 273 supporting edns-chain-query MAY respond by confirming that it is 274 returning a DNS Query Chain. To do so, it MUST set the edns-chain- 275 query option with an OPTION-LENGTH of zero to indicate the DNS answer 276 contains a Chain Query. It extends the Authority Section in the DNS 277 answer packet with the DNS RRSets required for validating the answer. 278 The DNS RRsets added start with the first chain element below the 279 received Last Known Query Name up to and including the NS and DS 280 RRsets that represent the zone cut (authoritative servers) of the 281 QNAME. The actual DNS answer to the question in the Query Section is 282 placed in the DNS Answer Section identical to the traditional DNS 283 answer. All required DNSSEC related records must be added to their 284 appropriate sections. This includes records required for proof of 285 non-existence of regular and/or wildcard records, such as NSEC or 286 NSEC3 records. 288 Recursive Resolvers that have not implemented or enabled support for 289 the edns-chain-query option, or are otherwise unwilling to perform 290 the additional work for a Chain Query due to work load, may safely 291 ignore the option in the incoming queries. Such a server MUST NOT 292 include an edns-chain-query option when sending DNS answer replies 293 back, thus indicating it is not able or willing to support Chain 294 Queries at this time. 296 Requests with wrongly formatted options (i.e. bogus FQDN) MUST be 297 rejected and a FORMERR response must be returned to the sender, as 298 described by [RFC6891]. 300 Requests resulting in chains that the receiving resolver is unwilling 301 to serve can be rejected by sending a REFUSED response to the sender, 302 as described by [RFC6891]. This refusal can be used for chains that 303 would be too big or chains that would reveal too much information 304 considered private. 306 At any time, a Recursive Resolver that has determined that it is 307 running low on resources can refuse to acknowledge a Chain Query by 308 omitting the edns-chain-query option in its reply. It may do so even 309 if it conveyed support to a DNS client previously. It may even 310 change its support for edns-chain-query within the same TCP session. 312 If the DNS request results in an CNAME or DNAME for the Answer 313 Section, the Recursive Resolver MUST return these records in the 314 Answer Section similar to regular DNS processing. The CNAME or DNAME 315 target MAY be placed in the Additional Section only if all supporting 316 records for DNSSEC validation of the CNAME or DNAME target are also 317 added to the Authority Section. 319 The response from a Recursive Resolver to a Resolver MUST NOT contain 320 the edns-chain-query option if none was present in the Resolver's 321 original request. 323 A DNS query that contains the edns-chain-query option MUST also have 324 the DNSSEC OK bit set. If this bit is not set, the edns-chain-query 325 option received MUST be ignored. 327 6. Protocol Considerations 329 6.1. DNSSEC Considerations 330 The presence or absence of an OPT resource record containing an edns- 331 chain-query option in a DNS query does not change the usage of those 332 resource records and mechanisms used to provide data origin 333 authentication and data integrity to the DNS, as described in 334 [RFC4033], [RFC4034] and [RFC4035]. 336 6.2. NS record Considerations 338 edns-chain-query responses MUST include the NS RRset from the child 339 zone, which includes DNSSEC RRSIG records required for validation. 341 When a DNSSEC chain is supplied via edns-chain-query, the DNS 342 Forwarder no longer requires to use the NS RRset, as it can construct 343 the validation path via the DNSKEY and DS RRsets without using the NS 344 RRset. However, the DNS Forwarder might be forced to switch from 345 Forwarder mode to Recursive Resolver mode due to a network topology 346 change. In Recursive Resolver mode, it requires the NS RRsets to 347 find and query Authoritative Servers directly. It is preferred that 348 the DNS Forwarder populate its cache with this information to avoid 349 requiring future queries to obtain any missing NS records. Therefor, 350 edns-chain-query responses MUST include the NS RRset from the child 351 zone, which includes DNSSEC RRSIG records required for validation. 353 6.3. TCP Session Management 355 It is recommended that TCP sessions to the Recursive Resolver are not 356 immediately closed after the DNS answer to the first query is 357 received. It is recommended to use [TCP-KEEPALIVE]. 359 Both DNS clients and servers are subject to resource constraints 360 which will limit the extent to which Chain Queries can be executed. 361 Effective limits for the number of active sessions that can be 362 maintained on individual clients and servers should be established, 363 either as configuration options or by interrogation of process limits 364 imposed by the operating system. 366 In the event that there is greater demand for Chain Queries than can 367 be accommodated, DNS servers may stop advertising the edns-query- 368 chain option in successive DNS messages. This allows, for example, 369 clients with other candidate servers to query to establish new 370 sessions with different servers in expectation that those servers 371 might still allow Chain Queries. 373 6.4. Non-Clean Paths 375 Many paths between DNS clients and Recursive Resolvers suffer from 376 poor hygiene, limiting the free flow of DNS messages that include 377 particular EDNS0 options, or messages that exceed a particular size. 378 A fallback strategy similar to that described in [RFC6891] section 379 6.2.2 SHOULD be employed to avoid persistent interference due to non- 380 clean paths. 382 6.5. Anycast Considerations 384 Recursive Resolvers of various types are commonly deployed using 385 anycast [RFC4786]. 387 Successive DNS transactions between a client and server using UDP 388 transport may involve responses generated by different anycast nodes, 389 and the use of anycast in the implementation of a DNS server is 390 effectively undetectable by the client. The edns-chain-query option 391 SHOULD NOT be included in responses using UDP transport from servers 392 provisioned using anycast unless all anycast server nodes are capable 393 of processing the edns-query-chain option. 395 Changes in network topology between clients and anycast servers may 396 cause disruption to TCP sessions making use of edns-chain-query more 397 often than with TCP sessions that omit it, since the TCP sessions are 398 expected to be longer-lived. Anycast servers MAY make use of TCP 399 multipath [RFC6824] to anchor the server side of the TCP connection 400 to an unambiguously-unicast address in order to avoid disruption due 401 to topology changes. 403 7. Implementation Status 405 This section records the status of known implementations of the 406 protocol defined by this specification at the time of posting of this 407 Internet-Draft, and is based on a proposal described in [RFC6982]. 408 The description of implementations in this section is intended to 409 assist the IETF in its decision processes in progressing drafts to 410 RFCs. Please note that the listing of any individual implementation 411 here does not imply endorsement by the IETF. Furthermore, no effort 412 has been spent to verify the information presented here that was 413 supplied by IETF contributors. This is not intended as, and must not 414 be construed to be, a catalog of available implementations or their 415 features. Readers are advised to note that other implementations may 416 exist. 418 According to [RFC6982], "this will allow reviewers and working groups 419 to assign due consideration to documents that have the benefit of 420 running code, which may serve as evidence of valuable experimentation 421 and feedback that have made the implemented protocols more mature. 422 It is up to the individual working groups to use this information as 423 they see fit". 425 [While there is some interest, no work has started yet] 427 8. Security Considerations 429 8.1. Amplification Attacks 431 Chain Queries can potentially send very large DNS answers. Attackers 432 could abuse this using spoofed source IP addresses to inflict large 433 Distributed Denial of Service attacks using query-chains as an 434 amplification vector in their attack. While TCP is not vulnerable 435 for this type of abuse, the UDP protocol is vulnerable to this. 437 A Recursive Resolver MUST NOT return Query Chain answers to clients 438 over UDP without source IP address verification. An example of UDP 439 based source IP address verification is [DNS-COOKIES]. A Recursive 440 Resolver refusing a Query Chain request MUST ignore the ends-query- 441 chain option and answering the DNS request as if it was received 442 without the ends-query-chain option. It MUST NOT send an RCODE of 443 REFUSED. 445 A Recursive Resolver SHOULD signal support in response to a zero- 446 length edns-chain-query request over UDP by responding with an zero- 447 length edns-chain-query option even without source IP address 448 verification. This allows a client to detect edns-chain-query 449 support without the need for [DNS-COOKIES] or TCP. 451 9. Examples 453 9.1. Simple Query for example.com 455 o A web browser on a client machine asks the Forwarder running on 456 localhost to resolve the A record of "www.example.com." by sending 457 a regular DNS UDP query on port 53 to 127.0.0.1. 459 o The Forwarder on the client machine checks its cache, and notices 460 it already has a DNSSEC validated entry of "com." in its cache. 461 This includes the DNSKEY RRset with its RRSIG records. In other 462 words, according to its cache, ".com" is DNSSEC validated as 463 "secure" and can be used to continue a DNSSEC validated chain. 465 o The Forwarder on the client opens a TCP connection to its upstream 466 Recursive Resolver on port 53. It adds the edns-chain-query 467 option as follows: 469 * Option-code, set to [TBD] 471 * Option-length, set to 0x00 0x04 473 * Last Known Query Name set to "com." 475 o The upstream Recursive Resolver receives a DNS query over TCP with 476 the edns-chain-query Last Known Query Name set to "com.". After 477 accepting the query it starts constructing a DNS reply packet. 479 o The upstream Recursive Resolver performs all the regular work to 480 ensure it has all the answers to the query for the A record of 481 "www.example.com.". It does so without using the edns-chain-query 482 option - unless it is also configured as a Forwarder. The answer 483 to the original DNS question could be the actual A record, the 484 DNSSEC proof of non-existence, or an insecure NXDOMAIN response. 486 o The upstream Recursive Resolver adds the edns-chain-query option 487 to the DNS answer reply as follows: 489 * Option-code, set to [TBD] 491 * Option-length, set to 0x00 0x00 493 * The Last Known Query Name is ommited (zero length) 495 o The upstream Recursive Resolver constructs the DNS Authority 496 Section and fills it with: 498 * The DS RRset for "example.com." and its corresponding RRSIGs 499 (made by the "com." DNSKEY(s)) 501 * The DNSKEY RRset for "example.com." and its corresponding 502 RRSIGs (made by the "example.com" DNSKEY(s)) 504 * The authoritative NS RRset for "example.com." and its 505 corresponding RRSIGs (from the child zone) 507 If the answer does not exist, and the zone uses DNSSEC, it also 508 adds the proof of non-existance, such as NSEC or NSEC3 records, to 509 the Authority Section. 511 o The upstream Recursive Resolver constructs the DNS Answer 512 Section and fills it with: 514 * The A record of "www.example.com." and its corresponding RRSIGs 515 If the answer does not exist (no-data or NXDOMAIN), the Answer 516 Section remains empty. For the NXDOMAIN case, the RCode of the 517 DNS answer packet is set to NXDOMAIN. Otherwise it remains 518 NOERROR. 520 o The upstream Recursive Resolver returns the DNS answer over the 521 existing TCP connection. When all data is sent, it SHOULD keep 522 the TCP connection open to allow for additional incoming DNS 523 queries - provided it has enough resources to do so. 525 o The Forwarder receives the DNS answer. It processes the Authority 526 Section and the Answer Section and places the information in its 527 local cache. It ensures that no data is accepted into the cache 528 without having proper DNSSEC validation. It MAY do so by looping 529 over the entries in the Authority and Answer Sections. When an 530 entry is validated for its cache, it is removed from the 531 processing list. If an entry cannot be validated it is left in 532 the process list. When the end of the list is reached, the list 533 is processed again until either all entries are placed in the 534 cache, or the remaining items cannot be placed in the cache due to 535 lack of validation. Those entries are then discarded. 537 o If the cache contains a valid answer to the application's query, 538 this answer is returned to the application via a regular DNS 539 answer packet. This packet MUST NOT contain an edns-chain-query 540 option. If no valid answer can be returned, normal error 541 processing is done. For example, an NXDOMAIN or an empty Answer 542 Section could be returned depending on the error condition. 544 9.2. Out-of-path Query for example.com 546 A Recursive Resolver receives a query for the A record for 547 example.com. It includes the edns-chain-query option with the 548 following parameters: 550 o Option-code, set to [TBD] 552 o Option-length, set to 0x00 0x0D 554 o The Last Known Query Name set to 'unrelated.ca.' 556 As there is no chain that leads from "unrelated.ca." to 557 "example.com", the Resolving Nameserver answers with RCODE "FormErr". 558 It includes the edns-chain-query with the following parameters: 560 o Option-code, set to [TBD] 562 o Option-length, set to 0x00 0x00 563 o The Last Known Query Name is ommited (zero length) 565 9.3. Non-existent data 567 A Recursive Resolver receives a query for the A record for 568 "ipv6.toronto.redhat.ca". It includes the edns-chain-query option 569 with the following parameters: 571 o Option-code, set to [TBD] 573 o Option-length, set to 0x00 0x03 575 o The Last Known Query Name set to 'ca.' 577 Using regular UDP queries towards Authoritative Nameservers, it 578 locates the NS RRset for "toronto.redhat.ca.". When querying for the 579 A record it receives a reply with RCODE "NoError" and an empty Answer 580 Section. The Authority Section contains NSEC3 and RRSIG records 581 proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca". 583 The Recursive Resolver constructs a DNS reply with the following 584 edns-chain-query option parameters: 586 o Option-code, set to [TBD] 588 o Option-length, set to 0x00 0x00 590 o The Last Known Query Name is ommited (zero length) 592 The RCODE is set to "NoError". The Authority Section is filled in 593 with: 595 o The DS RRset for "redhat.ca." plus RRSIGs 597 o The DNSKEY RRset for "redhat.ca." plus RRSIGs 599 o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca) 601 o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs 603 o The DS RRset for "toronto.redhat.ca." plus RRSIGs 605 o The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg 606 ns[01].toronto.redhat.ca) 608 o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs 609 o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and 610 "ns1.toronto.redhat.ca." plus RRSIGs 612 o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs 613 do exist, does not include A) 615 o The NSEC record for "toronto.redhat.ca." (proves no wildcard 616 exists) 618 The Answer Section is empty. The RCode is set to NOERROR. 620 10. IANA Considerations 622 10.1. EDNS0 option code for edns-chain-query 624 IANA has assigned option code [TBD] in the "DNS EDNS0 Option Codes 625 (OPT)" registry to edns-chain-query. 627 11. Acknowledgements 629 Andrew Sullivan pointed out that we do not need any new data formats 630 to support DNS chains. Olafur Gudmundsson ensured the RRsets are 631 returned in the proper Sections. Thanks to Tim Wicinski for his 632 thorough review. 634 12. Normative References 636 [DNS-COOKIES] 637 Eastlake, Donald., "Domain Name System (DNS) Cookies", 638 draft-ietf-dnsop-cookies (work in progress), August 2015. 640 [DNS-TERMINOLOGY] 641 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 642 Terminology", draft-hoffman-dns-terminology (work in 643 progress), March 2015. 645 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 646 STD 13, RFC 1034, November 1987. 648 [RFC1035] Mockapetris, P., "Domain names - implementation and 649 specification", STD 13, RFC 1035, November 1987. 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, March 1997. 654 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 655 Rose, "DNS Security Introduction and Requirements", RFC 656 4033, March 2005. 658 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 659 Rose, "Resource Records for the DNS Security Extensions", 660 RFC 4034, March 2005. 662 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 663 Rose, "Protocol Modifications for the DNS Security 664 Extensions", RFC 4035, March 2005. 666 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 667 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 668 December 2006, . 670 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 671 "TCP Extensions for Multipath Operation with Multiple 672 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 673 . 675 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 676 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 677 RFC6891, April 2013, 678 . 680 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 681 Code: The Implementation Status Section", RFC 6982, DOI 682 10.17487/RFC6982, July 2013, 683 . 685 [TCP-KEEPALIVE] 686 Wouters, P., "The edns-tcp-keepalive EDNS0 Option", draft- 687 wouters-edns-tcp-keeaplive (work in progress), February 688 2014. 690 Author's Address 692 Paul Wouters 693 Red Hat 695 Email: pwouters@redhat.com