draft-ietf-dnsop-refuse-any-02.txt   draft-ietf-dnsop-refuse-any-03.txt 
Network Working Group J. Abley Network Working Group J. Abley
Internet-Draft Dyn, Inc. Internet-Draft Dyn, Inc.
Updates: 1035 (if approved) O. Gudmundsson Updates: 1035 (if approved) O. Gudmundsson
Intended status: Standards Track M. Majkowski Intended status: Standards Track M. Majkowski
Expires: January 22, 2017 CloudFlare Inc. Expires: May 20, 2017 Cloudflare Inc.
July 21, 2016 November 16, 2016
Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY
draft-ietf-dnsop-refuse-any-02 draft-ietf-dnsop-refuse-any-03
Abstract Abstract
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
The operator of an authoritative DNS server might choose not to The operator of an authoritative DNS server might choose not to
respond to such queries for reasons of local policy, motivated by respond to such queries for reasons of local policy, motivated by
security, performance or other reasons. security, performance or other reasons.
The DNS specification does not include specific guidance for the The DNS specification does not include specific guidance for the
behaviour of DNS servers or clients in this situation. This document behaviour of DNS servers or clients in this situation. This document
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 22, 2017. This Internet-Draft will expire on May 20, 2017.
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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. General Approach . . . . . . . . . . . . . . . . . . . . . . 4 3. General Approach . . . . . . . . . . . . . . . . . . . . . . 4
4. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 4 4. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 4
5. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 5 5. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 5
6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 5 6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 5
7. Changes to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 6 7. Updates to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 6
8. Implementation Experience . . . . . . . . . . . . . . . . . . 6 8. Implementation Experience . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7
12.2. Informative References . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 7
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 8 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 8
A.1. Change History . . . . . . . . . . . . . . . . . . . . . 8 A.1. Change History . . . . . . . . . . . . . . . . . . . . . 8
A.1.1. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 8 A.1.1. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 8
A.1.2. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 8 A.1.2. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 8
A.1.3. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 8 A.1.3. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 8
A.1.4. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 8 A.1.4. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 8
A.1.5. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 8 A.1.5. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 8
A.1.6. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 8 A.1.6. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY". The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
The operator of an authoritative DNS server might choose not to The operator of an authoritative DNS server might choose not to
respond to such queries for reasons of local policy, motivated by respond to such queries for reasons of local policy, motivated by
security, performance or other reasons. security, performance or other reasons.
The DNS specification [RFC1034] [RFC1035] does not include specific The DNS specification [RFC1034] [RFC1035] does not include specific
guidance for the behaviour of DNS servers or clients in this guidance for the behaviour of DNS servers or clients in this
skipping to change at page 3, line 42 skipping to change at page 3, line 42
fallback when that does not happen. fallback when that does not happen.
ANY queries are also frequently used to exploit the amplification ANY queries are also frequently used to exploit the amplification
potential of DNS servers/resolvers using spoofed source addresses and potential of DNS servers/resolvers using spoofed source addresses and
UDP transport (see [RFC5358]). Having the ability to return small UDP transport (see [RFC5358]). Having the ability to return small
responses to such queries makes DNS servers less attractive responses to such queries makes DNS servers less attractive
amplifiers. amplifiers.
ANY queries are sometimes used to help mine authoritative-only DNS ANY queries are sometimes used to help mine authoritative-only DNS
servers for zone data, since they are expected to return all RRSets servers for zone data, since they are expected to return all RRSets
for a particular query name. A DNS operator MAY prefer not to send for a particular query name. If a DNS operator prefers to reduce the
large ANY responses to reduce the potential for information leaks. potential for information leaks, they MAY choose to not to send large
ANY responses.
Some authoritative-only DNS server implementations require additional Some authoritative-only DNS server implementations require additional
processing in order to send a conventional ANY response, and avoiding processing in order to send a conventional ANY response, and avoiding
that processing expense might be desirable. that processing expense might be desirable.
3. General Approach 3. General Approach
This proposal provides a mechanism for an authority server to signal This proposal provides a mechanism for an authority server to signal
that conventional ANY queries are not supported for a particular that conventional ANY queries are not supported for a particular
QNAME, and to do so in such a way that is both compatible with and QNAME, and to do so in such a way that is both compatible with and
skipping to change at page 4, line 28 skipping to change at page 4, line 28
unknown RCODE caused them to re-send the same query to all available unknown RCODE caused them to re-send the same query to all available
authoritative servers, rather than suppress future such ANY queries authoritative servers, rather than suppress future such ANY queries
for the same QNAME. for the same QNAME.
This proposal avoids that outcome by returning a non-empty RRSet in This proposal avoids that outcome by returning a non-empty RRSet in
the ANY response, providing resolvers with something to cache and the ANY response, providing resolvers with something to cache and
effectively suppressing repeat queries to the same or different effectively suppressing repeat queries to the same or different
authority servers. authority servers.
This proposal specifies two different modes of behaviour by DNS This proposal specifies two different modes of behaviour by DNS
responders, for names that exists. Operators/Implementers are free responders for names that exists. Operators/Implementers are free to
to choose whichever mechanism best suits their environment. choose whichever mechanism best suits their environment.
1. A DNS responder can choose to select one or subset of RRSets at 1. A DNS responder can choose to select one or subset of RRSets at
the QNAME. the QNAME.
2. A DNS responder can instead return a synthesised HINFO resource 2. A DNS responder can instead return a synthesised HINFO resource
record. See Section 6 for discussion of the use of HINFO. record. See Section 6 for discussion of the use of HINFO.
4. Behaviour of DNS Responders 4. Behaviour of DNS Responders
A DNS responder which receives an ANY query MAY decline to provide a A DNS responder which receives an ANY query MAY decline to provide a
conventional response, and MAY instead send a response with a single conventional response, or MAY instead send a response with a single
RRSet in the answer section. RRSet in the answer section.
The RRSet returned in the answer section of the response MAY be a The RRSet returned in the answer section of the response MAY be a
single RRSet owned by the name specified in the QNAME. Where single RRSet owned by the name specified in the QNAME. Where
multiple RRSets exist, the responder SHOULD choose a small one(s) to multiple RRSets exist, the responder SHOULD choose a small one(s) to
reduce its amplification potential. reduce its amplification potential.
If there is no CNAME present at the owner name matching the QNAME, If there is no CNAME present at the owner name matching the QNAME,
the resource record returned in the response MAY instead be the resource record returned in the response MAY instead be
synthesised, in which case a single HINFO resource record SHOULD be synthesised, in which case a single HINFO resource record SHOULD be
skipping to change at page 5, line 39 skipping to change at page 5, line 39
following normal caching semantics, as it would with any other following normal caching semantics, as it would with any other
response received from a DNS responder. response received from a DNS responder.
A DNS initiator MAY suppress queries with QTYPE=ANY in the event that A DNS initiator MAY suppress queries with QTYPE=ANY in the event that
the local cache contains a matching HINFO resource record with the local cache contains a matching HINFO resource record with
RDATA.CPU field, as described in Section 4. RDATA.CPU field, as described in Section 4.
6. HINFO Considerations 6. HINFO Considerations
In the case where a zone that contains HINFO RRSets is served from an In the case where a zone that contains HINFO RRSets is served from an
authority server that does not provide conventional ANY responses, it authority server that does not provide conventional ANY responses.
is possible that the HINFO RRSet in an ANY response, once cached by It is possible that the HINFO RRSet in an ANY response, once cached
the initiator, might suppress subsequent queries from the same by the initiator, might suppress subsequent queries from the same
initiator with QTYPE=HINFO. The use of HINFO in this proposal would initiator with QTYPE=HINFO. The use of HINFO in this proposal would
hence have effectively mask the HINFO RRSet present in the zone. hence have effectively mask the HINFO RRSet present in the zone.
Authority-server operators who serve zones that rely upon Authority-server operators who serve zones that rely upon
conventional use of the HINFO RRTYPE MAY sensibly choose not to conventional use of the HINFO RRTYPE MAY sensibly choose not to
deploy the mechanism described in this document or select other type. deploy the mechanism described in this document or select another
type.
The HINFO RRTYPE is believed to be rarely used in the DNS at the time The HINFO RRTYPE is believed to be rarely used in the DNS at the time
of writing, based on observations made both at recursive servers and of writing, based on observations made both at recursive servers and
authority servers. authority servers.
7. Changes to RFC 1035 7. Updates to RFC 1035
It is important to note that returning a subset of available RRSets It is important to note that returning a subset of available RRSets
when processing an ANY query is legitimate and consistent with when processing an ANY query is legitimate and consistent with
[RFC1035]; ANY does not mean ALL. [RFC1035]; ANY does not mean ALL.
This document describes optional behaviour for both DNS initiators This document describes optional behaviour for both DNS initiators
and responders, and implementation of the guidance provided by this and responders, and implementation of the guidance provided by this
document is OPTIONAL. document is OPTIONAL.
RRSIG queries have the same potential as ANY queries of generating
large answers as well as extra work. DNS implementations are free to
not return all RRSIGS. In the wild there are implimentations that
return REFUSE, others return single RRSIG, etc.
8. Implementation Experience 8. Implementation Experience
In October 2015 CloudFlare Authoritative Nameserver implementation In October 2015 Cloudflare Authoritative Nameserver implementation
implemented the HINFO response. Few minor problems have been implemented the HINFO response. Few minor problems have been
reported and worked out. NSD has for a while implemented a sub-set reported and worked out. NSD has for a while implemented a sub-set
response. A Bind user implemented this draft suggestion of returning response. A Bind user implemented this draft suggestion of returning
only single RRset during an attack. only single RRset during an attack.
9. Security Considerations 9. Security Considerations
Queries with QTYPE=ANY are frequently observed as part of reflection Queries with QTYPE=ANY are frequently observed as part of reflection
attacks, since a relatively small query can be used to elicit a large attacks, since a relatively small query can be used to elicit a large
response; this is a desirable characteristic if the goal is to response; this is a desirable characteristic if the goal is to
skipping to change at page 8, line 13 skipping to change at page 8, line 18
parameters.xhtml#dns-parameters-4 parameters.xhtml#dns-parameters-4
Appendix A. Editorial Notes Appendix A. Editorial Notes
This section (and sub-sections) to be removed prior to publication. This section (and sub-sections) to be removed prior to publication.
A.1. Change History A.1. Change History
A.1.1. draft-ietf-dnsop-refuse-any-03 A.1.1. draft-ietf-dnsop-refuse-any-03
Change section name to "Updates to RFC1034", few minor grammar
changes suggested by Matthew Pounsett and Tony Finch.
Text clarifications, reflecting experience, added implementation Text clarifications, reflecting experience, added implementation
experience. experience.
A.1.2. draft-ietf-dnsop-refuse-any-02 A.1.2. draft-ietf-dnsop-refuse-any-02
Added suggestion to call out RRSIG is optional when DO=0. Added suggestion to call out RRSIG is optional when DO=0.
Number of text suggestions from Jeremy Laidman Number of text suggestions from Jeremy Laidman
A.1.3. draft-ietf-dnsop-refuse-any-01 A.1.3. draft-ietf-dnsop-refuse-any-01
skipping to change at page 9, line 4 skipping to change at page 9, line 15
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Dyn, Inc. Dyn, Inc.
103-186 Albert Street 103-186 Albert Street
London, ON N6A 1M1 London, ON N6A 1M1
Canada Canada
Phone: +1 519 670 9327 Phone: +1 519 670 9327
Email: jabley@dyn.com Email: jabley@dyn.com
Olafur Gudmundsson Olafur Gudmundsson
CloudFlare Inc. Cloudflare Inc.
Email: olafur@cloudflare.com Email: olafur+ietf@cloudflare.com
Marek Majkowski Marek Majkowski
CloudFlare Inc. Cloudflare Inc.
Email: marek@cloudflare.com Email: marek@cloudflare.com
 End of changes. 19 change blocks. 
21 lines changed or deleted 32 lines changed or added

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