7Internet Engineering Task Force (IETF) P. Wouters
8Request for Comments: 7901 Red Hat
9Category: Experimental June 2016
13 CHAIN Query Requests in DNS
17 This document defines an EDNS0 extension that can be used by a
18 security-aware validating resolver configured to use a forwarding
19 resolver to send a single query, requesting a complete validation
20 path along with the regular query answer. The reduction in queries
21 potentially lowers the latency and reduces the need to send multiple
22 queries at once. This extension mandates the use of source-IP-
23 verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot
24 be abused in amplification attacks.
28 This document is not an Internet Standards Track specification; it is
29 published for examination, experimental implementation, and
32 This document defines an Experimental Protocol for the Internet
33 community. This document is a product of the Internet Engineering
34 Task Force (IETF). It represents the consensus of the IETF
35 community. It has received public review and has been approved for
36 publication by the Internet Engineering Steering Group (IESG). Not
37 all documents approved by the IESG are a candidate for any level of
38 Internet Standard; see Section 2 of RFC 7841.
40 Information about the current status of this document, any errata,
41 and how to provide feedback on it may be obtained at
42 http://www.rfc-editor.org/info/rfc7901.
58Wouters Experimental [Page 1]
60RFC 7901 CHAIN Query Requests in DNS June 2016
65 Copyright (c) 2016 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
81 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
82 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
83 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
84 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5
85 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
86 5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 6
87 5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 6
88 5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6
89 5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 7
90 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 8
91 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 8
92 6.2. NS Record Considerations . . . . . . . . . . . . . . . . 8
93 6.3. Session Management . . . . . . . . . . . . . . . . . . . 9
94 6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 9
95 6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9
96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
97 7.1. Additional Work and Bandwidth . . . . . . . . . . . . . . 10
98 7.2. Amplification Attacks . . . . . . . . . . . . . . . . . . 10
99 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 10
100 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
101 8.1. CHAIN Query for "www.example.com" . . . . . . . . . . . . 10
102 8.2. Out-of-Path Query for "example.com" . . . . . . . . . . . 12
103 8.3. Nonexistent Data . . . . . . . . . . . . . . . . . . . . 13
104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
105 9.1. EDNS0 Option Code for CHAIN . . . . . . . . . . . . . . . 14
106 10. Normative References . . . . . . . . . . . . . . . . . . . . 14
107 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
114Wouters Experimental [Page 2]
116RFC 7901 CHAIN Query Requests in DNS June 2016
121 Traditionally, a DNS client operates in stub mode. For each DNS
122 question the DNS client needs to resolve, it sends a single query to
123 an upstream recursive resolver to obtain a single DNS answer. When
124 DNSSEC [RFC4033] is deployed on such DNS clients, validation requires
125 that the client obtain all the intermediate information from the DNS
126 root down to the queried-for host name, so it can perform DNSSEC
127 validation on the complete chain of trust.
129 Currently, applications send out many UDP requests concurrently.
130 This requires more resources on the DNS client with respect to state
131 (CPU, memory, battery) and bandwidth. There is also no guarantee
132 that the initial set of UDP questions will result in all the records
133 required for DNSSEC validation. More round trips could be required
134 depending on the resulting DNS answers. This especially affects
137 This document specifies an EDNS0 extension that allows a validating
138 resolver running as a forwarding resolver to open a TCP connection to
139 another resolver and request a DNS chain answer using one DNS query/
140 answer pair. This reduces the number of round trips to two. If
141 combined with long-lived TCP or [RFC7828], there is only one round
142 trip. While the upstream resolver still needs to perform all the
143 individual queries required for the complete answer, it usually has a
144 much bigger cache and does not experience significant slowdown from
147 This EDNS0 extension allows the forwarding resolver to indicate which
148 part of the DNS hierarchy it already contains in its cache. This
149 reduces the amount of data required to be transferred and reduces the
150 work the upstream recursive resolver has to perform.
152 This EDNS0 extension is only intended to be sent by forwarding
153 resolvers to recursive resolvers. It MUST be ignored by
154 authoritative servers.
1561.1. Requirements Notation
158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
160 document are to be interpreted as described in [RFC2119].
170Wouters Experimental [Page 3]
172RFC 7901 CHAIN Query Requests in DNS June 2016
177 The DNS terminology used in this document is that of [RFC7719].
178 Additionally, the following terms are used:
180 Forwarding Resolver: A nameserver that does not do iterative
181 resolution itself; instead, it passes that responsibility to
182 another recursive resolver, called a "forwarder" in [RFC2308],
185 Recursive Resolver: A nameserver that is responsible for resolving
186 domain names for clients by following the domain's delegation
187 chain, starting at the root. Recursive resolvers frequently use
188 caches to be able to respond to client queries quickly, as
189 described in [RFC1035], Section 7.
191 Validating Resolver: A recursive nameserver that also performs
192 DNSSEC [RFC4033] validation. Also known as "security-aware
197 When DNSSEC is deployed on a host, it can no longer delegate all DNS
198 work to the upstream recursive resolver. Obtaining just the DNS
199 answer itself is not enough to validate that answer using DNSSEC.
200 For DNSSEC validation, the DNS client requires a locally running
201 validating resolver, so it can confirm DNSSEC validation of all
202 intermediary DNS answers. It can configure itself as a forwarding
203 resolver if it obtains the IP addresses of one or more recursive
204 resolvers that are available or as a stand-alone recursive resolver
205 if no functional recursive resolvers were obtained. Generating the
206 required queries for validation adds a significant delay in answering
207 the DNS question of the locally running application. The application
208 must wait while the resolver validates all intermediate answers.
209 Each round trip adds to the total time waiting on DNS resolution with
210 validation to complete. This makes DNSSEC resolving impractical for
211 devices on networks with a high latency.
213 This document defines the CHAIN option that allows the resolver to
214 request all intermediate DNS data it requires to resolve and validate
215 a particular DNS answer in a single round trip. The resolver could
216 be part of the application or a recursive resolver running on the
219 Servers answering with CHAIN data should ensure that the peer's IP
220 address is not a spoofed source IP address. See Section 7. This
221 prevents DNS amplification attacks.
226Wouters Experimental [Page 4]
228RFC 7901 CHAIN Query Requests in DNS June 2016
231 Applications that support CHAIN internally can perform validation
232 without requiring the host to run a recursive resolver. This is
233 particularly useful for virtual servers in a cloud or container-based
234 deployment where it is undesirable to run a recursive resolver per
237 The format of this option is described in Section 4.
239 As described in Section 5.4, a recursive resolver can use this EDNS0
240 option to include additional data required by the resolver in the
241 Authority Section of the DNS answer packet. The Answer
242 Section remains unchanged from a traditional DNS answer and contains
243 the answer and related DNSSEC entries.
245 An empty CHAIN EDNS0 option MAY be sent over any transport as a
246 discovery method. A DNS server receiving such an empty CHAIN option
247 SHOULD add an empty CHAIN option in its answer to indicate that it
248 supports the CHAIN option.
250 The mechanisms provided by CHAIN raise various security concerns
251 related to the additional work, bandwidth, amplification attacks, and
252 privacy issues with the cache. These concerns are described in
257 This document uses an EDNS0 option [RFC6891] to include client IP
258 information in DNS messages. The option is structured as follows:
261 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
262 +-------------------------------+-------------------------------+
263 ! OPTION-CODE ! OPTION-LENGTH !
264 +-------------------------------+-------------------------------+
265 ~ Closest Trust Point (FQDN) ~
266 +---------------------------------------------------------------+
268 o OPTION-CODE, 2 octets, for CHAIN is 13.
270 o OPTION-LENGTH, 2 octets, contains the length of the payload
271 (everything after Option-length) in octets.
273 o Closest trust point, a variable-length Fully-Qualified Domain Name
274 (FQDN) in DNS wire format of the requested start point of the
275 chain. This entry is the "lowest" known entry in the DNS chain
276 known by the recursive server seeking a CHAIN answer for which it
277 has a validated Delegation Signer (DS) and DNSKEY record. The
282Wouters Experimental [Page 5]
284RFC 7901 CHAIN Query Requests in DNS June 2016
287 endpoint of the chain is obtained from the DNS Query
288 Section itself. No DNS name compression is allowed for this
2915. Protocol Description
2935.1. Discovery of Support
295 A forwarding resolver may include a zero-length CHAIN option in a
296 regular query over any transport to discover the DNS server
297 capability for CHAIN. Recursive resolvers that support and are
298 willing to accept CHAIN queries over source IP verified transport
299 respond to a zero-length CHAIN received by including a zero-length
300 CHAIN option in the answer. If not already using a source-IP-
301 verified transport, the forwarding resolver MAY then switch to a
302 source-IP-verified transport and start sending queries with the CHAIN
303 option to request a CHAIN response from the recursive resolver.
304 Examples of source-IP-verified transports are the three-way TCP
305 handshake and UDP with DNS cookies [RFC7873].
309 In this option value, the forwarding resolver sets the closest trust
310 point in the chain -- furthest from the root -- that it already has a
311 DNSSEC-validated (secure or not) answer for in its cache. The
312 upstream recursive resolver does not need to include any part of the
313 chain from the root down to this option's FQDN. A complete example
314 is described in Section 8.1.
316 The CHAIN option should generally be sent by system forwarding
317 resolvers and resolvers within an application that also performs
322 When CHAIN is available, the downstream recursive resolver can adjust
323 its query strategy based on the desired queries and its cache
326 A forwarding resolver can request the CHAIN option with every
327 outgoing DNS query. However, it is RECOMMENDED that forwarding
328 resolvers remember which upstream recursive resolvers did not return
329 the option (and additional data) with their response. The forwarding
330 resolver SHOULD fall back to regular DNS for subsequent queries to
331 those recursive resolvers. It MAY switch to another recursive
332 resolver that does support the CHAIN option or try again later to see
333 if the server has become less loaded and is now willing to answer
334 with CHAIN queries. A fallback strategy similar to that described in
338Wouters Experimental [Page 6]
340RFC 7901 CHAIN Query Requests in DNS June 2016
343 [RFC6891], Section 6.2.2 SHOULD be employed to avoid persistent
344 interference due to non-clean paths.
3465.4. Generate a Response
348 When a query containing a non-zero CHAIN option is received from a
349 forwarding resolver, the upstream recursive resolver supporting CHAIN
350 MAY respond by confirming that it is returning a CHAIN. To do so, it
351 MUST set the CHAIN option to the lowest trust point sent as part of
352 the chain, with its corresponding OPTION-LENGTH. It extends the
353 Authority Section in the DNS answer packet with the DNS RRsets
354 required for validating the answer. The added DNS RRsets start with
355 the first chain element below the received closest trust point up to
356 and including the NS and DS RRsets that represent the zone cut
357 (authoritative servers) of the QNAME. The added RRsets MAY be added
358 in matching hierarchical order, but a DNS client MUST NOT depend on
359 the order of the added RRsets for validation. The actual DNS answer
360 to the question in the Query Section is placed in the DNS Answer
361 Section identical to the traditional DNS answer. All required
362 DNSSEC-related records must be added to their appropriate sections.
363 This includes records required for proof of nonexistence of regular
364 and/or wildcard records, such as NextSECure (NSEC) or NSEC3 records.
366 Recursive resolvers that have not implemented or enabled support for
367 the CHAIN option, or are otherwise unwilling to perform the
368 additional work for a CHAIN query due to workload, may safely ignore
369 the option in the incoming queries. Such a server MUST NOT include a
370 CHAIN option when sending DNS answer replies back, thus indicating it
371 is not able or willing to support CHAIN queries at this time.
373 Requests with wrongly formatted options (i.e., bogus FQDN) MUST be
374 rejected; a FORMERR response must be returned to the sender, as
375 described by [RFC6891].
377 Requests resulting in chains that the receiving resolver is unwilling
378 to serve can be rejected by answering the query as a regular DNS
379 reply but with an empty CHAIN payload. Replying with an empty CHAIN
380 can be used for chains that would be too big or for chains that would
381 reveal too much information considered private.
383 At any time, a recursive resolver that has determined that it is
384 running low on resources can refuse CHAIN queries by replying with a
385 regular DNS reply with an empty CHAIN payload.
387 If a CHAIN answer would be bigger than the recursive resolver is
388 willing to serve, it SHOULD send a partial chain starting with the
389 data closest to the top of the chain. The client MAY resend the
390 query with an updated closest trust point until it has received the
394Wouters Experimental [Page 7]
396RFC 7901 CHAIN Query Requests in DNS June 2016
399 full chain. The CHAIN response will contain the lowest closest trust
400 point that was included in the CHAIN answer.
402 If the DNS request results in a CNAME or DNAME for the Answer
403 Section, the recursive resolver MUST return these records in the
404 Answer Section similar to regular DNS processing. The CNAME or DNAME
405 target MAY be placed in the Additional Section only if all supporting
406 records for DNSSEC validation of the CNAME or DNAME target are also
407 added to the Authority Section.
409 The response from a recursive resolver to a resolver MUST NOT contain
410 the CHAIN option if none was present in the resolver's original
413 A DNS query that contains the CHAIN option MUST also have the "DNSSEC
414 OK" (DO) bit set. If this bit is not set, or if the "Checking
415 Disabled" (CD) bit is set, the CHAIN option received MUST be ignored.
4176. Protocol Considerations
4196.1. DNSSEC Considerations
421 The presence or absence of an OPT resource record containing a CHAIN
422 option in a DNS query does not change the usage of those resource
423 records and mechanisms used to provide data origin authentication and
424 data integrity to the DNS, as described in [RFC4033], [RFC4034], and
4276.2. NS Record Considerations
429 CHAIN responses SHOULD include the authoritative NS RRset with its
430 RRSIG records required for validation. It MUST NOT include the NS
431 RRset from the parent zone, as this RRset is not signed. If the size
432 of the answer is an important factor, the NS RRset MAY be omitted.
434 When a DNSSEC chain is supplied via CHAIN, the forwarding resolver is
435 no longer required to use the NS RRset, as it can construct the
436 validation path via the DNSKEY and DS RRsets without using the NS
437 RRset. However, the forwarding resolver might be forced to switch
438 from forwarding resolver mode to recursive resolver mode due to a
439 network topology change. In recursive resolver mode, the NS RRsets
440 are needed to find and query authoritative servers directly. It is
441 RECOMMENDED that the DNS forwarding resolver populate its cache with
442 this information to avoid requiring future queries to obtain any
443 missing NS records. Therefore, CHAIN responses MUST include the NS
444 RRset from the child zone, including the RRSIG records required for
450Wouters Experimental [Page 8]
452RFC 7901 CHAIN Query Requests in DNS June 2016
4556.3. Session Management
457 The use of TCP keepalive [RFC7828] on DNS TCP sessions is
458 RECOMMENDED; thus, TCP sessions should not immediately be closed
459 after the DNS answer to the first query is received.
461 Both DNS clients and servers are subject to resource constraints that
462 will limit the extent to which CHAIN queries can be executed.
463 Effective limits for the number of active sessions that can be
464 maintained on individual clients and servers should be established
465 either as configuration options or by interrogation of process limits
466 imposed by the operating system.
468 In the event that there is greater demand for CHAIN queries than can
469 be accommodated, DNS servers may stop advertising the CHAIN option in
470 successive DNS messages. This allows, for example, clients with
471 other candidate servers to query to establish new sessions with
472 different servers in expectation that those servers might still allow
4756.4. Negative Trust Anchors
477 If a CHAIN answer would intersect with a negative trust anchor
478 [RFC7646], a partial CHAIN up to the node above the negative trust
479 anchor should be returned.
4816.5. Anycast Considerations
483 Recursive resolvers of various types are commonly deployed using
486 Successive DNS transactions between a client and server using UDP
487 transport may involve responses generated by different anycast nodes,
488 and the use of anycast in the implementation of a DNS server is
489 effectively undetectable by the client. The CHAIN option SHOULD NOT
490 be included in responses using UDP transport from servers provisioned
491 using anycast unless all anycast server nodes are capable of
492 processing the CHAIN option.
494 Since DNS queries using CHAIN may result in longer TCP sessions,
495 network topology changes may disrupt them more frequently. Anycast
496 servers MAY make use of Multipath TCP [RFC6824] to anchor the server
497 side of the TCP connection to an unambiguously unicast address in
498 order to avoid disruption due to topology changes.
506Wouters Experimental [Page 9]
508RFC 7901 CHAIN Query Requests in DNS June 2016
5117. Security Considerations
5137.1. Additional Work and Bandwidth
515 Producing CHAIN answers incurs additional load and bandwidth on the
516 recursive resolver. At any time, a recursive resolver may decide to
517 no longer answer with CHAIN answers and fall back to traditional DNS
5207.2. Amplification Attacks
522 CHAIN queries can potentially send very large DNS answers. Attackers
523 could abuse this using spoofed source IP addresses to inflict large
524 distributed denial-of-service attacks using CHAINS as an
525 amplification vector in their attack. While TCP is not vulnerable
526 for this type of abuse, the UDP protocol is vulnerable to this.
528 A recursive resolver MUST NOT return CHAIN answers to clients over
529 UDP without source IP address verification. An example of UDP-based
530 source IP address verification is [RFC7873]. A recursive resolver
531 refusing a CHAIN option MUST respond with a zero-length CHAIN option
532 to indicate support for CHAIN queries when a proper transport is
533 used. It MUST NOT send an RCODE of REFUSED.
5357.3. Privacy Considerations
537 A client producing CHAIN queries reveals a little more information
538 about its cache contents than regular DNS clients. This could be
539 used to fingerprint a client across network reconnections. If DNS
540 privacy is a concern, a CHAIN query client MAY try to use a DNS
541 transport that provides privacy, such as [RFC7858] or a trusted DNS
542 server that is contacted through a VPN connection such as IPsec.
5468.1. CHAIN Query for "www.example.com"
548 o A web browser on a client machine asks the forwarding resolver
549 running on the local host to resolve the A record of
550 "www.example.com." by sending a regular DNS UDP query on port 53
553 o The resolver on the client machine checks its cache and notices it
554 already has a DNSSEC-validated entry of "com." in its cache. This
555 includes the DNSKEY RRset with its RRSIG records. In other words,
556 according to its cache, ".com" is DNSSEC validated as "secure" and
557 can be used to continue a DNSSEC-validated chain.
562Wouters Experimental [Page 10]
564RFC 7901 CHAIN Query Requests in DNS June 2016
567 o The resolver on the client opens a TCP connection to its upstream
568 recursive resolver on port 53. It adds the CHAIN option as
571 * Option-code, set to 13
573 * Option-length, set to 5
575 * Closest trust point set to "com." (0x03 0x63 0x6f 0x6d 0x00)
577 o The upstream recursive resolver receives a DNS query over TCP with
578 the CHAIN closest trust point set to "com.". After accepting the
579 query, it starts constructing a DNS reply packet.
581 o The upstream recursive resolver performs all the regular work to
582 ensure it has all the answers to the query for the A record of
583 "www.example.com.". It does so without using the CHAIN option --
584 unless it is also configured as a forwarding resolver. The answer
585 to the original DNS question could be the actual A record, the
586 DNSSEC proof of nonexistence, or an insecure NXDOMAIN response.
588 o The upstream recursive resolver adds the CHAIN option to the DNS
591 * Option-code, set to 13
593 * Option-length, set to 5
595 * The closest trust point is set to "com." (0x03 0x63 0x6f 0x6d
598 o The upstream recursive resolver constructs the DNS Authority
599 Section and fills it (in any order) with:
601 * The DS RRset for "example.com." and its corresponding RRSIGs
602 (made by the "com." DNSKEY(s))
604 * The DNSKEY RRset for "example.com." and its corresponding
605 RRSIGs (made by the "example.com." DNSKEY(s))
607 * The authoritative NS RRset for "example.com." and its
608 corresponding RRSIGs (from the child zone)
610 If the answer does not exist, and the zone uses DNSSEC, it also
611 adds the proof of nonexistence, such as NSEC or NSEC3 records, to
612 the Authority Section.
618Wouters Experimental [Page 11]
620RFC 7901 CHAIN Query Requests in DNS June 2016
623 o The upstream recursive resolver constructs the DNS Answer section
626 * The A record of "www.example.com." and its corresponding
629 If the answer does not exist (NODATA or NXDOMAIN), the Answer
630 Section remains empty. For the NXDOMAIN case, the RCODE of the
631 DNS answer packet is set to NXDOMAIN. Otherwise, it remains as
634 o The upstream recursive resolver returns the DNS answer over the
635 existing TCP connection. When all data is sent, it SHOULD keep
636 the TCP connection open to allow for additional incoming DNS
637 queries -- provided it has enough resources to do so.
639 o The resolver on the client receives the DNS answer. It processes
640 the Authority and the Answer Sections and places the information
641 in its local cache. It ensures that no data is accepted into the
642 cache without having proper DNSSEC validation. It MAY do so by
643 looping over the entries in the Authority and Answer Sections.
644 When an entry is validated for its cache, it is removed from the
645 processing list. If an entry cannot be validated, it is left in
646 the process list. When the end of the list is reached, the list
647 is processed again until either all entries are placed in the
648 cache or the remaining items cannot be placed in the cache due to
649 lack of validation. Those entries are then discarded.
651 o If the cache contains a valid answer to the application's query,
652 this answer is returned to the application via a regular DNS
653 answer packet. This packet MUST NOT contain a CHAIN option. If
654 no valid answer can be returned, normal error processing is done.
655 For example, an NXDOMAIN or an empty Answer Section could be
656 returned depending on the error condition.
6588.2. Out-of-Path Query for "example.com"
660 A recursive resolver receives a query for the A record for
661 "example.com". It includes the CHAIN option with the following
664 o Option-code, set to 13
666 o Option-length, set to 14
668 o The closest trust point set to "unrelated.ca." (0x09 0x75 0x6e
669 0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00)
674Wouters Experimental [Page 12]
676RFC 7901 CHAIN Query Requests in DNS June 2016
679 As there is no chain that leads from "unrelated.ca." to
680 "example.com.", the resolving nameserver answers with an empty CHAIN
683 o Option-code, set to 13
685 o Option-length, set to 0x00 0x00
687 o The closest trust point is omitted (zero length)
689 Note that the regular answer is still present just as it would be for
690 a query that did not specify the CHAIN option.
694 A recursive resolver receives a query for the A record for
695 "ipv6.toronto.redhat.ca". It includes the CHAIN option with the
696 following parameters:
698 o Option-code, set to 13
700 o Option-length, set to 0x00 0x03
702 o The closest trust point set to "ca."
704 Using regular UDP queries towards authoritative nameservers, it
705 locates the NS RRset for "toronto.redhat.ca.". When querying for the
706 A record, it receives a reply with RCODE "NoError" and an empty
707 Answer Section. The Authority Section contains NSEC3 and RRSIG
708 records proving there is no A RRTYPE for the QNAME
709 "ipv6.toronto.redhat.ca".
711 The recursive resolver constructs a DNS reply with the following
712 CHAIN option parameters:
714 o Option-code, set to 13
716 o Option-length, set to 0x00 0x00
718 o The closest trust point is omitted (zero length)
720 The RCODE is set to "NoError". The Authority Section is filled in
723 o The DS RRset for "redhat.ca." plus RRSIGs
725 o The DNSKEY RRset for "redhat.ca." plus RRSIGs
730Wouters Experimental [Page 13]
732RFC 7901 CHAIN Query Requests in DNS June 2016
735 o The NS RRset for "redhat.ca." plus RRSIGs (e.g., ns[01].redhat.ca)
737 o The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs
739 o The DS RRset for "toronto.redhat.ca." plus RRSIGs
741 o The NS RRset for "toronto.redhat.ca." plus RRSIGs (e.g.,
742 ns[01].toronto.redhat.ca)
744 o The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs
746 o The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and
747 "ns1.toronto.redhat.ca." plus RRSIGs
749 o The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs
750 do exist; does not include A)
752 o The NSEC record for "toronto.redhat.ca." (proves no wildcard
755 The Answer Section is empty. The RCODE is set to NOERROR.
7579. IANA Considerations
7599.1. EDNS0 Option Code for CHAIN
761 IANA has assigned option code 13 in the "DNS EDNS0 Option Codes
762 (OPT)" registry to CHAIN.
76410. Normative References
766 [RFC1035] Mockapetris, P., "Domain names - implementation and
767 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
768 November 1987, <http://www.rfc-editor.org/info/rfc1035>.
770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
771 Requirement Levels", BCP 14, RFC 2119,
772 DOI 10.17487/RFC2119, March 1997,
773 <http://www.rfc-editor.org/info/rfc2119>.
775 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
776 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
777 <http://www.rfc-editor.org/info/rfc2308>.
779 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
780 Rose, "DNS Security Introduction and Requirements",
781 RFC 4033, DOI 10.17487/RFC4033, March 2005,
782 <http://www.rfc-editor.org/info/rfc4033>.
786Wouters Experimental [Page 14]
788RFC 7901 CHAIN Query Requests in DNS June 2016
791 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
792 Rose, "Resource Records for the DNS Security Extensions",
793 RFC 4034, DOI 10.17487/RFC4034, March 2005,
794 <http://www.rfc-editor.org/info/rfc4034>.
796 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
797 Rose, "Protocol Modifications for the DNS Security
798 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
799 <http://www.rfc-editor.org/info/rfc4035>.
801 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
802 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
803 December 2006, <http://www.rfc-editor.org/info/rfc4786>.
805 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
806 "TCP Extensions for Multipath Operation with Multiple
807 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
808 <http://www.rfc-editor.org/info/rfc6824>.
810 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
811 for DNS (EDNS(0))", STD 75, RFC 6891,
812 DOI 10.17487/RFC6891, April 2013,
813 <http://www.rfc-editor.org/info/rfc6891>.
815 [RFC7646] Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
816 and R. Weber, "Definition and Use of DNSSEC Negative Trust
817 Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
818 <http://www.rfc-editor.org/info/rfc7646>.
820 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
821 Terminology", RFC 7719, DOI 10.17487/RFC7719, December
822 2015, <http://www.rfc-editor.org/info/rfc7719>.
824 [RFC7828] Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
825 edns-tcp-keepalive EDNS0 Option", RFC 7828,
826 DOI 10.17487/RFC7828, April 2016,
827 <http://www.rfc-editor.org/info/rfc7828>.
829 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
830 and P. Hoffman, "Specification for DNS over Transport
831 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
832 2016, <http://www.rfc-editor.org/info/rfc7858>.
834 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
835 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
836 <http://www.rfc-editor.org/info/rfc7873>.
842Wouters Experimental [Page 15]
844RFC 7901 CHAIN Query Requests in DNS June 2016
849 Andrew Sullivan pointed out that we do not need any new data formats
850 to support DNS chains. Olafur Gudmundsson ensured the RRsets are
851 returned in the proper sections. Thanks to Tim Wicinski for his
859 Email: pwouters@redhat.com
898Wouters Experimental [Page 16]