< draft-ietf-dnsop-edns-chain-query-03.txt   draft-ietf-dnsop-edns-chain-query-04.txt >
dnsop P. Wouters dnsop P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Intended status: Standards Track October 03, 2015 Intended status: Standards Track October 19, 2015
Expires: April 05, 2016 Expires: April 21, 2016
Chain Query requests in DNS Chain Query requests in DNS
draft-ietf-dnsop-edns-chain-query-03 draft-ietf-dnsop-edns-chain-query-04
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 as a Forwarder to send security-aware validating Resolver configured as a Forwarder to send
a single query, requesting a complete validation path along with the a single query, requesting a complete validation path along with the
regular query answer. The reduction in queries lowers the latency. regular query answer. The reduction in queries lowers the latency.
This extension requries the use of source IP verified transport such This extension requries the use of source IP verified transport such
as TCP or UDP with DNS-COOKIES so it cannot be abused in as TCP or UDP with EDNS-COOKIE so it cannot be abused in
amplification attacks. amplification attacks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 05, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 5
5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5 5.1. Discovery of Support . . . . . . . . . . . . . . . . . . 5
5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 5 5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 5
5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6 5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6
5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6 5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6
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. TCP Session Management . . . . . . . . . . . . . . . . . 8 6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8
6.4. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 9 6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 9
6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9 6.5. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 9
6.6. Anycast Considerations . . . . . . . . . . . . . . . . . 9
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 10 8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 10
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Simple Query for example.com . . . . . . . . . . . . . . 10 9.1. Simple Query for example.com . . . . . . . . . . . . . . 10
9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12 9.2. Out-of-path Query for example.com . . . . . . . . . . . . 12
9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13 9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. EDNS0 option code for edns-chain-query . . . . . . . . . 14 10.1. EDNS0 option code for CHAIN . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
12. Normative References . . . . . . . . . . . . . . . . . . . . 14 12. Normative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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 obtains 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 hostname so it can perform DNSSEC
validation on the complete chain of trust. validation on the complete chain of trust.
skipping to change at page 3, line 11 skipping to change at page 3, line 12
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 Forwarder to open a TCP connection to another
Resolver and request a DNS chain answer using one DNS query/answer Resolver and request a DNS chain answer using one DNS query/answer
pair. This reduces the number of round-trip times ("RTT") to two. pair. This reduces the number of round trips to two. If combined
If combined with long livd TCP or [TCP-KEEPALIVE] there is only 1 with long lived TCP or [TCP-KEEPALIVE] there is only one round trip.
RTT. While the upstream Resolver still needs to perform all the While the upstream Resolver still needs to perform all the individual
individual queries required for the complete answer, it usually has a queries required for the complete answer, it usually has a much
much bigger cache and does not experience significant slowdown from bigger cache and does not experience significant slowdown from last-
last-mile latency. mile latency.
This EDNS0 extension allows the DNS Forwarder to indicate which part This EDNS0 extension allows the Forwarder to indicate which part of
of the DNS hierarchy it already contains in its cache. This reduces the DNS hierarchy it already contains in its cache. This reduces the
the amount of data required to be transferred and reduces the work amount of data required to be transferred and reduces the work the
the upstream Recursive Resolver has to perform. 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 Forwarders to
Recursive Resolvers. It can (and should be) ignored by Authoritative Recursive Resolvers. It can (and should) be ignored by Authoritative
Servers. 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
skipping to change at page 4, line 4 skipping to change at page 4, line 4
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. Described
in [RFC1035] chapter 7. in [RFC1035] chapter 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 the host, it can no longer delegate all When DNSSEC is deployed on a host, it can no longer delegate all DNS
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 DNS Forwarder intermediary DNS answers. It can configure itself as a Forwarder if
if it obtains the IP addresses of one or more Recursive Resolvers it obtains the IP addresses of one or more Recursive Resolvers that
that are available, or as a stand-alone Recursive Resolver if no are available, or as a stand-alone Recursive Resolver if no
functional Recursive Resolvers were obtained. Generating the 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.
The edns-chain-query option allows the Resolver to request all This document defines the CHAIN option that allows the Resolver to
intermediate DNS data it requires to resolve and validate a request all intermediate DNS data it requires to resolve and validate
particular DNS answer in a single round-trip. The Resolver could be a particular DNS answer in a single round-trip. The Resolver could
part of the application or a Recursive Resolver running on the host. be part of the application or a Recursive Resolver running on the
host.
Servers answering with chain query data exceeding 512 bytes should Servers answering with CHAIN data should ensure that the transport is
ensure that the transport is TCP or source IP address verified UDP. TCP or source IP address verified UDP. See Section 8. This avoids
See Section 8. This avoids abuse in DNS amplification attacks. abuse in DNS amplification attacks.
Applications that support edns-chain-query internally can perform Applications that support CHAIN internally can perform validation
validation without requiring the host the run a Recursive Resolver. without requiring the host the run a Recursive Resolver. This is
This is particularly useful for virtual servers in a cloud or particularly useful for virtual servers in a cloud or container based
container based deployment where it is undesirable to run a Recursive deployment where it is undesirable to run a Recursive Resolver per
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 could use this
EDNS0 option to include additional data required by the Resolver in EDNS0 option to include additional data required by the Resolver in
the Authority Section of the DNS answer packet when using a source IP the Authority Section of the DNS answer packet when using a source IP
verified transport. The Answer Section remains unchanged from a verified transport. The Answer Section remains unchanged from a
traditional DNS answer and contains the answer and related DNSSEC traditional DNS answer and contains the answer and related DNSSEC
entries. entries.
An empty edns-chain-query EDNS0 option MAY be sent over any transport An empty CHAIN EDNS0 option MAY be sent over any transport as a
as a discovery method. A DNS server receiving such an empty edns- discovery method. A DNS server receiving such an empty CHAIN option
chain-query option SHOULD add an empty edns-chain-query option in its SHOULD add an empty CHAIN option in its answer to indicate that it
answer to indicate that it supports edns-chain-query for source IP supports CHAIN for source IP address verified transports.
address verified transports.
The mechanisms provided by edns-chain-query raise various security The mechanisms provided by CHAIN raise various security related
related concerns, related to the additional work, bandwidth, concerns, related to the additional work, bandwidth, amplification
amplification attacks as well as privacy issues with the cache. attacks as well as privacy issues with the cache. These concerns are
These concerns are described in Section 8. described in Section 8.
4. Option Format 4. Option Format
This draft uses an EDNS0 [RFC6891] option to include client IP This draft uses an EDNS0 [RFC6891] option 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 !
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
~ Last Known Query Name (FQDN) ~ ~ Closest Trust Point (FQDN) ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
o OPTION-CODE, 2 octets, for edns-chain-query is [TBD]. o OPTION-CODE, 2 octets, for CHAIN is [TBD1].
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 Last Known Query Name, a variable length FDQN of the requested o Closest Trust Point, a variable length FDQN of the requested start
start point of the chain. This entry is the 'lowest' known entry point of the chain. This entry is the 'lowest' known entry in the
in the DNS chain known by the recursive server seeking a edns- DNS chain known by the recursive server seeking a CHAIN answer for
chain-query answer. The end point of the chain is obtained from which it has a validated DS and DNSKEY record. The end point of
the DNS Query Section itself. No compression is allowed for this the chain is obtained from the DNS Query Section itself. No DNS
value. name compression is allowed for this value.
5. Protocol Description 5. Protocol Description
5.1. Discovery of Support 5.1. Discovery of Support
A DNS Forwarder may include a zero-length edns-chain-query option in A Forwarder may include a zero-length CHAIN option in a regular query
queries over any transport to discover the DNS server capability for over any transport to discover the DNS server capability for CHAIN.
edns-chain-query. Recursive Resolvers that support and are willing Recursive Resolvers that support and are willing to accept CHAIN
to accept chain queries over source IP verified transport respond to queries over source IP verified transport respond to a zero-length
a zero-length edns-chain-query received by including a zero-length CHAIN received by including a zero-length CHAIN option in the answer.
edns-chain-query option in the answer. A DNS Forwarder MAY then If not already using a source IP verified transport, the Forwarder
switch to a source IP verified transport and sent a non-zero edns- MAY then switch to a source IP verified transport and start sending
chain-query value to request a chain-query response from the queries with the CHAIN option to request a CHAIN response from the
Recursive Resolver. Examples of source IP verification is the 3-way Recursive Resolver. Examples of source IP verification are the 3-way
TCP handshake and UDP with [DNS-COOKIES]. TCP handshake and UDP with [EDNS-COOKIE].
5.2. Generate a Query 5.2. Generate a Query
In this option value, the Forwarder sets the last known entry point In this option value, the Forwarder sets the Closest Trust Point in
in the chain - furthest from the root - that it already has a DNSSEC the chain - furthest from the root - that it already has a DNSSEC
validated (secure or not) answer for in its cache. The upstream validated (secure or not) answer for in its cache. The upstream
Recursive Resolver does not need to include any part of the chain 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 from the root down to this option's FQDN. A complete example is
described in Section 9.1. described in Section 9.1.
Depending on the size of the labels of the last known entry point The CHAIN option should generally be sent by system Forwarders and
value, a DNS Query packet could be arbitrarily large. If using the Resolvers within an application that also perform DNSSEC validation.
last known entry point would result in a query size of more then 512
bytes, the last known entry point should be replaced with its parent
entry until the query size would be 512 bytes or less. A separate
query should be send for the remainder of the validation chain.
The edns-chain-query option should generally be sent by system
Forwarders and Resolvers within an application that also perform
DNSSEC validation.
5.3. Send the Option 5.3. Send the Option
When edns-chain-query is available, the downstream Recursive Resolver When CHAIN is available, the downstream Recursive Resolver can adjust
can adjust its query strategy based on the desired queries and its its query strategy based on the desired queries and its cache
cache contents. contents.
A DNS Forwarder can request the edns-chain-query option with every A Forwarder can request the CHAIN option with every outgoing DNS
outgoing DNS query. However, it is RECOMMENDED that DNS Forwarders query. However, it is RECOMMENDED that Forwarders remember which
remember which upstream Recursive Resolvers did not return the option upstream Recursive Resolvers did not return the option (and
(and additional data) with their response. The DNS Forwarder SHOULD additional data) with their response. The Forwarder SHOULD fallback
fallback to regular DNS for subsequent queries to those Recursive to regular DNS for subsequent queries to those Recursive Resolvers.
Resolvers. It MAY switch to another Resolving Resolver that does It MAY switch to another Recursive Resolver that does support the
support the edns-chain-query option or try again later to see if the CHAIN option or try again later to see if the server has become less
server has become less loaded and is now willing to answer with Query loaded and is now willing to answer with Query Chains.
Chains.
5.4. Generate a Response 5.4. Generate a Response
When a query containing a non-zero edns-chain-query option is When a query containing a non-zero CHAIN option is received from a
received from a DNS Forwarder, the upstream Recursive Resolver Forwarder, the upstream Recursive Resolver supporting CHAIN MAY
supporting edns-chain-query MAY respond by confirming that it is respond by confirming that it is returning a CHAIN. To do so, it
returning a DNS Query Chain. To do so, it MUST set the edns-chain- MUST set the CHAIN option to the lowest Trust Point sent as part of
query option with an OPTION-LENGTH of zero to indicate the DNS answer the chain, with its corresponding OPTION-LENGTH. It extends the
contains a Chain Query. It extends the Authority Section in the DNS Authority Section in the DNS answer packet with the DNS RRsets
answer packet with the DNS RRSets required for validating the answer. required for validating the answer. The DNS RRsets added start with
The DNS RRsets added start with the first chain element below the the first chain element below the received Closest Trust Point up to
received Last Known Query Name up to and including the NS and DS and including the NS and DS RRsets that represent the zone cut
RRsets that represent the zone cut (authoritative servers) of the (authoritative servers) of the QNAME. The actual DNS answer to the
QNAME. The actual DNS answer to the question in the Query Section is question in the Query Section is placed in the DNS Answer
placed in the DNS Answer Section identical to the traditional DNS Section identical to the traditional DNS answer. All required DNSSEC
answer. All required DNSSEC related records must be added to their related records must be added to their appropriate sections. This
appropriate sections. This includes records required for proof of includes records required for proof of non-existence of regular and/
non-existence of regular and/or wildcard records, such as NSEC or or wildcard records, such as NSEC or NSEC3 records.
NSEC3 records.
Recursive Resolvers that have not implemented or enabled support for Recursive Resolvers that have not implemented or enabled support for
the edns-chain-query option, or are otherwise unwilling to perform the CHAIN option, or are otherwise unwilling to perform the
the additional work for a Chain Query due to work load, may safely additional work for a Chain Query due to work load, may safely ignore
ignore the option in the incoming queries. Such a server MUST NOT the option in the incoming queries. Such a server MUST NOT include
include an edns-chain-query option when sending DNS answer replies an CHAIN option when sending DNS answer replies back, thus indicating
back, thus indicating it is not able or willing to support Chain it is not able or willing to support Chain Queries at this time.
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 and 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 sending a REFUSED response to the sender, to serve can be rejected by answering the query as a regular DNS
as described by [RFC6891]. This refusal can be used for chains that reply but with an empty CHAIN payload. Replying with an empty CHAIN
would be too big or chains that would reveal too much information can be used for chains that would be too big or chains that would
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 to acknowledge a Chain Query by running low on resources can refuse CHAIN queries by replying with a
omitting the edns-chain-query option in its reply. It may do so even regular DNS reply with an empty CHAIN payload.
if it conveyed support to a DNS client previously. It may even
change its support for edns-chain-query within the same TCP session. If a CHAIN answer would be bigger than the Recursive Resolver is
willing to serve, it SHOULD send a partial chain starting with the
data closest to the top of the chain. The client MAY re-send the
query with an updated Closest Trust Point until it has received the
full chain. The CHAIN response will contain the lowest Closest Trust
Point that was included in the CHAIN answer.
If the DNS request results in an CNAME or DNAME for the Answer If the DNS request results in an 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 edns-chain-query option if none was present in the Resolver's the CHAIN option if none was present in the Resolver's original
original request. request.
A DNS query that contains the edns-chain-query option MUST also have A DNS query that contains the CHAIN option MUST also have the DNSSEC
the DNSSEC OK bit set. If this bit is not set, the edns-chain-query OK bit set. If this bit is not set, the CHAIN option received MUST
option received MUST be ignored. be 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 edns-
chain-query option in a DNS query does not change the usage of those The presence or absence of an OPT resource record containing an CHAIN
resource records and mechanisms used to provide data origin option in a DNS query does not change the usage of those resource
authentication and data integrity to the DNS, as described in records and mechanisms used to provide data origin authentication and
[RFC4033], [RFC4034] and [RFC4035]. data integrity to the DNS, as described in [RFC4033], [RFC4034] and
[RFC4035].
6.2. NS record Considerations 6.2. NS record Considerations
edns-chain-query responses MUST include the NS RRset from the child CHAIN responses MUST include the NS RRset from the child zone
zone, which includes DNSSEC RRSIG records required for validation. including the RRSIG records required for validation.
When a DNSSEC chain is supplied via edns-chain-query, the DNS When a DNSSEC chain is supplied via CHAIN, the Forwarder is no longer
Forwarder no longer requires to use the NS RRset, as it can construct required to use the NS RRset, as it can construct the validation path
the validation path via the DNSKEY and DS RRsets without using the NS via the DNSKEY and DS RRsets without using the NS RRset. However,
RRset. However, the DNS Forwarder might be forced to switch from the Forwarder might be forced to switch from Forwarder mode to
Forwarder mode to Recursive Resolver mode due to a network topology Recursive Resolver mode due to a network topology change. In
change. In Recursive Resolver mode, it requires the NS RRsets to Recursive Resolver mode, the NS RRsets are needed to find and query
find and query Authoritative Servers directly. It is preferred that Authoritative Servers directly. It is RECOMMENDED that the DNS
the DNS Forwarder populate its cache with this information to avoid Forwarder populate its cache with this information to avoid requiring
requiring future queries to obtain any missing NS records. Therefor, future queries to obtain any missing NS records. Therefore, CHAIN
edns-chain-query responses MUST include the NS RRset from the child responses MUST include the NS RRset from the child zone, including
zone, which includes DNSSEC RRSIG records required for validation. the RRSIG records required for validation.
6.3. TCP Session Management 6.3. TCP Session Management
It is recommended that TCP sessions to the Recursive Resolver are not It is RECOMMENDED that TCP sessions not immediately be closed after
immediately closed after the DNS answer to the first query is the DNS answer to the first query is received. It is recommended to
received. It is recommended to use [TCP-KEEPALIVE]. use [TCP-KEEPALIVE].
Both DNS clients and servers are subject to resource constraints Both DNS clients and servers are subject to resource constraints
which will limit the extent to which Chain Queries can be executed. which 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 edns-query- be accommodated, DNS servers may stop advertising the CHAIN option in
chain option in successive DNS messages. This allows, for example, successive DNS messages. This allows, for example, clients with
clients with other candidate servers to query to establish new other candidate servers to query to establish new sessions with
sessions with different servers in expectation that those servers different servers in expectation that those servers might still allow
might still allow Chain Queries. Chain Queries.
6.4. Non-Clean Paths 6.4. Negative Trust Anchors
If a CHAIN answer would intersect with a Negative Trust Anchor
[RFC7646], a partian CHAIN up to the node above the Negative Trust
Anchor should be returned.
6.5. Non-Clean Paths
Many paths between DNS clients and Recursive Resolvers suffer from Many paths between DNS clients and Recursive Resolvers suffer from
poor hygiene, limiting the free flow of DNS messages that include poor hygiene, limiting the free flow of DNS messages that include
particular EDNS0 options, or messages that exceed a particular size. particular EDNS0 options, or messages that exceed a particular size.
A fallback strategy similar to that described in [RFC6891] section A fallback strategy similar to that described in [RFC6891] section
6.2.2 SHOULD be employed to avoid persistent interference due to non- 6.2.2 SHOULD be employed to avoid persistent interference due to non-
clean paths. clean paths.
6.5. Anycast Considerations 6.6. 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 edns-chain-query option effectively undetectable by the client. The CHAIN option SHOULD NOT
SHOULD NOT be included in responses using UDP transport from servers be included in responses using UDP transport from servers provisioned
provisioned using anycast unless all anycast server nodes are capable using anycast unless all anycast server nodes are capable of
of processing the edns-query-chain option. processing the CHAIN option.
Changes in network topology between clients and anycast servers may Changes in network topology between clients and anycast servers may
cause disruption to TCP sessions making use of edns-chain-query more cause disruption to TCP sessions making use of CHAIN more often than
often than with TCP sessions that omit it, since the TCP sessions are with TCP sessions that omit it, since the TCP sessions are expected
expected to be longer-lived. Anycast servers MAY make use of TCP to be longer-lived. Anycast servers MAY make use of TCP multipath
multipath [RFC6824] to anchor the server side of the TCP connection [RFC6824] to anchor the server side of the TCP connection to an
to an unambiguously-unicast address in order to avoid disruption due unambiguously-unicast address in order to avoid disruption due to
to topology changes. topology changes.
7. Implementation Status 7. Implementation Status
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC6982]. Internet-Draft, and is based on a proposal described in [RFC6982].
The description of implementations in this section is intended to The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort here does not imply endorsement by the IETF. Furthermore, no effort
skipping to change at page 10, line 20 skipping to change at page 10, line 26
8. Security Considerations 8. Security Considerations
8.1. Amplification Attacks 8.1. 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 query-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 Query Chain answers to clients A Recursive Resolver MUST NOT return CHAIN answers to clients over
over UDP without source IP address verification. An example of UDP UDP without source IP address verification. An example of UDP based
based source IP address verification is [DNS-COOKIES]. A Recursive source IP address verification is [EDNS-COOKIE]. A Recursive
Resolver refusing a Query Chain request MUST ignore the ends-query- Resolver refusing a CHAIN option MUST respond with a zero-length
chain option and answering the DNS request as if it was received CHAIN option to indicate support for CHAIN queries when a proper
without the ends-query-chain option. It MUST NOT send an RCODE of transport is used. It MUST NOT send an RCODE of REFUSED.
REFUSED.
A Recursive Resolver SHOULD signal support in response to a zero-
length edns-chain-query request over UDP by responding with an zero-
length edns-chain-query option even without source IP address
verification. This allows a client to detect edns-chain-query
support without the need for [DNS-COOKIES] or TCP.
9. Examples 9. Examples
9.1. Simple Query for example.com 9.1. Simple Query for 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 Forwarder running on
localhost to resolve the A record of "www.example.com." by sending localhost to resolve the A record of "www.example.com." by sending
a regular DNS UDP query on port 53 to 127.0.0.1. a regular DNS UDP query on port 53 to 127.0.0.1.
o The Forwarder on the client machine checks its cache, and notices o The Forwarder on the client machine checks its cache, and notices
it already has a DNSSEC validated entry of "com." in its cache. it already has a DNSSEC validated entry of "com." in its cache.
This includes the DNSKEY RRset with its RRSIG records. In other This includes the DNSKEY RRset with its RRSIG records. In other
words, according to its cache, ".com" is DNSSEC validated as words, according to its cache, ".com" is DNSSEC validated as
"secure" and can be used to continue a DNSSEC validated chain. "secure" and can be used to continue a DNSSEC validated chain.
o The Forwarder on the client opens a TCP connection to its upstream o The Forwarder on the client opens a TCP connection to its upstream
Recursive Resolver on port 53. It adds the edns-chain-query Recursive Resolver on port 53. It adds the CHAIN option as
option as follows: follows:
* Option-code, set to [TBD]
* Option-code, set to [TBD1]
* Option-length, set to 0x00 0x04 * Option-length, set to 0x00 0x04
* Last Known Query Name set to "com." * Closest Trust Point set to "com."
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 edns-chain-query Last Known Query Name set to "com.". After the CHAIN Closest Trust Point set to "com.". After accepting the
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 edns-chain-query "www.example.com.". It does so without using the CHAIN option -
option - unless it is also configured as a Forwarder. The answer unless it is also configured as a Forwarder. The answer to the
to the original DNS question could be the actual A record, the original DNS question could be the actual A record, the DNSSEC
DNSSEC proof of non-existence, or an insecure NXDOMAIN response. proof of non-existence, or an insecure NXDOMAIN response.
o The upstream Recursive Resolver adds the edns-chain-query option o The upstream Recursive Resolver adds the CHAIN option to the DNS
to the DNS answer reply as follows: response as follows:
* Option-code, set to [TBD] * Option-code, set to [TBD1]
* Option-length, set to 0x00 0x00 * Option-length, set to 0x00 0x00
* The Last Known Query Name is ommited (zero length) * The Closest Trust Point is ommited (zero length)
o The upstream Recursive Resolver constructs the DNS Authority o The upstream Recursive Resolver constructs the DNS Authority
Section and fills it with: Section and fills it 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-existance, such as NSEC or NSEC3 records, to adds the proof of non-existence, 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 and fills it with: Section 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 (no-data 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
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 Forwarder receives the DNS answer. It processes the Authority o The Forwarder receives the DNS answer. It processes the Authority
skipping to change at page 12, line 28 skipping to change at page 12, line 28
over the entries in the Authority and Answer Sections. When an over the entries in the Authority and Answer Sections. When an
entry is validated for its cache, it is removed from the entry is validated for its cache, it is removed from the
processing list. If an entry cannot be validated it is left in processing list. If an entry cannot be validated it is left in
the process list. When the end of the list is reached, the list the process list. When the end of the list is reached, the list
is processed again until either all entries are placed in the is processed again until either all entries are placed in the
cache, or the remaining items cannot be placed in the cache due to cache, or the remaining items cannot be placed in the cache due to
lack of validation. Those entries are then discarded. lack of validation. Those entries are then 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 edns-chain-query answer packet. This packet MUST NOT contain an CHAIN option. If
option. If no valid answer can be returned, normal error no valid answer can be returned, normal error processing is done.
processing is done. For example, an NXDOMAIN or an empty Answer For example, an NXDOMAIN or an empty Answer Section could be
Section could be returned depending on the error condition. returned depending on the error condition.
9.2. Out-of-path Query for example.com 9.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 edns-chain-query option with the example.com. It includes the CHAIN option with the following
following parameters: parameters:
o Option-code, set to [TBD] o Option-code, set to [TBD1]
o Option-length, set to 0x00 0x0D o Option-length, set to 0x00 0x0D
o The Last Known Query Name set to 'unrelated.ca.' o The Closest Trust Point set to 'unrelated.ca.'
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 RCODE "FormErr". "example.com", the Resolving Nameserver answers with an empty CHAIN
It includes the edns-chain-query with the following parameters: specified using:
o Option-code, set to [TBD] o Option-code, set to [TBD1]
o Option-length, set to 0x00 0x00 o Option-length, set to 0x00 0x00
o The Last Known Query Name is ommited (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
a query that did not specify the CHAIN option.
9.3. Non-existent data 9.3. Non-existent 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 edns-chain-query option "ipv6.toronto.redhat.ca". It includes the CHAIN option with the
with the following parameters: following parameters:
o Option-code, set to [TBD] o Option-code, set to [TBD1]
o Option-length, set to 0x00 0x03 o Option-length, set to 0x00 0x03
o The Last Known Query Name 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 Answer
Section. The Authority Section contains NSEC3 and RRSIG records Section. The Authority Section contains NSEC3 and RRSIG records
proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca". 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
edns-chain-query option parameters: CHAIN option parameters:
o Option-code, set to [TBD] o Option-code, set to [TBD1]
o Option-length, set to 0x00 0x00 o Option-length, set to 0x00 0x00
o The Last Known Query Name is ommited (zero length) o The Closest Trust Point is ommited (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 (eg ns[01].redhat.ca) o The NS RRset for "redhat.ca." plus RRSIGs (eg ns[01].redhat.ca)
skipping to change at page 14, line 4 skipping to change at page 14, line 6
o The NS RRset for "redhat.ca." plus RRSIGs (eg 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 (eg
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 10. IANA Considerations
10.1. EDNS0 option code for edns-chain-query 10.1. EDNS0 option code for CHAIN
IANA has assigned option code [TBD] in the "DNS EDNS0 Option Codes IANA has assigned option code [TBD1] in the "DNS EDNS0 Option Codes
(OPT)" registry to edns-chain-query. (OPT)" registry to CHAIN.
11. Acknowledgements 11. Acknowledgements
Andrew Sullivan pointed out that we do not need any new data formats Andrew Sullivan pointed out that we do not need any new data formats
to support DNS chains. Olafur Gudmundsson ensured the RRsets are to support DNS chains. Olafur Gudmundsson ensured the RRsets are
returned in the proper Sections. Thanks to Tim Wicinski for his returned in the proper Sections. Thanks to Tim Wicinski for his
thorough review. thorough review.
12. Normative References 12. Normative References
[DNS-COOKIES]
Eastlake, Donald., "Domain Name System (DNS) Cookies",
draft-ietf-dnsop-cookies (work in progress), August 2015.
[DNS-TERMINOLOGY] [DNS-TERMINOLOGY]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-hoffman-dns-terminology (work in Terminology", draft-ietf-dnsop-dns-terminology-05 (work in
progress), March 2015. progress), September 2015.
[EDNS-COOKIE]
Eastlake, Donald., "Domain Name System (DNS) Cookies",
draft-ietf-dnsop-cookies (work in progress), August 2015.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. 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, November 1987. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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", RFC
4033, March 2005. 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. [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, March 2005. 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. [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, March 2005. 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 [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, DOI 10.17487/
RFC6891, April 2013, 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 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982, DOI Code: The Implementation Status Section", RFC 6982, DOI
10.17487/RFC6982, July 2013, 10.17487/RFC6982, July 2013,
<http://www.rfc-editor.org/info/rfc6982>. <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>.
[TCP-KEEPALIVE] [TCP-KEEPALIVE]
Wouters, P., "The edns-tcp-keepalive EDNS0 Option", draft- Wouters, P., Abley, J., Dickinson, S., and R. Bellis, "The
wouters-edns-tcp-keeaplive (work in progress), February edns-tcp-keepalive EDNS0 Option", draft-ietf-dnsop-edns-
2014. tcp-keepalive-03 (work in progress), September 2015.
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. 78 change blocks. 
230 lines changed or deleted 240 lines changed or added

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