idnits 2.17.1 draft-ietf-dnsop-edns-chain-query-04.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 19, 2015) is 3084 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: 'TBD1' is mentioned on line 622, but not defined -- Looks like a reference, but probably isn't: '01' on line 603 == Unused Reference: 'RFC1034' is defined on line 643, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-dnsop-dns-terminology (ref. 'DNS-TERMINOLOGY') ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7646 == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-edns-tcp-keepalive-03 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 19, 2015 5 Expires: April 21, 2016 7 Chain Query requests in DNS 8 draft-ietf-dnsop-edns-chain-query-04 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 EDNS-COOKIE 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 21, 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 . . . . . . . . . . . . . . . . . . . 8 65 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 8 66 6.2. NS record Considerations . . . . . . . . . . . . . . . . 8 67 6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8 68 6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 9 69 6.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 9 70 6.6. Anycast Considerations . . . . . . . . . . . . . . . . . 9 71 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 10 74 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9.1. Simple Query for example.com . . . . . . . . . . . . . . 10 76 9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12 77 9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 10.1. EDNS0 option code for CHAIN . . . . . . . . . . . . . . 14 80 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 81 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 84 1. Introduction 86 Traditionally, a DNS client operates in stub-mode. For each DNS 87 question the DNS client needs to resolve, it sends a single query to 88 an upstream Recursive Resolver to obtain a single DNS answer. When 89 DNSSEC [RFC4033] is deployed on such DNS clients, validation requires 90 that the client obtains all the intermediate information from the DNS 91 root down to the queried-for hostname so it can perform DNSSEC 92 validation on the complete chain of trust. 94 Currently, applications send out many UDP requests concurrently. 95 This requires more resources on the DNS client with respect to state 96 (cpu, memory, battery) and bandwidth. There is also no guarantee 97 that the initial set of UDP questions will result in all the records 98 required for DNSSEC validation. More round trips could be required 99 depending on the resulting DNS answers. This especially affects 100 high-latency links. 102 This document specifies an EDNS0 extension that allows a validating 103 Resolver running as a Forwarder to open a TCP connection to another 104 Resolver and request a DNS chain answer using one DNS query/answer 105 pair. This reduces the number of round trips to two. If combined 106 with long lived TCP or [TCP-KEEPALIVE] there is only one round trip. 107 While the upstream Resolver still needs to perform all the individual 108 queries required for the complete answer, it usually has a much 109 bigger cache and does not experience significant slowdown from last- 110 mile latency. 112 This EDNS0 extension allows the Forwarder to indicate which part of 113 the DNS hierarchy it already contains in its cache. This reduces the 114 amount of data required to be transferred and reduces the work the 115 upstream Recursive Resolver has to perform. 117 This EDNS0 extension is only intended to be sent by Forwarders to 118 Recursive Resolvers. It can (and should) be ignored by Authoritative 119 Servers. 121 1.1. Requirements Notation 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 2. Terminology 129 The DNS terminology used in this document is that of 130 [DNS-TERMINOLOGY]. Additionally, the following terms are used: 131 [edit: which I hope will end up in the terminology document] 133 Recursive Resolver: A nameserver that is responsible for resolving 134 domain names for clients by following the domain's delegation 135 chain, starting at the root. Recursive Resolvers frequently use 136 caches to be able to respond to client queries quickly. Described 137 in [RFC1035] chapter 7. 139 Validating Resolver: A recursive nameserver that also performs 140 DNSSEC [RFC4033] validation. Also known as "security-aware 141 resolver". 143 3. Overview 144 When DNSSEC is deployed on a host, it can no longer delegate all DNS 145 work to the upstream Recursive Resolver. Obtaining just the DNS 146 answer itself is not enough to validate that answer using DNSSEC. 147 For DNSSEC validation, the DNS client requires a locally running 148 validating Resolver so it can confirm DNSSEC validation of all 149 intermediary DNS answers. It can configure itself as a Forwarder if 150 it obtains the IP addresses of one or more Recursive Resolvers that 151 are available, or as a stand-alone Recursive Resolver if no 152 functional Recursive Resolvers were obtained. Generating the 153 required queries for validation adds a significant delay in answering 154 the DNS question of the locally running application. The application 155 must wait while the Resolver validates all intermediate answers. 156 Each round-trip adds to the total time waiting on DNS resolution with 157 validation to complete. This makes DNSSEC resolving impractical for 158 devices on networks with a high latency. 160 This document defines the CHAIN option that allows the Resolver to 161 request all intermediate DNS data it requires to resolve and validate 162 a particular DNS answer in a single round-trip. The Resolver could 163 be part of the application or a Recursive Resolver running on the 164 host. 166 Servers answering with CHAIN data should ensure that the transport is 167 TCP or source IP address verified UDP. See Section 8. This avoids 168 abuse in DNS amplification attacks. 170 Applications that support CHAIN internally can perform validation 171 without requiring the host the run a Recursive Resolver. This is 172 particularly useful for virtual servers in a cloud or container based 173 deployment where it is undesirable to run a Recursive Resolver per 174 virtual machine. 176 The format of this option is described in Section 4. 178 As described in Section 5.4, a Recursive Resolver could use this 179 EDNS0 option to include additional data required by the Resolver in 180 the Authority Section of the DNS answer packet when using a source IP 181 verified transport. The Answer Section remains unchanged from a 182 traditional DNS answer and contains the answer and related DNSSEC 183 entries. 185 An empty CHAIN EDNS0 option MAY be sent over any transport as a 186 discovery method. A DNS server receiving such an empty CHAIN option 187 SHOULD add an empty CHAIN option in its answer to indicate that it 188 supports CHAIN for source IP address verified transports. 190 The mechanisms provided by CHAIN raise various security related 191 concerns, related to the additional work, bandwidth, amplification 192 attacks as well as privacy issues with the cache. These concerns are 193 described in Section 8. 195 4. Option Format 197 This draft uses an EDNS0 [RFC6891] 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 ~ Closest Trust Point (FQDN) ~ 206 +---------------------------------------------------------------+ 208 o OPTION-CODE, 2 octets, for CHAIN is [TBD1]. 210 o OPTION-LENGTH, 2 octets, contains the length of the payload 211 (everything after Option-length) in octets. 213 o Closest Trust Point, a variable length FDQN of the requested start 214 point of the chain. This entry is the 'lowest' known entry in the 215 DNS chain known by the recursive server seeking a CHAIN answer for 216 which it has a validated DS and DNSKEY record. The end point of 217 the chain is obtained from the DNS Query Section itself. No DNS 218 name compression is allowed for this value. 220 5. Protocol Description 222 5.1. Discovery of Support 224 A Forwarder may include a zero-length CHAIN option in a regular query 225 over any transport to discover the DNS server capability for CHAIN. 226 Recursive Resolvers that support and are willing to accept CHAIN 227 queries over source IP verified transport respond to a zero-length 228 CHAIN received by including a zero-length CHAIN option in the answer. 229 If not already using a source IP verified transport, the Forwarder 230 MAY then switch to a source IP verified transport and start sending 231 queries with the CHAIN option to request a CHAIN response from the 232 Recursive Resolver. Examples of source IP verification are the 3-way 233 TCP handshake and UDP with [EDNS-COOKIE]. 235 5.2. Generate a Query 236 In this option value, the Forwarder sets the Closest Trust Point in 237 the chain - furthest from the root - that it already has a DNSSEC 238 validated (secure or not) answer for in its cache. The upstream 239 Recursive Resolver does not need to include any part of the chain 240 from the root down to this option's FQDN. A complete example is 241 described in Section 9.1. 243 The CHAIN option should generally be sent by system Forwarders and 244 Resolvers within an application that also perform DNSSEC validation. 246 5.3. Send the Option 248 When CHAIN is available, the downstream Recursive Resolver can adjust 249 its query strategy based on the desired queries and its cache 250 contents. 252 A Forwarder can request the CHAIN option with every outgoing DNS 253 query. However, it is RECOMMENDED that Forwarders remember which 254 upstream Recursive Resolvers did not return the option (and 255 additional data) with their response. The Forwarder SHOULD fallback 256 to regular DNS for subsequent queries to those Recursive Resolvers. 257 It MAY switch to another Recursive Resolver that does support the 258 CHAIN option or try again later to see if the server has become less 259 loaded and is now willing to answer with Query Chains. 261 5.4. Generate a Response 263 When a query containing a non-zero CHAIN option is received from a 264 Forwarder, the upstream Recursive Resolver supporting CHAIN MAY 265 respond by confirming that it is returning a CHAIN. To do so, it 266 MUST set the CHAIN option to the lowest Trust Point sent as part of 267 the chain, with its corresponding OPTION-LENGTH. It extends the 268 Authority Section in the DNS answer packet with the DNS RRsets 269 required for validating the answer. The DNS RRsets added start with 270 the first chain element below the received Closest Trust Point up to 271 and including the NS and DS RRsets that represent the zone cut 272 (authoritative servers) of the QNAME. The actual DNS answer to the 273 question in the Query Section is placed in the DNS Answer 274 Section identical to the traditional DNS answer. All required DNSSEC 275 related records must be added to their appropriate sections. This 276 includes records required for proof of non-existence of regular and/ 277 or wildcard records, such as NSEC or NSEC3 records. 279 Recursive Resolvers that have not implemented or enabled support for 280 the CHAIN option, or are otherwise unwilling to perform the 281 additional work for a Chain Query due to work load, may safely ignore 282 the option in the incoming queries. Such a server MUST NOT include 283 an CHAIN option when sending DNS answer replies back, thus indicating 284 it is not able or willing to support Chain Queries at this time. 286 Requests with wrongly formatted options (i.e. bogus FQDN) MUST be 287 rejected and a FORMERR response must be returned to the sender, as 288 described by [RFC6891]. 290 Requests resulting in chains that the receiving resolver is unwilling 291 to serve can be rejected by answering the query as a regular DNS 292 reply but with an empty CHAIN payload. Replying with an empty CHAIN 293 can be used for chains that would be too big or chains that would 294 reveal too much information considered private. 296 At any time, a Recursive Resolver that has determined that it is 297 running low on resources can refuse CHAIN queries by replying with a 298 regular DNS reply with an empty CHAIN payload. 300 If a CHAIN answer would be bigger than the Recursive Resolver is 301 willing to serve, it SHOULD send a partial chain starting with the 302 data closest to the top of the chain. The client MAY re-send the 303 query with an updated Closest Trust Point until it has received the 304 full chain. The CHAIN response will contain the lowest Closest Trust 305 Point that was included in the CHAIN answer. 307 If the DNS request results in an CNAME or DNAME for the Answer 308 Section, the Recursive Resolver MUST return these records in the 309 Answer Section similar to regular DNS processing. The CNAME or DNAME 310 target MAY be placed in the Additional Section only if all supporting 311 records for DNSSEC validation of the CNAME or DNAME target are also 312 added to the Authority Section. 314 The response from a Recursive Resolver to a Resolver MUST NOT contain 315 the CHAIN option if none was present in the Resolver's original 316 request. 318 A DNS query that contains the CHAIN option MUST also have the DNSSEC 319 OK bit set. If this bit is not set, the CHAIN option received MUST 320 be ignored. 322 6. Protocol Considerations 324 6.1. DNSSEC Considerations 326 The presence or absence of an OPT resource record containing an CHAIN 327 option in a DNS query does not change the usage of those resource 328 records and mechanisms used to provide data origin authentication and 329 data integrity to the DNS, as described in [RFC4033], [RFC4034] and 330 [RFC4035]. 332 6.2. NS record Considerations 334 CHAIN responses MUST include the NS RRset from the child zone 335 including the RRSIG records required for validation. 337 When a DNSSEC chain is supplied via CHAIN, the Forwarder is no longer 338 required to use the NS RRset, as it can construct the validation path 339 via the DNSKEY and DS RRsets without using the NS RRset. However, 340 the Forwarder might be forced to switch from Forwarder mode to 341 Recursive Resolver mode due to a network topology change. In 342 Recursive Resolver mode, the NS RRsets are needed to find and query 343 Authoritative Servers directly. It is RECOMMENDED that the DNS 344 Forwarder populate its cache with this information to avoid requiring 345 future queries to obtain any missing NS records. Therefore, CHAIN 346 responses MUST include the NS RRset from the child zone, including 347 the RRSIG records required for validation. 349 6.3. TCP Session Management 351 It is RECOMMENDED that TCP sessions not immediately be closed after 352 the DNS answer to the first query is received. It is recommended to 353 use [TCP-KEEPALIVE]. 355 Both DNS clients and servers are subject to resource constraints 356 which will limit the extent to which Chain Queries can be executed. 357 Effective limits for the number of active sessions that can be 358 maintained on individual clients and servers should be established, 359 either as configuration options or by interrogation of process limits 360 imposed by the operating system. 362 In the event that there is greater demand for Chain Queries than can 363 be accommodated, DNS servers may stop advertising the CHAIN option in 364 successive DNS messages. This allows, for example, clients with 365 other candidate servers to query to establish new sessions with 366 different servers in expectation that those servers might still allow 367 Chain Queries. 369 6.4. Negative Trust Anchors 371 If a CHAIN answer would intersect with a Negative Trust Anchor 372 [RFC7646], a partian CHAIN up to the node above the Negative Trust 373 Anchor should be returned. 375 6.5. Non-Clean Paths 377 Many paths between DNS clients and Recursive Resolvers suffer from 378 poor hygiene, limiting the free flow of DNS messages that include 379 particular EDNS0 options, or messages that exceed a particular size. 380 A fallback strategy similar to that described in [RFC6891] section 381 6.2.2 SHOULD be employed to avoid persistent interference due to non- 382 clean paths. 384 6.6. Anycast Considerations 386 Recursive Resolvers of various types are commonly deployed using 387 anycast [RFC4786]. 389 Successive DNS transactions between a client and server using UDP 390 transport may involve responses generated by different anycast nodes, 391 and the use of anycast in the implementation of a DNS server is 392 effectively undetectable by the client. The CHAIN option SHOULD NOT 393 be included in responses using UDP transport from servers provisioned 394 using anycast unless all anycast server nodes are capable of 395 processing the CHAIN option. 397 Changes in network topology between clients and anycast servers may 398 cause disruption to TCP sessions making use of CHAIN more often than 399 with TCP sessions that omit it, since the TCP sessions are expected 400 to be longer-lived. Anycast servers MAY make use of TCP multipath 401 [RFC6824] to anchor the server side of the TCP connection to an 402 unambiguously-unicast address in order to avoid disruption due to 403 topology changes. 405 7. Implementation Status 407 This section records the status of known implementations of the 408 protocol defined by this specification at the time of posting of this 409 Internet-Draft, and is based on a proposal described in [RFC6982]. 410 The description of implementations in this section is intended to 411 assist the IETF in its decision processes in progressing drafts to 412 RFCs. Please note that the listing of any individual implementation 413 here does not imply endorsement by the IETF. Furthermore, no effort 414 has been spent to verify the information presented here that was 415 supplied by IETF contributors. This is not intended as, and must not 416 be construed to be, a catalog of available implementations or their 417 features. Readers are advised to note that other implementations may 418 exist. 420 According to [RFC6982], "this will allow reviewers and working groups 421 to assign due consideration to documents that have the benefit of 422 running code, which may serve as evidence of valuable experimentation 423 and feedback that have made the implemented protocols more mature. 424 It is up to the individual working groups to use this information as 425 they see fit". 427 [While there is some interest, no work has started yet] 429 8. Security Considerations 431 8.1. Amplification Attacks 433 Chain Queries can potentially send very large DNS answers. Attackers 434 could abuse this using spoofed source IP addresses to inflict large 435 Distributed Denial of Service attacks using query-chains as an 436 amplification vector in their attack. While TCP is not vulnerable 437 for this type of abuse, the UDP protocol is vulnerable to this. 439 A Recursive Resolver MUST NOT return CHAIN answers to clients over 440 UDP without source IP address verification. An example of UDP based 441 source IP address verification is [EDNS-COOKIE]. A Recursive 442 Resolver refusing a CHAIN option MUST respond with a zero-length 443 CHAIN option to indicate support for CHAIN queries when a proper 444 transport is used. It MUST NOT send an RCODE of REFUSED. 446 9. Examples 448 9.1. Simple Query for example.com 450 o A web browser on a client machine asks the Forwarder running on 451 localhost to resolve the A record of "www.example.com." by sending 452 a regular DNS UDP query on port 53 to 127.0.0.1. 454 o The Forwarder on the client machine checks its cache, and notices 455 it already has a DNSSEC validated entry of "com." in its cache. 456 This includes the DNSKEY RRset with its RRSIG records. In other 457 words, according to its cache, ".com" is DNSSEC validated as 458 "secure" and can be used to continue a DNSSEC validated chain. 460 o The Forwarder on the client opens a TCP connection to its upstream 461 Recursive Resolver on port 53. It adds the CHAIN option as 462 follows: 464 * Option-code, set to [TBD1] 465 * Option-length, set to 0x00 0x04 467 * Closest Trust Point set to "com." 469 o The upstream Recursive Resolver receives a DNS query over TCP with 470 the CHAIN Closest Trust Point set to "com.". After accepting the 471 query it starts constructing a DNS reply packet. 473 o The upstream Recursive Resolver performs all the regular work to 474 ensure it has all the answers to the query for the A record of 475 "www.example.com.". It does so without using the CHAIN option - 476 unless it is also configured as a Forwarder. The answer to the 477 original DNS question could be the actual A record, the DNSSEC 478 proof of non-existence, or an insecure NXDOMAIN response. 480 o The upstream Recursive Resolver adds the CHAIN option to the DNS 481 response as follows: 483 * Option-code, set to [TBD1] 485 * Option-length, set to 0x00 0x00 487 * The Closest Trust Point is ommited (zero length) 489 o The upstream Recursive Resolver constructs the DNS Authority 490 Section and fills it with: 492 * The DS RRset for "example.com." and its corresponding RRSIGs 493 (made by the "com." DNSKEY(s)) 495 * The DNSKEY RRset for "example.com." and its corresponding 496 RRSIGs (made by the "example.com" DNSKEY(s)) 498 * The authoritative NS RRset for "example.com." and its 499 corresponding RRSIGs (from the child zone) 501 If the answer does not exist, and the zone uses DNSSEC, it also 502 adds the proof of non-existence, such as NSEC or NSEC3 records, to 503 the Authority Section. 505 o The upstream Recursive Resolver constructs the DNS Answer 506 Section and fills it with: 508 * The A record of "www.example.com." and its corresponding RRSIGs 509 If the answer does not exist (NODATA or NXDOMAIN), the Answer 510 Section remains empty. For the NXDOMAIN case, the RCode of the 511 DNS answer packet is set to NXDOMAIN. Otherwise it remains 512 NOERROR. 514 o The upstream Recursive Resolver returns the DNS answer over the 515 existing TCP connection. When all data is sent, it SHOULD keep 516 the TCP connection open to allow for additional incoming DNS 517 queries - provided it has enough resources to do so. 519 o The Forwarder receives the DNS answer. It processes the Authority 520 Section and the Answer Section and places the information in its 521 local cache. It ensures that no data is accepted into the cache 522 without having proper DNSSEC validation. It MAY do so by looping 523 over the entries in the Authority and Answer Sections. When an 524 entry is validated for its cache, it is removed from the 525 processing list. If an entry cannot be validated it is left in 526 the process list. When the end of the list is reached, the list 527 is processed again until either all entries are placed in the 528 cache, or the remaining items cannot be placed in the cache due to 529 lack of validation. Those entries are then discarded. 531 o If the cache contains a valid answer to the application's query, 532 this answer is returned to the application via a regular DNS 533 answer packet. This packet MUST NOT contain an CHAIN option. If 534 no valid answer can be returned, normal error processing is done. 535 For example, an NXDOMAIN or an empty Answer Section could be 536 returned depending on the error condition. 538 9.2. Out-of-path Query for example.com 540 A Recursive Resolver receives a query for the A record for 541 example.com. It includes the CHAIN option with the following 542 parameters: 544 o Option-code, set to [TBD1] 546 o Option-length, set to 0x00 0x0D 548 o The Closest Trust Point set to 'unrelated.ca.' 550 As there is no chain that leads from "unrelated.ca." to 551 "example.com", the Resolving Nameserver answers with an empty CHAIN 552 specified using: 554 o Option-code, set to [TBD1] 556 o Option-length, set to 0x00 0x00 557 o The Closest Trust Point is omitted (zero length) 559 Note that the regular answer is still present just as it would be for 560 a query that did not specify the CHAIN option. 562 9.3. Non-existent data 564 A Recursive Resolver receives a query for the A record for 565 "ipv6.toronto.redhat.ca". It includes the CHAIN option with the 566 following parameters: 568 o Option-code, set to [TBD1] 570 o Option-length, set to 0x00 0x03 572 o The Closest Trust Point set to 'ca.' 574 Using regular UDP queries towards Authoritative Nameservers, it 575 locates the NS RRset for "toronto.redhat.ca.". When querying for the 576 A record it receives a reply with RCODE "NoError" and an empty Answer 577 Section. The Authority Section contains NSEC3 and RRSIG records 578 proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca". 580 The Recursive Resolver constructs a DNS reply with the following 581 CHAIN option parameters: 583 o Option-code, set to [TBD1] 585 o Option-length, set to 0x00 0x00 587 o The Closest Trust Point is ommited (zero length) 589 The RCODE is set to "NoError". The Authority Section is filled in 590 with: 592 o The DS RRset for "redhat.ca." plus RRSIGs 594 o The DNSKEY RRset for "redhat.ca." plus RRSIGs 596 o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca) 598 o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs 600 o The DS RRset for "toronto.redhat.ca." plus RRSIGs 602 o The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg 603 ns[01].toronto.redhat.ca) 605 o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs 607 o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and 608 "ns1.toronto.redhat.ca." plus RRSIGs 610 o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs 611 do exist, does not include A) 613 o The NSEC record for "toronto.redhat.ca." (proves no wildcard 614 exists) 616 The Answer Section is empty. The RCode is set to NOERROR. 618 10. IANA Considerations 620 10.1. EDNS0 option code for CHAIN 622 IANA has assigned option code [TBD1] in the "DNS EDNS0 Option Codes 623 (OPT)" registry to CHAIN. 625 11. Acknowledgements 627 Andrew Sullivan pointed out that we do not need any new data formats 628 to support DNS chains. Olafur Gudmundsson ensured the RRsets are 629 returned in the proper Sections. Thanks to Tim Wicinski for his 630 thorough review. 632 12. Normative References 634 [DNS-TERMINOLOGY] 635 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 636 Terminology", draft-ietf-dnsop-dns-terminology-05 (work in 637 progress), September 2015. 639 [EDNS-COOKIE] 640 Eastlake, Donald., "Domain Name System (DNS) Cookies", 641 draft-ietf-dnsop-cookies (work in progress), August 2015. 643 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 644 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 645 . 647 [RFC1035] Mockapetris, P., "Domain names - implementation and 648 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 649 November 1987, . 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 653 RFC2119, March 1997, 654 . 656 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 657 Rose, "DNS Security Introduction and Requirements", RFC 658 4033, DOI 10.17487/RFC4033, March 2005, 659 . 661 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 662 Rose, "Resource Records for the DNS Security Extensions", 663 RFC 4034, DOI 10.17487/RFC4034, March 2005, 664 . 666 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 667 Rose, "Protocol Modifications for the DNS Security 668 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 669 . 671 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 672 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 673 December 2006, . 675 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 676 "TCP Extensions for Multipath Operation with Multiple 677 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 678 . 680 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 681 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 682 RFC6891, April 2013, 683 . 685 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 686 Code: The Implementation Status Section", RFC 6982, DOI 687 10.17487/RFC6982, July 2013, 688 . 690 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 691 and R. Weber, "Definition and Use of DNSSEC Negative Trust 692 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 693 . 695 [TCP-KEEPALIVE] 696 Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 697 edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- 698 tcp-keepalive-03 (work in progress), September 2015. 700 Author's Address 702 Paul Wouters 703 Red Hat 705 Email: pwouters@redhat.com