1 Internet Engineering Task Force (IETF) P. Wouters
2 Request for Comments: 7901 Red Hat
3 Category: Experimental June 2016
4 ISSN: 2070-1721
5
6
7 CHAIN Query Requests in DNS
8
9 Abstract
10
11 This document defines an EDNS0 extension that can be used by a
12 security-aware validating resolver configured to use a forwarding
13 resolver to send a single query, requesting a complete validation
14 path along with the regular query answer. The reduction in queries
15 potentially lowers the latency and reduces the need to send multiple
16 queries at once. This extension mandates the use of source-IP-
17 verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot
18 be abused in amplification attacks.
19
20 Status of This Memo
21
22 This document is not an Internet Standards Track specification; it is
23 published for examination, experimental implementation, and
24 evaluation.
25
26 This document defines an Experimental Protocol for the Internet
27 community. This document is a product of the Internet Engineering
28 Task Force (IETF). It represents the consensus of the IETF
29 community. It has received public review and has been approved for
30 publication by the Internet Engineering Steering Group (IESG). Not
31 all documents approved by the IESG are a candidate for any level of
32 Internet Standard; see Section 2 of RFC 7841.
33
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 http://www.rfc-editor.org/info/rfc7901.
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52 Wouters Experimental [Page 1]
53 RFC 7901 CHAIN Query Requests in DNS June 2016
54
55
56 Copyright Notice
57
58 Copyright (c) 2016 IETF Trust and the persons identified as the
59 document authors. All rights reserved.
60
61 This document is subject to BCP 78 and the IETF Trust's Legal
62 Provisions Relating to IETF Documents
63 (http://trustee.ietf.org/license-info) in effect on the date of
64 publication of this document. Please review these documents
65 carefully, as they describe your rights and restrictions with respect
66 to this document. Code Components extracted from this document must
67 include Simplified BSD License text as described in Section 4.e of
68 the Trust Legal Provisions and are provided without warranty as
69 described in the Simplified BSD License.
70
71 Table of Contents
72
73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
74 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
75 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
76 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
77 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5
78 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
79 5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 6
80 5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 6
81 5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6
82 5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 7
83 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8
84 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 8
85 6.2. NS Record Considerations . . . . . . . . . . . . . . . . 8
86 6.3. Session Management . . . . . . . . . . . . . . . . . . . 9
87 6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 9
88 6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9
89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
90 7.1. Additional Work and Bandwidth . . . . . . . . . . . . . . 10
91 7.2. Amplification Attacks . . . . . . . . . . . . . . . . . . 10
92 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 10
93 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
94 8.1. CHAIN Query for "www.example.com" . . . . . . . . . . . . 10
95 8.2. Out-of-Path Query for "example.com" . . . . . . . . . . . 12
96 8.3. Nonexistent Data . . . . . . . . . . . . . . . . . . . . 13
97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
98 9.1. EDNS0 Option Code for CHAIN . . . . . . . . . . . . . . . 14
99 10. Normative References . . . . . . . . . . . . . . . . . . . . 14
100 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
102
103
104
105
106
107 Wouters Experimental [Page 2]
108 RFC 7901 CHAIN Query Requests in DNS June 2016
109
110
111 1. Introduction
112
113 Traditionally, a DNS client operates in stub mode. For each DNS
114 question the DNS client needs to resolve, it sends a single query to
115 an upstream recursive resolver to obtain a single DNS answer. When
116 DNSSEC [RFC4033] is deployed on such DNS clients, validation requires
117 that the client obtain all the intermediate information from the DNS
118 root down to the queried-for host name, so it can perform DNSSEC
119 validation on the complete chain of trust.
120
121 Currently, applications send out many UDP requests concurrently.
122 This requires more resources on the DNS client with respect to state
123 (CPU, memory, battery) and bandwidth. There is also no guarantee
124 that the initial set of UDP questions will result in all the records
125 required for DNSSEC validation. More round trips could be required
126 depending on the resulting DNS answers. This especially affects
127 high-latency links.
128
129 This document specifies an EDNS0 extension that allows a validating
130 resolver running as a forwarding resolver to open a TCP connection to
131 another resolver and request a DNS chain answer using one DNS query/
132 answer pair. This reduces the number of round trips to two. If
133 combined with long-lived TCP or [RFC7828], there is only one round
134 trip. While the upstream resolver still needs to perform all the
135 individual queries required for the complete answer, it usually has a
136 much bigger cache and does not experience significant slowdown from
137 last-mile latency.
138
139 This EDNS0 extension allows the forwarding resolver to indicate which
140 part of the DNS hierarchy it already contains in its cache. This
141 reduces the amount of data required to be transferred and reduces the
142 work the upstream recursive resolver has to perform.
143
144 This EDNS0 extension is only intended to be sent by forwarding
145 resolvers to recursive resolvers. It MUST be ignored by
146 authoritative servers.
147
148 1.1. Requirements Notation
149
150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
152 document are to be interpreted as described in [RFC2119].
153
154
155
156
157
158
159
160
161
162 Wouters Experimental [Page 3]
163 RFC 7901 CHAIN Query Requests in DNS June 2016
164
165
166 2. Terminology
167
168 The DNS terminology used in this document is that of [RFC7719].
169 Additionally, the following terms are used:
170
171 Forwarding Resolver: A nameserver that does not do iterative
172 resolution itself; instead, it passes that responsibility to
173 another recursive resolver, called a "forwarder" in [RFC2308],
174 Section 1.
175
176 Recursive Resolver: A nameserver that is responsible for resolving
177 domain names for clients by following the domain's delegation
178 chain, starting at the root. Recursive resolvers frequently use
179 caches to be able to respond to client queries quickly, as
180 described in [RFC1035], Section 7.
181
182 Validating Resolver: A recursive nameserver that also performs
183 DNSSEC [RFC4033] validation. Also known as "security-aware
184 resolver".
185
186 3. Overview
187
188 When DNSSEC is deployed on a host, it can no longer delegate all DNS
189 work to the upstream recursive resolver. Obtaining just the DNS
190 answer itself is not enough to validate that answer using DNSSEC.
191 For DNSSEC validation, the DNS client requires a locally running
192 validating resolver, so it can confirm DNSSEC validation of all
193 intermediary DNS answers. It can configure itself as a forwarding
194 resolver if it obtains the IP addresses of one or more recursive
195 resolvers that are available or as a stand-alone recursive resolver
196 if no functional recursive resolvers were obtained. Generating the
197 required queries for validation adds a significant delay in answering
198 the DNS question of the locally running application. The application
199 must wait while the resolver validates all intermediate answers.
200 Each round trip adds to the total time waiting on DNS resolution with
201 validation to complete. This makes DNSSEC resolving impractical for
202 devices on networks with a high latency.
203
204 This document defines the CHAIN option that allows the resolver to
205 request all intermediate DNS data it requires to resolve and validate
206 a particular DNS answer in a single round trip. The resolver could
207 be part of the application or a recursive resolver running on the
208 host.
209
210 Servers answering with CHAIN data should ensure that the peer's IP
211 address is not a spoofed source IP address. See Section 7. This
212 prevents DNS amplification attacks.
213
214
215
216
217 Wouters Experimental [Page 4]
218 RFC 7901 CHAIN Query Requests in DNS June 2016
219
220
221 Applications that support CHAIN internally can perform validation
222 without requiring the host to run a recursive resolver. This is
223 particularly useful for virtual servers in a cloud or container-based
224 deployment where it is undesirable to run a recursive resolver per
225 virtual machine.
226
227 The format of this option is described in Section 4.
228
229 As described in Section 5.4, a recursive resolver can use this EDNS0
230 option to include additional data required by the resolver in the
231 Authority Section of the DNS answer packet. The Answer
232 Section remains unchanged from a traditional DNS answer and contains
233 the answer and related DNSSEC entries.
234
235 An empty CHAIN EDNS0 option MAY be sent over any transport as a
236 discovery method. A DNS server receiving such an empty CHAIN option
237 SHOULD add an empty CHAIN option in its answer to indicate that it
238 supports the CHAIN option.
239
240 The mechanisms provided by CHAIN raise various security concerns
241 related to the additional work, bandwidth, amplification attacks, and
242 privacy issues with the cache. These concerns are described in
243 Section 7.
244
245 4. Option Format
246
247 This document uses an EDNS0 option [RFC6891] to include client IP
248 information in DNS messages. The option is structured as follows:
249
250 1 2 3
251 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
252 +-------------------------------+-------------------------------+
253 ! OPTION-CODE ! OPTION-LENGTH !
254 +-------------------------------+-------------------------------+
255 ~ Closest Trust Point (FQDN) ~
256 +---------------------------------------------------------------+
257
258 o OPTION-CODE, 2 octets, for CHAIN is 13.
259
260 o OPTION-LENGTH, 2 octets, contains the length of the payload
261 (everything after Option-length) in octets.
262
263 o Closest trust point, a variable-length Fully-Qualified Domain Name
264 (FQDN) in DNS wire format of the requested start point of the
265 chain. This entry is the "lowest" known entry in the DNS chain
266 known by the recursive server seeking a CHAIN answer for which it
267 has a validated Delegation Signer (DS) and DNSKEY record. The
268
269
270
271
272 Wouters Experimental [Page 5]
273 RFC 7901 CHAIN Query Requests in DNS June 2016
274
275
276 endpoint of the chain is obtained from the DNS Query
277 Section itself. No DNS name compression is allowed for this
278 value.
279
280 5. Protocol Description
281
282 5.1. Discovery of Support
283
284 A forwarding resolver may include a zero-length CHAIN option in a
285 regular query over any transport to discover the DNS server
286 capability for CHAIN. Recursive resolvers that support and are
287 willing to accept CHAIN queries over source IP verified transport
288 respond to a zero-length CHAIN received by including a zero-length
289 CHAIN option in the answer. If not already using a source-IP-
290 verified transport, the forwarding resolver MAY then switch to a
291 source-IP-verified transport and start sending queries with the CHAIN
292 option to request a CHAIN response from the recursive resolver.
293 Examples of source-IP-verified transports are the three-way TCP
294 handshake and UDP with DNS cookies [RFC7873].
295
296 5.2. Generate a Query
297
298 In this option value, the forwarding resolver sets the closest trust
299 point in the chain -- furthest from the root -- that it already has a
300 DNSSEC-validated (secure or not) answer for in its cache. The
301 upstream recursive resolver does not need to include any part of the
302 chain from the root down to this option's FQDN. A complete example
303 is described in Section 8.1.
304
305 The CHAIN option should generally be sent by system forwarding
306 resolvers and resolvers within an application that also performs
307 DNSSEC validation.
308
309 5.3. Send the Option
310
311 When CHAIN is available, the downstream recursive resolver can adjust
312 its query strategy based on the desired queries and its cache
313 contents.
314
315 A forwarding resolver can request the CHAIN option with every
316 outgoing DNS query. However, it is RECOMMENDED that forwarding
317 resolvers remember which upstream recursive resolvers did not return
318 the option (and additional data) with their response. The forwarding
319 resolver SHOULD fall back to regular DNS for subsequent queries to
320 those recursive resolvers. It MAY switch to another recursive
321 resolver that does support the CHAIN option or try again later to see
322 if the server has become less loaded and is now willing to answer
323 with CHAIN queries. A fallback strategy similar to that described in
324
325
326
327 Wouters Experimental [Page 6]
328 RFC 7901 CHAIN Query Requests in DNS June 2016
329
330
331 [RFC6891], Section 6.2.2 SHOULD be employed to avoid persistent
332 interference due to non-clean paths.
333
334 5.4. Generate a Response
335
336 When a query containing a non-zero CHAIN option is received from a
337 forwarding resolver, the upstream recursive resolver supporting CHAIN
338 MAY respond by confirming that it is returning a CHAIN. To do so, it
339 MUST set the CHAIN option to the lowest trust point sent as part of
340 the chain, with its corresponding OPTION-LENGTH. It extends the
341 Authority Section in the DNS answer packet with the DNS RRsets
342 required for validating the answer. The added DNS RRsets start with
343 the first chain element below the received closest trust point up to
344 and including the NS and DS RRsets that represent the zone cut
345 (authoritative servers) of the QNAME. The added RRsets MAY be added
346 in matching hierarchical order, but a DNS client MUST NOT depend on
347 the order of the added RRsets for validation. The actual DNS answer
348 to the question in the Query Section is placed in the DNS Answer
349 Section identical to the traditional DNS answer. All required
350 DNSSEC-related records must be added to their appropriate sections.
351 This includes records required for proof of nonexistence of regular
352 and/or wildcard records, such as NextSECure (NSEC) or NSEC3 records.
353
354 Recursive resolvers that have not implemented or enabled support for
355 the CHAIN option, or are otherwise unwilling to perform the
356 additional work for a CHAIN query due to workload, may safely ignore
357 the option in the incoming queries. Such a server MUST NOT include a
358 CHAIN option when sending DNS answer replies back, thus indicating it
359 is not able or willing to support CHAIN queries at this time.
360
361 Requests with wrongly formatted options (i.e., bogus FQDN) MUST be
362 rejected; a FORMERR response must be returned to the sender, as
363 described by [RFC6891].
364
365 Requests resulting in chains that the receiving resolver is unwilling
366 to serve can be rejected by answering the query as a regular DNS
367 reply but with an empty CHAIN payload. Replying with an empty CHAIN
368 can be used for chains that would be too big or for chains that would
369 reveal too much information considered private.
370
371 At any time, a recursive resolver that has determined that it is
372 running low on resources can refuse CHAIN queries by replying with a
373 regular DNS reply with an empty CHAIN payload.
374
375 If a CHAIN answer would be bigger than the recursive resolver is
376 willing to serve, it SHOULD send a partial chain starting with the
377 data closest to the top of the chain. The client MAY resend the
378 query with an updated closest trust point until it has received the
379
380
381
382 Wouters Experimental [Page 7]
383 RFC 7901 CHAIN Query Requests in DNS June 2016
384
385
386 full chain. The CHAIN response will contain the lowest closest trust
387 point that was included in the CHAIN answer.
388
389 If the DNS request results in a CNAME or DNAME for the Answer
390 Section, the recursive resolver MUST return these records in the
391 Answer Section similar to regular DNS processing. The CNAME or DNAME
392 target MAY be placed in the Additional Section only if all supporting
393 records for DNSSEC validation of the CNAME or DNAME target are also
394 added to the Authority Section.
395
396 The response from a recursive resolver to a resolver MUST NOT contain
397 the CHAIN option if none was present in the resolver's original
398 request.
399
400 A DNS query that contains the CHAIN option MUST also have the "DNSSEC
401 OK" (DO) bit set. If this bit is not set, or if the "Checking
402 Disabled" (CD) bit is set, the CHAIN option received MUST be ignored.
403
404 6. Protocol Considerations
405
406 6.1. DNSSEC Considerations
407
408 The presence or absence of an OPT resource record containing a CHAIN
409 option in a DNS query does not change the usage of those resource
410 records and mechanisms used to provide data origin authentication and
411 data integrity to the DNS, as described in [RFC4033], [RFC4034], and
412 [RFC4035].
413
414 6.2. NS Record Considerations
415
416 CHAIN responses SHOULD include the authoritative NS RRset with its
417 RRSIG records required for validation. It MUST NOT include the NS
418 RRset from the parent zone, as this RRset is not signed. If the size
419 of the answer is an important factor, the NS RRset MAY be omitted.
420
421 When a DNSSEC chain is supplied via CHAIN, the forwarding resolver is
422 no longer required to use the NS RRset, as it can construct the
423 validation path via the DNSKEY and DS RRsets without using the NS
424 RRset. However, the forwarding resolver might be forced to switch
425 from forwarding resolver mode to recursive resolver mode due to a
426 network topology change. In recursive resolver mode, the NS RRsets
427 are needed to find and query authoritative servers directly. It is
428 RECOMMENDED that the DNS forwarding resolver populate its cache with
429 this information to avoid requiring future queries to obtain any
430 missing NS records. Therefore, CHAIN responses MUST include the NS
431 RRset from the child zone, including the RRSIG records required for
432 validation.
433
434
435
436
437 Wouters Experimental [Page 8]
438 RFC 7901 CHAIN Query Requests in DNS June 2016
439
440
441 6.3. Session Management
442
443 The use of TCP keepalive [RFC7828] on DNS TCP sessions is
444 RECOMMENDED; thus, TCP sessions should not immediately be closed
445 after the DNS answer to the first query is received.
446
447 Both DNS clients and servers are subject to resource constraints that
448 will limit the extent to which CHAIN queries can be executed.
449 Effective limits for the number of active sessions that can be
450 maintained on individual clients and servers should be established
451 either as configuration options or by interrogation of process limits
452 imposed by the operating system.
453
454 In the event that there is greater demand for CHAIN queries than can
455 be accommodated, DNS servers may stop advertising the CHAIN option in
456 successive DNS messages. This allows, for example, clients with
457 other candidate servers to query to establish new sessions with
458 different servers in expectation that those servers might still allow
459 CHAIN queries.
460
461 6.4. Negative Trust Anchors
462
463 If a CHAIN answer would intersect with a negative trust anchor
464 [RFC7646], a partial CHAIN up to the node above the negative trust
465 anchor should be returned.
466
467 6.5. Anycast Considerations
468
469 Recursive resolvers of various types are commonly deployed using
470 anycast [RFC4786].
471
472 Successive DNS transactions between a client and server using UDP
473 transport may involve responses generated by different anycast nodes,
474 and the use of anycast in the implementation of a DNS server is
475 effectively undetectable by the client. The CHAIN option SHOULD NOT
476 be included in responses using UDP transport from servers provisioned
477 using anycast unless all anycast server nodes are capable of
478 processing the CHAIN option.
479
480 Since DNS queries using CHAIN may result in longer TCP sessions,
481 network topology changes may disrupt them more frequently. Anycast
482 servers MAY make use of Multipath TCP [RFC6824] to anchor the server
483 side of the TCP connection to an unambiguously unicast address in
484 order to avoid disruption due to topology changes.
485
486
487
488
489
490
491
492 Wouters Experimental [Page 9]
493 RFC 7901 CHAIN Query Requests in DNS June 2016
494
495
496 7. Security Considerations
497
498 7.1. Additional Work and Bandwidth
499
500 Producing CHAIN answers incurs additional load and bandwidth on the
501 recursive resolver. At any time, a recursive resolver may decide to
502 no longer answer with CHAIN answers and fall back to traditional DNS
503 answers.
504
505 7.2. Amplification Attacks
506
507 CHAIN queries can potentially send very large DNS answers. Attackers
508 could abuse this using spoofed source IP addresses to inflict large
509 distributed denial-of-service attacks using CHAINS as an
510 amplification vector in their attack. While TCP is not vulnerable
511 for this type of abuse, the UDP protocol is vulnerable to this.
512
513 A recursive resolver MUST NOT return CHAIN answers to clients over
514 UDP without source IP address verification. An example of UDP-based
515 source IP address verification is [RFC7873]. A recursive resolver
516 refusing a CHAIN option MUST respond with a zero-length CHAIN option
517 to indicate support for CHAIN queries when a proper transport is
518 used. It MUST NOT send an RCODE of REFUSED.
519
520 7.3. Privacy Considerations
521
522 A client producing CHAIN queries reveals a little more information
523 about its cache contents than regular DNS clients. This could be
524 used to fingerprint a client across network reconnections. If DNS
525 privacy is a concern, a CHAIN query client MAY try to use a DNS
526 transport that provides privacy, such as [RFC7858] or a trusted DNS
527 server that is contacted through a VPN connection such as IPsec.
528
529 8. Examples
530
531 8.1. CHAIN Query for "www.example.com"
532
533 o A web browser on a client machine asks the forwarding resolver
534 running on the local host to resolve the A record of
535 "www.example.com." by sending a regular DNS UDP query on port 53
536 to 127.0.0.1.
537
538 o The resolver on the client machine checks its cache and notices it
539 already has a DNSSEC-validated entry of "com." in its cache. This
540 includes the DNSKEY RRset with its RRSIG records. In other words,
541 according to its cache, ".com" is DNSSEC validated as "secure" and
542 can be used to continue a DNSSEC-validated chain.
543
544
545
546
547 Wouters Experimental [Page 10]
548 RFC 7901 CHAIN Query Requests in DNS June 2016
549
550
551 o The resolver on the client opens a TCP connection to its upstream
552 recursive resolver on port 53. It adds the CHAIN option as
553 follows:
554
555 * Option-code, set to 13
556
557 * Option-length, set to 5
558
559 * Closest trust point set to "com." (0x03 0x63 0x6f 0x6d 0x00)
560
561 o The upstream recursive resolver receives a DNS query over TCP with
562 the CHAIN closest trust point set to "com.". After accepting the
563 query, it starts constructing a DNS reply packet.
564
565 o The upstream recursive resolver performs all the regular work to
566 ensure it has all the answers to the query for the A record of
567 "www.example.com.". It does so without using the CHAIN option --
568 unless it is also configured as a forwarding resolver. The answer
569 to the original DNS question could be the actual A record, the
570 DNSSEC proof of nonexistence, or an insecure NXDOMAIN response.
571
572 o The upstream recursive resolver adds the CHAIN option to the DNS
573 response as follows:
574
575 * Option-code, set to 13
576
577 * Option-length, set to 5
578
579 * The closest trust point is set to "com." (0x03 0x63 0x6f 0x6d
580 0x00)
581
582 o The upstream recursive resolver constructs the DNS Authority
583 Section and fills it (in any order) with:
584
585 * The DS RRset for "example.com." and its corresponding RRSIGs
586 (made by the "com." DNSKEY(s))
587
588 * The DNSKEY RRset for "example.com." and its corresponding
589 RRSIGs (made by the "example.com." DNSKEY(s))
590
591 * The authoritative NS RRset for "example.com." and its
592 corresponding RRSIGs (from the child zone)
593
594 If the answer does not exist, and the zone uses DNSSEC, it also
595 adds the proof of nonexistence, such as NSEC or NSEC3 records, to
596 the Authority Section.
597
598
599
600
601
602 Wouters Experimental [Page 11]
603 RFC 7901 CHAIN Query Requests in DNS June 2016
604
605
606 o The upstream recursive resolver constructs the DNS Answer section
607 and fills it with:
608
609 * The A record of "www.example.com." and its corresponding
610 RRSIGs.
611
612 If the answer does not exist (NODATA or NXDOMAIN), the Answer
613 Section remains empty. For the NXDOMAIN case, the RCODE of the
614 DNS answer packet is set to NXDOMAIN. Otherwise, it remains as
615 NOERROR.
616
617 o The upstream recursive resolver returns the DNS answer over the
618 existing TCP connection. When all data is sent, it SHOULD keep
619 the TCP connection open to allow for additional incoming DNS
620 queries -- provided it has enough resources to do so.
621
622 o The resolver on the client receives the DNS answer. It processes
623 the Authority and the Answer Sections and places the information
624 in its local cache. It ensures that no data is accepted into the
625 cache without having proper DNSSEC validation. It MAY do so by
626 looping over the entries in the Authority and Answer Sections.
627 When an entry is validated for its cache, it is removed from the
628 processing list. If an entry cannot be validated, it is left in
629 the process list. When the end of the list is reached, the list
630 is processed again until either all entries are placed in the
631 cache or the remaining items cannot be placed in the cache due to
632 lack of validation. Those entries are then discarded.
633
634 o If the cache contains a valid answer to the application's query,
635 this answer is returned to the application via a regular DNS
636 answer packet. This packet MUST NOT contain a CHAIN option. If
637 no valid answer can be returned, normal error processing is done.
638 For example, an NXDOMAIN or an empty Answer Section could be
639 returned depending on the error condition.
640
641 8.2. Out-of-Path Query for "example.com"
642
643 A recursive resolver receives a query for the A record for
644 "example.com". It includes the CHAIN option with the following
645 parameters:
646
647 o Option-code, set to 13
648
649 o Option-length, set to 14
650
651 o The closest trust point set to "unrelated.ca." (0x09 0x75 0x6e
652 0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00)
653
654
655
656
657 Wouters Experimental [Page 12]
658 RFC 7901 CHAIN Query Requests in DNS June 2016
659
660
661 As there is no chain that leads from "unrelated.ca." to
662 "example.com.", the resolving nameserver answers with an empty CHAIN
663 specified using:
664
665 o Option-code, set to 13
666
667 o Option-length, set to 0x00 0x00
668
669 o The closest trust point is omitted (zero length)
670
671 Note that the regular answer is still present just as it would be for
672 a query that did not specify the CHAIN option.
673
674 8.3. Nonexistent Data
675
676 A recursive resolver receives a query for the A record for
677 "ipv6.toronto.redhat.ca". It includes the CHAIN option with the
678 following parameters:
679
680 o Option-code, set to 13
681
682 o Option-length, set to 0x00 0x03
683
684 o The closest trust point set to "ca."
685
686 Using regular UDP queries towards authoritative nameservers, it
687 locates the NS RRset for "toronto.redhat.ca.". When querying for the
688 A record, it receives a reply with RCODE "NoError" and an empty
689 Answer Section. The Authority Section contains NSEC3 and RRSIG
690 records proving there is no A RRTYPE for the QNAME
691 "ipv6.toronto.redhat.ca".
692
693 The recursive resolver constructs a DNS reply with the following
694 CHAIN option parameters:
695
696 o Option-code, set to 13
697
698 o Option-length, set to 0x00 0x00
699
700 o The closest trust point is omitted (zero length)
701
702 The RCODE is set to "NoError". The Authority Section is filled in
703 with:
704
705 o The DS RRset for "redhat.ca." plus RRSIGs
706
707 o The DNSKEY RRset for "redhat.ca." plus RRSIGs
708
709
710
711
712 Wouters Experimental [Page 13]
713 RFC 7901 CHAIN Query Requests in DNS June 2016
714
715
716 o The NS RRset for "redhat.ca." plus RRSIGs (e.g., ns[01].redhat.ca)
717
718 o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs
719
720 o The DS RRset for "toronto.redhat.ca." plus RRSIGs
721
722 o The NS RRset for "toronto.redhat.ca." plus RRSIGs (e.g.,
723 ns[01].toronto.redhat.ca)
724
725 o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs
726
727 o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and
728 "ns1.toronto.redhat.ca." plus RRSIGs
729
730 o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs
731 do exist; does not include A)
732
733 o The NSEC record for "toronto.redhat.ca." (proves no wildcard
734 exists)
735
736 The Answer Section is empty. The RCODE is set to NOERROR.
737
738 9. IANA Considerations
739
740 9.1. EDNS0 Option Code for CHAIN
741
742 IANA has assigned option code 13 in the "DNS EDNS0 Option Codes
743 (OPT)" registry to CHAIN.
744
745 10. Normative References
746
747 [RFC1035] Mockapetris, P., "Domain names - implementation and
748 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
749 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
750
751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
752 Requirement Levels", BCP 14, RFC 2119,
753 DOI 10.17487/RFC2119, March 1997,
754 <http://www.rfc-editor.org/info/rfc2119>.
755
756 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
757 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
758 <http://www.rfc-editor.org/info/rfc2308>.
759
760 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
761 Rose, "DNS Security Introduction and Requirements",
762 RFC 4033, DOI 10.17487/RFC4033, March 2005,
763 <http://www.rfc-editor.org/info/rfc4033>.
764
765
766
767 Wouters Experimental [Page 14]
768 RFC 7901 CHAIN Query Requests in DNS June 2016
769
770
771 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
772 Rose, "Resource Records for the DNS Security Extensions",
773 RFC 4034, DOI 10.17487/RFC4034, March 2005,
774 <http://www.rfc-editor.org/info/rfc4034>.
775
776 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
777 Rose, "Protocol Modifications for the DNS Security
778 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
779 <http://www.rfc-editor.org/info/rfc4035>.
780
781 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
782 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
783 December 2006, <http://www.rfc-editor.org/info/rfc4786>.
784
785 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
786 "TCP Extensions for Multipath Operation with Multiple
787 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
788 <http://www.rfc-editor.org/info/rfc6824>.
789
790 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
791 for DNS (EDNS(0))", STD 75, RFC 6891,
792 DOI 10.17487/RFC6891, April 2013,
793 <http://www.rfc-editor.org/info/rfc6891>.
794
795 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
796 and R. Weber, "Definition and Use of DNSSEC Negative Trust
797 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
798 <http://www.rfc-editor.org/info/rfc7646>.
799
800 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
801 Terminology", RFC 7719, DOI 10.17487/RFC7719, December
802 2015, <http://www.rfc-editor.org/info/rfc7719>.
803
804 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
805 edns-tcp-keepalive EDNS0 Option", RFC 7828,
806 DOI 10.17487/RFC7828, April 2016,
807 <http://www.rfc-editor.org/info/rfc7828>.
808
809 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
810 and P. Hoffman, "Specification for DNS over Transport
811 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
812 2016, <http://www.rfc-editor.org/info/rfc7858>.
813
814 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
815 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
816 <http://www.rfc-editor.org/info/rfc7873>.
817
818
819
820
821
822 Wouters Experimental [Page 15]
823 RFC 7901 CHAIN Query Requests in DNS June 2016
824
825
826 Acknowledgments
827
828 Andrew Sullivan pointed out that we do not need any new data formats
829 to support DNS chains. Olafur Gudmundsson ensured the RRsets are
830 returned in the proper sections. Thanks to Tim Wicinski for his
831 thorough review.
832
833 Author's Address
834
835 Paul Wouters
836 Red Hat
837
838 Email: pwouters@redhat.com
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877 Wouters Experimental [Page 16]
878
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.