dnsop
Internet Engineering Task Force (IETF)                        P. Wouters
Internet-Draft
Request for Comments: 7901                                       Red Hat
Intended status:
Category: Experimental                          February 18, 2016
Expires: August 21,                                         June 2016

                      Chain
ISSN: 2070-1721

                      CHAIN Query requests Requests in DNS
                  draft-ietf-dnsop-edns-chain-query-07

Abstract

   This document defines an EDNS0 extension that can be used by a
   security-aware validating resolver configured to use a Forwarder 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 source-IP-
   verified transport such as TCP or UDP with EDNS-COOKIE EDNS-COOKIE, so it cannot
   be abused in amplification attacks.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and BCP 79.

   Internet-Drafts are working documents
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid 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 maximum candidate for any level of
   Internet Standard; see Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 21, 2016.
   http://www.rfc-editor.org/info/rfc7901.

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Option Format . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Protocol Description  . . . . . . . . . . . . . . . . . . . .   5
     5.1.  Discovery of Support  . . . . . . . . . . . . . . . . . .   5
     5.2.  Generate a Query  . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Send the Option . . . . . . . . . . . . . . . . . . . . .   6
     5.4.  Generate a Response . . . . . . . . . . . . . . . . . . .   6
   6.  Protocol Considerations . . . . . . . . . . . . . . . . . . .   7   8
     6.1.  DNSSEC Considerations . . . . . . . . . . . . . . . . . .   7   8
     6.2.  NS record Record Considerations  . . . . . . . . . . . . . . . .   8
     6.3.  Session Management  . . . . . . . . . . . . . . . . . . .   8
     6.4.  Negative Trust Anchors  . . . . . . . . . . . . . . . . .   8   9
     6.5.  Anycast Considerations  . . . . . . . . . . . . . . . . .   9
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .   9
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.1.   9
     7.1.  Additional work Work and bandwidth Bandwidth . . . . . . . . . . . . . .  10
     8.2.   9
     7.2.  Amplification Attacks . . . . . . . . . . . . . . . . . .  10
     8.3.   9
     7.3.  Privacy Considerations  . . . . . . . . . . . . . . . . .  10
   9.
   8.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Simple
     8.1.  CHAIN Query for example.com  . . "www.example.com" . . . . . . . . . . . .  10
     9.2.  Out-of-path
     8.2.  Out-of-Path Query for example.com . "example.com" . . . . . . . . . . .  12
     9.3.  Non-existent data
     8.3.  Nonexistent Data  . . . . . . . . . . . . . . . . . . . .  13
   10.  12
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     10.1.
     9.1.  EDNS0 option code Option Code for CHAIN . . . . . . . . . . . . . . .  14
   11. Acknowledgements
   10. Normative References  . . . . . . . . . . . . . . . . . . . .  14
   Acknowledgments . .  14
   12. Normative References . . . . . . . . . . . . . . . . . . . .  14 . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16  15

1.  Introduction

   Traditionally, a DNS client operates in stub-mode. stub mode.  For each DNS
   question the DNS client needs to resolve, it sends a single query to
   an upstream Recursive Resolver recursive resolver to obtain a single DNS answer.  When
   DNSSEC [RFC4033] is deployed on such DNS clients, validation requires
   that the client obtains obtain all the intermediate information from the DNS
   root down to the queried-for hostname 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,
   (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
   resolver running as a Forwarder forwarding resolver to open a TCP connection to
   another
   Resolver resolver and request a DNS chain answer using one DNS query/answer query/
   answer pair.  This reduces the number of round trips to two.  If
   combined with long lived long-lived TCP or [TCP-KEEPALIVE] [RFC7828], there is only one round
   trip.  While the upstream Resolver 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
   last-mile latency.

   This EDNS0 extension allows the Forwarder 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 recursive resolver has to perform.

   This EDNS0 extension is only intended to be sent by Forwarders forwarding
   resolvers to
   Recursive Resolvers. recursive resolvers.  It MUST be ignored by Authoritative Servers.
   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].

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 resolvers frequently use
      caches to be able to respond to client queries quickly.  Described quickly, as
      described in [RFC1035] chapter [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. 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 resolver, so it can confirm DNSSEC validation of all
   intermediary DNS answers.  It can configure itself as a Forwarder forwarding
   resolver if it obtains the IP addresses of one or more Recursive Resolvers recursive
   resolvers that are available, available or as a stand-alone Recursive Resolver recursive resolver
   if no functional Recursive Resolvers 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 resolver validates all intermediate answers.
   Each round-trip 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 resolver to
   request all intermediate DNS data it requires to resolve and validate
   a particular DNS answer in a single round-trip. round trip.  The Resolver resolver could
   be part of the application or a Recursive Resolver recursive resolver running on the
   host.

   Servers answering with CHAIN data should ensure that the transport peer's IP
   address is
   TCP or not a spoofed source IP address verified UDP. address.  See Section 8. 7.  This avoids
   abuse in
   prevents DNS amplification attacks.

   Applications that support CHAIN internally can perform validation
   without requiring the host to run a Recursive Resolver. recursive resolver.  This is
   particularly useful for virtual servers in a cloud or container based container-based
   deployment where it is undesirable to run a Recursive Resolver recursive resolver per
   virtual machine.

   The format of this option is described in Section 4.

   As described in Section 5.4, a Recursive Resolver could recursive resolver can use this EDNS0
   option to include additional data required by the Resolver resolver in the
   Authority Section of the DNS answer packet when using a source IP
   verified transport. 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 for source IP address verified transports. option.

   The mechanisms provided by CHAIN raise various security related
   concerns, concerns
   related to the additional work, bandwidth, amplification
   attacks as well as attacks, and
   privacy issues with the cache.  These concerns are described in
   Section 8. 7.

4.  Option Format

   This draft document uses an EDNS0 [RFC6891] 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, trust point, a variable length Fully Qualified variable-length Fully-Qualified Domain Name
      ("FQDN")
      (FQDN) in DNS wire format of the requested start point of the
      chain.  This entry is the 'lowest' "lowest" known entry in the DNS chain
      known by the recursive server seeking a CHAIN answer for which it
      has a validated DS Delegation Signer (DS) and DNSKEY record.  The end point
      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 Forwarder 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 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 source-IP-
   verified transport, the Forwarder forwarding resolver MAY then switch to a source IP verified
   source-IP-verified transport and start sending queries with the CHAIN
   option to request a CHAIN response from the
   Recursive Resolver. recursive resolver.
   Examples of source IP verification source-IP-verified transports are the 3-way three-way TCP
   handshake and UDP with [EDNS-COOKIE]. DNS cookies [RFC7873].

5.2.  Generate a Query

   In this option value, the Forwarder forwarding resolver sets the Closest Trust Point closest trust
   point in the chain - -- furthest from the root - -- that it already has a DNSSEC
   validated
   DNSSEC-validated (secure or not) answer for in its cache.  The
   upstream
   Recursive Resolver 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 9.1. 8.1.

   The CHAIN option should generally be sent by system Forwarders forwarding
   resolvers and
   Resolvers resolvers within an application that also perform performs
   DNSSEC validation.

5.3.  Send the Option

   When CHAIN is available, the downstream Recursive Resolver recursive resolver can adjust
   its query strategy based on the desired queries and its cache
   contents.

   A Forwarder forwarding resolver can request the CHAIN option with every
   outgoing DNS query.  However, it is RECOMMENDED that Forwarders forwarding
   resolvers remember which upstream Recursive Resolvers recursive resolvers did not return
   the option (and additional data) with their response.  The Forwarder forwarding
   resolver SHOULD fallback fall back to regular DNS for subsequent queries to
   those Recursive Resolvers. recursive resolvers.  It MAY switch to another Recursive Resolver 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 Query Chains. CHAIN queries.  A fallback strategy similar to that described in [RFC6891] section
   [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
   Forwarder,
   forwarding resolver, the upstream Recursive Resolver 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 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 added start with
   the first chain element below the received Closest Trust Point 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 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
   DNSSEC-related records must be added to their appropriate sections.
   This includes records required for proof of non-existence nonexistence of regular and/
   or
   and/or wildcard records, such as NSEC NextSECure (NSEC) or NSEC3 records.

   Recursive Resolvers 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 CHAIN query due to work load, workload, may safely ignore
   the option in the incoming queries.  Such a server MUST NOT include
   an a
   CHAIN option when sending DNS answer replies back, thus indicating it
   is not able or willing to support Chain Queries CHAIN queries at this time.

   Requests with wrongly formatted options (i.e. (i.e., bogus FQDN) MUST be
   rejected and
   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 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 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 re-send resend the
   query with an updated Closest Trust Point closest trust point until it has received the
   full chain.  The CHAIN response will contain the lowest Closest Trust
   Point closest trust
   point that was included in the CHAIN answer.

   If the DNS request results in an a CNAME or DNAME for the Answer
   Section, the Recursive Resolver 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 recursive resolver to a Resolver resolver MUST NOT contain
   the CHAIN option if none was present in the Resolver's resolver's original
   request.

   A DNS query that contains the CHAIN option MUST also have the DNSSEC
   OK ("OK") "DNSSEC
   OK" (DO) bit set.  If this bit is not set, or if the Checking
   Disabled ("CD") "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 an 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] [RFC4034], and
   [RFC4035].

6.2.  NS record Record Considerations

   CHAIN responses SHOULD include the authoritative NS RRset from the zone itself
   including the 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
   omited. omitted.

   When a DNSSEC chain is supplied via CHAIN, the Forwarder 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 Forwarder forwarding resolver might be forced to switch
   from Forwarder forwarding resolver mode to
   Recursive Resolver recursive resolver mode due to a
   network topology change.  In
   Recursive Resolver recursive resolver mode, the NS RRsets
   are needed to find and query
   Authoritative Servers authoritative servers directly.  It is
   RECOMMENDED that the DNS
   Forwarder 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.

6.3.  Session Management

   The use of [TCP-KEEPALIVE] TCP keepalive [RFC7828] on DNS TCP sessions is RECOMMENDED, and
   thus
   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
   which that
   will limit the extent to which Chain Queries 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, 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 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.
   CHAIN queries.

6.4.  Negative Trust Anchors

   If a CHAIN answer would intersect with a Negative Trust Anchor negative trust anchor
   [RFC7646], a partial CHAIN up to the node above the Negative Trust
   Anchor negative trust
   anchor should be returned.

6.5.  Anycast Considerations

   Recursive Resolvers 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 multipath [RFC6824] to anchor the server
   side of the TCP connection to an unambiguously-unicast unambiguously unicast address in
   order to avoid disruption due to topology changes.

7.  Implementation Status

   [RFC Editor Note: Please remove this entire seciton prior to
   publication as an RFC.]

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft,  Security Considerations

7.1.  Additional Work and is based Bandwidth

   Producing CHAIN answers incurs additional load and bandwidth on the
   recursive resolver.  At any time, a proposal described in [RFC6982].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to [RFC6982], "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

   [While there is some interest, no work has started yet]

8.  Security Considerations

8.1.  Additional work and bandwidth

   Producing CHAIN answers incurs additional load and bandwidth on the
   Recursive Resolver.  At any time, a Recursive Resolver recursive resolver may decide to
   no longer answer with CHAIN answers and fall back to traditional DNS
   answers.

8.2.

7.2.  Amplification Attacks

   Chain Queries

   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
   distributed denial-of-service attacks using query-chains 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 recursive resolver MUST NOT return CHAIN answers to clients over
   UDP without source IP address verification.  An example of UDP based UDP-based
   source IP address verification is [EDNS-COOKIE]. [RFC7873].  A Recursive
   Resolver 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.

8.3.

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 the 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 [DNS-over-TLS] [RFC7858] or a trusted DNS
   server that is contacted through a VPN connection such as IPsec.

9.

8.  Examples

9.1.  Simple

8.1.  CHAIN Query for example.com "www.example.com"

   o  A web browser on a client machine asks the Forwarder forwarding resolver
      running on
      localhost 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 resolver on the client machine checks its cache, cache and notices it
      already has a DNSSEC validated 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 DNSSEC-validated chain.

   o  The Resolver resolver on the client opens a TCP connection to its upstream
      Recursive Resolver
      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 trust point set to "com." (0x03 0x63 0x6f 0x6d 0x00)

   o  The upstream Recursive Resolver recursive resolver receives a DNS query over TCP with
      the CHAIN Closest Trust Point closest trust point set to "com.".  After accepting the
      query
      query, it starts constructing a DNS reply packet.

   o  The upstream Recursive Resolver 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 Forwarder. forwarding resolver.  The answer
      to the original DNS question could be the actual A record, the
      DNSSEC proof of non-existence, nonexistence, or an insecure NXDOMAIN response.

   o  The upstream Recursive Resolver 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 closest trust point is set to "com." (0x03 0x63 0x6f 0x6d
         0x00)

   o  The upstream Recursive Resolver 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" "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 non-existence, nonexistence, such as NSEC or NSEC3 records, to
      the Authority Section.

   o  The upstream Recursive Resolver recursive resolver constructs the DNS Answer
      Section section
      and fills it with:

      *  The A record of "www.example.com." and its corresponding RRSIGs
         RRSIGs.

      If the answer does not exist (NODATA or NXDOMAIN), the Answer
      Section remains empty.  For the NXDOMAIN case, the RCode RCODE of the
      DNS answer packet is set to NXDOMAIN.  Otherwise  Otherwise, it remains as
      NOERROR.

   o  The upstream Recursive Resolver 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 resolver on the client receives the DNS answer.  It processes
      the Authority Section and the Answer Section 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 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,
      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 an 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.

9.2.  Out-of-path

8.2.  Out-of-Path Query for example.com "example.com"

   A Recursive Resolver recursive resolver receives a query for the A record for
   example.com.
   "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 closest trust point set to 'unrelated.ca.' "unrelated.ca." (0x09 0x75 0x6e
      0x72 0x65 0x6c 0x61 0x74 0x65 0x64 0x03 0x63 0x61 0x00)

   As there is no chain that leads from "unrelated.ca." to
   "example.com",
   "example.com.", the Resolving Nameserver 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 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.

9.3.  Non-existent data

8.3.  Nonexistent Data

   A Recursive Resolver 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 closest trust point set to 'ca.' "ca."

   Using regular UDP queries towards Authoritative Nameservers, authoritative nameservers, it
   locates the NS RRset for "toronto.redhat.ca.".  When querying for the
   A record 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 RRTYPE for the QNAME
   "ipv6.toronto.redhat.ca".

   The Recursive Resolver 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 closest trust point is ommited 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

   o  The NS RRset for "redhat.ca." plus RRSIGs (eg (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 (eg (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, exist; does not include A)

   o  The NSEC record for "toronto.redhat.ca." (proves no wildcard
      exists)
   The Answer Section is empty.  The RCode RCODE is set to NOERROR.

10.

9.  IANA Considerations

10.1.

9.1.  EDNS0 option code Option Code for CHAIN

   IANA has assigned option code 13 in the "DNS EDNS0 Option Codes
   (OPT)" registry to CHAIN.

11.  Acknowledgements

   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.

12.

10.  Normative References

   [DNS-over-TLS]
              Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
              and P. Hoffman, "DNS over TLS: Initiation and Performance
              Considerations", draft-ietf-dprive-dns-over-tls-05 (work
              in progress), January 2016.

   [EDNS-COOKIE]
              Eastlake, Donald., "Domain Name System (DNS) Cookies",
              draft-ietf-dnsop-cookies (work in progress), January 2016.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [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, 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>.

   [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, 10.17487/RFC6891, April 2013,
              <http://www.rfc-editor.org/info/rfc6891>.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982, DOI
              10.17487/RFC6982, July 2013,
              <http://www.rfc-editor.org/info/rfc6982>.

   [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>.

   [TCP-KEEPALIVE]

   [RFC7828]  Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
              edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns-
              tcp-keepalive-05 (work 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>.

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 progress), January 2016. the proper sections.  Thanks to Tim Wicinski for his
   thorough review.

Author's Address

   Paul Wouters
   Red Hat

   Email: pwouters@redhat.com