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

<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>

   <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>Salesforce</organization>
     <address>
       <postal>
         <street>415 Mission St</street>
         <city>San Francisco</city><region>CA</region>
         <code>94105</code>
         <country>United States of America</country>
       </postal>
       <email>tale@dd.org</email>
     </address>
   </author>
   <date month="October" year="2020"/>

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

     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. Apologies if we forgot to acknowledge
     your contributions.</t>

     <t>One author also wants to thank the band Infected Mushroom
     for providing a good background soundtrack. 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>
