draft-ogud-dnsop-any-notimp.xml

<?xml version="1.0" encoding="US-ASCII"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc1035 PUBLIC "" "./reference.RFC.1035.xml">
  <!ENTITY rfc1995 PUBLIC "" "./reference.RFC.1995.xml">
  <!ENTITY rfc2119 PUBLIC "" "./reference.RFC.2119.xml">
  <!ENTITY rfc2845 PUBLIC "" "./reference.RFC.2845.xml">
  <!ENTITY rfc3833 PUBLIC "" "./reference.RFC.3833.xml">
  <!ENTITY rfc4034 PUBLIC "" "./reference.RFC.4034.xml">
  <!ENTITY rfc5358 PUBLIC "" "./reference.RFC.5358.xml">
]>

<rfc category="std" docName="draft-ogud-dnsop-any-notimp-01"
     ipr="trust200902" updates="1035">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes"?>
  <?rfc compact="yes" ?>

  <front>
    <title abbrev="Refusing DNS Queries of Type ANY">
      Required Behaviour for Authoritative-Only DNS Servers that
      Refuse Meta Queries 
    </title>
     
    <author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
      <organization>CloudFlare Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>San Francisco</city>
          <region>CA</region>
          <code>94107</code>
          <country>USA</country>
        </postal>
        <email>olafur@cloudflare.com</email>
      </address>
    </author>

    <author fullname="Marek Majkowski" initials="M." surname="Majkowski">
      <organization>CloudFlare Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>London</city>
          <region></region>
          <code></code>
          <country>UK</country>
        </postal>
        <email>marek@cloudflare.com</email>
      </address>
    </author>

    <author fullname="Joe Abley" initials="J." surname="Abley">
      <organization>Dyn, Inc.</organization>
      <address>
        <postal>
          <street>103-186 Albert Street</street>
          <city>London</city>
          <region>ON</region>
          <code>N6A 1M1</code>
          <country>Canada</country>
        </postal>
        <email>jabley@dyn.com</email>
      </address>
    </author>

    <date />
      
    <area>Operations</area>
      
    <workgroup>DNSOP</workgroup>
      
    <abstract>
      <t> Some DNS types have special meaning and are classified as
	meta queries, this includes ANY, AXFR, IXFR. 
	These queries frequently return larger answers than
	queries for other types. 
      </t> 
      <t> This document defines a standard way
	for Authoritative-Only servers to refuse to serve these and
	other similar queries, with the expectation that resolvers honor that, by not
	asking followup queries. 
      </t> 
    </abstract>
  </front>

  <middle>
    <section title="Introduction"> 
      <t> The <xref target="RFC1035"> DNS Specification</xref> meta queries where defined for use either zone
	  maintenance AXFR, full zone transfer,
	  <xref target="RFC1995">IXFR</xref>, incremental zone transfer. For
	  security reasons Authoritative name servers frequently only respond to
	  these queries if a TSIG  <xref target="RFC2845"/>  key is presented or the query comes
	  from an approved address. 
      </t> 
      <t>The ANY meta query was defined for debugging purposes
	mainly against resolvers. There have been widespread
	misunderstanding as to what the query is supposed to do and when
	it is appropriate. The query is intended for testing what
	records for a particular name a resolver has in its cache. 
	There are security implications related to 
	information leaks and use in DoS attacks that strongly
	argue for restricting its use like the other Meta Queries. 
	</t> 

      <t> 
	RRSIG <xref target="RFC4034"/> type used in a query can also
	return large answers as the server attempts to put all RRSIG
	records at that one name into one answer. This type was
	envisioned as deployment tool for validators to overcome
	resolvers and/or servers that did not understand DNSSEC. 
	For all practical purposes this is never needed. 
	</t> 

      <t>Queries yielding large answers are known to be widely abused by
        attackers carrying out reflection attacks, since they provide
        a convenient way to elicit large responses from small queries,
        and hence exhibit significant amplification potential. A similar
        reaction to an operational security problem can be observed in
        the advice contained within <xref target="RFC5358"/>.
      </t>

      <t>The data model used by some authoritative-only DNS server
        implementations does not align easily with the zone structure
        described in <xref target="RFC1035"/>, and responding accurately
        to meta queries involves significant
        processing overhead. The ability to refuse meta queries 
        can simplify the implementation with corresponding benefits to
        performance and code correctness.</t>

      <t>Recursive Resolvers frequently treat REFUSED as a temporary
      denial. In the case of policy statement that certain queries
      will not answered, having a more explicit statement is
      beneficial. There are two choices as how more permanent
      semantics can be expressed, reusing an existing RCODE or define
      a new one. This document proposes reusing the NOTIMP rcode. 
	This feels like the right choice as far as the querier is
      concerned. It makes no difference if the meta type is implemented
      or the authoritative server has no interest in providing that
      service to the client. 
      </t> 
      <t>Various DNS operators have chosen to refuse various meta queries including
	QTYPE=ANY in the past, using a variety of approaches,
	including rate-limiting of queries and responses, returning
	TC=1 on queries received via UDP transport and
	silently dropping queries 
	before they reach the DNS server.  Consistency in approach
	would provide a more predictable outcome for DNS clients.</t>

    </section>

    <section title="Requirements Notation">
      <t>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 <xref target="RFC2119"/>.</t>
    </section>

    <section title="Protocol Changes">
      <t> DNS processing entities SHOULD support authenticated meta
      queries, and process them when appropriate as defined by
      policy. By default support should be disabled. When disabled 
      the behavior below should be used. The types where this behavior
      is appropriate includes ANY, AXFR, IXFR, RRSIG. 
      </t> 
	
      <t>An authoritative-only DNS server MAY reject meta queries received
        by returning RCODE=4 (NOTIMP).
      </t>

      <t>An iterative resolver MUST NOT forward a meta-query when the
	query arrives with RD=0, even when it has no types for that
	name. 
	An iterative resolver SHOULD ignore the RD bit set on a
        meta query's received, i.e. it SHOULD NOT forward them
        upstream.
      </t>

      <t>
	An iterative resolver that sends a query to an authoritative
	DNS server and receives a response with
	RCODE=4 SHOULD remember that upstream server's behaviour, for
	that qname, qtype combination. It should suppress any
	subsequent queries for that qname, qtype for that
	same server for at least one hour.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>No actions are requested of the IANA.</t>
    </section>

    <section title="Security Considerations">
      <t> In the original Internet where everyone behaved nicely had
      different security and operating model than modern Internet. This
      document is defining how DNS servers can express that they will
      never answer a particular query from a given address.
	RCODE=REFUSED is frequently treated as temporary thus
      resolver may repeat queries in the hope of getting an answer. 
      </t> 
      <t> An on-path attacker<xref target="RFC3833"/> can forge these
      answers easily, but as that document explains the attacker can
      anyway inject any lies it wants to. 
	</t> 
<!--     <t> DNS queries that return large answers are frequently abused as amplifiers
       for the purposes of carrying out denial-of-service attacks.
       Providing a standard way for authoritative-only DNS servers to
       refuse such queries has the potential to reduce the number of
       amplification vectors available to attackers, at minimal cost
       to DNS operators.
      </t> --> 
    </section>

    <section title="Implementation Experience"> 
      <t>TBD</t>
    </section> 

    <section title="Acknowledgements">
      <t> Editors want to thank following people, in random order, for
	useful feedback: 
	Paul Vixie, 
	Tony Finch, 
	Ralph Weber,
	Mark Andrews,
	Stephane Ortzmeyre, 
	Filippo Valsodra and
	Edward Lewis.
      </t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &rfc1035;
      &rfc2119;
    </references>

    <references title="Informative References">
      &rfc1995;
      &rfc2845;
      &rfc3833;
      &rfc4034;
      &rfc5358;
    </references>

    <section title="Document history"> 
      <t>This section (and sub-sections) should be removed before
        publication.</t>

      <section title="Venue">
        <t>An appropriate venue to discuss this draft is the dnsop
          working group mailing list.</t>
      </section>

      <section title="Abridged Revision History">
        <section title="draft-ogud-dnsop-any-notimp-00">
          <t>Initial draft.</t>
        </section>

        <section title="draft-ogud-dnsop-any-notimp-01">
          <t>Wordsmithing; add jabley as co-author; normalise
            normative language in protocol changes section.</t>
	  <t> Based on feeback from dnsop mailing list, we Expaned the scope of the document to cover "META" types
	  in general, and express that RCODE=NOTIMP should be cached by
	  resolvers. 
	    </t> 
        </section>
      </section>
    </section>
  </back>
</rfc>