doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7901.txt b/doc/rfc/rfc7901.txt
new file mode 100644
index 0000000..2f9da19
--- /dev/null
+++ b/doc/rfc/rfc7901.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        P. Wouters
+Request for Comments: 7901                                       Red Hat
+Category: Experimental                                         June 2016
+ISSN: 2070-1721
+
+
+                      CHAIN Query Requests in DNS
+
+Abstract
+
+   This document defines an EDNS0 extension that can be used by a
+   security-aware validating resolver configured to use a forwarding
+   resolver to send a single query, requesting a complete validation
+   path along with the regular query answer.  The reduction in queries
+   potentially lowers the latency and reduces the need to send multiple
+   queries at once.  This extension mandates the use of source-IP-
+   verified transport such as TCP or UDP with EDNS-COOKIE, so it cannot
+   be abused in amplification attacks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7901.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wouters                       Experimental                      [Page 1]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
+   4.  Option Format . . . . . . . . . . . . . . . . . . . . . . . .   5
+   5.  Protocol Description  . . . . . . . . . . . . . . . . . . . .   6
+     5.1.  Discovery of Support  . . . . . . . . . . . . . . . . . .   6
+     5.2.  Generate a Query  . . . . . . . . . . . . . . . . . . . .   6
+     5.3.  Send the Option . . . . . . . . . . . . . . . . . . . . .   6
+     5.4.  Generate a Response . . . . . . . . . . . . . . . . . . .   7
+   6.  Protocol Considerations . . . . . . . . . . . . . . . . . . .   8
+     6.1.  DNSSEC Considerations . . . . . . . . . . . . . . . . . .   8
+     6.2.  NS Record Considerations  . . . . . . . . . . . . . . . .   8
+     6.3.  Session Management  . . . . . . . . . . . . . . . . . . .   9
+     6.4.  Negative Trust Anchors  . . . . . . . . . . . . . . . . .   9
+     6.5.  Anycast Considerations  . . . . . . . . . . . . . . . . .   9
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
+     7.1.  Additional Work and Bandwidth . . . . . . . . . . . . . .  10
+     7.2.  Amplification Attacks . . . . . . . . . . . . . . . . . .  10
+     7.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  10
+   8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     8.1.  CHAIN Query for "www.example.com" . . . . . . . . . . . .  10
+     8.2.  Out-of-Path Query for "example.com" . . . . . . . . . . .  12
+     8.3.  Nonexistent Data  . . . . . . . . . . . . . . . . . . . .  13
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
+     9.1.  EDNS0 Option Code for CHAIN . . . . . . . . . . . . . . .  14
+   10. Normative References  . . . . . . . . . . . . . . . . . . . .  14
+   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  16
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16
+
+
+
+
+
+Wouters                       Experimental                      [Page 2]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+1.  Introduction
+
+   Traditionally, a DNS client operates in stub mode.  For each DNS
+   question the DNS client needs to resolve, it sends a single query to
+   an upstream recursive resolver to obtain a single DNS answer.  When
+   DNSSEC [RFC4033] is deployed on such DNS clients, validation requires
+   that the client obtain all the intermediate information from the DNS
+   root down to the queried-for host name, so it can perform DNSSEC
+   validation on the complete chain of trust.
+
+   Currently, applications send out many UDP requests concurrently.
+   This requires more resources on the DNS client with respect to state
+   (CPU, memory, battery) and bandwidth.  There is also no guarantee
+   that the initial set of UDP questions will result in all the records
+   required for DNSSEC validation.  More round trips could be required
+   depending on the resulting DNS answers.  This especially affects
+   high-latency links.
+
+   This document specifies an EDNS0 extension that allows a validating
+   resolver running as a forwarding resolver to open a TCP connection to
+   another resolver and request a DNS chain answer using one DNS query/
+   answer pair.  This reduces the number of round trips to two.  If
+   combined with long-lived TCP or [RFC7828], there is only one round
+   trip.  While the upstream resolver still needs to perform all the
+   individual queries required for the complete answer, it usually has a
+   much bigger cache and does not experience significant slowdown from
+   last-mile latency.
+
+   This EDNS0 extension allows the forwarding resolver to indicate which
+   part of the DNS hierarchy it already contains in its cache.  This
+   reduces the amount of data required to be transferred and reduces the
+   work the upstream recursive resolver has to perform.
+
+   This EDNS0 extension is only intended to be sent by forwarding
+   resolvers to recursive resolvers.  It MUST be ignored by
+   authoritative servers.
+
+1.1.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+
+
+Wouters                       Experimental                      [Page 3]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+2.  Terminology
+
+   The DNS terminology used in this document is that of [RFC7719].
+   Additionally, the following terms are used:
+
+   Forwarding Resolver:  A nameserver that does not do iterative
+      resolution itself; instead, it passes that responsibility to
+      another recursive resolver, called a "forwarder" in [RFC2308],
+      Section 1.
+
+   Recursive Resolver:  A nameserver that is responsible for resolving
+      domain names for clients by following the domain's delegation
+      chain, starting at the root.  Recursive resolvers frequently use
+      caches to be able to respond to client queries quickly, as
+      described in [RFC1035], Section 7.
+
+   Validating Resolver:  A recursive nameserver that also performs
+      DNSSEC [RFC4033] validation.  Also known as "security-aware
+      resolver".
+
+3.  Overview
+
+   When DNSSEC is deployed on a host, it can no longer delegate all DNS
+   work to the upstream recursive resolver.  Obtaining just the DNS
+   answer itself is not enough to validate that answer using DNSSEC.
+   For DNSSEC validation, the DNS client requires a locally running
+   validating resolver, so it can confirm DNSSEC validation of all
+   intermediary DNS answers.  It can configure itself as a forwarding
+   resolver if it obtains the IP addresses of one or more recursive
+   resolvers that are available or as a stand-alone recursive resolver
+   if no functional recursive resolvers were obtained.  Generating the
+   required queries for validation adds a significant delay in answering
+   the DNS question of the locally running application.  The application
+   must wait while the resolver validates all intermediate answers.
+   Each round trip adds to the total time waiting on DNS resolution with
+   validation to complete.  This makes DNSSEC resolving impractical for
+   devices on networks with a high latency.
+
+   This document defines the CHAIN option that allows the resolver to
+   request all intermediate DNS data it requires to resolve and validate
+   a particular DNS answer in a single round trip.  The resolver could
+   be part of the application or a recursive resolver running on the
+   host.
+
+   Servers answering with CHAIN data should ensure that the peer's IP
+   address is not a spoofed source IP address.  See Section 7.  This
+   prevents DNS amplification attacks.
+
+
+
+
+Wouters                       Experimental                      [Page 4]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+   Applications that support CHAIN internally can perform validation
+   without requiring the host to run a recursive resolver.  This is
+   particularly useful for virtual servers in a cloud or container-based
+   deployment where it is undesirable to run a recursive resolver per
+   virtual machine.
+
+   The format of this option is described in Section 4.
+
+   As described in Section 5.4, a recursive resolver can use this EDNS0
+   option to include additional data required by the resolver in the
+   Authority Section of the DNS answer packet.  The Answer
+   Section remains unchanged from a traditional DNS answer and contains
+   the answer and related DNSSEC entries.
+
+   An empty CHAIN EDNS0 option MAY be sent over any transport as a
+   discovery method.  A DNS server receiving such an empty CHAIN option
+   SHOULD add an empty CHAIN option in its answer to indicate that it
+   supports the CHAIN option.
+
+   The mechanisms provided by CHAIN raise various security concerns
+   related to the additional work, bandwidth, amplification attacks, and
+   privacy issues with the cache.  These concerns are described in
+   Section 7.
+
+4.  Option Format
+
+   This document uses an EDNS0 option [RFC6891] to include client IP
+   information in DNS messages.  The option is structured as follows:
+
+                        1                   2                   3
+    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
+   +-------------------------------+-------------------------------+
+   !         OPTION-CODE           !         OPTION-LENGTH         !
+   +-------------------------------+-------------------------------+
+   ~                Closest Trust Point (FQDN)                     ~
+   +---------------------------------------------------------------+
+
+   o  OPTION-CODE, 2 octets, for CHAIN is 13.
+
+   o  OPTION-LENGTH, 2 octets, contains the length of the payload
+      (everything after Option-length) in octets.
+
+   o  Closest trust point, a variable-length Fully-Qualified Domain Name
+      (FQDN) in DNS wire format of the requested start point of the
+      chain.  This entry is the "lowest" known entry in the DNS chain
+      known by the recursive server seeking a CHAIN answer for which it
+      has a validated Delegation Signer (DS) and DNSKEY record.  The
+
+
+
+
+Wouters                       Experimental                      [Page 5]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+      endpoint of the chain is obtained from the DNS Query
+      Section itself.  No DNS name compression is allowed for this
+      value.
+
+5.  Protocol Description
+
+5.1.  Discovery of Support
+
+   A forwarding resolver may include a zero-length CHAIN option in a
+   regular query over any transport to discover the DNS server
+   capability for CHAIN.  Recursive resolvers that support and are
+   willing to accept CHAIN queries over source IP verified transport
+   respond to a zero-length CHAIN received by including a zero-length
+   CHAIN option in the answer.  If not already using a source-IP-
+   verified transport, the forwarding resolver MAY then switch to a
+   source-IP-verified transport and start sending queries with the CHAIN
+   option to request a CHAIN response from the recursive resolver.
+   Examples of source-IP-verified transports are the three-way TCP
+   handshake and UDP with DNS cookies [RFC7873].
+
+5.2.  Generate a Query
+
+   In this option value, the forwarding resolver sets the closest trust
+   point in the chain -- furthest from the root -- that it already has a
+   DNSSEC-validated (secure or not) answer for in its cache.  The
+   upstream recursive resolver does not need to include any part of the
+   chain from the root down to this option's FQDN.  A complete example
+   is described in Section 8.1.
+
+   The CHAIN option should generally be sent by system forwarding
+   resolvers and resolvers within an application that also performs
+   DNSSEC validation.
+
+5.3.  Send the Option
+
+   When CHAIN is available, the downstream recursive resolver can adjust
+   its query strategy based on the desired queries and its cache
+   contents.
+
+   A forwarding resolver can request the CHAIN option with every
+   outgoing DNS query.  However, it is RECOMMENDED that forwarding
+   resolvers remember which upstream recursive resolvers did not return
+   the option (and additional data) with their response.  The forwarding
+   resolver SHOULD fall back to regular DNS for subsequent queries to
+   those recursive resolvers.  It MAY switch to another recursive
+   resolver that does support the CHAIN option or try again later to see
+   if the server has become less loaded and is now willing to answer
+   with CHAIN queries.  A fallback strategy similar to that described in
+
+
+
+Wouters                       Experimental                      [Page 6]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+   [RFC6891], Section 6.2.2 SHOULD be employed to avoid persistent
+   interference due to non-clean paths.
+
+5.4.  Generate a Response
+
+   When a query containing a non-zero CHAIN option is received from a
+   forwarding resolver, the upstream recursive resolver supporting CHAIN
+   MAY respond by confirming that it is returning a CHAIN.  To do so, it
+   MUST set the CHAIN option to the lowest trust point sent as part of
+   the chain, with its corresponding OPTION-LENGTH.  It extends the
+   Authority Section in the DNS answer packet with the DNS RRsets
+   required for validating the answer.  The added DNS RRsets start with
+   the first chain element below the received closest trust point up to
+   and including the NS and DS RRsets that represent the zone cut
+   (authoritative servers) of the QNAME.  The added RRsets MAY be added
+   in matching hierarchical order, but a DNS client MUST NOT depend on
+   the order of the added RRsets for validation.  The actual DNS answer
+   to the question in the Query Section is placed in the DNS Answer
+   Section identical to the traditional DNS answer.  All required
+   DNSSEC-related records must be added to their appropriate sections.
+   This includes records required for proof of nonexistence of regular
+   and/or wildcard records, such as NextSECure (NSEC) or NSEC3 records.
+
+   Recursive resolvers that have not implemented or enabled support for
+   the CHAIN option, or are otherwise unwilling to perform the
+   additional work for a CHAIN query due to workload, may safely ignore
+   the option in the incoming queries.  Such a server MUST NOT include a
+   CHAIN option when sending DNS answer replies back, thus indicating it
+   is not able or willing to support CHAIN queries at this time.
+
+   Requests with wrongly formatted options (i.e., bogus FQDN) MUST be
+   rejected; a FORMERR response must be returned to the sender, as
+   described by [RFC6891].
+
+   Requests resulting in chains that the receiving resolver is unwilling
+   to serve can be rejected by answering the query as a regular DNS
+   reply but with an empty CHAIN payload.  Replying with an empty CHAIN
+   can be used for chains that would be too big or for chains that would
+   reveal too much information considered private.
+
+   At any time, a recursive resolver that has determined that it is
+   running low on resources can refuse CHAIN queries by replying with a
+   regular DNS reply with an empty CHAIN payload.
+
+   If a CHAIN answer would be bigger than the recursive resolver is
+   willing to serve, it SHOULD send a partial chain starting with the
+   data closest to the top of the chain.  The client MAY resend the
+   query with an updated closest trust point until it has received the
+
+
+
+Wouters                       Experimental                      [Page 7]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+   full chain.  The CHAIN response will contain the lowest closest trust
+   point that was included in the CHAIN answer.
+
+   If the DNS request results in a CNAME or DNAME for the Answer
+   Section, the recursive resolver MUST return these records in the
+   Answer Section similar to regular DNS processing.  The CNAME or DNAME
+   target MAY be placed in the Additional Section only if all supporting
+   records for DNSSEC validation of the CNAME or DNAME target are also
+   added to the Authority Section.
+
+   The response from a recursive resolver to a resolver MUST NOT contain
+   the CHAIN option if none was present in the resolver's original
+   request.
+
+   A DNS query that contains the CHAIN option MUST also have the "DNSSEC
+   OK" (DO) bit set.  If this bit is not set, or if the "Checking
+   Disabled" (CD) bit is set, the CHAIN option received MUST be ignored.
+
+6.  Protocol Considerations
+
+6.1.  DNSSEC Considerations
+
+   The presence or absence of an OPT resource record containing a CHAIN
+   option in a DNS query does not change the usage of those resource
+   records and mechanisms used to provide data origin authentication and
+   data integrity to the DNS, as described in [RFC4033], [RFC4034], and
+   [RFC4035].
+
+6.2.  NS Record Considerations
+
+   CHAIN responses SHOULD include the authoritative NS RRset with its
+   RRSIG records required for validation.  It MUST NOT include the NS
+   RRset from the parent zone, as this RRset is not signed.  If the size
+   of the answer is an important factor, the NS RRset MAY be omitted.
+
+   When a DNSSEC chain is supplied via CHAIN, the forwarding resolver is
+   no longer required to use the NS RRset, as it can construct the
+   validation path via the DNSKEY and DS RRsets without using the NS
+   RRset.  However, the forwarding resolver might be forced to switch
+   from forwarding resolver mode to recursive resolver mode due to a
+   network topology change.  In recursive resolver mode, the NS RRsets
+   are needed to find and query authoritative servers directly.  It is
+   RECOMMENDED that the DNS forwarding resolver populate its cache with
+   this information to avoid requiring future queries to obtain any
+   missing NS records.  Therefore, CHAIN responses MUST include the NS
+   RRset from the child zone, including the RRSIG records required for
+   validation.
+
+
+
+
+Wouters                       Experimental                      [Page 8]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+6.3.  Session Management
+
+   The use of TCP keepalive [RFC7828] on DNS TCP sessions is
+   RECOMMENDED; thus, TCP sessions should not immediately be closed
+   after the DNS answer to the first query is received.
+
+   Both DNS clients and servers are subject to resource constraints that
+   will limit the extent to which CHAIN queries can be executed.
+   Effective limits for the number of active sessions that can be
+   maintained on individual clients and servers should be established
+   either as configuration options or by interrogation of process limits
+   imposed by the operating system.
+
+   In the event that there is greater demand for CHAIN queries than can
+   be accommodated, DNS servers may stop advertising the CHAIN option in
+   successive DNS messages.  This allows, for example, clients with
+   other candidate servers to query to establish new sessions with
+   different servers in expectation that those servers might still allow
+   CHAIN queries.
+
+6.4.  Negative Trust Anchors
+
+   If a CHAIN answer would intersect with a negative trust anchor
+   [RFC7646], a partial CHAIN up to the node above the negative trust
+   anchor should be returned.
+
+6.5.  Anycast Considerations
+
+   Recursive resolvers of various types are commonly deployed using
+   anycast [RFC4786].
+
+   Successive DNS transactions between a client and server using UDP
+   transport may involve responses generated by different anycast nodes,
+   and the use of anycast in the implementation of a DNS server is
+   effectively undetectable by the client.  The CHAIN option SHOULD NOT
+   be included in responses using UDP transport from servers provisioned
+   using anycast unless all anycast server nodes are capable of
+   processing the CHAIN option.
+
+   Since DNS queries using CHAIN may result in longer TCP sessions,
+   network topology changes may disrupt them more frequently.  Anycast
+   servers MAY make use of Multipath TCP [RFC6824] to anchor the server
+   side of the TCP connection to an unambiguously unicast address in
+   order to avoid disruption due to topology changes.
+
+
+
+
+
+
+
+Wouters                       Experimental                      [Page 9]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+7.  Security Considerations
+
+7.1.  Additional Work and Bandwidth
+
+   Producing CHAIN answers incurs additional load and bandwidth on the
+   recursive resolver.  At any time, a recursive resolver may decide to
+   no longer answer with CHAIN answers and fall back to traditional DNS
+   answers.
+
+7.2.  Amplification Attacks
+
+   CHAIN queries can potentially send very large DNS answers.  Attackers
+   could abuse this using spoofed source IP addresses to inflict large
+   distributed denial-of-service attacks using CHAINS as an
+   amplification vector in their attack.  While TCP is not vulnerable
+   for this type of abuse, the UDP protocol is vulnerable to this.
+
+   A recursive resolver MUST NOT return CHAIN answers to clients over
+   UDP without source IP address verification.  An example of UDP-based
+   source IP address verification is [RFC7873].  A recursive resolver
+   refusing a CHAIN option MUST respond with a zero-length CHAIN option
+   to indicate support for CHAIN queries when a proper transport is
+   used.  It MUST NOT send an RCODE of REFUSED.
+
+7.3.  Privacy Considerations
+
+   A client producing CHAIN queries reveals a little more information
+   about its cache contents than regular DNS clients.  This could be
+   used to fingerprint a client across network reconnections.  If DNS
+   privacy is a concern, a CHAIN query client MAY try to use a DNS
+   transport that provides privacy, such as [RFC7858] or a trusted DNS
+   server that is contacted through a VPN connection such as IPsec.
+
+8.  Examples
+
+8.1.  CHAIN Query for "www.example.com"
+
+   o  A web browser on a client machine asks the forwarding resolver
+      running on the local host to resolve the A record of
+      "www.example.com." by sending a regular DNS UDP query on port 53
+      to 127.0.0.1.
+
+   o  The resolver on the client machine checks its cache and notices it
+      already has a DNSSEC-validated entry of "com." in its cache.  This
+      includes the DNSKEY RRset with its RRSIG records.  In other words,
+      according to its cache, ".com" is DNSSEC validated as "secure" and
+      can be used to continue a DNSSEC-validated chain.
+
+
+
+
+Wouters                       Experimental                     [Page 10]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+   o  The resolver on the client opens a TCP connection to its upstream
+      recursive resolver on port 53.  It adds the CHAIN option as
+      follows:
+
+      *  Option-code, set to 13
+
+      *  Option-length, set to 5
+
+      *  Closest trust point set to "com." (0x03 0x63 0x6f 0x6d 0x00)
+
+   o  The upstream recursive resolver receives a DNS query over TCP with
+      the CHAIN closest trust point set to "com.".  After accepting the
+      query, it starts constructing a DNS reply packet.
+
+   o  The upstream recursive resolver performs all the regular work to
+      ensure it has all the answers to the query for the A record of
+      "www.example.com.".  It does so without using the CHAIN option --
+      unless it is also configured as a forwarding resolver.  The answer
+      to the original DNS question could be the actual A record, the
+      DNSSEC proof of nonexistence, or an insecure NXDOMAIN response.
+
+   o  The upstream recursive resolver adds the CHAIN option to the DNS
+      response as follows:
+
+      *  Option-code, set to 13
+
+      *  Option-length, set to 5
+
+      *  The closest trust point is set to "com." (0x03 0x63 0x6f 0x6d
+         0x00)
+
+   o  The upstream recursive resolver constructs the DNS Authority
+      Section and fills it (in any order) with:
+
+      *  The DS RRset for "example.com." and its corresponding RRSIGs
+         (made by the "com."  DNSKEY(s))
+
+      *  The DNSKEY RRset for "example.com." and its corresponding
+         RRSIGs (made by the "example.com."  DNSKEY(s))
+
+      *  The authoritative NS RRset for "example.com." and its
+         corresponding RRSIGs (from the child zone)
+
+      If the answer does not exist, and the zone uses DNSSEC, it also
+      adds the proof of nonexistence, such as NSEC or NSEC3 records, to
+      the Authority Section.
+
+
+
+
+
+Wouters                       Experimental                     [Page 11]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+   o  The upstream recursive resolver constructs the DNS Answer section
+      and fills it with:
+
+      *  The A record of "www.example.com." and its corresponding
+         RRSIGs.
+
+      If the answer does not exist (NODATA or NXDOMAIN), the Answer
+      Section remains empty.  For the NXDOMAIN case, the RCODE of the
+      DNS answer packet is set to NXDOMAIN.  Otherwise, it remains as
+      NOERROR.
+
+   o  The upstream recursive resolver returns the DNS answer over the
+      existing TCP connection.  When all data is sent, it SHOULD keep
+      the TCP connection open to allow for additional incoming DNS
+      queries -- provided it has enough resources to do so.
+
+   o  The resolver on the client receives the DNS answer.  It processes
+      the Authority and the Answer Sections and places the information
+      in its local cache.  It ensures that no data is accepted into the
+      cache without having proper DNSSEC validation.  It MAY do so by
+      looping over the entries in the Authority and Answer Sections.
+      When an entry is validated for its cache, it is removed from the
+      processing list.  If an entry cannot be validated, it is left in
+      the process list.  When the end of the list is reached, the list
+      is processed again until either all entries are placed in the
+      cache or the remaining items cannot be placed in the cache due to
+      lack of validation.  Those entries are then discarded.
+
+   o  If the cache contains a valid answer to the application's query,
+      this answer is returned to the application via a regular DNS
+      answer packet.  This packet MUST NOT contain a CHAIN option.  If
+      no valid answer can be returned, normal error processing is done.
+      For example, an NXDOMAIN or an empty Answer Section could be
+      returned depending on the error condition.
+
+8.2.  Out-of-Path Query for "example.com"
+
+   A recursive resolver receives a query for the A record for
+   "example.com".  It includes the CHAIN option with the following
+   parameters:
+
+   o  Option-code, set to 13
+
+   o  Option-length, set to 14
+
+   o  The closest trust point set to "unrelated.ca." (0x09 0x75 0x6e
+      0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00)
+
+
+
+
+Wouters                       Experimental                     [Page 12]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+   As there is no chain that leads from "unrelated.ca." to
+   "example.com.", the resolving nameserver answers with an empty CHAIN
+   specified using:
+
+   o  Option-code, set to 13
+
+   o  Option-length, set to 0x00 0x00
+
+   o  The closest trust point is omitted (zero length)
+
+   Note that the regular answer is still present just as it would be for
+   a query that did not specify the CHAIN option.
+
+8.3.  Nonexistent Data
+
+   A recursive resolver receives a query for the A record for
+   "ipv6.toronto.redhat.ca".  It includes the CHAIN option with the
+   following parameters:
+
+   o  Option-code, set to 13
+
+   o  Option-length, set to 0x00 0x03
+
+   o  The closest trust point set to "ca."
+
+   Using regular UDP queries towards authoritative nameservers, it
+   locates the NS RRset for "toronto.redhat.ca.".  When querying for the
+   A record, it receives a reply with RCODE "NoError" and an empty
+   Answer Section.  The Authority Section contains NSEC3 and RRSIG
+   records proving there is no A RRTYPE for the QNAME
+   "ipv6.toronto.redhat.ca".
+
+   The recursive resolver constructs a DNS reply with the following
+   CHAIN option parameters:
+
+   o  Option-code, set to 13
+
+   o  Option-length, set to 0x00 0x00
+
+   o  The closest trust point is omitted (zero length)
+
+   The RCODE is set to "NoError".  The Authority Section is filled in
+   with:
+
+   o  The DS RRset for "redhat.ca." plus RRSIGs
+
+   o  The DNSKEY RRset for "redhat.ca." plus RRSIGs
+
+
+
+
+Wouters                       Experimental                     [Page 13]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+   o  The NS RRset for "redhat.ca." plus RRSIGs (e.g., ns[01].redhat.ca)
+
+   o  The A RRset for "ns0.redhat.ca." and "ns1.redhat.ca." plus RRSIGs
+
+   o  The DS RRset for "toronto.redhat.ca." plus RRSIGs
+
+   o  The NS RRset for "toronto.redhat.ca." plus RRSIGs (e.g.,
+      ns[01].toronto.redhat.ca)
+
+   o  The DNSKEY RRset for "toronto.redhat.ca." plus RRSIGs
+
+   o  The A RRset and/or AAAA RRset for "ns0.toronto.redhat.ca." and
+      "ns1.toronto.redhat.ca." plus RRSIGs
+
+   o  The NSEC record for "ipv6.toronto.redhat.ca." (proves what RRTYPEs
+      do exist; does not include A)
+
+   o  The NSEC record for "toronto.redhat.ca." (proves no wildcard
+      exists)
+
+   The Answer Section is empty.  The RCODE is set to NOERROR.
+
+9.  IANA Considerations
+
+9.1.  EDNS0 Option Code for CHAIN
+
+   IANA has assigned option code 13 in the "DNS EDNS0 Option Codes
+   (OPT)" registry to CHAIN.
+
+10.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <http://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
+              <http://www.rfc-editor.org/info/rfc2308>.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <http://www.rfc-editor.org/info/rfc4033>.
+
+
+
+Wouters                       Experimental                     [Page 14]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, DOI 10.17487/RFC4034, March 2005,
+              <http://www.rfc-editor.org/info/rfc4034>.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+              <http://www.rfc-editor.org/info/rfc4035>.
+
+   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
+              Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
+              December 2006, <http://www.rfc-editor.org/info/rfc4786>.
+
+   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
+              "TCP Extensions for Multipath Operation with Multiple
+              Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
+              <http://www.rfc-editor.org/info/rfc6824>.
+
+   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
+              for DNS (EDNS(0))", STD 75, RFC 6891,
+              DOI 10.17487/RFC6891, April 2013,
+              <http://www.rfc-editor.org/info/rfc6891>.
+
+   [RFC7646]  Ebersman, P., Kumari, W., Griffiths, C., Livingood, J.,
+              and R. Weber, "Definition and Use of DNSSEC Negative Trust
+              Anchors", RFC 7646, DOI 10.17487/RFC7646, September 2015,
+              <http://www.rfc-editor.org/info/rfc7646>.
+
+   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
+              2015, <http://www.rfc-editor.org/info/rfc7719>.
+
+   [RFC7828]  Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
+              edns-tcp-keepalive EDNS0 Option", RFC 7828,
+              DOI 10.17487/RFC7828, April 2016,
+              <http://www.rfc-editor.org/info/rfc7828>.
+
+   [RFC7858]  Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
+              and P. Hoffman, "Specification for DNS over Transport
+              Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
+              2016, <http://www.rfc-editor.org/info/rfc7858>.
+
+   [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
+              Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
+              <http://www.rfc-editor.org/info/rfc7873>.
+
+
+
+
+
+Wouters                       Experimental                     [Page 15]
+
+RFC 7901               CHAIN Query Requests in DNS             June 2016
+
+
+Acknowledgments
+
+   Andrew Sullivan pointed out that we do not need any new data formats
+   to support DNS chains.  Olafur Gudmundsson ensured the RRsets are
+   returned in the proper sections.  Thanks to Tim Wicinski for his
+   thorough review.
+
+Author's Address
+
+   Paul Wouters
+   Red Hat
+
+   Email: pwouters@redhat.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wouters                       Experimental                     [Page 16]
+