One document matched: draft-ogud-dnsop-acl-metaqueries-00.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-acl-metaqueries-00"
     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="Resticting DNS Meta-Queries">
      DNS Meta-Queries resticted.
    </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 how 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
	  maintainance 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 approriate. The query is intented 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
	DNSSEC ignorant resolvers and/or servers.
	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 Resovlers frequently treat REFUSED as a temporary
	denial. In the case of policy statement that certain queries
	will not answered, having a more explicit statment is
	beneficial. There are two chocies as how more permanent
	semantics can be expressed, reusing an exisiting RCODE or define
	a new one. This docuemnt proposes reusing the NOTIMP rcode. 
	This feels like the right choice as 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. There are other options like defining
	new RCODE or place stronger semantics on REFUSED. 
      </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 qeries 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 resolvers and
	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 the implemenations SHOULD be restrict it to
      localhost via ACL. For all rejected meta-queries the behavior
      specified 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 RD=1 on a 
        meta query, 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 qclass, qname, qtype combination. It SHOULD suppress any
	subsequent qeries for that qclass, qname, qtype to that
	server for at least one day (??? better value needed). 
      </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 secrity and operating model than todays Internet. This
      document is defining how DNS servers can express that they will
      never answer a particular query from a given address.</t>
	<t>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,
	Edward Lewis, 
	and we forgot someone. 
      </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-acl-metaqueries-00">
          <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.  Changed language so it is more neutral to as
	  what path this work takes. 
	    </t> 
        </section>
      </section>
    </section>
  </back>
</rfc>