idnits 2.17.1 draft-wouters-edns-tcp-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 15, 2013) is 3843 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 600, but not defined -- Looks like a reference, but probably isn't: '1' on line 214 -- Looks like a reference, but probably isn't: '01' on line 581 ** 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-wouters-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 dnsext P. Wouters 3 Internet-Draft Red Hat 4 Intended status: Standards Track October 15, 2013 5 Expires: April 18, 2014 7 TCP chain query requests in DNS 8 draft-wouters-edns-tcp-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 query over TCP requesting to receive a complete validation 15 path along with the regular query answer. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on April 18, 2014. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5 58 5.2. Generating a Query . . . . . . . . . . . . . . . . . . . 5 59 5.3. Generating a Response . . . . . . . . . . . . . . . . . . 6 60 5.4. Sending the Option . . . . . . . . . . . . . . . . . . . 7 61 6. Protocol Considerations . . . . . . . . . . . . . . . . . . 7 62 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7 63 6.2. NS record Considerations . . . . . . . . . . . . . . . . 7 64 6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8 65 6.4. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 8 66 6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 8 67 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 9 70 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9.1. Simple Query for example.com . . . . . . . . . . . . . . 10 72 9.2. Out-of-path query for example.com . . . . . . . . . . . . 12 73 9.3. non-existent data . . . . . . . . . . . . . . . . . . . . 12 74 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 10.1. EDNS0 option code for edns-tcp-chain-query . . . . . . . 13 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 77 12. Normative References . . . . . . . . . . . . . . . . . . . . 14 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Traditionally, clients operate in stub-mode for DNS. For each DNS 83 question the client needs to resolve, it sends a single query to an 84 upstream DNS resolver to obtain a single DNS answer. When DNSSEC 85 [RFC4033] is deployed on such clients, validation requires that the 86 client obtains all the (intermediate) information from the DNS root 87 down to the queried-for hostname so it can perform DNSSEC validation 88 on the complete chain of trust. 90 For example, the validated answer for the question of the A record 91 for the zone "example.com" requires over a hundred DNS queries. That 92 many queries adds a significant number of round-trip delays that is 93 considered unusable by current user expectation. It especially 94 affects web browsers which usually need to lookup dozens of hostnames 95 to render a single web page. 97 This document specifies an EDNS0 extension that allows a validating 98 recursive name server running as a forwarder to open a TCP connection 99 to another recursive name server and request a DNS chain answer using 100 one DNS query/answer pair. This reduces the number of round-trip 101 times ("RTT") to two. If combined with [TCP-KEEPALIVE] there is only 102 1 RTT. While the upstream DNS resolver still needs to perform all 103 these queries, it usually has a much bigger cache and does not 104 experience significant slowdown from last-mile latency. 106 This EDNS0 extension allows the Forwarder to indicate which part of 107 the DNS hierarchy it already contains in its cache. This reduces the 108 amount of data required to be transferred and reduces the work the 109 upstream Resolving Nameserver has to perform. 111 This EDNS0 extension is only intended for Forwarders. It can (and 112 should be) ignored by Authoritative Nameservers and by Recursive 113 Nameservers that do not support this EDNS0 option. 115 1.1. Requirements Notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 2. Terminology 123 Stub Resolver: A simple DNS protocol implementation on the client 124 side as described in [RFC1034] section 5.3.1. 126 Authoritative Nameserver: A nameserver that has authority over one 127 or more DNS zones. These are normally not contacted by clients 128 directly but by Recursive Resolvers. Described in [RFC1035] 129 chapter 6. 131 Recursive Resolver: A nameserver that is responsible for resolving 132 domain names for clients by following the domain's delegation 133 chain, starting at the root. Recursive Resolvers frequently use 134 caches to be able to respond to client queries quickly. Described 135 in [RFC1035] chapter 7. 137 Validating Resolver: A recursive nameserver that also performs 138 DNSSEC [RFC4033] validation. 140 Forwarder: A Recursive Resolver that is using another (upstream) 141 Recursive Resolver instead of querying Authoritative Nameservers 142 directly. It still performs validation. 144 3. Overview 146 When DNSSEC is deployed on the client, it can no longer delegate all 147 DNS work to the upstream Resolving Nameserer. Obtaining just the DNS 148 answer itself is not enough to validate that answer using DNSSEC. 149 For DNSSEC validation, the client requires a locally running 150 validating DNS server configured as Resolving Nameserver so it can 151 confirm DNSSEC validation of all intermediary DNS answers. It can 152 configure itself as a Forwarder if the DHCP server has indicated that 153 one or more Resolving Nameservers are available. Regardless, 154 generating the required queries for validation adds a significant 155 delay in answering the DNS question of the locally running 156 applications. The application has to wait while the Forwarder on the 157 client is querying for all the intermediate work. Each round-trip 158 adds to the total time waiting on DNS resolving to complete. This 159 makes DNSSEC resolving impractical on networks with a high latency. 161 The edns-tcp-chain-query option allows the client to request all 162 intermediate DNS data it requires to resolve and validate a 163 particular DNS answer in a single round-trip DNS query and answer. 165 Since this data is most likely larger than the common maximum UDP 166 packet size, the server must only return the additional data when 167 using the TCP transport. Requiring TCP furthermore avoid DNS 168 amplification attacks. 170 The format of this option is described in Section 4. 172 As described in Section 5.3, a recursive nameserver could use this 173 EDNS0 option to include additional data required by the client in the 174 Authority Section of the DNS answer packet when using the TCP 175 transport. The Answer Section remains unchanged from a traditional 176 DNS answer and contains the answer and related DNSSEC entries. 178 The edns-tcp-chain-query EDNS0 option MAY be sent over UDP as a 179 discovery method. A DNS server receiving edns-tcp-chain-query over 180 UDP MAY add an empty edns-tcp-chain-query option in its answer to 181 indicate that it supports edns-tcp-chain-query when the TCP transport 182 is used. 184 The mechanisms provided by edns-tcp-chain-query raise various 185 security related concerns, related to the additional work and 186 bandwidth as well as privacy issues with the cache. These concerns 187 are described in Section 8. 189 4. Option Format 190 This draft uses an EDNS0 ([RFC2671]) option to include client IP 191 information in DNS messages. The option is structured as follows: 193 1 2 3 194 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 195 +-------------------------------+-------------------------------+ 196 ! OPTION-CODE ! OPTION-LENGTH ! 197 +-------------------------------+-------------------------------+ 198 ~ Last Known Query Name (FQDN) ~ 199 +---------------------------------------------------------------+ 201 o (Defined in [RFC2671]) OPTION-CODE, 2 octets, for edns-tcp-chain- 202 query is [TBD]. 204 o (Defined in [RFC2671]) OPTION-LENGTH, 2 octets, contains the 205 length of the payload (everything after Option-length) in octets. 207 o Last Known Query Name, a variable length FDQN of the requested 208 start point of the chain. This entry is the 'lowest' known entry 209 in the DNS chain known by the recursive server seeking a edns-tcp- 210 chain-query answer. The end point of the chain is obtained from 211 the DNS Query Section itself. No compression is allowed for this 212 value. 214 o Assigned by IANA in IANA-AFI [1]. 216 5. Protocol Description 218 5.1. Discovery of Support 220 A Forwarder may include a zero-length edns-tcp-chain-query option in 221 queries over UDP or TCP to discover the DNS server capability for 222 edns-tcp-chain-query. DNS Servers that support and are willing to 223 accept chain queries over TCP SHOULD respond to a zero-length edns- 224 tcp-chain-query received over UDP or TCP queries by including a zero- 225 length edns-tcp-chain-query option in the answer. A Forwarder MAY 226 then switch to the TCP transport and sent a non-zero edns-tcp-chain- 227 query value to request a chain-query response from the DNS server. 229 5.2. Generating a Query 231 The edns-tcp-chain-query option should generally be deployed by 232 Forwarders, as described in Section 5.4. 234 In this option value, the Forwarder sets the last known entry point 235 in the chain - furthest from the root - that it already has a DNSSEC 236 validated (secure or not) answer for in its cache. The upstream 237 Recursive Resolver does not need to include any part of the chain 238 from the root down to this option's FQDN. A complete example is 239 described in Section 9. 241 5.3. Generating a Response 243 When a query containing a non-zero edns-tcp-chain-query option is 244 received over a TCP connection from a Forwarder, the upstream 245 Recursive Resolver supporting edns-tcp-chain-query MAY respond by 246 confirming that it is returning a DNS Query Chain. To do so, it MUST 247 set the edns-tcp-chain-query option with an OPTION-LENGTH of zero to 248 indicate the DNS answer contains a Chain Query. It extends the 249 Authority Section for the DNS answer packet with the required DNS 250 RRSets resulting in an Authority Section that contains a complete 251 chain of DNS RRsets that start with the first chain element below the 252 received Last Known Query Name upto and including the NS and DS 253 RRsets that represent the zone cut (authoritative servers) of the 254 QNAME. The actual DNS answer to the question in the Query Section is 255 placed in the DNS Answer Section identical to traditional DNS 256 answers. If the received query has the DNSSEC OK flag set, all 257 required DNSSEC related records must be added to their appropriate 258 sections. This includes records required for proof of non-existence 259 of regular and/or wildcard records, such as NSEC or NSEC3 records. 261 Recursive Resolvers that have not implemented or enabled support for 262 the edns-tcp-chain-query option, or are otherwise unwilling to 263 perform the additional work for a Chain Query due to work load, may 264 safely ignore the option in the incoming queries. Such a server MUST 265 NOT include an edns-tcp-chain-query option when sending DNS answer 266 replies back, thus indicating it is not able to support Chain Queries 267 at this time. 269 Requests with wrongly formatted options (i.e. bogus FQDN) MUST be 270 rejected and a FORMERR response must be returned to the sender, as 271 described by [RFC2671], Transport Considerations. 273 Requests resulting in chains that the receiving resolver is unwilling 274 to serve can be rejected by sending a REFUSED response to the sender, 275 as described by [RFC2671], Transport Considerations. This refusal 276 can be used for chains that would be too big or chains that would 277 reveal too much information considered private. 279 At any time, a DNS server that has determined that it is running low 280 on resources can refuse to acknowledge a Chain Query by omitting the 281 edns-tcp-chain-query option. It may do so even if it conveyed 282 support to a DNS client previously. If [TCP-KEEPALIVE] is used, it 283 may even change its support for edns-tcp-chain-query within the same 284 TCP session. 286 If the DNS request results in an CNAME or DNAME for the Answer 287 Section, the DNS server MUST return these records in the Answer 288 Section similar to regular DNS processing. It MUST NOT follow the 289 CNAME or DNAME. Otherwise, both the CNAME or DNAME and the followed 290 destination would end up in the Answer Section. [is that actually a 291 problem? Jelte thought so, but I am not sure] 293 In any case, the response from the receiving resolver to the client 294 resolver MUST NOT contain the edns-tcp-chain-query option if none was 295 present in the client's resolver original request. 297 5.4. Sending the Option 299 When edns-tcp-chain-query is available, the downstream Resolving 300 Nameserver can adjust its query strategy based on the desired queries 301 and its cache contents. 303 A Forwarder can request the edns-tcp-chain-query option with every 304 outgoing DNS query. However, it is RECOMMENDED that Forwarders 305 remember which upstream Resolving Nameservers did not return the 306 option (and additional data) with their response. The Forwarder 307 SHOULD fallback to regular DNS for subsequent queries to those 308 Recursive Nameservers. It MAY switch to another Resolving Nameserver 309 that does support the edns-tcp-chain-query option or try again later 310 to see if the server has become less loaded and is now willing to 311 answer with Query Chains. 313 6. Protocol Considerations 315 6.1. DNSSEC Considerations 317 The presence or absence of an OPT resource record containing an edns- 318 tcp-chain-query option in a DNS query does not change the usage of 319 those resource records and mechanisms used to provide data origin 320 authentication and data integrity to the DNS, as described in 321 [RFC4033], [RFC4034] and [RFC4035]. 323 6.2. NS record Considerations 325 When a DNSSEC chain is supplied via edns-tcp-chain-query, the 326 Forwarder no longer requires to use the NS RRset, as it can construct 327 the validation path via the DNSKEY and DS RRsets without using the NS 328 RRset. However, it is prefered that the Forwarder can populate its 329 cache with this information regardless, to avoid requiring queries in 330 the future just to obtain the missing NS records. Therefor, edns- 331 tcp-chain-query responses MUST include the NS RRset from the child 332 zone, which includes DNSSEC RRSIG records required for validation. 334 6.3. TCP Session Management 336 It is recommended that TCP Chain Queries are used in combination with 337 [TCP-KEEPALIVE]. 339 Both DNS clients and servers are subject to resource constraints 340 which will limit the extent to which TCP Chain Queries can be 341 executed. Effective limits for the number of active sessions that 342 can be maintained on individual clients and servers should be 343 established, either as configuration options or by interrogation of 344 process limits imposed by the operating system. 346 In the event that there is greater demand for TCP Chain Queries than 347 can be accommodated, DNS servers may stop advertising the edns-tcp- 348 query-chain option in successive DNS messages. This allows, for 349 example, clients with other candidate servers to query to establish 350 new TCP sessions with different servers in expectation that those 351 servers might still allow TCP Chain Queries. 353 6.4. Non-Clean Paths 355 Many paths between DNS clients and servers suffer from poor hygiene, 356 limiting the free flow of DNS messages that include particular EDNS0 357 options, or messages that exceed a particular size. A fallback 358 strategy similar to that described in [RFC6891] section 6.2.2 SHOULD 359 be employed to avoid persistent interference due to non-clean paths. 361 6.5. Anycast Considerations 363 DNS servers of various types are commonly deployed using anycast 364 [RFC4786]. 366 Successive DNS transactions between a client and server using UDP 367 transport may involve responses generated by different anycast nodes, 368 and the use of anycast in the implementation of a DNS server is 369 effectively undetectable by the client. The edns-tcp-chain-query 370 option SHOULD NOT be included in responses using UDP transport from 371 servers provisioned using anycast unless all anycast server nodes are 372 capable of processing the edns-tcp-query-chain option. 374 Changes in network topology between clients and anycast servers may 375 cause disruption to TCP sessions making use of edns-tcp-chain-query 376 more often than with TCP sessions that omit it, since the TCP 377 sessions are expected to be longer-lived. Anycast servers MAY make 378 use of TCP multipath [RFC6824] to anchor the server side of the TCP 379 connection to an unambiguously-unicast address in order to avoid 380 disruption due to topology changes. 382 7. Implementation Status 384 This section records the status of known implementations of the 385 protocol defined by this specification at the time of posting of this 386 Internet-Draft, and is based on a proposal described in [RFC6982]. 387 The description of implementations in this section is intended to 388 assist the IETF in its decision processes in progressing drafts to 389 RFCs. Please note that the listing of any individual implementation 390 here does not imply endorsement by the IETF. Furthermore, no effort 391 has been spent to verify the information presented here that was 392 supplied by IETF contributors. This is not intended as, and must not 393 be construed to be, a catalog of available implementations or their 394 features. Readers are advised to note that other implementations may 395 exist. 397 According to [RFC6982], "this will allow reviewers and working groups 398 to assign due consideration to documents that have the benefit of 399 running code, which may serve as evidence of valuable experimentation 400 and feedback that have made the implemented protocols more mature. 401 It is up to the individual working groups to use this information as 402 they see fit". 404 [While there is some interest, no work has started yet] 406 8. Security Considerations 408 8.1. Amplification Attacks 410 Chain Queries can potentially send very large DNS answers. A 411 recursive nameserver MUST NOT return Query Chain answers to clients 412 over UDP. It is allowed to signal support in response to a Query 413 Chain request over UDP by responding using a zero-length edns-tcp- 414 chain-query option. This is to prevent a single spoofed UDP packet 415 from causing extremely large UDP response packets from being sent to 416 a spoofed IP address. Such Distributed Denial of Service attacks 417 using other DNS amplification mechanisms are fairly common. 419 9. Examples 420 9.1. Simple Query for example.com 422 1. A web browser on a client machine asks the Forwarder running on 423 localhost to resolve the A record of "www.example.com." by 424 sending a regular DNS UDP query on port 53 to 127.0.0.1. 426 2. The Forwarder on the client machine checks its cache, and 427 notices it already has a validated entry of "com." in its cache. 428 This includes the DNSKEY RRset with its RRSIG records. In other 429 words, according to its cache, ".com" is DNSSEC validated as 430 "secure" and can be used to continue a DNSSEC validated chain 431 on. 433 3. The Forwarder on the client opens a TCP connection to its 434 upstream Recursive Resolver on port 53. It adds the edns-tcp- 435 chain-query option as follows: 437 * Option-code, set to [TBD] 439 * Option-length, set to 0x00 0x04 441 * Last Known Query Name set to "com." 443 4. The upstream Recursive Resolver receives a DNS query over TCP 444 with the edns-tcp-chain-query Last Known Query Name set to 445 "com.". After accepting the query it starts constructing a DNS 446 reply packet over TCP. 448 5. The upstream Recursive Resolver performs all the regular work to 449 ensure it has all the answers to the query for the A record of 450 "www.example.com.". It does so without using the edns-tcp- 451 chain-query option - unless it is also configured as a 452 Forwarder. The answer to the original DNS question could be the 453 actual A record, the DNSSEC proof of non-existence, or an 454 insecure NXDOMAIN response. 456 6. The upstream Recursive Resolver adds the edns-tcp-chain-query 457 option to the DNS answer reply as follows: 459 * Option-code, set to [TBD] 461 * Option-length, set to 0x00 0x00 463 * The Last Known Query Name is ommited (zero length) 465 7. The upstream Recursive Resolver constructs the DNS Authority 466 Section and fills it with: 468 * The DS RRset for "example.com." and its corresponding RRSIGs 469 (made by the "com." DNSKEY(s)) 471 * The DNSKEY RRset for "example.com." and its corresponding 472 RRSIGs (made by the "example.com" DNSKEY(s)) 474 * The authoritative NS RRset for "example.com." and its 475 corresponding RRSIGs (from the child zone) 477 If the answer does not exist, and the zone uses DNSSEC, it also 478 adds the proof of non-existance, such as NSEC or NSEC3 records, 479 to the Authority Section. 481 8. The upstream Recursive Resolver constructs the DNS Answer 482 Section and fills it with: 484 * The A record of "www.example.com." and its corresponding 485 RRSIGs 487 If the answer does not exist (no-data or NXDOMAIN), the Answer 488 Section remains empty. For the NXDOMAIN case, the RCode of the 489 DNS answer packet is set to NXDOMAIN. Otherwise it remains 490 NOERROR. 492 9. The upstream Recursive Resolver returns the DNS answer over the 493 existing TCP connection. When all data is sent, it SHOULD keep 494 the TCP connection open to allow for additional incoming DNS 495 queries - provided it has enough resources to do so. 497 10. The Forwarder receives the DNS answer over TCP. It processes 498 the Authority Section and the Answer Section and places the 499 information in its local cache. If it is a DNSSEC validating 500 resolver, it ensures that no unvalidated data or out of baliwick 501 data is accepted into the cache without having proper DNSSEC 502 validation. It MAY do so by looping over the entries in the 503 Authority and Answer Sections. When an entry is validated for 504 its cache, it is removed from the processing list. If an entry 505 cannot be validated it is left in the process list. When the 506 end of the list is reached, the list is processed again until 507 either all entries are placed in the cache, or the remaining 508 items cannot be placed in the cache due to lack of validation. 509 Those entries are then disgarded. 511 11. If the cache contains a valid answer to the application's query, 512 this answer is returned to the application via a regular DNS 513 answer packet. This packet MUST NOT contain an edns-tcp-chain- 514 query option. If no valid answer can be returned, normal error 515 processing is done. For example, an NXDOMAIN or an empty Answer 516 Section could be returned depending on the error condition. 518 9.2. Out-of-path query for example.com 520 A Recursive Resolver receives a query for the A record for 521 example.com. It includes the edns-tcp-chain-query option with the 522 following parameters: 524 o Option-code, set to [TBD] 526 o Option-length, set to 0x00 0x0D 528 o The Last Known Query Name set to 'unrelated.ca.' 530 As there is no chain that leads from "unrelated.ca." to 531 "example.com", the Resolving Nameserver answers with RCODE "FormErr". 532 It includes the edns-tcp-chain-query with the following parameters: 534 o Option-code, set to [TBD] 536 o Option-length, set to 0x00 0x00 538 o The Last Known Query Name is ommited (zero length) 540 9.3. non-existent data 542 A Recursive Resolver receives a query for the A record for 543 "ipv6.toronto.redhat.ca". It includes the edns-tcp-chain-query 544 option with the following parameters: 546 o Option-code, set to [TBD] 548 o Option-length, set to 0x00 0x03 550 o The Last Known Query Name set to 'ca.' 552 Using regular UDP queries towards Authoritative Nameservers, it 553 locates the NS RRset for "toronto.redhat.ca.". When querying for the 554 A record it receives a reply with RCODE "NoError" and an empty Answer 555 Section. The Authority Section contains NSEC3 and RRSIG records 556 proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca". 558 The Recursive Resolver constructs a DNS reply with the following 559 edns-tcp-chain-query option parameters: 561 o Option-code, set to [TBD] 563 o Option-length, set to 0x00 0x00 565 o The Last Known Query Name is ommited (zero length) 567 The RCODE is set to "NoError". The Authority Section is filled in 568 with: 570 o The DS RRset for "redhat.ca." plus RRSIGs 572 o The DNSKEY RRset for "redhat.ca." plus RRSIGs 574 o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca) 576 o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs 578 o The DS RRset for "toronto.redhat.ca." plus RRSIGs 580 o The NS RRset for "toronto.redhat.ca." plus RRSIGs (eg 581 ns[01].toronto.redhat.ca) 583 o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs 585 o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and 586 "ns1.toronto.redhat.ca." plus RRSIGs 588 o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs 589 do exist, does not include A) 591 o The NSEC record for "toronto.redhat.ca." (proves no wildcard 592 exists) 594 The Answer Section is empty. The RCode is set to NOERROR. 596 10. IANA Considerations 598 10.1. EDNS0 option code for edns-tcp-chain-query 600 IANA has assigned option code [TBD] in the "DNS EDNS0 Option Codes 601 (OPT)" registry to edns-tcp-chain-query. 603 11. Acknowledgements 604 Andrew Sullivan pointed out that we do not need any new data formats 605 to support DNS chains. Olafur Gudmundsson ensured the RRsets are 606 returned in the proper Sections. 608 12. Normative References 610 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 611 STD 13, RFC 1034, November 1987. 613 [RFC1035] Mockapetris, P., "Domain names - implementation and 614 specification", STD 13, RFC 1035, November 1987. 616 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 617 Requirement Levels", BCP 14, RFC 2119, March 1997. 619 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 620 2671, August 1999. 622 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 623 Rose, "DNS Security Introduction and Requirements", RFC 624 4033, March 2005. 626 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 627 Rose, "Resource Records for the DNS Security Extensions", 628 RFC 4034, March 2005. 630 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 631 Rose, "Protocol Modifications for the DNS Security 632 Extensions", RFC 4035, March 2005. 634 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 635 Services", BCP 126, RFC 4786, December 2006. 637 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 638 "TCP Extensions for Multipath Operation with Multiple 639 Addresses", RFC 6824, January 2013. 641 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 642 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 644 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 645 Code: The Implementation Status Section", RFC 6982, July 646 2013. 648 [TCP-KEEPALIVE] 649 Wouters, P., "The edns-tcp-keepalive EDNS0 Option", draft- 650 wouters-edns-tcp-keeaplive (work in progress), October 651 2013. 653 Author's Address 655 Paul Wouters 656 Red Hat 658 Email: pwouters@redhat.com