<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-spacek-edns-camel-diet-00"
     ipr="trust200902">
  <front>
    <title abbrev="Minimal EDNS compliance">Minimal EDNS compliance requirements</title>

    <author fullname="Petr Spacek" initials="P." surname="Spacek">

      <organization abbrev="CZ.NIC"/>

      <address>
        <email>petr.spacek@nic.cz</email>
      </address>
    </author>

    <author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
      <organization abbrev="Cloudflare"/>

      <address>
        <email>olafur+ietf@cloudflare.com</email>
      </address>
    </author>

    <author fullname="Ondrej Sury" initials="O." surname="Sury">
      <organization abbrev="ISC"/>

      <address>
        <email>ondrej@isc.org</email>
      </address>
    </author>

    <date day="19" month="March" year="2018"/>

    <area>Internet</area>

    <abstract>
	    <t>DNS responders must either follow RFC 6891 by implementing EDNS or respond with RCODE=FORMERR to queries containing OPT record.
		    Non-compliant implementations are not worth talking to.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
    <t>
	    EDNS version 0 was standardized in 1999, but non-RFC 1035 compliant implementations still exist and cause lot of extra queries and complicated logic in recursive resolvers. RFC 6891 clearly states that FORMERR is the only acceptable answer for implementations without support for EDNS. The cost of supporting these non-compliant implementations keeps increasing.
    </t>
      <section title="Terminology">
        <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 RFC 2119.</t>
      </section>
    </section>

    <section title="The Protocol">
	    <t>No DNS response message to a repeated DNS query containing EDNS extension means that the other side is not a DNS responder and the querier MUST NOT retry its query without EDNS.</t>
    </section>

    <section title="Security Considerations">
      <t>Instruction to follow EDNS standard does not change security properties beyond what is written in RFC 6891.</t>
    </section>

    <section title="Privacy Considerations">
      <t>This has no effect on privacy of DNS.</t>
    </section>

    <section title="IANA Considerations">
      <t>[Note to IANA, to be removed prior to publication: there are no IANA
      considerations stated in this version of the document.]</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='https://xml2rfc.tools.ietf.org/public/rfc/bibxml-rfcs/reference.RFC.2671.xml'?>

      <?rfc include='https://xml2rfc.tools.ietf.org/public/rfc/bibxml-rfcs/reference.RFC.6891.xml'?>

      <?rfc include='https://xml2rfc.tools.ietf.org/public/rfc/bibxml-rfcs/reference.RFC.1035.xml'?>

    </references>
  </back>
</rfc>
