draft-ietf-dnsop-refuse-any-03.txt   draft-ietf-dnsop-refuse-any-04.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: May 20, 2017 Cloudflare Inc. Expires: August 12, 2017 Cloudflare Inc.
November 16, 2016 February 08, 2017
Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY
draft-ietf-dnsop-refuse-any-03 draft-ietf-dnsop-refuse-any-04
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 May 20, 2017. This Internet-Draft will expire on August 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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. 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 4.1. Select one RRSet mode . . . . . . . . . . . . . . . . . . 4
6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 5 4.2. Synthesised HINFO RRset . . . . . . . . . . . . . . . . . 5
4.3. Guess intention . . . . . . . . . . . . . . . . . . . . . 5
4.4. Responding to queries over TCP . . . . . . . . . . . . . 5
5. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 6
6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Updates to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 6 7. Updates to RFC 1035 . . . . . . . . . . . . . . . . . . . . . 6
8. Implementation Experience . . . . . . . . . . . . . . . . . . 6 8. Implementation Experience . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 7 12.2. Informative References . . . . . . . . . . . . . . . . . 8
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 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-04 . . . . . . . . . . . 8
A.1.2. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 8 A.1.2. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 9
A.1.3. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 8 A.1.3. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 9
A.1.4. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 8 A.1.4. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 9
A.1.5. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 8 A.1.5. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 9
A.1.6. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 8 A.1.6. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 9
A.1.7. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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
skipping to change at page 4, line 27 skipping to change at page 4, line 27
resolvers and authoritative-only servers; resolvers receiving an resolvers and authoritative-only servers; resolvers receiving an
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 4. Behaviour of DNS Responders
responders for names that exists. Operators/Implementers are free to
choose whichever mechanism best suits their environment. Below are the three different modes of behaviour by DNS responders
for names that exists that are used, listed in the order of
preference. Operators/Implementers are free to 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 return a synthesised HINFO resource record.
record. See Section 6 for discussion of the use of HINFO. See Section 6 for discussion of the use of HINFO.
4. Behaviour of DNS Responders 3. Resolver can try to give out the most likely records the
requester wants. This is not always possible and the likely
RRsets may add up to a large answer.
Except as described below in this section, the DNS responder MUST
follow the standard algorithms when constructing a response.
4.1. Select one RRSet mode
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, or 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 the zone is signed RRSIG records MUST be included in the answer
4.2. Synthesised HINFO RRset
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
returned. The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX returned. The CPU field of the HINFO RDATA SHOULD be set to RFCXXXX
[note to RFC Editor, replace with RFC number assigned to this [note to RFC Editor, replace with RFC number assigned to this
document]. The OS field of the HINFO RDATA SHOULD be set to the null document]. The OS field of the HINFO RDATA SHOULD be set to the null
string to minimize the size of the response. string to minimize the size of the response.
The TTL encoded for a synthesised RR SHOULD be chosen by the operator The TTL encoded for a synthesised RR SHOULD be chosen by the operator
of the DNS responder to be large enough to suppress frequent of the DNS responder to be large enough to suppress frequent
skipping to change at page 5, line 20 skipping to change at page 5, line 35
understanding that a TTL that is too long might make policy changes understanding that a TTL that is too long might make policy changes
relating to ANY queries difficult to change in the future. The relating to ANY queries difficult to change in the future. The
specific value used is hence a familiar balance when choosing TTL for specific value used is hence a familiar balance when choosing TTL for
any RR in any zone, and be specified according to local policy. any RR in any zone, and be specified according to local policy.
If the DNS query includes DO=1 and the QNAME corresponds to a zone If the DNS query includes DO=1 and the QNAME corresponds to a zone
that is known by the responder to be signed, a valid RRSIG for the that is known by the responder to be signed, a valid RRSIG for the
RRSets in the answer (or authority if answer is empty) section MUST RRSets in the answer (or authority if answer is empty) section MUST
be returned. In the case of DO=0, the RRSIG SHOULD be omitted. be returned. In the case of DO=0, the RRSIG SHOULD be omitted.
Except as described in this section, the DNS responder MUST follow 4.3. Guess intention
the standard algorithms when constructing a response.
In some cases it is possible to guess what the initiator wants in the
answer but not always. Some implementations have implemented the
spirit of this document by returning all of CNAME or (MX A and AAAA)
RRsets that are present. This is not a guess but a heuristic that
seems to work well in practice. The main drawback is the size of the
answer.
As in the first one if the zone is signed RRSIG MUST be returned if
there the DO bit is set on query.
4.4. Responding to queries over TCP
There has been a desire to specify that a ANY query over TCP get full
response. This document does not specify that as that is best left
to the operator to decide. Implementers SHOULD provide an option for
operators to specify behavior over TCP.
5. Behaviour of DNS Initiators 5. Behaviour of DNS Initiators
A DNS initiator which sends a query with QTYPE=ANY and receives a A DNS initiator which sends a query with QTYPE=ANY and receives a
response containing an HINFO resource record, as described in response containing an HINFO resource record or a single RRset, as
Section 4, MAY cache the HINFO response in the normal way. Such described in Section 4, MAY cache the response in the normal way.
cached HINFO resource records SHOULD be retained in the cache Such cached resource records SHOULD be retained in the cache
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. Similarly it is fine to
replay back exactly what Authoritative server returned to ANY query.
6. HINFO Considerations 6. HINFO Considerations
In the case where a zone that contains HINFO RRSets is served from an It is possible that the synthesised HINFO RRSet in an ANY response,
authority server that does not provide conventional ANY responses. once cached by the initiator, might suppress subsequent queries from
It is possible that the HINFO RRSet in an ANY response, once cached the same initiator with QTYPE=HINFO. Thus the use of HINFO in this
by the initiator, might suppress subsequent queries from the same proposal would hence have effectively mask the HINFO RRSet present in
initiator with QTYPE=HINFO. The use of HINFO in this proposal would 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 SHOULD sensibly choose the
deploy the mechanism described in this document or select another "single RRset" method described in this document or select another
type. 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 at recursive servers,
authority servers. authority servers and in passive DNS.
7. Updates 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. The main difference here is that
the TC bit SHOULD not be set on the response indicating that this is
not a complete answer.
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 RRSIG queries have the same potential as ANY queries of generating
large answers as well as extra work. DNS implementations are free to large answers as well as extra work. DNS implementations are free to
not return all RRSIGS. In the wild there are implimentations that not return all RRSIG records. In the wild there are implementations
return REFUSE, others return single RRSIG, etc. that return REFUSE, others return single RRSIG, etc. This document
recommends returning a single RRSIG in this case.
8. Implementation Experience 8. Implementation Experience
In October 2015 Cloudflare Authoritative Nameserver implementation In October 2015 Cloudflare Authoritative Name server 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, his code is now in the current
release.
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
maximize the amplification potential of a DNS server as part of a maximize the amplification potential of a DNS server as part of a
volumetric attack. The ability of a DNS operator to suppress such volumetric attack. The ability of a DNS operator to suppress such
responses on a particular server makes that server a less useful responses on a particular server makes that server a less useful
amplifier. amplifier.
skipping to change at page 8, line 16 skipping to change at page 8, line 48
[1] http://www.iana.org/assignments/dns-parameters/dns- [1] http://www.iana.org/assignments/dns-parameters/dns-
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-04
These are the changes requested during WGLC. The title has been
updated for readability The behavior section now contains description
of three different approaches in order of preference. Text added on
behavior over TCP. The document is clear in how it updates from
RFC1035. Minor adjustments for readability and remove redundancy.
A.1.2. draft-ietf-dnsop-refuse-any-03
Change section name to "Updates to RFC1034", few minor grammar Change section name to "Updates to RFC1034", few minor grammar
changes suggested by Matthew Pounsett and Tony Finch. 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.3. 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.4. draft-ietf-dnsop-refuse-any-01
Add IANA Considerations Add IANA Considerations
A.1.4. draft-ietf-dnsop-refuse-any-00 A.1.5. draft-ietf-dnsop-refuse-any-00
Re-submitted with a different name following adoption at the dnsop wg Re-submitted with a different name following adoption at the dnsop WG
meeting convened at IETF 94. meeting convened at IETF 94.
A.1.5. draft-jabley-dnsop-refuse-any-01 A.1.6. draft-jabley-dnsop-refuse-any-01
Make signing of RRSets in answers from signed zones mandatory. Make signing of RRSets in answers from signed zones mandatory.
Document the option of returning an existing RRSet in place of a Document the option of returning an existing RRSet in place of a
synthesised one. synthesised one.
A.1.6. draft-jabley-dnsop-refuse-any-00 A.1.7. draft-jabley-dnsop-refuse-any-00
Initial draft circulated for comment. Initial draft circulated for comment.
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
 End of changes. 29 change blocks. 
54 lines changed or deleted 101 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/