idnits 2.17.1 draft-ietf-dnsop-edns-chain-query-07.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 (February 18, 2016) is 2989 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '01' on line 625 == Unused Reference: 'RFC1034' is defined on line 666, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-dprive-dns-over-tls-05 ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Obsolete normative reference: RFC 7719 (Obsoleted by RFC 8499) == Outdated reference: A later version (-06) exists of draft-ietf-dnsop-edns-tcp-keepalive-05 Summary: 3 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: Experimental February 18, 2016 5 Expires: August 21, 2016 7 Chain Query requests in DNS 8 draft-ietf-dnsop-edns-chain-query-07 10 Abstract 12 This document defines an EDNS0 extension that can be used by a 13 security-aware validating resolver configured to use a Forwarder to 14 send a single query, requesting a complete validation path along with 15 the regular query answer. The reduction in queries potentially 16 lowers the latency and reduces the need to send multiple queries at 17 once. This extension mandates the use of source IP verified 18 transport such as TCP or UDP with EDNS-COOKIE so it cannot be abused 19 in amplification attacks. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 21, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 61 5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5 62 5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 6 63 5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6 64 5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6 65 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7 66 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7 67 6.2. NS record Considerations . . . . . . . . . . . . . . . . 8 68 6.3. Session Management . . . . . . . . . . . . . . . . . . . 8 69 6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 8 70 6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9 71 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 8.1. Additional work and bandwidth . . . . . . . . . . . . . . 10 74 8.2. Amplification Attacks . . . . . . . . . . . . . . . . . . 10 75 8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 10 76 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Simple Query for example.com . . . . . . . . . . . . . . 10 78 9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12 79 9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 10.1. EDNS0 option code for CHAIN . . . . . . . . . . . . . . 14 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 83 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 Traditionally, a DNS client operates in stub-mode. For each DNS 89 question the DNS client needs to resolve, it sends a single query to 90 an upstream Recursive Resolver to obtain a single DNS answer. When 91 DNSSEC [RFC4033] is deployed on such DNS clients, validation requires 92 that the client obtains all the intermediate information from the DNS 93 root down to the queried-for hostname so it can perform DNSSEC 94 validation on the complete chain of trust. 96 Currently, applications send out many UDP requests concurrently. 97 This requires more resources on the DNS client with respect to state 98 (cpu, memory, battery) and bandwidth. There is also no guarantee 99 that the initial set of UDP questions will result in all the records 100 required for DNSSEC validation. More round trips could be required 101 depending on the resulting DNS answers. This especially affects 102 high-latency links. 104 This document specifies an EDNS0 extension that allows a validating 105 Resolver running as a Forwarder to open a TCP connection to another 106 Resolver and request a DNS chain answer using one DNS query/answer 107 pair. This reduces the number of round trips to two. If combined 108 with long lived TCP or [TCP-KEEPALIVE] there is only one round trip. 109 While the upstream Resolver still needs to perform all the individual 110 queries required for the complete answer, it usually has a much 111 bigger cache and does not experience significant slowdown from last- 112 mile latency. 114 This EDNS0 extension allows the Forwarder to indicate which part of 115 the DNS hierarchy it already contains in its cache. This reduces the 116 amount of data required to be transferred and reduces the work the 117 upstream Recursive Resolver has to perform. 119 This EDNS0 extension is only intended to be sent by Forwarders to 120 Recursive Resolvers. It MUST be ignored by Authoritative Servers. 122 1.1. Requirements Notation 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. Terminology 130 The DNS terminology used in this document is that of [RFC7719]. 131 Additionally, the following terms are used: 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 145 When DNSSEC is deployed on a host, it can no longer delegate all DNS 146 work to the upstream Recursive Resolver. Obtaining just the DNS 147 answer itself is not enough to validate that answer using DNSSEC. 148 For DNSSEC validation, the DNS client requires a locally running 149 validating Resolver so it can confirm DNSSEC validation of all 150 intermediary DNS answers. It can configure itself as a Forwarder if 151 it obtains the IP addresses of one or more Recursive Resolvers that 152 are available, or as a stand-alone Recursive Resolver if no 153 functional Recursive Resolvers were obtained. Generating the 154 required queries for validation adds a significant delay in answering 155 the DNS question of the locally running application. The application 156 must wait while the Resolver validates all intermediate answers. 157 Each round-trip adds to the total time waiting on DNS resolution with 158 validation to complete. This makes DNSSEC resolving impractical for 159 devices on networks with a high latency. 161 This document defines the CHAIN option that allows the Resolver to 162 request all intermediate DNS data it requires to resolve and validate 163 a particular DNS answer in a single round-trip. The Resolver could 164 be part of the application or a Recursive Resolver running on the 165 host. 167 Servers answering with CHAIN data should ensure that the transport is 168 TCP or source IP address verified UDP. See Section 8. This avoids 169 abuse in DNS amplification attacks. 171 Applications that support CHAIN internally can perform validation 172 without requiring the host to run a Recursive Resolver. This is 173 particularly useful for virtual servers in a cloud or container based 174 deployment where it is undesirable to run a Recursive Resolver per 175 virtual machine. 177 The format of this option is described in Section 4. 179 As described in Section 5.4, a Recursive Resolver could use this 180 EDNS0 option to include additional data required by the Resolver in 181 the Authority Section of the DNS answer packet when using a source IP 182 verified transport. The Answer Section remains unchanged from a 183 traditional DNS answer and contains the answer and related DNSSEC 184 entries. 186 An empty CHAIN EDNS0 option MAY be sent over any transport as a 187 discovery method. A DNS server receiving such an empty CHAIN option 188 SHOULD add an empty CHAIN option in its answer to indicate that it 189 supports CHAIN for source IP address verified transports. 191 The mechanisms provided by CHAIN raise various security related 192 concerns, related to the additional work, bandwidth, amplification 193 attacks as well as privacy issues with the cache. These concerns are 194 described in Section 8. 196 4. Option Format 198 This draft uses an EDNS0 [RFC6891] option to include client IP 199 information in DNS messages. The option is structured as follows: 201 1 2 3 202 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 203 +-------------------------------+-------------------------------+ 204 ! OPTION-CODE ! OPTION-LENGTH ! 205 +-------------------------------+-------------------------------+ 206 ~ Closest Trust Point (FQDN) ~ 207 +---------------------------------------------------------------+ 209 o OPTION-CODE, 2 octets, for CHAIN is 13. 211 o OPTION-LENGTH, 2 octets, contains the length of the payload 212 (everything after Option-length) in octets. 214 o Closest Trust Point, a variable length Fully Qualified Domain Name 215 ("FQDN") in DNS wire format of the requested start point of the 216 chain. This entry is the 'lowest' known entry in the DNS chain 217 known by the recursive server seeking a CHAIN answer for which it 218 has a validated DS and DNSKEY record. The end point of the chain 219 is obtained from the DNS Query Section itself. No DNS name 220 compression is allowed for this value. 222 5. Protocol Description 224 5.1. Discovery of Support 226 A Forwarder may include a zero-length CHAIN option in a regular query 227 over any transport to discover the DNS server capability for CHAIN. 228 Recursive Resolvers that support and are willing to accept CHAIN 229 queries over source IP verified transport respond to a zero-length 230 CHAIN received by including a zero-length CHAIN option in the answer. 231 If not already using a source IP verified transport, the Forwarder 232 MAY then switch to a source IP verified transport and start sending 233 queries with the CHAIN option to request a CHAIN response from the 234 Recursive Resolver. Examples of source IP verification are the 3-way 235 TCP handshake and UDP with [EDNS-COOKIE]. 237 5.2. Generate a Query 239 In this option value, the Forwarder sets the Closest Trust Point in 240 the chain - furthest from the root - that it already has a DNSSEC 241 validated (secure or not) answer for in its cache. The upstream 242 Recursive Resolver does not need to include any part of the chain 243 from the root down to this option's FQDN. A complete example is 244 described in Section 9.1. 246 The CHAIN option should generally be sent by system Forwarders and 247 Resolvers within an application that also perform DNSSEC validation. 249 5.3. Send the Option 251 When CHAIN is available, the downstream Recursive Resolver can adjust 252 its query strategy based on the desired queries and its cache 253 contents. 255 A Forwarder can request the CHAIN option with every outgoing DNS 256 query. However, it is RECOMMENDED that Forwarders remember which 257 upstream Recursive Resolvers did not return the option (and 258 additional data) with their response. The Forwarder SHOULD fallback 259 to regular DNS for subsequent queries to those Recursive Resolvers. 260 It MAY switch to another Recursive Resolver that does support the 261 CHAIN option or try again later to see if the server has become less 262 loaded and is now willing to answer with Query Chains. A fallback 263 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 264 be employed to avoid persistent interference due to non-clean paths. 266 5.4. Generate a Response 268 When a query containing a non-zero CHAIN option is received from a 269 Forwarder, the upstream Recursive Resolver supporting CHAIN MAY 270 respond by confirming that it is returning a CHAIN. To do so, it 271 MUST set the CHAIN option to the lowest Trust Point sent as part of 272 the chain, with its corresponding OPTION-LENGTH. It extends the 273 Authority Section in the DNS answer packet with the DNS RRsets 274 required for validating the answer. The DNS RRsets added start with 275 the first chain element below the received Closest Trust Point up to 276 and including the NS and DS RRsets that represent the zone cut 277 (authoritative servers) of the QNAME. The added RRsets MAY be added 278 in matching hierarchical order but a DNS client MUST NOT depend on 279 the order of the added RRsets for validation. The actual DNS answer 280 to the question in the Query Section is placed in the DNS Answer 281 Section identical to the traditional DNS answer. All required DNSSEC 282 related records must be added to their appropriate sections. This 283 includes records required for proof of non-existence of regular and/ 284 or wildcard records, such as NSEC or NSEC3 records. 286 Recursive Resolvers that have not implemented or enabled support for 287 the CHAIN option, or are otherwise unwilling to perform the 288 additional work for a Chain Query due to work load, may safely ignore 289 the option in the incoming queries. Such a server MUST NOT include 290 an CHAIN option when sending DNS answer replies back, thus indicating 291 it is not able or willing to support Chain Queries at this time. 293 Requests with wrongly formatted options (i.e. bogus FQDN) MUST be 294 rejected and a FORMERR response must be returned to the sender, as 295 described by [RFC6891]. 297 Requests resulting in chains that the receiving resolver is unwilling 298 to serve can be rejected by answering the query as a regular DNS 299 reply but with an empty CHAIN payload. Replying with an empty CHAIN 300 can be used for chains that would be too big or chains that would 301 reveal too much information considered private. 303 At any time, a Recursive Resolver that has determined that it is 304 running low on resources can refuse CHAIN queries by replying with a 305 regular DNS reply with an empty CHAIN payload. 307 If a CHAIN answer would be bigger than the Recursive Resolver is 308 willing to serve, it SHOULD send a partial chain starting with the 309 data closest to the top of the chain. The client MAY re-send the 310 query with an updated Closest Trust Point until it has received the 311 full chain. The CHAIN response will contain the lowest Closest Trust 312 Point that was included in the CHAIN answer. 314 If the DNS request results in an CNAME or DNAME for the Answer 315 Section, the Recursive Resolver MUST return these records in the 316 Answer Section similar to regular DNS processing. The CNAME or DNAME 317 target MAY be placed in the Additional Section only if all supporting 318 records for DNSSEC validation of the CNAME or DNAME target are also 319 added to the Authority Section. 321 The response from a Recursive Resolver to a Resolver MUST NOT contain 322 the CHAIN option if none was present in the Resolver's original 323 request. 325 A DNS query that contains the CHAIN option MUST also have the DNSSEC 326 OK ("OK") bit set. If this bit is not set, or if the Checking 327 Disabled ("CD") bit is set, the CHAIN option received MUST be 328 ignored. 330 6. Protocol Considerations 332 6.1. DNSSEC Considerations 333 The presence or absence of an OPT resource record containing an CHAIN 334 option in a DNS query does not change the usage of those resource 335 records and mechanisms used to provide data origin authentication and 336 data integrity to the DNS, as described in [RFC4033], [RFC4034] and 337 [RFC4035]. 339 6.2. NS record Considerations 341 CHAIN responses SHOULD include the NS RRset from the zone itself 342 including the RRSIG records required for validation. It MUST NOT 343 include the NS RRset from parent zone, as this RRset is not signed. 344 If the size of the answer is an important factor, the NS RRset MAY be 345 omited. 347 When a DNSSEC chain is supplied via CHAIN, the Forwarder is no longer 348 required to use the NS RRset, as it can construct the validation path 349 via the DNSKEY and DS RRsets without using the NS RRset. However, 350 the Forwarder might be forced to switch from Forwarder mode to 351 Recursive Resolver mode due to a network topology change. In 352 Recursive Resolver mode, the NS RRsets are needed to find and query 353 Authoritative Servers directly. It is RECOMMENDED that the DNS 354 Forwarder populate its cache with this information to avoid requiring 355 future queries to obtain any missing NS records. Therefore, CHAIN 356 responses MUST include the NS RRset from the child zone, including 357 the RRSIG records required for validation. 359 6.3. Session Management 361 The use of [TCP-KEEPALIVE] on DNS TCP sessions is RECOMMENDED, and 362 thus TCP sessions should not immediately be closed after the DNS 363 answer to the first query is received. 365 Both DNS clients and servers are subject to resource constraints 366 which will limit the extent to which Chain Queries can be executed. 367 Effective limits for the number of active sessions that can be 368 maintained on individual clients and servers should be established, 369 either as configuration options or by interrogation of process limits 370 imposed by the operating system. 372 In the event that there is greater demand for Chain Queries than can 373 be accommodated, DNS servers may stop advertising the CHAIN option in 374 successive DNS messages. This allows, for example, clients with 375 other candidate servers to query to establish new sessions with 376 different servers in expectation that those servers might still allow 377 Chain Queries. 379 6.4. Negative Trust Anchors 380 If a CHAIN answer would intersect with a Negative Trust Anchor 381 [RFC7646], a partial CHAIN up to the node above the Negative Trust 382 Anchor should be returned. 384 6.5. 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 Since DNS queries using CHAIN may result in longer TCP sessions, 398 network topology changes may disrupt them more frequently. Anycast 399 servers MAY make use of TCP multipath [RFC6824] to anchor the server 400 side of the TCP connection to an unambiguously-unicast address in 401 order to avoid disruption due to topology changes. 403 7. Implementation Status 405 [RFC Editor Note: Please remove this entire seciton prior to 406 publication as an RFC.] 408 This section records the status of known implementations of the 409 protocol defined by this specification at the time of posting of this 410 Internet-Draft, and is based on a proposal described in [RFC6982]. 411 The description of implementations in this section is intended to 412 assist the IETF in its decision processes in progressing drafts to 413 RFCs. Please note that the listing of any individual implementation 414 here does not imply endorsement by the IETF. Furthermore, no effort 415 has been spent to verify the information presented here that was 416 supplied by IETF contributors. This is not intended as, and must not 417 be construed to be, a catalog of available implementations or their 418 features. Readers are advised to note that other implementations may 419 exist. 421 According to [RFC6982], "this will allow reviewers and working groups 422 to assign due consideration to documents that have the benefit of 423 running code, which may serve as evidence of valuable experimentation 424 and feedback that have made the implemented protocols more mature. 425 It is up to the individual working groups to use this information as 426 they see fit". 428 [While there is some interest, no work has started yet] 430 8. Security Considerations 432 8.1. Additional work and bandwidth 434 Producing CHAIN answers incurs additional load and bandwidth on the 435 Recursive Resolver. At any time, a Recursive Resolver may decide to 436 no longer answer with CHAIN answers and fall back to traditional DNS 437 answers. 439 8.2. Amplification Attacks 441 Chain Queries can potentially send very large DNS answers. Attackers 442 could abuse this using spoofed source IP addresses to inflict large 443 Distributed Denial of Service attacks using query-chains as an 444 amplification vector in their attack. While TCP is not vulnerable 445 for this type of abuse, the UDP protocol is vulnerable to this. 447 A Recursive Resolver MUST NOT return CHAIN answers to clients over 448 UDP without source IP address verification. An example of UDP based 449 source IP address verification is [EDNS-COOKIE]. A Recursive 450 Resolver refusing a CHAIN option MUST respond with a zero-length 451 CHAIN option to indicate support for CHAIN queries when a proper 452 transport is used. It MUST NOT send an RCODE of REFUSED. 454 8.3. Privacy Considerations 456 A client producing CHAIN queries reveals a little more information 457 about its cache contents than regular DNS clients. This could be 458 used the fingerprint a client across network reconnections. If DNS 459 privacy is a concern, a CHAIN query client MAY try to use a DNS 460 transport that provides privacy, such as [DNS-over-TLS] or a trusted 461 DNS server that is contacted through a VPN connection such as IPsec. 463 9. Examples 465 9.1. Simple Query for example.com 467 o A web browser on a client machine asks the Forwarder running on 468 localhost to resolve the A record of "www.example.com." by sending 469 a regular DNS UDP query on port 53 to 127.0.0.1. 471 o The Resolver on the client machine checks its cache, and notices 472 it already has a DNSSEC validated entry of "com." in its cache. 473 This includes the DNSKEY RRset with its RRSIG records. In other 474 words, according to its cache, ".com" is DNSSEC validated as 475 "secure" and can be used to continue a DNSSEC validated chain. 477 o The Resolver on the client opens a TCP connection to its upstream 478 Recursive Resolver on port 53. It adds the CHAIN option as 479 follows: 481 * Option-code, set to 13 483 * Option-length, set to 5 485 * Closest Trust Point set to "com." (0x03 0x63 0x6f 0x6d 0x00) 487 o The upstream Recursive Resolver receives a DNS query over TCP with 488 the CHAIN Closest Trust Point set to "com.". After accepting the 489 query it starts constructing a DNS reply packet. 491 o The upstream Recursive Resolver performs all the regular work to 492 ensure it has all the answers to the query for the A record of 493 "www.example.com.". It does so without using the CHAIN option - 494 unless it is also configured as a Forwarder. The answer to the 495 original DNS question could be the actual A record, the DNSSEC 496 proof of non-existence, or an insecure NXDOMAIN response. 498 o The upstream Recursive Resolver adds the CHAIN option to the DNS 499 response as follows: 501 * Option-code, set to 13 503 * Option-length, set to 5 505 * The Closest Trust Point is set to "com." (0x03 0x63 0x6f 0x6d 506 0x00) 508 o The upstream Recursive Resolver constructs the DNS Authority 509 Section and fills it (in any order) with: 511 * The DS RRset for "example.com." and its corresponding RRSIGs 512 (made by the "com." DNSKEY(s)) 514 * The DNSKEY RRset for "example.com." and its corresponding 515 RRSIGs (made by the "example.com" DNSKEY(s)) 517 * The authoritative NS RRset for "example.com." and its 518 corresponding RRSIGs (from the child zone) 520 If the answer does not exist, and the zone uses DNSSEC, it also 521 adds the proof of non-existence, such as NSEC or NSEC3 records, to 522 the Authority Section. 524 o The upstream Recursive Resolver constructs the DNS Answer 525 Section and fills it with: 527 * The A record of "www.example.com." and its corresponding RRSIGs 529 If the answer does not exist (NODATA or NXDOMAIN), the Answer 530 Section remains empty. For the NXDOMAIN case, the RCode of the 531 DNS answer packet is set to NXDOMAIN. Otherwise it remains 532 NOERROR. 534 o The upstream Recursive Resolver returns the DNS answer over the 535 existing TCP connection. When all data is sent, it SHOULD keep 536 the TCP connection open to allow for additional incoming DNS 537 queries - provided it has enough resources to do so. 539 o The Resolver on the client receives the DNS answer. It processes 540 the Authority Section and the Answer Section and places the 541 information in its local cache. It ensures that no data is 542 accepted into the cache without having proper DNSSEC validation. 543 It MAY do so by looping over the entries in the Authority and 544 Answer Sections. When an entry is validated for its cache, it is 545 removed from the processing list. If an entry cannot be validated 546 it is left in the process list. When the end of the list is 547 reached, the list is processed again until either all entries are 548 placed in the cache, or the remaining items cannot be placed in 549 the cache due to lack of validation. Those entries are then 550 discarded. 552 o If the cache contains a valid answer to the application's query, 553 this answer is returned to the application via a regular DNS 554 answer packet. This packet MUST NOT contain an CHAIN option. If 555 no valid answer can be returned, normal error processing is done. 556 For example, an NXDOMAIN or an empty Answer Section could be 557 returned depending on the error condition. 559 9.2. Out-of-path Query for example.com 561 A Recursive Resolver receives a query for the A record for 562 example.com. It includes the CHAIN option with the following 563 parameters: 565 o Option-code, set to 13 567 o Option-length, set to 14 569 o The Closest Trust Point set to 'unrelated.ca.' (0x09 0x75 0x6e 570 0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00) 572 As there is no chain that leads from "unrelated.ca." to 573 "example.com", the Resolving Nameserver answers with an empty CHAIN 574 specified using: 576 o Option-code, set to 13 578 o Option-length, set to 0x00 0x00 580 o The Closest Trust Point is omitted (zero length) 582 Note that the regular answer is still present just as it would be for 583 a query that did not specify the CHAIN option. 585 9.3. Non-existent data 587 A Recursive Resolver receives a query for the A record for 588 "ipv6.toronto.redhat.ca". It includes the CHAIN option with the 589 following parameters: 591 o Option-code, set to 13 593 o Option-length, set to 0x00 0x03 595 o The Closest Trust Point set to 'ca.' 597 Using regular UDP queries towards Authoritative Nameservers, it 598 locates the NS RRset for "toronto.redhat.ca.". When querying for the 599 A record it receives a reply with RCODE "NoError" and an empty Answer 600 Section. The Authority Section contains NSEC3 and RRSIG records 601 proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca". 603 The Recursive Resolver constructs a DNS reply with the following 604 CHAIN option parameters: 606 o Option-code, set to 13 608 o Option-length, set to 0x00 0x00 610 o The Closest Trust Point is ommited (zero length) 612 The RCODE is set to "NoError". The Authority Section is filled in 613 with: 615 o The DS RRset for "redhat.ca." plus RRSIGs 617 o The DNSKEY RRset for "redhat.ca." plus RRSIGs 619 o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca) 620 o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs 622 o The DS RRset for "toronto.redhat.ca." plus RRSIGs 624 o The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg 625 ns[01].toronto.redhat.ca) 627 o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs 629 o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and 630 "ns1.toronto.redhat.ca." plus RRSIGs 632 o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs 633 do exist, does not include A) 635 o The NSEC record for "toronto.redhat.ca." (proves no wildcard 636 exists) 638 The Answer Section is empty. The RCode is set to NOERROR. 640 10. IANA Considerations 642 10.1. EDNS0 option code for CHAIN 644 IANA has assigned option code 13 in the "DNS EDNS0 Option Codes 645 (OPT)" registry to CHAIN. 647 11. Acknowledgements 649 Andrew Sullivan pointed out that we do not need any new data formats 650 to support DNS chains. Olafur Gudmundsson ensured the RRsets are 651 returned in the proper Sections. Thanks to Tim Wicinski for his 652 thorough review. 654 12. Normative References 656 [DNS-over-TLS] 657 Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 658 and P. Hoffman, "DNS over TLS: Initiation and Performance 659 Considerations", draft-ietf-dprive-dns-over-tls-05 (work 660 in progress), January 2016. 662 [EDNS-COOKIE] 663 Eastlake, Donald., "Domain Name System (DNS) Cookies", 664 draft-ietf-dnsop-cookies (work in progress), January 2016. 666 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 667 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 668 . 670 [RFC1035] Mockapetris, P., "Domain names - implementation and 671 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 672 November 1987, . 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 676 RFC2119, March 1997, 677 . 679 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 680 Rose, "DNS Security Introduction and Requirements", RFC 681 4033, DOI 10.17487/RFC4033, March 2005, 682 . 684 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 685 Rose, "Resource Records for the DNS Security Extensions", 686 RFC 4034, DOI 10.17487/RFC4034, March 2005, 687 . 689 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 690 Rose, "Protocol Modifications for the DNS Security 691 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 692 . 694 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 695 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 696 December 2006, . 698 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 699 "TCP Extensions for Multipath Operation with Multiple 700 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 701 . 703 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 704 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 705 RFC6891, April 2013, 706 . 708 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 709 Code: The Implementation Status Section", RFC 6982, DOI 710 10.17487/RFC6982, July 2013, 711 . 713 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J., 714 and R. Weber, "Definition and Use of DNSSEC Negative Trust 715 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015, 716 . 718 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 719 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 720 2015, . 722 [TCP-KEEPALIVE] 723 Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The 724 edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns- 725 tcp-keepalive-05 (work in progress), January 2016. 727 Author's Address 729 Paul Wouters 730 Red Hat 732 Email: pwouters@redhat.com