rfc8914.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">

<!-- WK: Set category, IPR, docName -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dnsop-extended-error-16" number="8914" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.44.0 -->

  <front>
    <!-- WK: Set long title. -->

    <title abbrev="Extended DNS Errors">Extended DNS
    Errors</title>
    <seriesInfo name="RFC" value="8914"/>
    <author fullname="Warren Kumari" initials="W." surname="Kumari">
      <organization>Google</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View</city><region>CA</region>
          <code>94043</code>
          <country>United States of America</country>
        </postal>
        <email>warren@kumari.net</email>
      </address>
    </author>
    <author fullname="Evan Hunt" initials="E." surname="Hunt">
      <organization>ISC</organization>
      <address>
        <postal>
          <street>950 Charter St</street>
          <city>Redwood City</city><region>CA</region>
          <code>94063</code>
          <country>United States of America</country>
        </postal>
        <email>each@isc.org</email>
      </address>
    </author>
    <author fullname="Roy Arends" initials="R." surname="Arends">
      <organization>ICANN</organization>
      <address>
        <postal>
          <street/>
        </postal>
        <email>roy.arends@icann.org</email>
      </address>
    </author>
    <author fullname="Wes Hardaker" initials="W." surname="Hardaker">
      <organization>USC/ISI</organization>
      <address>
        <postal>
          <street>P.O. Box 382</street>
          <city>Davis</city><region>CA</region>
          <code>95617</code>
          <country>United States of America</country>
        </postal>
        <email>ietf@hardakers.net</email>
      </address>
    </author>
    <author fullname="David C Lawrence" initials="D." surname="Lawrence">
      <organization>Oracle + Dyn</organization>
      <address>
        <postal>
          <street>150 Dow St</street>
          <city>Manchester</city><region>NH</region>
          <code>03101</code>
          <country>United States of America</country>
        </postal>
        <email>tale@dd.org</email>
      </address>
    </author>
    <date month="September" year="2020"/>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>DNS</keyword>
<keyword>Error</keyword>
<keyword>Domain</keyword>
<keyword>Name</keyword>
<keyword>System</keyword>

    <abstract>
      <t>This document defines an extensible method to return
      additional information about the cause of DNS errors. Though
      created primarily to extend SERVFAIL to provide additional
      information about the cause of DNS and DNSSEC failures, the
      Extended DNS Errors option defined in this document allows all
      response types to contain extended error information. Extended
      DNS Error information does not change the processing of RCODEs.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="default">
      <name>Introduction and Background</name>
      <t>There are many reasons that a DNS query may fail -- some of
      them transient, some permanent; some can be resolved by querying
      another server, some are likely best handled by stopping
      resolution.  Unfortunately, the error signals that a DNS server
      can return are very limited and are not very expressive. This
      means that applications and resolvers often have to "guess" at
      what the issue is, e.g., was the answer marked REFUSED because
      of a lame delegation or because the nameserver is still
      starting up and loading zones? Is a SERVFAIL a DNSSEC validation
      issue, or is the nameserver experiencing some other failure?
      What error messages should be presented to the user or logged
      under these conditions?</t>
      <t>A good example of issues that would benefit from additional
      error information are errors caused by DNSSEC validation
      issues. When a stub resolver queries a name that is DNSSEC
      bogus <xref target="RFC8499" format="default"/> (using a validating resolver),
      the stub resolver receives only a SERVFAIL in
      response. Unfortunately, the SERVFAIL Response Code (RCODE) is
      used to signal many sorts of DNS errors, and so the stub
      resolver's only option is to ask the next configured DNS
      resolver. The result of trying the next resolver is one of two
      outcomes: either the next resolver also validates and a
      SERVFAIL is returned again or the next resolver is not a
      validating resolver and the user is returned a potentially
      harmful result.  With an Extended DNS Error (EDE) option
      enclosed in the response message, the resolver is able to return
      a more descriptive reason as to why any failures happened or
      add additional context to a message containing a NOERROR
      RCODE.</t>
      <t>This document specifies a mechanism to extend DNS errors to
      provide additional information about the cause of an error.
      The Extended DNS Error codes described in this document
      can be used by any system that sends DNS queries and receives a
      response containing an EDE option. Different codes are useful
      in different circumstances, and thus different systems (stub
      resolvers, recursive resolvers, and authoritative resolvers)
      might receive and use them.</t>
      <section numbered="true" toc="default">
        <name>Requirements Notation</name>
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.
        </t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>Extended DNS Error EDNS0 Option Format</name>
      <t>This document uses an Extended Mechanism for DNS (EDNS0) <xref
      target="RFC6891" format="default"/> option to include 
      Extended DNS Error (EDE) information in DNS messages. The option
      is structured as follows:</t>
      <artwork align="left" name="" type="" alt=""><![CDATA[
                                             1   1   1   1   1   1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: |                            OPTION-CODE                        |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: |                           OPTION-LENGTH                       |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: | INFO-CODE                                                     |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: / EXTRA-TEXT ...                                                /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
      <t/>
      <t>Field definition details:</t>
      <dl newline="true">
        <dt>OPTION-CODE: </dt>
	<dd>2 octets / 16 bits (defined in <xref target="RFC6891"
	format="default"/>) contains the value 15 for EDE.</dd> 
	
          <dt>OPTION-LENGTH: </dt>
	  <dd>2 octets / 16 bits (defined in <xref target="RFC6891" format="default"/>) contains
          the length of the payload (everything after OPTION-LENGTH)
          in octets and should be 2 plus the length of the EXTRA-TEXT
          field (which may be a zero-length string).</dd>
	  
          <dt>INFO-CODE:</dt>
	  <dd>16 bits, which is the principal contribution
          of this document.  This 16-bit value, encoded in network
          most significant bit (MSB) byte order, provides the additional context for the
          RESPONSE-CODE of the DNS message. The INFO-CODE serves as an
          index into the "Extended DNS Errors" registry, defined and
          created in <xref target="IANA" format="default"/>.</dd>
	  
          <dt>EXTRA-TEXT: </dt>
	  <dd>a variable-length, UTF-8-encoded <xref target="RFC5198"
	  format="default"/> text field that may hold additional 
          textual information. This information is intended for human
          consumption (not automated parsing).  EDE text may be null
          terminated but <bcp14>MUST NOT</bcp14> be assumed to be; the length <bcp14>MUST</bcp14> be
          derived from the OPTION-LENGTH field. The EXTRA-TEXT field
          may be zero octets in length, indicating that there is no
          EXTRA-TEXT included.  Care should be taken not to include
          private information in the EXTRA-TEXT field that an observer
          would not otherwise have access to, such as account
          numbers.</dd>
	</dl>
	
      <t>The Extended DNS Error (EDE) option can be included in any
      response (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to
      a query that includes an OPT pseudo-RR <xref target="RFC6891" format="default"/>.
      This document includes a set of initial codepoints but is
      extensible via the IANA registry defined and created in <xref target="IANA" format="default"/>.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Extended DNS Error Processing</name>
      <t>When the response grows beyond the requestor's UDP payload
      size <xref target="RFC6891" format="default"/>, servers <bcp14>SHOULD</bcp14> truncate messages
      by dropping EDE options before dropping other data from packets.
      Implementations <bcp14>SHOULD</bcp14> set the truncation bit when dropping EDE
      options.  Because long EXTRA-TEXT fields may trigger truncation
      (which is undesirable given the supplemental nature of
      EDE), implementers and operators creating EDE options <bcp14>SHOULD</bcp14>
      avoid lengthy EXTRA-TEXT contents.</t>
      <t>When a resolver or forwarder receives an EDE option, whether
      or not (and how) to pass along EDE information on to their
      original client is implementation dependent. Implementations <bcp14>MAY</bcp14>
      choose to not forward information, or they <bcp14>MAY</bcp14> choose to create
      a new EDE option(s) that conveys the information encoded in the
      received EDE.  When doing so, the source of the error <bcp14>SHOULD</bcp14> be
      attributed in the EXTRA-TEXT field, since an EDNS0 option
      received by the original client will appear to have come from
      the resolver or forwarder sending it.</t>
      <t>This document does not allow or prohibit any particular
      extended error codes and information to be matched with any
      particular RCODEs. Some combinations of extended error codes and
      RCODEs may seem nonsensical (such as resolver-specific extended
      error codes received in responses from authoritative servers), so systems
      interpreting the extended error codes <bcp14>MUST NOT</bcp14> assume that a
      combination will make sense.  Receivers <bcp14>MUST</bcp14> be able to accept
      EDE codes and EXTRA-TEXT in all messages, including those with a
      NOERROR RCODE but need not act on them.  Applications <bcp14>MUST</bcp14>
      continue to follow requirements from applicable specifications on how to
      process RCODEs no matter what EDE values are also received.
      Senders <bcp14>MAY</bcp14> include more than one EDE option and receivers <bcp14>MUST</bcp14>
      be able to accept (but not necessarily process or act on)
      multiple EDE options in a DNS message.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Defined Extended DNS Errors</name>
      <t>This document defines some initial EDE codes. The mechanism
      is intended to be extensible, and additional codepoints can be
      registered in the "Extended DNS Errors" registry (<xref target="IANA"
      format="default"/>).  The INFO-CODE from the EDE EDNS option is 
      used to serve as an index into the "Extended DNS Error" IANA
      registry, the initial values for which are defined in the
      following subsections.</t>
      <section anchor="errother" numbered="true" toc="default">
        <name>Extended DNS Error Code 0 - Other</name>
        <t>The error in question falls into a category that does
	      not match known extended error codes.  Implementations
	      <bcp14>SHOULD</bcp14> include an EXTRA-TEXT value to augment this error
	      code with additional information.</t>
      </section>
      <section anchor="errbaddnskeyalg" numbered="true" toc="default">
        <name>Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm</name>
        <t>The resolver attempted to perform DNSSEC validation, but a DNSKEY
          RRset contained only unsupported DNSSEC algorithms.</t>
      </section>
      <section anchor="errbaddsdigest" numbered="true" toc="default">
        <name>Extended DNS Error Code 2 - Unsupported DS Digest Type</name>
        <t>The resolver attempted to perform DNSSEC validation, but a DS
          RRset contained only unsupported Digest Types.</t>
      </section>
      <section anchor="stalenoerror" numbered="true" toc="default">
        <name>Extended DNS Error Code 3 - Stale Answer</name>
        <t>The resolver was unable to resolve the answer within its
          time limits and decided to answer with previously cached
          data instead of answering with an error.  This is typically
          caused by problems communicating with an authoritative
          server, possibly as result of a denial of service (DoS)
          attack against another network. (See also Code 19.)</t>
      </section>
      <section anchor="forgedanswer" numbered="true" toc="default">
        <name>Extended DNS Error Code 4 - Forged Answer</name>
        <t>For policy reasons (legal obligation or malware
          filtering, for instance), an answer was forged.  Note that
          this should be used when an answer is still provided, not
          when failure codes are returned instead.  See Blocked (15),
          Censored (16), and Filtered (17) for use when returning
          other response codes.</t>
      </section>
      <section anchor="errindeterminate" numbered="true" toc="default">
        <name>Extended DNS Error Code 5 - DNSSEC Indeterminate</name>
        <t>The resolver attempted to perform DNSSEC validation, but
          validation ended in the Indeterminate state <xref target="RFC4035" format="default"/>.</t>
      </section>
      <section anchor="errbogus" numbered="true" toc="default">
        <name>Extended DNS Error Code 6 - DNSSEC Bogus</name>
        <t>The resolver attempted to perform DNSSEC validation, but
          validation ended in the Bogus state.</t>
      </section>
      <section anchor="errexpired" numbered="true" toc="default">
        <name>Extended DNS Error Code 7 - Signature Expired</name>
        <t>The resolver attempted to perform DNSSEC validation, but
          no signatures are presently valid and some (often all) are
          expired.</t>
      </section>
      <section anchor="errprior" numbered="true" toc="default">
        <name>Extended DNS Error Code 8 - Signature Not Yet Valid</name>
        <t>The resolver attempted to perform DNSSEC validation, but
          no signatures are presently valid and at least some are
          not yet valid.</t>
      </section>
      <section anchor="errnodnskey" numbered="true" toc="default">
        <name>Extended DNS Error Code 9 - DNSKEY Missing</name>
        <t>A DS record existed at a parent, but no supported
          matching DNSKEY record could be found for the child.</t>
      </section>
      <section anchor="errnorrsig" numbered="true" toc="default">
        <name>Extended DNS Error Code 10 - RRSIGs Missing</name>
        <t>The resolver attempted to perform DNSSEC validation, but no
          RRSIGs could be found for at least one RRset where RRSIGs were
          expected.</t>
      </section>
      <section anchor="errnozonekey" numbered="true" toc="default">
        <name>Extended DNS Error Code 11 - No Zone Key Bit Set</name>
        <t>The resolver attempted to perform DNSSEC validation, but no Zone
          Key Bit was set in a DNSKEY.</t>
      </section>
      <section anchor="nonsec" numbered="true" toc="default">
        <name>Extended DNS Error Code 12 - NSEC Missing</name>
        <t>The resolver attempted to perform DNSSEC validation, but
          the requested data was missing and a covering NSEC or NSEC3
          was not provided.</t>
      </section>
      <section anchor="cachederror" numbered="true" toc="default">
        <name>Extended DNS Error Code 13 - Cached Error</name>
        <t>The resolver is returning the SERVFAIL RCODE from its cache.</t>
      </section>
      <section anchor="notready" numbered="true" toc="default">
        <name>Extended DNS Error Code 14 - Not Ready</name>
        <t>The server is unable to answer the query, as it was not
          fully functional when the query was received.</t>
      </section>
      <section anchor="errblocked" numbered="true" toc="default">
        <name>Extended DNS Error Code 15 - Blocked</name>
        <t>The server is unable to respond to the request because
          the domain is on a blocklist due to an internal security policy
          imposed by the operator of the server resolving or forwarding
          the query.</t>
      </section>
      <section anchor="errcensored" numbered="true" toc="default">
        <name>Extended DNS Error Code 16 - Censored</name>
        <t>The server is unable to respond to the request because
          the domain is on a blocklist due to an external requirement
          imposed by an entity other than the operator of the server
          resolving or forwarding the query. Note that how the imposed
          policy is applied is irrelevant (in-band DNS filtering,
          court order, etc.).</t>
      </section>
      <section anchor="errfiltered" numbered="true" toc="default">
        <name>Extended DNS Error Code 17 - Filtered</name>
        <t>The server is unable to respond to the request because
          the domain is on a blocklist as requested by the client.
          Functionally, this amounts to "you requested that we filter
          domains like this one."</t>
      </section>
      <section anchor="errprohibted" numbered="true" toc="default">
        <name>Extended DNS Error Code 18 - Prohibited</name>
        <t>An authoritative server or recursive resolver that receives a query from
          an "unauthorized" client can annotate its REFUSED message with this
          code. Examples of "unauthorized" clients are recursive queries from
          IP addresses outside the network, blocklisted IP addresses, local
          policy, etc.</t>
      </section>
      <section anchor="stalenx" numbered="true" toc="default">
        <name>Extended DNS Error Code 19 - Stale NXDOMAIN Answer</name>
        <t>The resolver was unable to resolve an answer within its
          configured time limits and decided to answer with a
          previously cached NXDOMAIN answer instead of answering with
          an error. This may be caused, for example, by problems
          communicating with an authoritative server, possibly as
          result of a denial of service (DoS) attack against another
          network. (See also Code 3.) </t>
      </section>
      <section anchor="errlame" numbered="true" toc="default">
        <name>Extended DNS Error Code 20 - Not Authoritative</name>
        <t>An authoritative server that receives a query with the Recursion
	Desired (RD) bit clear,
         or when it is not configured for recursion for a domain for which it is
         not authoritative, <bcp14>SHOULD</bcp14> include this EDE code in the REFUSED
         response.  A resolver that receives a query with the RD bit clear
         <bcp14>SHOULD</bcp14> include this EDE code in the REFUSED response.</t>
      </section>
      <section anchor="deprecated" numbered="true" toc="default">
        <name>Extended DNS Error Code 21 - Not Supported</name>
        <t>The requested operation or query is not supported.</t>
      </section>
      <section anchor="noreachable" numbered="true" toc="default">
        <name>Extended DNS Error Code 22 - No Reachable Authority</name>
        <t>The resolver could not reach any of the authoritative name servers
          (or they potentially refused to reply).</t>
      </section>
      <section anchor="networkerror" numbered="true" toc="default">
        <name>Extended DNS Error Code 23 - Network Error</name>
        <t>An unrecoverable error occurred while communicating with
          another server.</t>
      </section>
      <section anchor="invaliddata" numbered="true" toc="default">
        <name>Extended DNS Error Code 24 - Invalid Data</name>
        <t>The authoritative server cannot answer with data for
          a zone it is otherwise configured to support.  Examples of
          this include its most recent zone being too old or having
          expired.</t>
      </section>
    </section>
    <section numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section numbered="true" toc="default">
        <name>A New Extended DNS Error Code EDNS Option</name>
        <t>This document defines a new EDNS(0) option, entitled
        "Extended DNS Error", with the assigned value of 15 from the "DNS
        EDNS0 Option Codes (OPT)" registry:
	</t>
	
        <table anchor="ext-DNS">
	<thead>
	<tr>
	<th> Value </th>
	<th> Name </th>
	<th> Status </th>
	<th> Reference </th>
	</tr>
	</thead>
	
	<tbody>
	<tr>
	<td>15</td>
	<td>Extended DNS Error</td>
	<td>Standard</td>
	<td>RFC 8914</td>
      </tr>
	</tbody>
	
	</table>
      </section>
      <section anchor="IANA" numbered="true" toc="default">
        <name>New Registry for Extended DNS Error Codes</name>
        <t>IANA has created and will maintain a new registry
        called "Extended DNS Error Codes" on the "Domain Name
        System (DNS) Parameters" web page as follows:</t>

<table anchor="reg_proc">
  <thead>
    <tr>
      <th>Range</th>
      <th>Registration Procedures</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0 - 49151</td><td>First Come First Served</td>
    </tr>
    <tr>
      <td>49152 - 65535</td><td>Private Use</td>
    </tr>
  </tbody>
</table>

        <t>The "Extended DNS Error Codes" registry is a table with
        three columns: INFO-CODE, Purpose, and Reference. The initial
        content is as below.</t>
        <table>
	    <thead>
	      <tr>
		<th>INFO-CODE </th>
		<th>Purpose </th>
		<th>Reference </th>
	      </tr>
	    </thead>
	    <tbody>
	      <tr>
		<td> 0 </td>
		<td> Other Error</td>
		<td>  <xref target="errother" format="default"/> </td>
	      </tr>
	      <tr>
		<td> 1  </td>
		<td align="center"> Unsupported DNSKEY Algorithm  </td>
		<td>  <xref target="errbaddnskeyalg" format="default"/>  </td>
	      </tr>
	       <tr>
		<td> 2  </td>
		<td>Unsupported DS Digest Type </td>
		<td> <xref target="errbaddsdigest" format="default"/>  </td>
	       </tr>
	        <tr>
		<td> 3  </td>
		<td> Stale Answer  </td>
		<td>  <xref target="stalenoerror" format="default"/> and
    <xref target="RFC8767" format="default"/>  </td>
		</tr>
		 <tr>
		<td> 4  </td>
		<td> Forged Answer  </td>
		<td>  <xref target="forgedanswer" format="default"/>  </td>
		 </tr>
		  <tr>
		<td> 5  </td>
		<td> DNSSEC Indeterminate  </td>
		<td> <xref target="errindeterminate" format="default"/>  </td>
		  </tr>
		   <tr>
		<td> 6  </td>
		<td>DNSSEC Bogus </td>
		<td>  <xref target="errbogus" format="default"/>   </td>
		   </tr>
		    <tr>
		<td> 7  </td>
		<td> Signature Expired  </td>
		<td>  <xref target="errexpired" format="default"/>   </td>
		    </tr>
		    <tr>
		      <td>8 </td>
		      <td>Signature Not Yet Valid </td>
		      <td> <xref target="errprior" format="default"/> </td>
		    </tr>
		       <tr>
		      <td>9 </td>
		      <td>DNSKEY Missing </td>
		      <td> <xref target="errnodnskey" format="default"/> </td>
		       </tr>
		          <tr>
		      <td>10 </td>
		      <td>RRSIGs Missing </td>
		      <td> <xref target="errnorrsig" format="default"/> </td>
			  </tr>
			     <tr>
		      <td>11 </td>
		      <td>No Zone Key Bit Set </td>
		      <td> <xref target="errnozonekey" format="default"/> </td>
			     </tr>
			        <tr>
		      <td>12 </td>
		      <td>NSEC Missing </td>
		      <td> <xref target="nonsec" format="default"/> </td>
				</tr>
				   <tr>
		      <td>13 </td>
		      <td>Cached Error </td>
		      <td> <xref target="cachederror" format="default"/> </td>
				   </tr>
				      <tr>
		      <td>14 </td>
		      <td>Not Ready</td>
		      <td> <xref target="notready" format="default"/> </td>
				      </tr>
				         <tr>
		      <td>15 </td>
		      <td>Blocked </td>
		      <td> <xref target="errblocked" format="default"/> </td>
		     </tr>
			<tr>
			<td>16 </td>
		      <td>Censored </td>
		      <td> <xref target="errcensored" format="default"/> </td>
			</tr>
		       <tr>
			<td>17 </td>
		      <td>Filtered </td>
		      <td> <xref target="errfiltered" format="default"/> </td>
		      </tr>
			 <tr>
		      <td>18 </td>
		      <td>Prohibited </td>
		      <td> <xref target="errprohibted" format="default"/> </td>
			</tr>
			 <tr>
		      <td>19 </td>
		      <td>Stale NXDomain Answer </td>
		      <td> <xref target="stalenx" format="default"/> </td>
			 </tr>
			 <tr>
		      <td>20 </td>
		      <td>Not Authoritative </td>
		      <td> <xref target="errlame" format="default"/> </td>
			 </tr>
			  <tr>
		       <td>21 </td>
		      <td>Not Supported </td>
		      <td><xref target="deprecated" format="default"/> </td>
			  </tr>
			  	 
			  <tr>
		       <td>22 </td>
		      <td>No Reachable Authority </td>
		      <td> <xref target="noreachable" format="default"/> </td>
			  </tr>
			  	 
			  <tr>
		       <td>23 </td>
		      <td>Network Error </td>
		      <td> <xref target="networkerror" format="default"/> </td>
			  </tr>
			  	
			  <tr>
		       <td>24 </td>
		      <td>Invalid Data </td>
		      <td> <xref target="invaliddata" format="default"/> </td>
			  </tr>
			  	 
			  <tr>
		       <td>25-49151</td>
		      <td>Unassigned</td>
		      <td></td>
			  </tr>
			  <tr>
			    <td>49152-65535</td>
			    <td>Reserved for Private Use</td>
			    <td><xref target="IANA"/></td>
			  </tr>
	    </tbody>
	</table>

      </section>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Though DNSSEC continues to be deployed, unfortunately a
      significant number of clients (~11% according to <xref target="GeoffValidation" format="default"/>) that receive a SERVFAIL from a
      validating resolver because of a DNSSEC validation issue will
      simply ask the next (potentially non-validating) resolver in
      their list and thus don't get the protections that
      DNSSEC should provide.</t>
      <t>EDE information is unauthenticated information, unless
      secured by a form of secured DNS transaction, such as <xref
      target="RFC2845" format="default"/>, <xref target="RFC2931"
      format="default"/>, <xref target="RFC8094" format="default"/>, or <xref
      target="RFC8484" format="default"/>. An attacker (e.g., a man in the
      middle (MITM) or malicious
      recursive server) could insert an extended error response into
      untrusted data -- although, ideally, clients and resolvers
      would not trust any unauthenticated information.  As such, EDE
      content should be treated only as diagnostic information and
      <bcp14>MUST NOT</bcp14> alter DNS protocol processing.  Until all DNS answers
      are authenticated via DNSSEC or the other mechanisms mentioned
      above, there are some trade-offs. As an example, an attacker who
      is able to insert the DNSSEC Bogus Extended Error into a DNS
      message could instead simply reply with a fictitious address (A
      or AAAA) record.  Note that DNS RCODEs also
      contain no authentication and can be just as easily manipulated.
      </t>
      <t>By design, EDE potentially exposes additional information
      via DNS resolution processes that may leak information. 
<!--[rfced] We are having some trouble parsing this sentence, particularly
because of the first instance of "information". Please let us know how we may
clairfy. 

Original:
   By design, EDE potentially exposes additional information DNS
   resolution processes that may leak information. 

Perhaps:
   By design, EDE potentially exposes additional DNS
   resolution processes that may leak information. 

Or:
   By design, EDE potentially exposes additional information from DNS
   resolution processes that may leak information. 

ANSWER: Good catch, but really none of those.  I think adding "via" as I did
above fixes the sentence.  Look ok?  -Wes

-->
      An example
      of this is the Prohibited EDE code (18), which may leak the fact
      that the name is on a blocklist.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5198.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8499.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8767.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2845.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2931.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/>

        <reference anchor="GeoffValidation" target="http://www.potaroo.net/presentations/2016-06-27-dnssec.pdf">
          <front>
            <title abbrev="Validation today">A quick review of DNSSEC Validation
          in today's Internet</title>
            <author initials="G" surname="Huston" fullname="Geoff Huston">
              <organization>APNIC</organization>
            </author>
            <date month="June" year="2016"/>
          </front>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="default">
      <name>Acknowledgements</name>

      <t>The authors wish to thank <contact fullname=" Joe Abley"/>, <contact
      fullname="Mark Andrews"/>, <contact fullname="Tim April"/>, <contact
      fullname="Vittorio Bertola"/>, <contact fullname="Stephane
      Bortzmeyer"/>, <contact fullname="Vladimir Cunat"/>, <contact
      fullname="Ralph Dolmans"/>, <contact fullname="Peter DeVries"/>,
      <contact fullname="Peter van Dijk"/>, <contact fullname="Mats
      Dufberg"/>, <contact fullname=" Donald Eastlake"/>, <contact
      fullname="Bob Harold"/>, <contact fullname="Paul Hoffman"/>, <contact
      fullname="Geoff Huston"/>, <contact fullname=" Shane Kerr"/>, <contact
      fullname="Edward Lewis"/>, <contact fullname="Carlos M. Martinez"/>,
      <contact fullname="George Michelson"/>, <contact fullname="Eric Orth"/>,
      <contact fullname="Michael Sheldon"/>, <contact fullname="Puneet
      Sood"/>, <contact fullname="Petr Spacek"/>, <contact fullname=" Ondrej
      Sury"/>, <contact fullname="John Todd"/>, <contact fullname="Loganaden
      Velvindron"/>, and <contact fullname="Paul Vixie"/>.  They also vaguely
      remember discussing this with a number of people over the years but have
      forgotten who all of them were.</t>

      <t>One author also wants to thank the band Infected Mushroom
      for providing a good background soundtrack (and to see if he can
      get away with this in an RFC!). Another author would like to
      thank the band Mushroom Infectors. This was funny at the time
      we wrote it, but we cannot remember why...</t>
       </section>
  </back>
</rfc>