| dnsext | P. Wouters |
| Internet-Draft | Red Hat |
| Intended status: Standards Track | September 10, 2013 |
| Expires: March 14, 2014 |
TCP chain query requests in DNS
draft-wouters-edns-tcp-chain-query-00
This document defines an EDNS0 extension that can be used by a DNSSEC enabled Recursive Nameserver configured as a forwarder to send a single query over TCP requesting to receive a complete validation path along with the regular query answer. Additionally, use of this option is considered a request to keep the TCP connection open to serve additional DNS requests. Use of this option significantly reduces DNS latency for hosts deploying DNSSEC.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 14, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Traditionally, clients operate in stub-mode for DNS. For each DNS question the client only needs to send a single query to an upstream DNS resolver to obtain a DNS answer. When DNSSEC [RFC4033] is deployed on such clients, validation requires that the client obtains all the (intermediate) information from the DNS root down to the queried-for hostname for the DNSSEC validation of the complete chain of trust.
For example, the validated answer for the question of the A record for the zone "example.com" requires over a hundred DNS queries. That many queries adds a significant number of round-trip delays that is considered unusable by current user expectation. It especially affects web browsers which usually need to lookup dozens of hostnames to render a single web page.
This document specifies an EDNS0 extension that allows a validating recursive name server running as a forwarder to open a TCP connection to another recursive name server, to request a DNS chain answer in one DNS query. This reduces the number of round-trip times ("RTT") to one. While the upstream DNS resolver still needs to perform all these queries, it usually has a much bigger cache and does not experience significant slowdown from last-mile latency problems.
This EDNS0 extension allows the Forwarder to indicate which part of the DNS hierarchy it already contains in its cache. This reduces the amount of data required to be transferred and reduces the work the upstream Resolving Nameserver has to perform.
This EDNS0 extension is only intended for Forwarders. It can (and should be) ignored by Authoritative Nameservers and by Recursive Nameservers that do not support this EDNS0 option.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
When DNSSEC is deployed on the client, it can no longer delegate all DNS work to the upstream Resolving Nameserer. Obtaining just the DNS answer itself is not enough to validate that answer using DNSSEC. For DNSSEC validation, all the intermediate work performed by the upstream Resolving Nameserver is work the client itself needs to perform as well. The client needs a locally running DNS server configured as Resolving Nameserver so it can confirm DNSSEC validation of the DNS answer. It can configure itself as a Forwarder if the DHCP server has indicated that one or more Resolving Nameservers are available. Regardless, generating the required queries for validation adds a significant delay in answering the DNS question of the locally running applications. The application has to wait while the Forwarder on the client is querying for all the intermediate work. Each round-trip adds to the total time waiting on DNS resolving to complete. This makes DNSSEC resolving as a Forwarder very slow, especially on networks with a high latency.
The edns-tcp-chain-query option allows the client to ask for all intermediate DNS data it requires to resolve and validate a particular DNS answer in a single round-trip DNS query. Since this data is practically guaranteed to be larger then the common UDP packet size (and to avoid DNS amplification attacks) the client must use TCP when it wants to use this EDNS0 option. To reduce the round-trip times required for the three-way TCP handshake, servers and clients supporting this option can choose to keep the TCP connection open for re-use of additional TCP queries.
The format of this option is described in Section 4.
As described in Section 5.2, a recursive nameserver could use this EDNS0 option to include additional data required by the client in the Authority Section of the DNS answer packet. The Answer Section remains unchanged from a traditional DNS answer and contains the answer and related DNSSEC entries.
Its reply would contain an EDNS0 edns-tcp-chain-query option, clearly indicating that (1) the server supports this EDNS0 option and (2) it was willing to add the additional data into the DNS Authority section and (3) it is willing to keep the TCP connection open for the client to send another DNS query.
The mechanisms provided by edns-tcp-chain-query raise various security related concerns, related to the additional work and bandwidth as well as privacy issues with the cache. These concerns are described in Section 7.
Failure to support this option or its improper handling will at worst case waste the time of a single TCP DNS request, at which point the recursive resolver on the client will fall back to traditional DNS queries towards the upstream recursive resolver.
This draft uses an EDNS0 ([RFC2671]) option to include client IP information in DNS messages. The option is structured as follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
! OPTION-CODE ! OPTION-LENGTH !
+-------------------------------+-------------------------------+
~ Last Known Query Name (FQDN) ~
+---------------------------------------------------------------+
The edns-tcp-chain-query option should generally be added by Forwarders, as described in Section 5.3.
In this option value, the Forwarder sets the last known entry point in the chain - furthest from the root - that it already has a validated (secure or not) answer for in its cache. The upstream Recursive Resolver does not need to include any part of the chain from the root down to this option's FQDN. A complete example is described in Section 8.
When a query containing an edns-tcp-chain-query option is received over a TCP connection from a Forwarder, the upstream Recursive Resolver supporting edns-tcp-chain-query MAY respond by confirming the edns-tcp-chain-query option with an OPTION-LENGTH of zero. It extends the Authority Section for the DNS answer packet with the required DNS RRSets resulting in an Authority Section that contains a complete chain of DNS RRsets that start with the first chain element below the received Last Known Query Name upto and including the NS and DS RRsets that represent the zone cut (authoritative servers) of the QNAME. The actual DNS answer to the question in the Query Section is placed in the DNS Answer Section identical to traditional DNS answers. If the received query has the DNSSEC OK flag set, all required DNSSEC related records must be added to their appropriate sections. This includes records required for proof of non-existence of regular and/or wildcard records, such as NSEC or NSEC3 records.
Recursive Resolvers that have not implemented or enabled support for the edns-tcp-chain-query option may safely ignore the option within incoming queries. Such a server MUST NOT include an edns-tcp-chain-query option when sending DNS answer replies, thus indicating lack of support for the option.
Requests with wrongly formatted options (i.e. bogus FQDN) MUST be rejected and a FORMERR response must be returned to the sender, as described by [RFC2671], Transport Considerations.
Requests resulting in chains that the receiving resolver is unwilling to serve can be rejected by sending a REFUSED response to the sender, as described by [RFC2671], Transport Considerations. This refusal can be used for chains that would be too big or chains that would reveal too much information considered private.
In any case, the response from the receiving resolver to the client resolver MUST NOT contain the edns-tcp-chain-query option if none was present in the client's resolver original request.
When edns-tcp-chain-querys is available, the downstream Resolving Nameserver can adjust its query strategy based on the desired query and its cache contents.
A Forwarder can send the edns-tcp-chain-query option with every outgoing TCP query. However, it is RECOMMENDED that Forwarders remember which upstream Resolving Nameservers did not return the 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-tcp-chain-query option.
A Forwarder should not open many TCP connections to an upstream resolver if that upstream resolver supports edns-tcp-chain-query. Instead, it should chain its TCP queries over a limited number of TCP connections.
A Forwarder that does not use its TCP connection for 300 seconds SHOULD close its TCP connection. Recursive Resolvers MAY close the TCP connection to a Forwarder at any time.
The presence or absence of an OPT resource record containing an edns-tcp-chain-query option in a DNS query does not change the usage of those resource records and mechanisms used to provide data origin authentication and data integrity to the DNS, as described in [RFC4033], [RFC4034] and [RFC4035].
When a DNSSEC chain is supplied via edns-tcp-chain-query, the Forwarder no longer requires to use the NS RRset, as it can construct the validation path via the DNSKEY and DS RRsets without using the NS RRset. However, the Forwarder might be instructed via a device manager to change from Forwarder to Recursive Resolver. At this point it would require the NS RRsets to perform additional work. Therefor, edns-tcp-chain-query responses MUST include the NS RRset from the child zone, which includes DNSSEC RRSIG records required for validation.
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC6982]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
According to [RFC6982], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".
[While there is some interest, no work has started yet]
edns-tcp-chain-query can potentially send very large answers. A recursive nameserver MUST NOT offer the edns-tcp-chain-query option to clients over UDP. Otherwise, a single spoofed packet could generate extremely large UDP packets back to the spoofed victim's IP address. Such Distributed Denial of Service attacks using other DNS amplification mechanisms are fairly common. It is important that this EDNS option does not give attackers an alternative method of amplification.
It is possible for a malicious Authoritative Nameserver to respond to a regular DNS query with an an excessively long or even infinite chain of delegations. Recursive Resolvers already have code detecting such malicious delegations, and abort such queries after a maximum amount of delegations has been reached. Recursive Resolvers supporting the edns-tcp-chain-query option should not send a partial chain back to the client if such an abort happened, but instead return a REFUSED RCode.
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 the Authority Section.
If the answer does not exist (no-data or NXDOMAIN), the Answer Section remains empty. For the NXDOMAIN case, the RCode of the DNS answer packet is set to NXDOMAIN. Otherwise it remains NOERROR.
A Recursive Resolver receives a query for the A record for example.com. It includes the edns-tcp-chain-query option with the following parameters:
As there is no chain that leads from "unrelated.ca." to "example.com", the Resolving Nameserver answers with RCODE "FormErr". It includes the edns-tcp-chain-query with the following parameters:
A Recursive Resolver receives a query for the A record for "ipv6.toronto.redhat.ca". It includes the edns-tcp-chain-query option with the following parameters:
Using regular UDP queries towards Authoritative Nameservers, it locates the NS RRset for "toronto.redhat.ca.". When querying for the A record it receives a reply with RCODE "NoError" and an empty Answer Section. The Authority Section contains NSEC3 and RRSIG records proving there is no A RRtype for the QNAME "ipv6.toronto.redhat.ca".
The Recursive Resolver constructs a DNS reply with the following edns-tcp-chain-query option parameters:
The RCODE is set to "NoError". The Authority Section is filled in with:
The Answer Section is empty. The RCode is set to NOERROR.
IANA has assigned option code [TBD] in the "DNS EDNS0 Option Codes (OPT)" registry to edns-tcp-chain-query.
[No longer needed?] IANA has assigned the Extended RCODE number [TBD] in the "DNS RCODEs" registry to NXPROOF
Andrew Sullivan pointed out that we do not need any new data formats to support DNS chains. Olafur Gudmundsson ensured the RRsets are returned in the proper Sections.
| [RFC1034] | Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. |
| [RFC1035] | Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate 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. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. |
| [RFC4034] | Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. |
| [RFC4035] | Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. |
| [RFC6982] | Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", RFC 6982, July 2013. |