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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/