idnits 2.17.1 draft-ietf-dnsop-edns-chain-query-01.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 27, 2014) is 3467 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 616, but not defined -- Looks like a reference, but probably isn't: '1' on line 220 -- Looks like a reference, but probably isn't: '01' on line 598 ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) -- No information found for draft-ietf-dnsop-edns-tcp-keeaplive - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'TCP-KEEPALIVE' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 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 27, 2014 5 Expires: April 30, 2015 7 Chain Query requests in DNS 8 draft-ietf-dnsop-edns-chain-query-01 10 Abstract 12 This document defines an EDNS0 extension that can be used by a DNSSEC 13 enabled Recursive Nameserver configured as a forwarder to send a 14 single DNS query requesting to receive a complete validation path 15 along with the regular DNS answer, without the need to rapid-fire 16 many UDP requests in an attempt to attain a low latency. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 30, 2015. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 58 5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5 59 5.2. Generating a Query . . . . . . . . . . . . . . . . . . . 5 60 5.3. Generating a Response . . . . . . . . . . . . . . . . . . 6 61 5.4. Sending the Option . . . . . . . . . . . . . . . . . . . 7 62 6. Protocol Considerations . . . . . . . . . . . . . . . . . . 7 63 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7 64 6.2. NS record Considerations . . . . . . . . . . . . . . . . 7 65 6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8 66 6.4. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 8 67 6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 8 68 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 9 71 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 9.1. Simple Query for example.com . . . . . . . . . . . . . . 10 73 9.2. Out-of-path query for example.com . . . . . . . . . . . . 12 74 9.3. non-existent data . . . . . . . . . . . . . . . . . . . . 12 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 10.1. EDNS0 option code for edns-chain-query . . . . . . . . . 13 77 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 Traditionally, clients operate in stub-mode for DNS. For each DNS 84 question the client needs to resolve, it sends a single query to an 85 upstream DNS resolver to obtain a single DNS answer. When DNSSEC 86 [RFC4033] is deployed on such clients, validation requires that the 87 client obtains all the (intermediate) information from the DNS root 88 down to the queried-for hostname so it can perform DNSSEC validation 89 on the complete chain of trust. This process increases the number of 90 DNS queries and answers required, and thus increases the latency 91 before a validated DNS answer has been obtained. 93 Currently, applications use a rapid-fire approach to send out many 94 UDP requests concurrently. This requires more resources on the DNS 95 client with respect to state (cpu, memory, battery) and bandwidth. 96 There is also no guarantee that the initial burst of UDP questions 97 will result in all the records required for DNSSEC validation, and 98 more round trips could be required depending on the resulting DNS 99 answers. This especially affects high-latency links. 101 This document specifies an EDNS0 extension that allows a validating 102 recursive name server running as a forwarder to request another 103 recursive name server for a DNS chain answer using one DNS query/ 104 answer pair. This reduces the number of round-trip times ("RTT") to 105 two. If combined with [TCP-KEEPALIVE] there is only 1 RTT. While 106 the upstream DNS resolver still needs to perform all the individual 107 queries required for the complete answer, it usually has a much 108 bigger cache and does not experience significant slowdown from last- 109 mile latency. 111 This EDNS0 extension allows the Forwarder to indicate which part of 112 the DNS hierarchy it already contains in its cache. This reduces the 113 amount of data required to be transferred and reduces the work the 114 upstream Resolving Nameserver has to perform. 116 This EDNS0 extension is only intended for Forwarders. It can (and 117 should be) ignored by Authoritative Nameservers and by Recursive 118 Nameservers that do not support this EDNS0 option. 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 Stub Resolver: A simple DNS protocol implementation on the client 129 side as described in [RFC1034] section 5.3.1. 131 Authoritative Nameserver: A nameserver that has authority over one 132 or more DNS zones. These are normally not contacted by clients 133 directly but by Recursive Resolvers. Described in [RFC1035] 134 chapter 6. 136 Recursive Resolver: A nameserver that is responsible for resolving 137 domain names for clients by following the domain's delegation 138 chain, starting at the root. Recursive Resolvers frequently use 139 caches to be able to respond to client queries quickly. Described 140 in [RFC1035] chapter 7. 142 Validating Resolver: A recursive nameserver that also performs 143 DNSSEC [RFC4033] validation. 145 Forwarder: A Recursive Resolver that is using another (upstream) 146 Recursive Resolver instead of querying Authoritative Nameservers 147 directly. It still performs validation. 149 3. Overview 151 When DNSSEC is deployed on the client, it can no longer delegate all 152 DNS work to the upstream Resolving Nameserer. Obtaining just the DNS 153 answer itself is not enough to validate that answer using DNSSEC. 154 For DNSSEC validation, the client requires a locally running 155 validating DNS server configured as Resolving Nameserver so it can 156 confirm DNSSEC validation of all intermediary DNS answers. It can 157 configure itself as a Forwarder if the DHCP server has indicated that 158 one or more Resolving Nameservers are available. Regardless, 159 generating the required queries for validation adds a significant 160 delay in answering the DNS question of the locally running 161 application. The application has to wait while the Forwarder on the 162 client is querying for all the intermediate work. Each round-trip 163 adds to the total time waiting on DNS resolving to complete. This 164 makes DNSSEC resolving impractical on networks with a high latency. 166 The edns-chain-query option allows the client to request all 167 intermediate DNS data it requires to resolve and validate a 168 particular DNS answer in a single round-trip DNS query and answer. 170 Servers answering with chain query data exceeding 512 bytes should 171 ensure that the transport is TCP or source IP address verified UDP. 172 See Section 8. This avoids abuse in DNS amplification attacks. 174 The format of this option is described in Section 4. 176 As described in Section 5.3, a recursive nameserver could use this 177 EDNS0 option to include additional data required by the client in the 178 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 ([RFC2671]) 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 (Defined in [RFC2671]) OPTION-CODE, 2 octets, for edns-chain-query 208 is [TBD]. 210 o (Defined in [RFC2671]) OPTION-LENGTH, 2 octets, contains the 211 length of the payload (everything after Option-length) in octets. 213 o Last Known Query Name, a variable length FDQN of the requested 214 start point of the chain. This entry is the 'lowest' known entry 215 in the DNS chain known by the recursive server seeking a edns- 216 chain-query answer. The end point of the chain is obtained from 217 the DNS Query Section itself. No compression is allowed for this 218 value. 220 o Assigned by IANA in IANA-AFI [1]. 222 5. Protocol Description 224 5.1. Discovery of Support 226 A Forwarder may include a zero-length edns-chain-query option in 227 queries over UDP or TCP to discover the DNS server capability for 228 edns-chain-query. DNS Servers that support and are willing to accept 229 chain queries over TCP SHOULD respond to a zero-length edns-chain- 230 query received over UDP or TCP queries by including a zero-length 231 edns-chain-query option in the answer. A Forwarder MAY then switch 232 to the TCP transport and sent a non-zero edns-chain-query value to 233 request a chain-query response from the DNS server. 235 5.2. Generating a Query 237 The edns-chain-query option should generally be deployed by 238 Forwarders, as described in Section 5.4. 240 In this option value, the Forwarder sets the last known entry point 241 in the chain - furthest from the root - that it already has a DNSSEC 242 validated (secure or not) answer for in its cache. The upstream 243 Recursive Resolver does not need to include any part of the chain 244 from the root down to this option's FQDN. A complete example is 245 described in Section 9. 247 Depending on the size of the labels of the last known entry point 248 value, a DNS Query packet could be arbitrarily large. If using the 249 last known entry point would result in a query size of more then 512 250 bytes, the last known entry point should be replaced with its parent 251 entry until the query size would be 512 bytes or less. 253 5.3. Generating a Response 255 When a query containing a non-zero edns-chain-query option is 256 received over a TCP connection from a Forwarder, the upstream 257 Recursive Resolver supporting edns-chain-query MAY respond by 258 confirming that it is returning a DNS Query Chain. To do so, it MUST 259 set the edns-chain-query option with an OPTION-LENGTH of zero to 260 indicate the DNS answer contains a Chain Query. It extends the 261 Authority Section for the DNS answer packet with the required DNS 262 RRSets resulting in an Authority Section that contains a complete 263 chain of DNS RRsets that start with the first chain element below the 264 received Last Known Query Name upto and including the NS and DS 265 RRsets that represent the zone cut (authoritative servers) of the 266 QNAME. The actual DNS answer to the question in the Query Section is 267 placed in the DNS Answer Section identical to traditional DNS 268 answers. If the received query has the DNSSEC OK flag set, all 269 required DNSSEC related records must be added to their appropriate 270 sections. This includes records required for proof of non-existence 271 of regular and/or wildcard records, such as NSEC or NSEC3 records. 273 Recursive Resolvers that have not implemented or enabled support for 274 the edns-chain-query option, or are otherwise unwilling to perform 275 the additional work for a Chain Query due to work load, may safely 276 ignore the option in the incoming queries. Such a server MUST NOT 277 include an edns-chain-query option when sending DNS answer replies 278 back, thus indicating it is not able to support Chain Queries at this 279 time. 281 Requests with wrongly formatted options (i.e. bogus FQDN) MUST be 282 rejected and a FORMERR response must be returned to the sender, as 283 described by [RFC2671], Transport Considerations. 285 Requests resulting in chains that the receiving resolver is unwilling 286 to serve can be rejected by sending a REFUSED response to the sender, 287 as described by [RFC2671], Transport Considerations. This refusal 288 can be used for chains that would be too big or chains that would 289 reveal too much information considered private. 291 At any time, a DNS server that has determined that it is running low 292 on resources can refuse to acknowledge a Chain Query by omitting the 293 edns-chain-query option. It may do so even if it conveyed support to 294 a DNS client previously. If [TCP-KEEPALIVE] is used, it may even 295 change its support for edns-chain-query within the same TCP session. 297 If the DNS request results in an CNAME or DNAME for the Answer 298 Section, the DNS server MUST return these records in the Answer 299 Section similar to regular DNS processing. The CNAME or DNAME target 300 MAY be placed in the Additional Section only if all supporting 301 records for DNSSEC validation of the CNAME or DNAME target is also 302 added to the Authority Section. 304 In any case, the response from the receiving resolver to the client 305 resolver MUST NOT contain the edns-chain-query option if none was 306 present in the client's resolver original request. 308 5.4. Sending the Option 310 When edns-chain-query is available, the downstream Resolving 311 Nameserver can adjust its query strategy based on the desired queries 312 and its cache contents. 314 A Forwarder can request the edns-chain-query option with every 315 outgoing DNS query. However, it is RECOMMENDED that Forwarders 316 remember which upstream Resolving Nameservers did not return the 317 option (and additional data) with their response. The Forwarder 318 SHOULD fallback to regular DNS for subsequent queries to those 319 Recursive Nameservers. It MAY switch to another Resolving Nameserver 320 that does support the edns-chain-query option or try again later to 321 see if the server has become less loaded and is now willing to answer 322 with Query Chains. 324 6. Protocol Considerations 326 6.1. DNSSEC Considerations 328 The presence or absence of an OPT resource record containing an edns- 329 chain-query option in a DNS query does not change the usage of those 330 resource records and mechanisms used to provide data origin 331 authentication and data integrity to the DNS, as described in 332 [RFC4033], [RFC4034] and [RFC4035]. 334 6.2. NS record Considerations 335 edns-chain-query responses MUST include the NS RRset from the child 336 zone, which includes DNSSEC RRSIG records required for validation. 338 When a DNSSEC chain is supplied via edns-chain-query, the Forwarder 339 no longer requires to use the NS RRset, as it can construct the 340 validation path via the DNSKEY and DS RRsets without using the NS 341 RRset. However, it is prefered that the Forwarder can populate its 342 cache with this information regardless, to avoid requiring queries in 343 the future just to obtain the missing NS records. This can happen on 344 a roaming device that needs to swich from using a DHCP obtained DNS 345 server as forwarder to running in full autonomous resolver mode, for 346 example when the DHCP obtained DNS server is broken in some way. 348 6.3. TCP Session Management 350 It is recommended that TCP Chain Queries are used in combination with 351 [TCP-KEEPALIVE]. 353 Both DNS clients and servers are subject to resource constraints 354 which will limit the extent to which TCP Chain Queries can be 355 executed. Effective limits for the number of active sessions that 356 can be maintained on individual clients and servers should be 357 established, either as configuration options or by interrogation of 358 process limits imposed by the operating system. 360 In the event that there is greater demand for TCP Chain Queries than 361 can be accommodated, DNS servers may stop advertising the edns-query- 362 chain option in successive DNS messages. This allows, for example, 363 clients with other candidate servers to query to establish new TCP 364 sessions with different servers in expectation that those servers 365 might still allow TCP Chain Queries. 367 6.4. Non-Clean Paths 369 Many paths between DNS clients and servers suffer from poor hygiene, 370 limiting the free flow of DNS messages that include particular EDNS0 371 options, or messages that exceed a particular size. A fallback 372 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 373 be employed to avoid persistent interference due to non-clean paths. 375 6.5. Anycast Considerations 377 DNS servers of various types are commonly deployed using anycast 378 [RFC4786]. 380 Successive DNS transactions between a client and server using UDP 381 transport may involve responses generated by different anycast nodes, 382 and the use of anycast in the implementation of a DNS server is 383 effectively undetectable by the client. The edns-chain-query option 384 SHOULD NOT be included in responses using UDP transport from servers 385 provisioned using anycast unless all anycast server nodes are capable 386 of processing the edns-query-chain option. 388 Changes in network topology between clients and anycast servers may 389 cause disruption to TCP sessions making use of edns-chain-query more 390 often than with TCP sessions that omit it, since the TCP sessions are 391 expected to be longer-lived. Anycast servers MAY make use of TCP 392 multipath [RFC6824] to anchor the server side of the TCP connection 393 to an unambiguously-unicast address in order to avoid disruption due 394 to topology changes. 396 7. Implementation Status 398 This section records the status of known implementations of the 399 protocol defined by this specification at the time of posting of this 400 Internet-Draft, and is based on a proposal described in [RFC6982]. 401 The description of implementations in this section is intended to 402 assist the IETF in its decision processes in progressing drafts to 403 RFCs. Please note that the listing of any individual implementation 404 here does not imply endorsement by the IETF. Furthermore, no effort 405 has been spent to verify the information presented here that was 406 supplied by IETF contributors. This is not intended as, and must not 407 be construed to be, a catalog of available implementations or their 408 features. Readers are advised to note that other implementations may 409 exist. 411 According to [RFC6982], "this will allow reviewers and working groups 412 to assign due consideration to documents that have the benefit of 413 running code, which may serve as evidence of valuable experimentation 414 and feedback that have made the implemented protocols more mature. 415 It is up to the individual working groups to use this information as 416 they see fit". 418 [While there is some interest, no work has started yet] 420 8. Security Considerations 422 8.1. Amplification Attacks 424 Chain Queries can potentially send very large DNS answers. Attackers 425 could abuse this using spoofed source IP addresses to inflict large 426 Distributed Denial of Service attacks using query-chains as an 427 amplification vector in their attack. While TCP is not vulnerable 428 for this type of abuse, the UDP protocol is vulnerable to this. 430 A recursive nameserver MUST NOT return Query Chain answers to clients 431 over UDP without source IP address verification, for instance using 432 [EASTLAKE-COOKIES]. A recursive nameserver SHOULD signal support in 433 response to a Query Chain request over UDP by responding using a 434 zero-length edns-chain-query option over UDO even without source IP 435 address verification. 437 9. Examples 439 9.1. Simple Query for example.com 441 1. A web browser on a client machine asks the Forwarder running on 442 localhost to resolve the A record of "www.example.com." by 443 sending a regular DNS UDP query on port 53 to 127.0.0.1. 445 2. The Forwarder on the client machine checks its cache, and 446 notices it already has a DNSSEC validated entry of "com." in its 447 cache. This includes the DNSKEY RRset with its RRSIG records. 448 In other words, according to its cache, ".com" is DNSSEC 449 validated as "secure" and can be used to continue a DNSSEC 450 validated chain on. 452 3. The Forwarder on the client opens a TCP connection to its 453 upstream Recursive Resolver on port 53. It adds the edns-chain- 454 query option as follows: 456 * Option-code, set to [TBD] 458 * Option-length, set to 0x00 0x04 460 * Last Known Query Name set to "com." 462 4. The upstream Recursive Resolver receives a DNS query over TCP 463 with the edns-chain-query Last Known Query Name set to "com.". 464 After accepting the query it starts constructing a DNS reply 465 packet. 467 5. The upstream Recursive Resolver performs all the regular work to 468 ensure it has all the answers to the query for the A record of 469 "www.example.com.". It does so without using the edns-chain- 470 query option - unless it is also configured as a Forwarder. The 471 answer to the original DNS question could be the actual A 472 record, the DNSSEC proof of non-existence, or an insecure 473 NXDOMAIN response. 475 6. The upstream Recursive Resolver adds the edns-chain-query option 476 to the DNS answer reply as follows: 478 * Option-code, set to [TBD] 480 * Option-length, set to 0x00 0x00 482 * The Last Known Query Name is ommited (zero length) 484 7. The upstream Recursive Resolver constructs the DNS Authority 485 Section and fills it with: 487 * The DS RRset for "example.com." and its corresponding RRSIGs 488 (made by the "com." DNSKEY(s)) 490 * The DNSKEY RRset for "example.com." and its corresponding 491 RRSIGs (made by the "example.com" DNSKEY(s)) 493 * The authoritative NS RRset for "example.com." and its 494 corresponding RRSIGs (from the child zone) 496 If the answer does not exist, and the zone uses DNSSEC, it also 497 adds the proof of non-existance, such as NSEC or NSEC3 records, 498 to the Authority Section. 500 8. The upstream Recursive Resolver constructs the DNS Answer 501 Section and fills it with: 503 * The A record of "www.example.com." and its corresponding 504 RRSIGs 506 If the answer does not exist (no-data or NXDOMAIN), the Answer 507 Section remains empty. For the NXDOMAIN case, the RCode of the 508 DNS answer packet is set to NXDOMAIN. Otherwise it remains 509 NOERROR. 511 9. The upstream Recursive Resolver returns the DNS answer over the 512 existing TCP connection. When all data is sent, it SHOULD keep 513 the TCP connection open to allow for additional incoming DNS 514 queries - provided it has enough resources to do so. 516 10. The Forwarder receives the DNS answer. It processes the 517 Authority Section and the Answer Section and places the 518 information in its local cache. It ensures that no data is 519 accepted into the cache without having proper DNSSEC validation. 520 It MAY do so by looping over the entries in the Authority and 521 Answer Sections. When an entry is validated for its cache, it 522 is removed from the processing list. If an entry cannot be 523 validated it is left in the process list. When the end of the 524 list is reached, the list is processed again until either all 525 entries are placed in the cache, or the remaining items cannot 526 be placed in the cache due to lack of validation. Those entries 527 are then disgarded. 529 11. If the cache contains a valid answer to the application's query, 530 this answer is returned to the application via a regular DNS 531 answer packet. This packet MUST NOT contain an edns-chain-query 532 option. If no valid answer can be returned, normal error 533 processing is done. For example, an NXDOMAIN or an empty Answer 534 Section could be returned depending on the error condition. 536 9.2. Out-of-path query for example.com 538 A Recursive Resolver receives a query for the A record for 539 example.com. It includes the edns-chain-query option with the 540 following parameters: 542 o Option-code, set to [TBD] 544 o Option-length, set to 0x00 0x0D 546 o The Last Known Query Name set to 'unrelated.ca.' 548 As there is no chain that leads from "unrelated.ca." to 549 "example.com", the Resolving Nameserver answers with RCODE "FormErr". 550 It includes the edns-chain-query with the following parameters: 552 o Option-code, set to [TBD] 554 o Option-length, set to 0x00 0x00 556 o The Last Known Query Name is ommited (zero length) 558 9.3. non-existent data 560 A Recursive Resolver receives a query for the A record for 561 "ipv6.toronto.redhat.ca". It includes the edns-chain-query option 562 with the following parameters: 564 o Option-code, set to [TBD] 566 o Option-length, set to 0x00 0x03 568 o The Last Known Query Name set to 'ca.' 569 Using regular UDP queries towards Authoritative Nameservers, it 570 locates the NS RRset for "toronto.redhat.ca.". When querying for the 571 A record it receives a reply with RCODE "NoError" and an empty Answer 572 Section. The Authority Section contains NSEC3 and RRSIG records 573 proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca". 575 The Recursive Resolver constructs a DNS reply with the following 576 edns-chain-query option parameters: 578 o Option-code, set to [TBD] 580 o Option-length, set to 0x00 0x00 582 o The Last Known Query Name is ommited (zero length) 584 The RCODE is set to "NoError". The Authority Section is filled in 585 with: 587 o The DS RRset for "redhat.ca." plus RRSIGs 589 o The DNSKEY RRset for "redhat.ca." plus RRSIGs 591 o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca) 593 o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs 595 o The DS RRset for "toronto.redhat.ca." plus RRSIGs 597 o The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg 598 ns[01].toronto.redhat.ca) 600 o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs 602 o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and 603 "ns1.toronto.redhat.ca." plus RRSIGs 605 o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs 606 do exist, does not include A) 608 o The NSEC record for "toronto.redhat.ca." (proves no wildcard 609 exists) 611 The Answer Section is empty. The RCode is set to NOERROR. 613 10. IANA Considerations 615 10.1. EDNS0 option code for edns-chain-query 616 IANA has assigned option code [TBD] in the "DNS EDNS0 Option Codes 617 (OPT)" registry to edns-chain-query. 619 11. Acknowledgements 621 Andrew Sullivan pointed out that we do not need any new data formats 622 to support DNS chains. Olafur Gudmundsson ensured the RRsets are 623 returned in the proper Sections. 625 12. Normative References 627 [EASTLAKE-COOKIES] 628 Eastlake, Donald., "Domain Name System (DNS) Cookies", 629 draft-eastlake-dnsext-cookies (work in progress), October 630 2014. 632 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 633 STD 13, RFC 1034, November 1987. 635 [RFC1035] Mockapetris, P., "Domain names - implementation and 636 specification", STD 13, RFC 1035, November 1987. 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, March 1997. 641 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 642 2671, August 1999. 644 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 645 Rose, "DNS Security Introduction and Requirements", RFC 646 4033, March 2005. 648 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 649 Rose, "Resource Records for the DNS Security Extensions", 650 RFC 4034, March 2005. 652 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 653 Rose, "Protocol Modifications for the DNS Security 654 Extensions", RFC 4035, March 2005. 656 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 657 Services", BCP 126, RFC 4786, December 2006. 659 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 660 "TCP Extensions for Multipath Operation with Multiple 661 Addresses", RFC 6824, January 2013. 663 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 664 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 666 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 667 Code: The Implementation Status Section", RFC 6982, July 668 2013. 670 [TCP-KEEPALIVE] 671 Wouters, P., "The edns-tcp-keepalive EDNS0 Option", draft- 672 ietf-dnsop-edns-tcp-keeaplive (work in progress), October 673 2014. 675 Author's Address 677 Paul Wouters 678 Red Hat 680 Email: pwouters@redhat.com