Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY
draft-jabley-dnsop-refuse-any-00

Network Working Group                                           J. Abley
Internet-Draft                                                 Dyn, Inc.
Updates: 1035 (if approved)                               O. Gudmundsson
Intended status: Standards Track                            M. Majkowski
Expires: April 2, 2016                                   CloudFlare Inc.
                                                      September 30, 2015

    Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY
                    draft-jabley-dnsop-refuse-any-00

Abstract

   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

   The DNS specification does not include specific guidance for the
   behaviour of DNS servers or clients in this situation.  This document
   aims to provide such guidance.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 2, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Abley, et al.             Expires April 2, 2016                 [Page 1]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Motivations  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  General Approach . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Behaviour of DNS Responders  . . . . . . . . . . . . . . . . .  7
   6.  Behaviour of DNS Initiators  . . . . . . . . . . . . . . . . .  8
   7.  HINFO Considerations . . . . . . . . . . . . . . . . . . . . .  9
   8.  Changes to RFC 1035  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     12.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
     12.2.  Informative References  . . . . . . . . . . . . . . . . . 14
   Appendix A.  Editorial Notes . . . . . . . . . . . . . . . . . . . 15
     A.1.   Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     A.2.   Change History  . . . . . . . . . . . . . . . . . . . . . 15
       A.2.1.  draft-jabley-dnsop-ordered-answers-00  . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Abley, et al.             Expires April 2, 2016                 [Page 2]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

1.  Terminology

   This document uses terminology specific to the Domain Name System
   (DNS), descriptions of which can be found in
   [I-D.ietf-dnsop-dns-terminology].

   In this document, "ANY Query" refers to a DNS query with QTYPE=ANY.
   An "ANY Response" is a response to such a query.

   In an exchange of DNS messages between two hosts, this document
   refers to the host sending a DNS request as the initiator, and the
   host sending a DNS response as the responder.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Abley, et al.             Expires April 2, 2016                 [Page 3]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

2.  Introduction

   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

   The DNS specification [RFC1034] [RFC1035] does not include specific
   guidance for the behaviour of DNS servers or clients in this
   situation.  This document aims to provide such guidance.

Abley, et al.             Expires April 2, 2016                 [Page 4]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

3.  Motivations

   ANY queries are legitimately used for debugging and checking the
   state of a DNS server for a particular owner name.  ANY queries are
   sometimes used as a attempt to reduce the number of queries needed to
   get information, e.g. to obtain MX, A and AAAA RRSets for a mail
   domain in a single query, although there is no documented guidance
   available for this use case and some implementations have been
   observed that appear not to function as perhaps their developers
   expected.

   ANY queries are also frequently used to exploit the amplification
   potential of DNS servers using spoofed source addresses and UDP
   transport (see [RFC5358]).  Having the ability to return small
   responses to such queries makes DNS servers less attractive
   amplifiers.

   ANY queries are sometimes used to help mine authoritative-only DNS
   servers for zone data, since they return all RRSets for a particular
   owner name.  A DNS zone maintainer might prefer not to send
   conventional ANY responses to reduce the potential for such
   information leaks.

   Some authoritative-only DNS server implementations require additional
   processing in order to send a conventional ANY response, and avoiding
   that processing expense may be desirable.

Abley, et al.             Expires April 2, 2016                 [Page 5]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

4.  General Approach

   This proposal provides a mechanism for an authority server to signal
   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
   triggers desirable behaviour by unmodified clients (e.g.  DNS
   resolvers).

   Alternative proposals for dealing with ANY queries have been
   discussed.  One approach proposed using a new RCODE to signal that an
   authortitaive server did not answer ANY queries in the standard way.
   This approach was found to have an undesirable effect on both
   resolvers and authoritative-only servers; resolvers receiving an
   unknown RCODE caused them to re-send the same query to all available
   authoritative servers, rather than suppress future such ANY queries
   for the same QNAME.

   This proposal avoids that outcome by returning a non-empty RRSet in
   the ANY response, providing resolvers with something to cache and
   effectively suppressing repeat queries to the same or different
   authority servers.

   This proposal makes use of the HINFO RRType rather than specifying a
   new RRType.  This is intended both to facilitate desired behaviour by
   initators who might otherwise struggle to deal correctly with new
   RRTypes, but also because in a general sense the signalling from
   responder to initiator is providing some information about the
   responding host, which seems in keeping with the originally-imagined
   use of HINFO.  See also Section 7.

Abley, et al.             Expires April 2, 2016                 [Page 6]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

5.  Behaviour of DNS Responders

   A DNS responder which receives an ANY query MAY decline to provide a
   conventional response, and instead send a response with a single
   HINFO resource record in the answer section.  The CPU field of the
   HINFO RDATA SHOULD be set to RFCXXXX [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 string to minimise the size of
   the response.

   The TTL encoded for the HINFO RR SHOULD be chosen by the operator of
   the DNS responder to be large enough to suppress frequent subsequent
   ANY queries from the same initiator with the same QNAME,
   understanding that a TTL that is too long might make policy changes
   relating to ANY queries difficult to change in the future.  The
   specific value used is hence a familiar balance when choosing TTLs
   for any RR in any zone, and should be specified according to local
   policy.

   If the DNS query includes DO=1 and the QNAME corresponds to a zone
   that is known by the responder to be signed, valid RRSIG resource
   records MAY be returned.  However, the responder MAY return an
   unsigned answer; a validating initiator that sends a subsequent
   explicit query with QTYPE=HINFO will receive a signed proof that the
   HINFO does not exist or a signed HINFO RRSet, either of which can be
   cached to suppress repeated queries.

   Except as described in this section, the DNS responder MUST follow
   the standard algorithms when constructing a response.

Abley, et al.             Expires April 2, 2016                 [Page 7]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

6.  Behaviour of DNS Initiators

   XXX consider whether separate text here is required depending on
   whether the initiator is a non-caching stub resolver or a caching
   recursive resolver.

   A DNS initator which sends a query with QTYPE=ANY and receives a
   response containing an HINFO, as described in Section 5, MAY cache
   the HINFO response in the normal way.  Such cached HINFO resource
   records SHOULD be retained in the cache following normal caching
   semantics, as it would with any other response received from a DNS
   responder.

   A DNS initiator MAY suppress queries with QTYPE=ANY in the event that
   the local cache contains a matching HINFO resource record with
   RDATA.CPU as described in Section 5.

Abley, et al.             Expires April 2, 2016                 [Page 8]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

7.  HINFO Considerations

   In the case where a zone that contains HINFO RRSets is served from an
   authority server that does not provide conventional ANY responses, it
   is possible that the HINFO RRSet in an ANY response, once cached by
   the initiator, might suppress subsequent queries from the same
   initiator with QTYPE=HINFO.  The use of HINFO in this proposal would
   hence have effectively masked the HINFO RRSet present in the zone.

   Authority-server operators who serve zones that rely upon
   conventional use of the HINFO RRType might sensibly choose not to
   deploy the mechanism described in this document.

   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
   authority servers.

Abley, et al.             Expires April 2, 2016                 [Page 9]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

8.  Changes to RFC 1035

   It is important to note that returning a subset of available RRSets
   when processing an ANY query is legitimate and consistent with
   [RFC1035]; ANY does not mean ALL.

   This document describes optional behaviour for both DNS initators and
   responders, and implementation of the guidance provided by this
   document is OPTIONAL.

   XXX more words here about any updates implied to RFC 1035, or delete
   the section if it turns out that, in the final analysis, there are
   none.

Abley, et al.             Expires April 2, 2016                [Page 10]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

9.  Security Considerations

   Queries with QTYPE=ANY are frequently observed as part of reflection
   attacks, since a relatively small query can be used to elicit a large
   response; this is a desirable characteristic if the goal is to
   maximise the amplification potential of a DNS server as part of a
   volumetric attack.  The ability of a DNS operator to suppress such
   responses on a particular server makes that server a less useful
   amplifier.

   The optional behaviour described in this document to reduce the size
   of responses to queries with QTYPE=ANY is compatible with the use of
   DNSSEC by both initiator and responder.

Abley, et al.             Expires April 2, 2016                [Page 11]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

10.  IANA Considerations

   This document has no IANA actions.

Abley, et al.             Expires April 2, 2016                [Page 12]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

11.  Acknowledgements

   Your name here, etc.

Abley, et al.             Expires April 2, 2016                [Page 13]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

12.  References

12.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <http://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

12.2.  Informative References

   [I-D.ietf-dnsop-dns-terminology]
              Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", draft-ietf-dnsop-dns-terminology-05 (work in
              progress), September 2015.

   [RFC5358]  Damas, J. and F. Neves, "Preventing Use of Recursive
              Nameservers in Reflector Attacks", BCP 140, RFC 5358,
              DOI 10.17487/RFC5358, October 2008,
              <http://www.rfc-editor.org/info/rfc5358>.

Abley, et al.             Expires April 2, 2016                [Page 14]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

Appendix A.  Editorial Notes

   This section (and sub-sections) to be removed prior to publication.

A.1.  Venue

   An appropriate forum for discussion of this draft is the dnsop
   working group.

A.2.  Change History

A.2.1.  draft-jabley-dnsop-ordered-answers-00

   Initial draft circulated for comment.

Abley, et al.             Expires April 2, 2016                [Page 15]
Internet-Draft      Minimal Responses for ANY Queries     September 2015

Authors' Addresses

   Joe Abley
   Dyn, Inc.
   103-186 Albert Street
   London, ON  N6A 1M1
   Canada

   Phone: +1 519 670 9327
   Email: jabley@dyn.com

   Olafur Gudmundsson
   CloudFlare Inc.

   Email: olafur@cloudflare.com

   Marek Majkowski
   CloudFlare Inc.

   Email: marek@cloudflare.com

Abley, et al.             Expires April 2, 2016                [Page 16]