< draft-ietf-dnsop-edns-chain-query-01.txt   draft-ietf-dnsop-edns-chain-query-02.txt >
dnsop P. Wouters dnsop P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Intended status: Standards Track October 27, 2014 Intended status: Standards Track March 09, 2015
Expires: April 30, 2015 Expires: September 10, 2015
Chain Query requests in DNS Chain Query requests in DNS
draft-ietf-dnsop-edns-chain-query-01 draft-ietf-dnsop-edns-chain-query-02
Abstract Abstract
This document defines an EDNS0 extension that can be used by a DNSSEC This document defines an EDNS0 extension that can be used by a
enabled Recursive Nameserver configured as a forwarder to send a security-aware validating Resolver configured as a Forwarder to send
single DNS query requesting to receive a complete validation path a single query, requesting a complete validation path along with the
along with the regular DNS answer, without the need to rapid-fire regular query answer. The reduction in queries lowers the latency.
many UDP requests in an attempt to attain a low latency. This extension requries the use of source IP verified transport such
as TCP or UDP with DNS-COOKIES so it cannot be abused in
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 30, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 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. Generating a Query . . . . . . . . . . . . . . . . . . . 5 5.2. Generate a Query . . . . . . . . . . . . . . . . . . . . 5
5.3. Generating a Response . . . . . . . . . . . . . . . . . . 6 5.3. Send the Option . . . . . . . . . . . . . . . . . . . . . 6
5.4. Sending the Option . . . . . . . . . . . . . . . . . . . 7 5.4. Generate a Response . . . . . . . . . . . . . . . . . . . 6
6. Protocol Considerations . . . . . . . . . . . . . . . . . . 7 6. Protocol Considerations . . . . . . . . . . . . . . . . . . . 7
6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7
6.2. NS record Considerations . . . . . . . . . . . . . . . . 7 6.2. NS record Considerations . . . . . . . . . . . . . . . . 8
6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8 6.3. TCP Session Management . . . . . . . . . . . . . . . . . 8
6.4. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 8 6.4. Non-Clean Paths . . . . . . . . . . . . . . . . . . . . . 9
6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 8 6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Amplification Attacks . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . 12 9.3. Non-existent data . . . . . . . . . . . . . . . . . . . . 13
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. EDNS0 option code for edns-chain-query . . . . . . . . . 13 10.1. EDNS0 option code for edns-chain-query . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
12. Normative References . . . . . . . . . . . . . . . . . . . . 14 12. Normative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Traditionally, clients operate in stub-mode for DNS. For each DNS Traditionally, a DNS client operates in stub-mode. For each DNS
question the client needs to resolve, it sends a single query to an question the DNS client needs to resolve, it sends a single query to
upstream DNS resolver to obtain a single DNS answer. When DNSSEC an upstream Recursive Resolver to obtain a single DNS answer. When
[RFC4033] is deployed on such clients, validation requires that the DNSSEC [RFC4033] is deployed on such DNS clients, validation requires
client obtains all the (intermediate) information from the DNS root that the client obtains all the intermediate information from the DNS
down to the queried-for hostname so it can perform DNSSEC validation root down to the queried-for hostname so it can perform DNSSEC
on the complete chain of trust. This process increases the number of validation on the complete chain of trust.
DNS queries and answers required, and thus increases the latency
before a validated DNS answer has been obtained.
Currently, applications use a rapid-fire approach to send out many Currently, applications send out many UDP requests concurrently.
UDP requests concurrently. This requires more resources on the DNS This requires more resources on the DNS client with respect to state
client with respect to state (cpu, memory, battery) and bandwidth. (cpu, memory, battery) and bandwidth. There is also no guarantee
There is also no guarantee that the initial burst of UDP questions that the initial set of UDP questions will result in all the records
will result in all the records required for DNSSEC validation, and required for DNSSEC validation. More round trips could be required
more round trips could be required depending on the resulting DNS depending on the resulting DNS answers. This especially affects
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
recursive name server running as a forwarder to request another Resolver running as a Forwarder to open a TCP connection to another
recursive name server for a DNS chain answer using one DNS query/ Resolver and request a DNS chain answer using one DNS query/answer
answer pair. This reduces the number of round-trip times ("RTT") to pair. This reduces the number of round-trip times ("RTT") to two.
two. If combined with [TCP-KEEPALIVE] there is only 1 RTT. While If combined with long livd TCP or [TCP-KEEPALIVE] there is only 1
the upstream DNS resolver still needs to perform all the individual RTT. 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 DNS Forwarder to indicate which part
the DNS hierarchy it already contains in its cache. This reduces the of the DNS hierarchy it already contains in its cache. This reduces
amount of data required to be transferred and reduces the work the the amount of data required to be transferred and reduces the work
upstream Resolving Nameserver has to perform. the upstream Recursive Resolver has to perform.
This EDNS0 extension is only intended for Forwarders. It can (and This EDNS0 extension is only intended to be sent by Forwarders to
should be) ignored by Authoritative Nameservers and by Recursive Recursive Resolvers. It can (and should be) ignored by Authoritative
Nameservers that do not support this EDNS0 option. 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
Stub Resolver: A simple DNS protocol implementation on the client The DNS terminology used in this document is that of
side as described in [RFC1034] section 5.3.1. [DNS-TERMINOLOGY]. Additionally, the following terms are used:
[edit: which I hope will end up in the terminology document]
Authoritative Nameserver: A nameserver that has authority over one
or more DNS zones. These are normally not contacted by clients
directly but by Recursive Resolvers. Described in [RFC1035]
chapter 6.
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. 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. DNSSEC [RFC4033] validation. Also known as "security-aware
resolver".
Forwarder: A Recursive Resolver that is using another (upstream)
Recursive Resolver instead of querying Authoritative Nameservers
directly. It still performs validation.
3. Overview 3. Overview
When DNSSEC is deployed on the host, it can no longer delegate all
When DNSSEC is deployed on the client, it can no longer delegate all DNS work to the upstream Recursive Resolver. Obtaining just the DNS
DNS work to the upstream Resolving Nameserer. 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 client requires a locally running For DNSSEC validation, the DNS client requires a locally running
validating DNS server configured as Resolving Nameserver so it can validating Resolver so it can confirm DNSSEC validation of all
confirm DNSSEC validation of all intermediary DNS answers. It can intermediary DNS answers. It can configure itself as a DNS Forwarder
configure itself as a Forwarder if the DHCP server has indicated that if it obtains the IP addresses of one or more Recursive Resolvers
one or more Resolving Nameservers are available. Regardless, that are available, or as a stand-alone Recursive Resolver if no
generating the required queries for validation adds a significant functional Recursive Resolvers were obtained. Generating the
delay in answering the DNS question of the locally running required queries for validation adds a significant delay in answering
application. The application has to wait while the Forwarder on the the DNS question of the locally running application. The application
client is querying for all the intermediate work. Each round-trip must wait while the Resolver validates all intermediate answers.
adds to the total time waiting on DNS resolving to complete. This Each round-trip adds to the total time waiting on DNS resolution with
makes DNSSEC resolving impractical on networks with a high latency. validation to complete. This makes DNSSEC resolving impractical for
devices on networks with a high latency.
The edns-chain-query option allows the client to request all The edns-chain-query option allows the Resolver to request all
intermediate DNS data it requires to resolve and validate a intermediate DNS data it requires to resolve and validate a
particular DNS answer in a single round-trip DNS query and answer. particular DNS answer in a single round-trip. The Resolver could be
part of the application or a Recursive Resolver running on the host.
Servers answering with chain query data exceeding 512 bytes should Servers answering with chain query data exceeding 512 bytes should
ensure that the transport is TCP or source IP address verified UDP. ensure that the transport is TCP or source IP address verified UDP.
See Section 8. This avoids abuse in DNS amplification attacks. See Section 8. This avoids abuse in DNS amplification attacks.
Applications that support edns-chain-query internally can perform
validation without requiring the host the run a Recursive Resolver.
This is particularly useful for virtual servers in a cloud or
container based deployment where it is undesirable to run a Recursive
Resolver per virtual machine.
The format of this option is described in Section 4. The format of this option is described in Section 4.
As described in Section 5.3, a recursive nameserver could use this As described in Section 5.4, a Recursive Resolver could use this
EDNS0 option to include additional data required by the client in the EDNS0 option to include additional data required by the Resolver in
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 edns-chain-query EDNS0 option MAY be sent over any transport
as a discovery method. A DNS server receiving such an empty edns- as a discovery method. A DNS server receiving such an empty edns-
chain-query option SHOULD add an empty edns-chain-query option in its chain-query option SHOULD add an empty edns-chain-query option in its
answer to indicate that it supports edns-chain-query for source IP answer to indicate that it supports edns-chain-query for source IP
address verified transports. address verified transports.
The mechanisms provided by edns-chain-query raise various security The mechanisms provided by edns-chain-query raise various security
related concerns, related to the additional work, bandwidth, related concerns, related to the additional work, bandwidth,
amplification attacks as well as privacy issues with the cache. amplification attacks as well as privacy issues with the cache.
These concerns are described in Section 8. These concerns are described in Section 8.
4. Option Format 4. Option Format
This draft uses an EDNS0 ([RFC2671]) 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) ~ ~ Last Known Query Name (FQDN) ~
+---------------------------------------------------------------+ +---------------------------------------------------------------+
o (Defined in [RFC2671]) OPTION-CODE, 2 octets, for edns-chain-query o OPTION-CODE, 2 octets, for edns-chain-query is [TBD].
is [TBD].
o (Defined in [RFC2671]) OPTION-LENGTH, 2 octets, contains the o OPTION-LENGTH, 2 octets, contains the length of the payload
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 Last Known Query Name, a variable length FDQN of the requested
start point of the chain. This entry is the 'lowest' known entry start point of the chain. This entry is the 'lowest' known entry
in the DNS chain known by the recursive server seeking a edns- in the DNS chain known by the recursive server seeking a edns-
chain-query answer. The end point of the chain is obtained from chain-query answer. The end point of the chain is obtained from
the DNS Query Section itself. No compression is allowed for this the DNS Query Section itself. No compression is allowed for this
value. value.
o Assigned by IANA in IANA-AFI [1].
5. Protocol Description 5. Protocol Description
5.1. Discovery of Support 5.1. Discovery of Support
A Forwarder may include a zero-length edns-chain-query option in A DNS Forwarder may include a zero-length edns-chain-query option in
queries over UDP or TCP to discover the DNS server capability for queries over any transport to discover the DNS server capability for
edns-chain-query. DNS Servers that support and are willing to accept edns-chain-query. Recursive Resolvers that support and are willing
chain queries over TCP SHOULD respond to a zero-length edns-chain- to accept chain queries over source IP verified transport respond to
query received over UDP or TCP queries by including a zero-length a zero-length edns-chain-query received by including a zero-length
edns-chain-query option in the answer. A Forwarder MAY then switch edns-chain-query option in the answer. A DNS Forwarder MAY then
to the TCP transport and sent a non-zero edns-chain-query value to switch to a source IP verified transport and sent a non-zero edns-
request a chain-query response from the DNS server. chain-query value to request a chain-query response from the
Recursive Resolver. Examples of source IP verification is the 3-way
5.2. Generating a Query TCP handshake and UDP with [DNS-COOKIES].
The edns-chain-query option should generally be deployed by
Forwarders, as described in Section 5.4.
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 last known entry point
in the chain - furthest from the root - that it already has a DNSSEC in 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. described in Section 9.1.
Depending on the size of the labels of the last known entry point Depending on the size of the labels of the last known entry point
value, a DNS Query packet could be arbitrarily large. If using the value, a DNS Query packet could be arbitrarily large. If using the
last known entry point would result in a query size of more then 512 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 bytes, the last known entry point should be replaced with its parent
entry until the query size would be 512 bytes or less. entry until the query size would be 512 bytes or less. A separate
query should be send for the remainder of the validation chain.
5.3. Generating a Response 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
When edns-chain-query is available, the downstream Recursive Resolver
can adjust its query strategy based on the desired queries and its
cache contents.
A DNS Forwarder can request the edns-chain-query option with every
outgoing DNS query. However, it is RECOMMENDED that DNS Forwarders
remember which upstream Recursive Resolvers did not return the option
(and additional data) with their response. The DNS Forwarder SHOULD
fallback to regular DNS for subsequent queries to those Recursive
Resolvers. It MAY switch to another Resolving Resolver that does
support the edns-chain-query option or try again later to see if the
server has become less loaded and is now willing to answer with Query
Chains.
5.4. Generate a Response
When a query containing a non-zero edns-chain-query option is When a query containing a non-zero edns-chain-query option is
received over a TCP connection from a Forwarder, the upstream received from a DNS Forwarder, the upstream Recursive Resolver
Recursive Resolver supporting edns-chain-query MAY respond by supporting edns-chain-query MAY respond by confirming that it is
confirming that it is returning a DNS Query Chain. To do so, it MUST returning a DNS Query Chain. To do so, it MUST set the edns-chain-
set the edns-chain-query option with an OPTION-LENGTH of zero to query option with an OPTION-LENGTH of zero to indicate the DNS answer
indicate the DNS answer contains a Chain Query. It extends the contains a Chain Query. It extends the Authority Section in the DNS
Authority Section for the DNS answer packet with the required DNS answer packet with the DNS RRSets required for validating the answer.
RRSets resulting in an Authority Section that contains a complete The DNS RRsets added start with the first chain element below the
chain of DNS RRsets that start with the first chain element below the received Last Known Query Name up to and including the NS and DS
received Last Known Query Name upto and including the NS and DS
RRsets that represent the zone cut (authoritative servers) of the RRsets that represent the zone cut (authoritative servers) of the
QNAME. The actual DNS answer to the question in the Query Section is QNAME. The actual DNS answer to the question in the Query Section is
placed in the DNS Answer Section identical to traditional DNS placed in the DNS Answer Section identical to the traditional DNS
answers. If the received query has the DNSSEC OK flag set, all answer. All required DNSSEC related records must be added to their
required DNSSEC related records must be added to their appropriate appropriate sections. This includes records required for proof of
sections. This includes records required for proof of non-existence non-existence of regular and/or wildcard records, such as NSEC or
of regular and/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 edns-chain-query option, or are otherwise unwilling to perform
the additional work for a Chain Query due to work load, may safely the additional work for a Chain Query due to work load, may safely
ignore the option in the incoming queries. Such a server MUST NOT ignore the option in the incoming queries. Such a server MUST NOT
include an edns-chain-query option when sending DNS answer replies include an edns-chain-query option when sending DNS answer replies
back, thus indicating it is not able to support Chain Queries at this back, thus indicating it is not able or willing to support Chain
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 [RFC2671], Transport Considerations. 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 sending a REFUSED response to the sender,
as described by [RFC2671], Transport Considerations. This refusal as described by [RFC6891]. This refusal can be used for chains that
can be used for chains that would be too big or chains that would would be too big or chains that would reveal too much information
reveal too much information considered private. considered private.
At any time, a DNS server that has determined that it is running low At any time, a Recursive Resolver that has determined that it is
on resources can refuse to acknowledge a Chain Query by omitting the running low on resources can refuse to acknowledge a Chain Query by
edns-chain-query option. It may do so even if it conveyed support to omitting the edns-chain-query option in its reply. It may do so even
a DNS client previously. If [TCP-KEEPALIVE] is used, it may even if it conveyed support to a DNS client previously. It may even
change its support for edns-chain-query within the same TCP session. change its support for edns-chain-query within the same TCP session.
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 DNS server MUST return these records in the Answer Section, the Recursive Resolver MUST return these records in the
Section similar to regular DNS processing. The CNAME or DNAME target Answer Section similar to regular DNS processing. The CNAME or DNAME
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 is also records for DNSSEC validation of the CNAME or DNAME target are also
added to the Authority Section. added to the Authority Section.
In any case, the response from the receiving resolver to the client The response from a Recursive Resolver to a Resolver MUST NOT contain
resolver MUST NOT contain the edns-chain-query option if none was the edns-chain-query option if none was present in the Resolver's
present in the client's resolver original request. original request.
5.4. Sending the Option
When edns-chain-query is available, the downstream Resolving
Nameserver can adjust its query strategy based on the desired queries
and its cache contents.
A Forwarder can request the edns-chain-query option with every A DNS query that contains the edns-chain-query option MUST also have
outgoing DNS query. However, it is RECOMMENDED that Forwarders the DNSSEC OK bit set. If this bit is not set, the edns-chain-query
remember which upstream Resolving Nameservers did not return the option received MUST be ignored.
option (and additional data) with their response. The Forwarder
SHOULD fallback to regular DNS for subsequent queries to those
Recursive Nameservers. It MAY switch to another Resolving Nameserver
that does support the edns-chain-query option or try again later to
see if the server has become less loaded and is now willing to answer
with Query Chains.
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- 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 chain-query option in a DNS query does not change the usage of those
resource records and mechanisms used to provide data origin resource records and mechanisms used to provide data origin
authentication and data integrity to the DNS, as described in authentication and data integrity to the DNS, as described in
[RFC4033], [RFC4034] and [RFC4035]. [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 edns-chain-query responses MUST include the NS RRset from the child
zone, which includes DNSSEC RRSIG records required for validation. zone, which includes DNSSEC RRSIG records required for validation.
When a DNSSEC chain is supplied via edns-chain-query, the Forwarder When a DNSSEC chain is supplied via edns-chain-query, the DNS
no longer requires to use the NS RRset, as it can construct the Forwarder no longer requires to use the NS RRset, as it can construct
validation path via the DNSKEY and DS RRsets without using the NS the validation path via the DNSKEY and DS RRsets without using the NS
RRset. However, it is prefered that the Forwarder can populate its RRset. However, the DNS Forwarder might be forced to switch from
cache with this information regardless, to avoid requiring queries in Forwarder mode to Recursive Resolver mode due to a network topology
the future just to obtain the missing NS records. This can happen on change. In Recursive Resolver mode, it requires the NS RRsets to
a roaming device that needs to swich from using a DHCP obtained DNS find and query Authoritative Servers directly. It is preferred that
server as forwarder to running in full autonomous resolver mode, for the DNS Forwarder populate its cache with this information to avoid
example when the DHCP obtained DNS server is broken in some way. requiring future queries to obtain any missing NS records. Therefor,
edns-chain-query responses MUST include the NS RRset from the child
zone, which includes DNSSEC RRSIG records required for validation.
6.3. TCP Session Management 6.3. TCP Session Management
It is recommended that TCP Chain Queries are used in combination with It is recommended that TCP sessions to the Recursive Resolver are not
[TCP-KEEPALIVE]. immediately closed after the DNS answer to the first query is
received. It is recommended to 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 TCP Chain Queries can be which will limit the extent to which Chain Queries can be executed.
executed. Effective limits for the number of active sessions that Effective limits for the number of active sessions that can be
can be maintained on individual clients and servers should be maintained on individual clients and servers should be established,
established, either as configuration options or by interrogation of either as configuration options or by interrogation of process limits
process limits imposed by the operating system. imposed by the operating system.
In the event that there is greater demand for TCP Chain Queries than In the event that there is greater demand for Chain Queries than can
can be accommodated, DNS servers may stop advertising the edns-query- be accommodated, DNS servers may stop advertising the edns-query-
chain option in successive DNS messages. This allows, for example, chain option in successive DNS messages. This allows, for example,
clients with other candidate servers to query to establish new TCP clients with other candidate servers to query to establish new
sessions with different servers in expectation that those servers sessions with different servers in expectation that those servers
might still allow TCP Chain Queries. might still allow Chain Queries.
6.4. Non-Clean Paths 6.4. Non-Clean Paths
Many paths between DNS clients and servers suffer from poor hygiene, Many paths between DNS clients and Recursive Resolvers suffer from
limiting the free flow of DNS messages that include particular EDNS0 poor hygiene, limiting the free flow of DNS messages that include
options, or messages that exceed a particular size. A fallback particular EDNS0 options, or messages that exceed a particular size.
strategy similar to that described in [RFC6891] section 6.2.2 SHOULD A fallback strategy similar to that described in [RFC6891] section
be employed to avoid persistent interference due to non-clean paths. 6.2.2 SHOULD be employed to avoid persistent interference due to non-
clean paths.
6.5. Anycast Considerations 6.5. Anycast Considerations
DNS servers of various types are commonly deployed using anycast Recursive Resolvers of various types are commonly deployed using
[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 edns-chain-query option
SHOULD NOT be included in responses using UDP transport from servers SHOULD NOT be included in responses using UDP transport from servers
provisioned using anycast unless all anycast server nodes are capable provisioned using anycast unless all anycast server nodes are capable
of processing the edns-query-chain option. of processing the edns-query-chain option.
Changes in network topology between clients and anycast servers may Changes in network topology between clients and anycast servers may
skipping to change at page 10, line 5 skipping to change at page 10, line 20
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 nameserver MUST NOT return Query Chain answers to clients A Recursive Resolver MUST NOT return Query Chain answers to clients
over UDP without source IP address verification, for instance using over UDP without source IP address verification. An example of UDP
[EASTLAKE-COOKIES]. A recursive nameserver SHOULD signal support in based source IP address verification is [DNS-COOKIES]. A Recursive
response to a Query Chain request over UDP by responding using a Resolver refusing a Query Chain request MUST ignore the ends-query-
zero-length edns-chain-query option over UDO even without source IP chain option and answering the DNS request as if it was received
address verification. without the ends-query-chain option. It MUST NOT send an RCODE of
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
1. 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 localhost to resolve the A record of "www.example.com." by sending
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.
2. The Forwarder on the client machine checks its cache, and
notices it already has a DNSSEC validated entry of "com." in its
cache. This includes the DNSKEY RRset with its RRSIG records.
In other words, according to its cache, ".com" is DNSSEC
validated as "secure" and can be used to continue a DNSSEC
validated chain on.
3. The Forwarder on the client opens a TCP connection to its o The Forwarder on the client machine checks its cache, and notices
upstream Recursive Resolver on port 53. It adds the edns-chain- it already has a DNSSEC validated entry of "com." in its cache.
query option as follows: This includes the DNSKEY RRset with its RRSIG records. In other
words, according to its cache, ".com" is DNSSEC validated as
"secure" and can be used to continue a DNSSEC validated chain.
* Option-code, set to [TBD] o The Forwarder on the client opens a TCP connection to its upstream
Recursive Resolver on port 53. It adds the edns-chain-query
option as follows:
* Option-length, set to 0x00 0x04 * Option-code, set to [TBD]
* Last Known Query Name set to "com." * Option-length, set to 0x00 0x04
4. The upstream Recursive Resolver receives a DNS query over TCP * Last Known Query Name set to "com."
with the edns-chain-query Last Known Query Name set to "com.".
After accepting the query it starts constructing a DNS reply
packet.
5. The upstream Recursive Resolver performs all the regular work to o The upstream Recursive Resolver receives a DNS query over TCP with
ensure it has all the answers to the query for the A record of the edns-chain-query Last Known Query Name set to "com.". After
"www.example.com.". It does so without using the edns-chain- accepting the query it starts constructing a DNS reply packet.
query option - unless it is also configured as a Forwarder. The
answer to the original DNS question could be the actual A
record, the DNSSEC proof of non-existence, or an insecure
NXDOMAIN response.
6. The upstream Recursive Resolver adds the edns-chain-query option o The upstream Recursive Resolver performs all the regular work to
to the DNS answer reply as follows: 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
option - unless it is also configured as a Forwarder. The answer
to the original DNS question could be the actual A record, the
DNSSEC proof of non-existence, or an insecure NXDOMAIN response.
* Option-code, set to [TBD] o The upstream Recursive Resolver adds the edns-chain-query option
to the DNS answer reply as follows:
* Option-length, set to 0x00 0x00 * Option-code, set to [TBD]
* The Last Known Query Name is ommited (zero length) * Option-length, set to 0x00 0x00
7. The upstream Recursive Resolver constructs the DNS Authority * The Last Known Query Name is ommited (zero length)
Section and fills it with:
* The DS RRset for "example.com." and its corresponding RRSIGs o The upstream Recursive Resolver constructs the DNS Authority
(made by the "com." DNSKEY(s)) Section and fills it with:
* The DNSKEY RRset for "example.com." and its corresponding * The DS RRset for "example.com." and its corresponding RRSIGs
RRSIGs (made by the "example.com" DNSKEY(s)) (made by the "com." DNSKEY(s))
* The authoritative NS RRset for "example.com." and its * The DNSKEY RRset for "example.com." and its corresponding
corresponding RRSIGs (from the child zone) RRSIGs (made by the "example.com" DNSKEY(s))
If the answer does not exist, and the zone uses DNSSEC, it also * The authoritative NS RRset for "example.com." and its
adds the proof of non-existance, such as NSEC or NSEC3 records, corresponding RRSIGs (from the child zone)
to the Authority Section.
8. The upstream Recursive Resolver constructs the DNS Answer If the answer does not exist, and the zone uses DNSSEC, it also
Section and fills it with: adds the proof of non-existance, such as NSEC or NSEC3 records, to
the Authority Section.
* The A record of "www.example.com." and its corresponding o The upstream Recursive Resolver constructs the DNS Answer
RRSIGs Section and fills it with:
If the answer does not exist (no-data or NXDOMAIN), the Answer * The A record of "www.example.com." and its corresponding RRSIGs
Section remains empty. For the NXDOMAIN case, the RCode of the If the answer does not exist (no-data or NXDOMAIN), the Answer
DNS answer packet is set to NXDOMAIN. Otherwise it remains Section remains empty. For the NXDOMAIN case, the RCode of the
NOERROR. DNS answer packet is set to NXDOMAIN. Otherwise it remains
NOERROR.
9. 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.
10. The Forwarder receives the DNS answer. It processes the o The Forwarder receives the DNS answer. It processes the Authority
Authority Section and the Answer Section and places the Section and the Answer Section and places the information in its
information in its local cache. It ensures that no data is local cache. It ensures that no data is accepted into the cache
accepted into the cache without having proper DNSSEC validation. without having proper DNSSEC validation. It MAY do so by looping
It MAY do so by looping over the entries in the Authority and over the entries in the Authority and Answer Sections. When an
Answer Sections. When an entry is validated for its cache, it entry is validated for its cache, it is removed from the
is removed from the processing list. If an entry cannot be processing list. If an entry cannot be validated it is left in
validated it is left in the process list. When the end of the the process list. When the end of the list is reached, the list
list is reached, the list is processed again until either all is processed again until either all entries are placed in the
entries are placed in the cache, or the remaining items cannot cache, or the remaining items cannot be placed in the cache due to
be placed in the cache due to lack of validation. Those entries lack of validation. Those entries are then discarded.
are then disgarded.
11. 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 edns-chain-query
option. If no valid answer can be returned, normal error option. If no valid answer can be returned, normal error
processing is done. For example, an NXDOMAIN or an empty Answer processing is done. For example, an NXDOMAIN or an empty Answer
Section could be returned depending on the error condition. Section could be 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 edns-chain-query option with the
following parameters: following parameters:
o Option-code, set to [TBD] o Option-code, set to [TBD]
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 Last Known Query Name set to 'unrelated.ca.'
skipping to change at page 12, line 33 skipping to change at page 13, line 4
o The Last Known Query Name set to 'unrelated.ca.' o The Last Known Query Name 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 RCODE "FormErr".
It includes the edns-chain-query with the following parameters: It includes the edns-chain-query with the following parameters:
o Option-code, set to [TBD] o Option-code, set to [TBD]
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 Last Known Query Name is ommited (zero length)
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 edns-chain-query option
with the following parameters: with the following parameters:
o Option-code, set to [TBD] o Option-code, set to [TBD]
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 Last Known Query Name set to 'ca.'
skipping to change at page 14, line 4 skipping to change at page 14, line 18
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 edns-chain-query
IANA has assigned option code [TBD] in the "DNS EDNS0 Option Codes IANA has assigned option code [TBD] in the "DNS EDNS0 Option Codes
(OPT)" registry to edns-chain-query. (OPT)" registry to edns-chain-query.
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. returned in the proper Sections. Thanks to Tim Wicinski for his
thorough review.
12. Normative References 12. Normative References
[EASTLAKE-COOKIES] [DNS-COOKIES]
Eastlake, Donald., "Domain Name System (DNS) Cookies", Eastlake, Donald., "Domain Name System (DNS) Cookies",
draft-eastlake-dnsext-cookies (work in progress), October draft-ietf-dnsop-cookies (work in progress), February
2014. 2015.
[DNS-TERMINOLOGY]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", draft-hoffman-dns-terminology (work in
progress), March 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, November 1987.
[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, November 1987.
[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, March 1997.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[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, March 2005.
[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, March 2005.
[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
skipping to change at page 15, line 14 skipping to change at page 15, line 33
[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, April 2013. for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[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, July Code: The Implementation Status Section", RFC 6982, July
2013. 2013.
[TCP-KEEPALIVE] [TCP-KEEPALIVE]
Wouters, P., "The edns-tcp-keepalive EDNS0 Option", draft- Wouters, P., "The edns-tcp-keepalive EDNS0 Option", draft-
ietf-dnsop-edns-tcp-keeaplive (work in progress), October wouters-edns-tcp-keeaplive (work in progress), February
2014. 2014.
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. 84 change blocks. 
273 lines changed or deleted 284 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/