draft-ietf-dnsop-refuse-any-07.txt   rfc8482.txt 
Network Working Group J. Abley Internet Engineering Task Force (IETF) J. Abley
Internet-Draft Afilias Request for Comments: 8482 Afilias
Updates: 1034, 1035 (if approved) O. Gudmundsson Updates: 1034, 1035 O. Gudmundsson
Intended status: Standards Track M. Majkowski Category: Standards Track M. Majkowski
Expires: February 15, 2019 Cloudflare Inc. ISSN: 2070-1721 Cloudflare Inc.
E. Hunt E. Hunt
ISC ISC
August 14, 2018 January 2019
Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
draft-ietf-dnsop-refuse-any-07
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 behavior of DNS servers or clients in this situation. This document
aims to provide such guidance. aims to provide such guidance.
This document updates RFC 1034 and RFC 1035. This document updates RFCs 1034 and 1035.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 15, 2019. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8482.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
2. Motivations for Use of ANY Queries . . . . . . . . . . . . . 3 2. Motivations for Use of ANY Queries ..............................3
3. General Approach . . . . . . . . . . . . . . . . . . . . . . 4 3. General Approach ................................................4
4. Behaviour of DNS Responders . . . . . . . . . . . . . . . . . 4 4. Behavior of DNS Responders ......................................5
4.1. Answer with a Subset of Available RRSets . . . . . . . . 5 4.1. Answer with a Subset of Available RRsets ...................5
4.2. Answer with a Synthesised HINFO RRSet . . . . . . . . . . 5 4.2. Answer with a Synthesized HINFO RRset ......................5
4.3. Answer with Best Guess as to Intention . . . . . . . . . 6 4.3. Answer with Best Guess as to Intention .....................6
4.4. Behaviour with TCP Transport . . . . . . . . . . . . . . 6 4.4. Transport Considerations ...................................6
5. Behaviour of DNS Initiators . . . . . . . . . . . . . . . . . 6 5. Behavior of DNS Initiators ......................................7
6. HINFO Considerations . . . . . . . . . . . . . . . . . . . . 7 6. HINFO Considerations ............................................7
7. Updates to RFC 1034 and RFC 1035 . . . . . . . . . . . . . . 7 7. Updates to RFCs 1034 and 1035 ...................................7
8. Implementation Experience . . . . . . . . . . . . . . . . . . 8 8. Implementation Experience .......................................8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations .........................................8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations ............................................9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. References .....................................................9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References ......................................9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References ....................................9
12.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements ..................................................10
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses ................................................10
Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 10
A.1. Change History . . . . . . . . . . . . . . . . . . . . . 10
A.1.1. draft-ietf-dnsop-refuse-any-07 . . . . . . . . . . . 10
A.1.2. draft-ietf-dnsop-refuse-any-06 . . . . . . . . . . . 10
A.1.3. draft-ietf-dnsop-refuse-any-05 . . . . . . . . . . . 10
A.1.4. draft-ietf-dnsop-refuse-any-04 . . . . . . . . . . . 10
A.1.5. draft-ietf-dnsop-refuse-any-03 . . . . . . . . . . . 10
A.1.6. draft-ietf-dnsop-refuse-any-02 . . . . . . . . . . . 10
A.1.7. draft-ietf-dnsop-refuse-any-01 . . . . . . . . . . . 11
A.1.8. draft-ietf-dnsop-refuse-any-00 . . . . . . . . . . . 11
A.1.9. draft-jabley-dnsop-refuse-any-01 . . . . . . . . . . 11
A.1.10. draft-jabley-dnsop-refuse-any-00 . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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 behavior of DNS servers or clients in this
situation. This document aims to provide such guidance. situation. This document aims to provide such guidance.
1.1. Terminology 1.1. Terminology
This document uses terminology specific to the Domain Name System This document uses terminology specific to the Domain Name System
(DNS), descriptions of which can be found in [RFC7719]. (DNS), descriptions of which can be found in [RFC8499].
In this document, "ANY Query" refers to a DNS meta-query with [RFC1035] defined type 255 to be "*". However, DNS implementations
QTYPE=ANY. An "ANY Response" is a response to such a query. commonly use the keyword "ANY" to refer to that type code; this
document follows that common usage.
In this document, "ANY query" refers to a DNS meta-query with
QTYPE=ANY. An "ANY response" is a response to such a query.
In this document, "conventional ANY response" means an ANY response In this document, "conventional ANY response" means an ANY response
that is constructed in accordance with the algorithm documented in that is constructed in accordance with the algorithm documented in
section 4.3.2 of [RFC1034] and specifically without implementing any Section 4.3.2 of [RFC1034] and specifically without implementing any
of the mechanisms described in this document. of the mechanisms described in this document.
In an exchange of DNS messages between two hosts, this document In an exchange of DNS messages between two hosts, this document
refers to the host sending a DNS request as the initiator, and the refers to the host sending a DNS request as the "initiator" and the
host sending a DNS response as the responder. host sending a DNS response as the "responder".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Motivations for Use of ANY Queries 2. Motivations for Use of ANY Queries
ANY queries are legitimately used for debugging and checking the ANY queries are legitimately used for debugging and checking the
state of a DNS server for a particular name. state of a DNS server for a particular name.
ANY queries are sometimes used as a attempt to reduce the number of ANY queries are sometimes used as an attempt to reduce the number of
queries needed to get information, e.g. to obtain MX, A and AAAA queries needed to get information, e.g., to obtain MX, A, and AAAA
RRSets for a mail domain in a single query. There is no documented resource record sets (RRsets) for a mail domain in a single query.
guidance available for this use case, however, and some However, there is no documented guidance available for this use case,
implementations have been observed not to function as perhaps their and some implementations have been observed not to function as their
developers expected. Implementers that assume that an ANY query will developers expected. If implementers assume that an ANY query will
ultimately be received by an authoritative server and will fetch all ultimately be received by an authoritative server and will fetch all
existing RRSets, should include a fallback mechanism to use when that existing RRsets, they should include a fallback mechanism to use when
does not happen. that does not happen.
ANY queries are frequently used to exploit the amplification ANY queries are frequently used to exploit the amplification
potential of DNS servers/resolvers using spoofed source addresses and potential of DNS servers and resolvers using spoofed source addresses
UDP transport (see [RFC5358]). Having the ability to return small and UDP transport (see [RFC5358]). Having the ability to return
responses to such queries makes DNS servers less attractive small 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. If a DNS operator prefers to reduce the for a particular query name. If DNS operators prefer to reduce the
potential for information leaks, they might choose not to send large potential for information leaks, they might choose not to send large
ANY responses. 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; 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 authoritative DNS server to
that conventional ANY queries are not supported for a particular signal that conventional ANY queries are not supported for a
QNAME, and to do so in such a way that is both compatible with and particular QNAME. It does so in a way that is both compatible with
triggers desirable behaviour by unmodified clients (e.g. DNS and triggers desirable behavior by unmodified clients (e.g., DNS
resolvers). resolvers).
Alternative proposals for dealing with ANY queries have been Alternative proposals for dealing with ANY queries have been
discussed. One approach proposed using a new RCODE to signal that an discussed. One approach proposes using a new RCODE to signal that an
authoritative server did not answer ANY queries in the standard way. authoritative server did not answer ANY queries in the standard way.
This approach was found to have an undesirable effect on both This approach was found to have an undesirable effect on both
resolvers and authoritative-only servers; resolvers receiving an resolvers and authoritative-only servers; resolvers receiving an
unknown RCODE would re-send the same query to all available unknown RCODE would resend the same query to all available
authoritative servers, rather than suppress future such ANY queries authoritative servers rather than suppress future ANY queries for the
for the same QNAME. same QNAME.
This proposal avoids that outcome by returning a non-empty RRSet in The proposal described in this document avoids that outcome by
the ANY response, providing resolvers with something to cache and returning a non-empty RRset in the ANY response, which provides
effectively suppressing repeat queries to the same or different resolvers with something to cache and effectively suppresses repeat
authority servers. queries to the same or different authoritative DNS servers.
4. Behaviour of DNS Responders 4. Behavior of DNS Responders
Below are the three different modes of behaviour by DNS responders Below are the three different modes of behavior by DNS responders
when processing queries with QNAMEs that exist, QCLASS=IN and when processing queries with QNAMEs that exist, QCLASS=IN, and
QTYPE=ANY. Operators/Implementers are free to choose whichever QTYPE=ANY. Operators and implementers are free to choose whichever
mechanism best suits their environment. mechanism best suits their environment.
1. A DNS responder can choose to select one or a larger subset of 1. A DNS responder can choose to select one or a larger subset of
the available RRSets at the QNAME. the available RRsets at the QNAME.
2. A DNS responder can return a synthesised HINFO resource record. 2. A DNS responder can return a synthesized HINFO resource record.
See Section 6 for discussion of the use of HINFO. See Section 6 for discussion of the use of HINFO.
3. Resolver can try to give out the most likely records the 3. A resolver can try to give out the most likely records the
requester wants. This is not always possible and the result requester wants. This is not always possible, and the result
might well be a large response. might well be a large response.
Except as described below in this section, the DNS responder MUST Except as described below in this section, the DNS responder MUST
follow the standard algorithms when constructing a response. follow the standard algorithms when constructing a response.
4.1. Answer with a Subset of Available RRSets 4.1. Answer with a Subset of Available RRsets
A DNS responder which receives an ANY query MAY decline to provide a A DNS responder that receives an ANY query MAY decline to provide a
conventional ANY response, or MAY instead send a response with a conventional ANY response or MAY instead send a response with a
single RRSet (or a larger subset of available RRSets) in the answer single RRset (or a larger subset of available RRsets) in the answer
section. section.
The RRSets returned in the answer section of the response MAY consist The RRsets returned in the answer section of the response MAY consist
of a single RRSet owned by the name specified in the QNAME. Where of a single RRset owned by the name specified in the QNAME. Where
multiple RRSets exist, the responder SHOULD choose a small subset of multiple RRsets exist, the responder SHOULD choose a small subset of
those avialable to reduce the amplification potential of the those available to reduce the amplification potential of the
response. response.
If the zone is signed, appropriate RRSIG records MUST be included in If the zone is signed, appropriate RRSIG records MUST be included in
the answer. the answer.
Note that this mechanism does not provide any signalling to indicate Note that this mechanism does not provide any signaling to indicate
to a client that an incomplete subset of the available RRSets has to a client that an incomplete subset of the available RRsets has
been returned. been returned.
4.2. Answer with a Synthesised HINFO RRSet 4.2. Answer with a Synthesized 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 synthesized. In this 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
[note to RFC Editor, replace with RFC number assigned to this "RFC8482". 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 the synthesised HINFO RR SHOULD be chosen by the The TTL encoded for the synthesized HINFO resource record SHOULD be
operator of the DNS responder to be large enough to suppress frequent chosen by the operator of the DNS responder to be large enough to
subsequent ANY queries from the same initiator with the same QNAME, suppress frequent subsequent ANY queries from the same initiator with
understanding that a TTL that is too long might make policy changes the same QNAME, understanding that a TTL that is too long might make
relating to ANY queries difficult to change in the future. The policy changes relating to ANY queries difficult to change in the
specific value used is hence a familiar balance when choosing TTL for future. The specific value used SHOULD be configurable by the
any RR in any zone, and be specified according to local policy. operator of the nameserver according to local policy, based on the
familiar considerations involved in choosing a TTL value for any
resource record in any zone.
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.
A system that receives an HINFO response SHOULD NOT infer that the A system that receives an HINFO response SHOULD NOT infer that the
response was generated according to this specification and apply any response was generated according to this specification and apply any
special processing of the response, since in general it is not special processing of the response because, in general, it is not
possible to tell with certainty whether the HINFO RRSet received was possible to tell with certainty whether the HINFO RRset received was
synthesised. In particular, systems SHOULD NOT rely upon the HINFO synthesized. In particular, systems SHOULD NOT rely upon the HINFO
RDATA described in this seection to distinguish between synthesised RDATA described in this section to distinguish between synthesized
and non-synthesised HINFO RRSets. and non-synthesized HINFO RRsets.
4.3. Answer with Best Guess as to Intention 4.3. Answer with Best Guess as to Intention
In some cases it is possible to guess what the initiator wants in the In some cases, it is possible to guess what the initiator wants in
answer (but not always). Some implementations have implemented the the answer (but not always). Some implementations have implemented
spirit of this document by returning all RRSets of RRType CNAME, MX, the spirit of this document by returning all RRsets of RRTYPE CNAME,
A and AAAA that are present at the owner name but suppressing others. MX, A, and AAAA that are present at the owner name while suppressing
This heuristic seems to work well in practice, satisfying the needs others. This heuristic seems to work well in practice; it satisfies
of some applications whilst suppressing other RRSets such as TXT and the needs of some applications whilst suppressing other RRsets such
DNSKEY that can often contribute to large responses. Whilst some as TXT and DNSKEY that can often contribute to large responses.
applications may be satisfied by this behaviour, the resulting Whilst some applications may be satisfied by this behavior, the
responses in the general case are larger than the approaches resulting responses in the general case are larger than in the
described in Section 4.1 and Section 4.2. approaches described in Sections 4.1 and 4.2.
As before, if the zone is signed and the DO bit is set on the As before, if the zone is signed and the DO bit is set on the
corresponding query, an RRSIG RRSet MUST be included in the response. corresponding query, an RRSIG RRset MUST be included in the response.
4.4. Behaviour with TCP Transport 4.4. Transport Considerations
A DNS responder MAY behave differently when processing ANY queries A DNS responder MAY behave differently when processing ANY queries
received over different transport, e.g. by providing a conventional received over different transports, e.g., by providing a conventional
ANY response over TCP whilst using one of the other mechanisms ANY response over TCP whilst using one of the other mechanisms
specified in this document in the case where a query was received specified in this document in the case where a query was received
using UDP. using UDP.
Implementers SHOULD provide configuration options to allow operators Implementers MAY provide configuration options to allow operators to
to specify different behaviour over UDP and TCP. specify different behavior over different transports.
5. Behaviour of DNS Initiators 5. Behavior of DNS Initiators
A DNS initiator which sends a query with QTYPE=ANY and receives a A DNS initiator that sends a query with QTYPE=ANY and receives a
response containing an HINFO resource record or a single RRset, as response containing an HINFO resource record or a single RRset, as
described in Section 4, MAY cache the response in the normal way. described in Section 4, MAY cache the response in the normal way.
Such cached 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 with any other response
response received from a DNS responder. 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 the
RDATA.CPU field, as described in Section 4. A DNS initiator MAY CPU field of the HINFO RDATA, as described in Section 4. A DNS
instead respond to such queries with the contents of the local cache initiator MAY instead respond to such queries with the contents of
in the usual way. the local cache in the usual way.
6. HINFO Considerations 6. HINFO Considerations
It is possible that the synthesised HINFO RRSet in an ANY response, It is possible that the synthesized HINFO RRset in an ANY response,
once cached by the initiator, might suppress subsequent queries from once cached by the initiator, might suppress subsequent queries from
the same initiator with QTYPE=HINFO. Thus the use of HINFO in this the same initiator with QTYPE=HINFO. Thus, the use of HINFO in this
proposal would hence have effectively mask the HINFO RRSet present in proposal would effectively mask the HINFO RRset present in the zone.
the zone.
Authority-server operators who serve zones that rely upon Operators of authoritative servers who serve zones that rely upon
conventional use of the HINFO RRTYPE SHOULD sensibly choose the conventional use of the HINFO RRTYPE SHOULD sensibly choose the
"single RRset" method 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 at recursive servers, of writing, based on observations made in passive DNS and at
authority servers and in passive DNS. recursive and authoritative DNS servers.
7. Updates to RFC 1034 and RFC 1035 7. Updates to RFCs 1034 and 1035
This document extends the specification for processing ANY queries This document extends the specification for processing ANY queries
described in section 4.3.2 of [RFC1034]. described in Section 4.3.2 of [RFC1034].
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]; it can be argued that ANY does not always mean ALL, as [RFC1035]; it can be argued that ANY does not always mean ALL, as
used in section 3.2.3 of [RFC1035]. The main difference here is that used in Section 3.2.3 of [RFC1035]. The main difference here is that
the TC bit SHOULD NOT be set on the response indicating that this is the TC bit SHOULD NOT be set in the response, thus indicating that
not a complete answer. this is not a complete answer.
This document describes optional behaviour for both DNS initiators This document describes optional behavior for both DNS initiators and
and responders, and implementation of the guidance provided by this responders; implementation of the guidance provided by this document
document is OPTIONAL. is OPTIONAL.
RRSIG queries (i.e. queries with QTYPE=RRSIG) are similar to ANY RRSIG queries (i.e., queries with QTYPE=RRSIG) are similar to ANY
queries in the sense that they have the potential to generate large queries in the sense that they have the potential to generate large
responses as well as extra work for the responders that process them, responses as well as extra work for the responders that process them,
e.g. in the case where signatures are generated on-the-fly. RRSIG e.g., in the case where signatures are generated on the fly. RRSIG
RRSets are not usually obtained using such explicit queries, but are RRsets are not usually obtained using such explicit queries but are
rather included in the responses for other RRSets that the RRSIGs rather included in the responses for other RRsets that the RRSIGs
cover. This document does not specify appropriate behaviour for cover. This document does not specify appropriate behavior for RRSIG
RRSIG queries, but note that future such advice might well benefit queries; however, future such advice might well benefit from
from consistency with and experience of the approaches for ANY consistency with and experience with the approaches for ANY queries
queries described here. described here.
8. Implementation Experience 8. Implementation Experience
In October 2015 Cloudflare Authoritative Name server implementation In October 2015, the Cloudflare authoritative nameserver
implemented the HINFO response. A few minor problems were reported implementation implemented the HINFO response. A few minor problems
and have since been resolved. were reported and have since been resolved.
An implementation of the subset-mode response to ANY queries was An implementation of the subset-mode response to ANY queries was
implemented in NSD 4.1 in 2016. implemented in NSD 4.1 in 2016.
An implementation of a single RRSet response to an ANY query was made An implementation of a single RRset response to an ANY query was made
for BIND9 by Tony Finch, and that functionality was subsequently made for BIND9 by Tony Finch, and that functionality was subsequently made
available in production releases starting in BIND 9.11. available in production releases starting in BIND 9.11.
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.
The optional behaviour described in this document to reduce the size The optional behavior described in this document to reduce the size
of responses to queries with QTYPE=ANY is compatible with the use of of responses to queries with QTYPE=ANY is compatible with the use of
DNSSEC by both initiator and responder. DNSSEC by both initiator and responder.
10. IANA Considerations 10. IANA Considerations
The IANA is requested to update the Resource Record (RR) TYPEs IANA has updated the following entry in the "Resource Record (RR)
Registry [1] entry as follows: TYPEs" registry [RR_TYPES]:
+------+-------+-------------------------------+--------------------+ +------+-------+-------------------------------+--------------------+
| Type | Value | Meaning | Reference | | TYPE | Value | Meaning | Reference |
+------+-------+-------------------------------+--------------------+ +------+-------+-------------------------------+--------------------+
| * | 255 | A request for some or all | [RFC1035][RFC6895] | | * | 255 | A request for some or all | [RFC1035][RFC6895] |
| | | records the server has | [This Document] | | | | records the server has | [RFC8482] |
| | | available | | | | | available | |
+------+-------+-------------------------------+--------------------+ +------+-------+-------------------------------+--------------------+
11. Acknowledgements 11. References
David Lawrence provided valuable observations and concrete
suggestions. Jeremy Laidman helped make the document better. Tony
Finch realized that this document was valuable and implemented it
while under attack. Richard Gibson identified areas where more
detail and accuracy was useful. A large number of other people also
provided comments and suggestions we thank them all for the feedback.
12. References
12.1. Normative References 11.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc1034>. <https://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, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 11.2. Informative References
[RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive [RFC5358] Damas, J. and F. Neves, "Preventing Use of Recursive
Nameservers in Reflector Attacks", BCP 140, RFC 5358, Nameservers in Reflector Attacks", BCP 140, RFC 5358,
DOI 10.17487/RFC5358, October 2008, DOI 10.17487/RFC5358, October 2008,
<https://www.rfc-editor.org/info/rfc5358>. <https://www.rfc-editor.org/info/rfc5358>.
[RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA
Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895,
April 2013, <https://www.rfc-editor.org/info/rfc6895>. April 2013, <https://www.rfc-editor.org/info/rfc6895>.
[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", RFC 7719, DOI 10.17487/RFC7719, December Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
2015, <https://www.rfc-editor.org/info/rfc7719>. January 2019, <https://www.rfc-editor.org/info/rfc8499>.
12.3. URIs
[1] http://www.iana.org/assignments/dns-parameters/dns-
parameters.xhtml#dns-parameters-4
Appendix A. Editorial Notes
This section (and sub-sections) to be removed prior to publication.
A.1. Change History
A.1.1. draft-ietf-dnsop-refuse-any-07
Address AD's concerns: more colour to describe updates to 1034/1035
in the abstract; don't rely upon HINFO RDATA formatting; language
cleanup around guess intent. Add Evan as author (originator of the
"choose one record" response idea).
A.1.2. draft-ietf-dnsop-refuse-any-06
Update RFC 1034 as well as RFC 1035; define the term "conventional
ANY response"; soften and qualify ANY does not mean ALL; note that
the subset mode response lacks signalling.
A.1.3. draft-ietf-dnsop-refuse-any-05
Minor editorial changes. Soften advice on RRSIG queries. Version
bump.
A.1.4. 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.5. 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
experience.
A.1.6. draft-ietf-dnsop-refuse-any-02
Added suggestion to call out RRSIG is optional when DO=0.
Number of text suggestions from Jeremy Laidman.
A.1.7. draft-ietf-dnsop-refuse-any-01
Add IANA Considerations
A.1.8. draft-ietf-dnsop-refuse-any-00
Re-submitted with a different name following adoption at the dnsop WG
meeting convened at IETF 94.
A.1.9. draft-jabley-dnsop-refuse-any-01
Make signing of RRSets in answers from signed zones mandatory.
Document the option of returning an existing RRSet in place of a [RR_TYPES] IANA, "Domain Name System (DNS) Parameters",
synthesised one. <https://www.iana.org/assignments/dns-parameters>.
A.1.10. draft-jabley-dnsop-refuse-any-00 Acknowledgements
Initial draft circulated for comment. David Lawrence provided valuable observations and concrete
suggestions. Jeremy Laidman helped make the document better. Tony
Finch realized that this document was valuable and implemented it
while under attack. Richard Gibson identified areas where more
detail and accuracy were useful. A large number of other people also
provided comments and suggestions; we thank them all for the
feedback.
Authors' Addresses Authors' Addresses
Joe Abley Joe Abley
Afilias Afilias
300-184 York Street 300-184 York Street
London, ON N6A 1B5 London, ON N6A 1B5
Canada Canada
Phone: +1 519 670 9327 Phone: +1 519 670 9327
skipping to change at page 12, line 4 skipping to change at page 10, line 38
Olafur Gudmundsson Olafur Gudmundsson
Cloudflare Inc. Cloudflare Inc.
Email: olafur+ietf@cloudflare.com Email: olafur+ietf@cloudflare.com
Marek Majkowski Marek Majkowski
Cloudflare Inc. Cloudflare Inc.
Email: marek@cloudflare.com Email: marek@cloudflare.com
Evan Hunt Evan Hunt
ISC ISC
950 Charter St 950 Charter St
Redwood City, CA 94063 Redwood City, CA 94063
USA United States of America
Email: each@isc.org Email: each@isc.org
 End of changes. 77 change blocks. 
270 lines changed or deleted 191 lines changed or added

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