draft-ietf-dnsop-edns-chain-query-06.txt   draft-ietf-dnsop-edns-chain-query-07.txt 
dnsop P. Wouters dnsop P. Wouters
Internet-Draft Red Hat Internet-Draft Red Hat
Intended status: Standards Track January 18, 2016 Intended status: Experimental February 18, 2016
Expires: July 21, 2016 Expires: August 21, 2016
Chain Query requests in DNS Chain Query requests in DNS
draft-ietf-dnsop-edns-chain-query-06 draft-ietf-dnsop-edns-chain-query-07
Abstract Abstract
This document defines an EDNS0 extension that can be used by a This document defines an EDNS0 extension that can be used by a
security-aware validating resolver configured to use a Forwarder to security-aware validating resolver configured to use a Forwarder to
send a single query, requesting a complete validation path along with send a single query, requesting a complete validation path along with
the regular query answer. The reduction in queries potentially the regular query answer. The reduction in queries potentially
lowers the latency and reduces the need to send multiple queries at lowers the latency and reduces the need to send multiple queries at
once. This extension mandates the use of source IP verified once. This extension mandates the use of source IP verified
transport such as TCP or UDP with EDNS-COOKIE so it cannot be abused transport such as TCP or UDP with EDNS-COOKIE so it cannot be abused
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 July 21, 2016. This Internet-Draft will expire on August 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . 7
6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 8 6.1. DNSSEC Considerations . . . . . . . . . . . . . . . . . . 7
6.2. NS record Considerations . . . . . . . . . . . . . . . . 8 6.2. NS record Considerations . . . . . . . . . . . . . . . . 8
6.3. Session Management . . . . . . . . . . . . . . . . . . . 8 6.3. Session Management . . . . . . . . . . . . . . . . . . . 8
6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 9 6.4. Negative Trust Anchors . . . . . . . . . . . . . . . . . 8
6.5. Anycast Considerations . . . . . . . . . . . . . . . . . 9 6.5. 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. Additional work and bandwidth . . . . . . . . . . . . . . 10
8.2. Amplification Attacks . . . . . . . . . . . . . . . . . . 10
8.3. Privacy Considerations . . . . . . . . . . . . . . . . . 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 CHAIN . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 4, line 29 skipping to change at page 4, line 34
request all intermediate DNS data it requires to resolve and validate request all intermediate DNS data it requires to resolve and validate
a particular DNS answer in a single round-trip. The Resolver could a particular DNS answer in a single round-trip. The Resolver could
be part of the application or a Recursive Resolver running on the be part of the application or a Recursive Resolver running on the
host. host.
Servers answering with CHAIN data should ensure that the transport is Servers answering with CHAIN data should ensure that the transport is
TCP or source IP address verified UDP. See Section 8. This avoids TCP or source IP address verified UDP. See Section 8. This avoids
abuse in DNS amplification attacks. abuse in DNS amplification attacks.
Applications that support CHAIN internally can perform validation Applications that support CHAIN internally can perform validation
without requiring the host the run a Recursive Resolver. This is without requiring the host to run a Recursive Resolver. This is
particularly useful for virtual servers in a cloud or container based particularly useful for virtual servers in a cloud or container based
deployment where it is undesirable to run a Recursive Resolver per deployment where it is undesirable to run a Recursive Resolver per
virtual machine. virtual machine.
The format of this option is described in Section 4. The format of this option is described in Section 4.
As described in Section 5.4, a Recursive Resolver could use this As described in Section 5.4, a Recursive Resolver 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
skipping to change at page 8, line 4 skipping to change at page 7, line 50
The response from a Recursive Resolver to a Resolver MUST NOT contain The response from a Recursive Resolver to a Resolver MUST NOT contain
the CHAIN option if none was present in the Resolver's original the CHAIN option if none was present in the Resolver's original
request. request.
A DNS query that contains the CHAIN option MUST also have the DNSSEC A DNS query that contains the CHAIN option MUST also have the DNSSEC
OK ("OK") bit set. If this bit is not set, or if the Checking OK ("OK") bit set. If this bit is not set, or if the Checking
Disabled ("CD") bit is set, the CHAIN option received MUST be Disabled ("CD") bit is set, the CHAIN option received MUST be
ignored. ignored.
6. Protocol Considerations 6. Protocol Considerations
6.1. DNSSEC Considerations
6.1. DNSSEC Considerations
The presence or absence of an OPT resource record containing an CHAIN The presence or absence of an OPT resource record containing an CHAIN
option in a DNS query does not change the usage of those resource option in a DNS query does not change the usage of those resource
records and mechanisms used to provide data origin authentication and records and mechanisms used to provide data origin authentication and
data integrity to the DNS, as described in [RFC4033], [RFC4034] and data integrity to the DNS, as described in [RFC4033], [RFC4034] and
[RFC4035]. [RFC4035].
6.2. NS record Considerations 6.2. NS record Considerations
CHAIN responses SHOULD include the NS RRset from the zone itself CHAIN responses SHOULD include the NS RRset from the zone itself
including the RRSIG records required for validation. It MUST NOT including the RRSIG records required for validation. It MUST NOT
skipping to change at page 8, line 34 skipping to change at page 8, line 32
Recursive Resolver mode due to a network topology change. In Recursive Resolver mode due to a network topology change. In
Recursive Resolver mode, the NS RRsets are needed to find and query Recursive Resolver mode, the NS RRsets are needed to find and query
Authoritative Servers directly. It is RECOMMENDED that the DNS Authoritative Servers directly. It is RECOMMENDED that the DNS
Forwarder populate its cache with this information to avoid requiring Forwarder populate its cache with this information to avoid requiring
future queries to obtain any missing NS records. Therefore, CHAIN future queries to obtain any missing NS records. Therefore, CHAIN
responses MUST include the NS RRset from the child zone, including responses MUST include the NS RRset from the child zone, including
the RRSIG records required for validation. the RRSIG records required for validation.
6.3. Session Management 6.3. Session Management
It is RECOMMENDED that TCP sessions not immediately be closed after The use of [TCP-KEEPALIVE] on DNS TCP sessions is RECOMMENDED, and
the DNS answer to the first query is received. It is recommended to thus TCP sessions should not immediately be closed after the DNS
use [TCP-KEEPALIVE]. answer to the first query is received.
Both DNS clients and servers are subject to resource constraints Both DNS clients and servers are subject to resource constraints
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 CHAIN option in be accommodated, DNS servers may stop advertising the CHAIN option in
skipping to change at page 10, line 16 skipping to change at page 10, line 9
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
[While there is some interest, no work has started yet] [While there is some interest, no work has started yet]
8. Security Considerations 8. Security Considerations
8.1. Amplification Attacks 8.1. Additional work and bandwidth
Producing CHAIN answers incurs additional load and bandwidth on the
Recursive Resolver. At any time, a Recursive Resolver may decide to
no longer answer with CHAIN answers and fall back to traditional DNS
answers.
8.2. Amplification Attacks
Chain Queries can potentially send very large DNS answers. Attackers Chain Queries can potentially send very large DNS answers. Attackers
could abuse this using spoofed source IP addresses to inflict large could abuse this using spoofed source IP addresses to inflict large
Distributed Denial of Service attacks using query-chains as an Distributed Denial of Service attacks using 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 CHAIN answers to clients over A Recursive Resolver MUST NOT return CHAIN answers to clients over
UDP without source IP address verification. An example of UDP based UDP without source IP address verification. An example of UDP based
source IP address verification is [EDNS-COOKIE]. A Recursive source IP address verification is [EDNS-COOKIE]. A Recursive
Resolver refusing a CHAIN option MUST respond with a zero-length Resolver refusing a CHAIN option MUST respond with a zero-length
CHAIN option to indicate support for CHAIN queries when a proper CHAIN option to indicate support for CHAIN queries when a proper
transport is used. It MUST NOT send an RCODE of REFUSED. transport is used. It MUST NOT send an RCODE of REFUSED.
8.3. Privacy Considerations
A client producing CHAIN queries reveals a little more information
about its cache contents than regular DNS clients. This could be
used the fingerprint a client across network reconnections. If DNS
privacy is a concern, a CHAIN query client MAY try to use a DNS
transport that provides privacy, such as [DNS-over-TLS] or a trusted
DNS server that is contacted through a VPN connection such as IPsec.
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 Resolver on the client machine checks its cache, and notices o The Resolver 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.
skipping to change at page 14, line 31 skipping to change at page 14, line 40
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-over-TLS]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "DNS over TLS: Initiation and Performance
Considerations", draft-ietf-dprive-dns-over-tls-05 (work
in progress), January 2016.
[EDNS-COOKIE] [EDNS-COOKIE]
Eastlake, Donald., "Domain Name System (DNS) Cookies", Eastlake, Donald., "Domain Name System (DNS) Cookies",
draft-ietf-dnsop-cookies (work in progress), December draft-ietf-dnsop-cookies (work in progress), January 2016.
2015.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>. November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 16 change blocks. 
17 lines changed or deleted 40 lines changed or added

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