rfc8914xml2.original.xml		rfc8914.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [		<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
	]>
	<!-- WK: Set category, IPR, docName -->
	<rfc category="std" docName="draft-ietf-dnsop-extended-error-16"
	ipr="trust200902">
	<?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" ?>
	<?rfc subcompact="yes" ?>
	<front>
	<!-- WK: Set long title. -->
	<title abbrev="draft-ietf-dnsop-extended-error">Extended DNS
	Errors</title>
	<author fullname="Warren Kumari" initials="W." surname="Kumari">
	<organization>Google</organization>
	<address>
	<postal>
	<street>1600 Amphitheatre Parkway</street>
	<city>Mountain View, CA</city>
	<code>94043</code>
	<country>US</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, CA</city>
	<code>94063</code>
	<country>US</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, CA</city>
	<code>95617</code>
	<country>US</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, NH</city>
	<code>03101</code>
	<country>US</country>
	</postal>
	<email>tale@dd.org</email>
	</address>
	</author>
	<date day="05" month="May" year="2020"/>
	<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>		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-dnsop-extend
	<section title="Introduction and background" anchor="intro">		ed-error-16" number="8914" ipr="trust200902" obsoletes="" updates="" submissionT
	<t>There are many reasons that a DNS query may fail, some of		ype="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRe
	them transient, some permanent; some can be resolved by querying		fs="true" sortRefs="true" version="3">
	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		<!-- xml2rfc v2v3 conversion 2.44.0 -->
	error information are errors caused by DNSSEC validation
	issues. When a stub resolver queries a name which is DNSSEC
	bogus <xref target="RFC8499" /> (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		<front>
	provide additional information about the cause of an error.
	These extended DNS error codes are 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 title="Requirements notation">		<title abbrev="Extended DNS Errors">Extended DNS
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		Errors</title>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",		<seriesInfo name="RFC" value="8914"/>
	"MAY", and "OPTIONAL" in this document are to be interpreted as		<author fullname="Warren Kumari" initials="W." surname="Kumari">
	described in BCP 14 <xref target="RFC2119"/> <xref		<organization>Google</organization>
	target="RFC8174"/> when, and only when, they appear in all		<address>
	capitals, as shown here.</t>		<postal>
	</section>		<street>1600 Amphitheatre Parkway</street>
	</section>		<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"/>
	<section title="Extended DNS Error EDNS0 option format">		<keyword>DNS</keyword>
	<t>This draft uses an EDNS0 (<xref target="RFC6891" />) option to include		<keyword>Error</keyword>
	Extended DNS Error (EDE) information in DNS messages. The option		<keyword>Domain</keyword>
	is structured as follows:</t>		<keyword>Name</keyword>
			<keyword>System</keyword>
	<figure>		<abstract>
	<artwork align="left"><![CDATA[		<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 resolve
			r),
			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		1 1 1 1 1 1
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	0: | OPTION-CODE |		0: | OPTION-CODE |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	2: | OPTION-LENGTH |		2: | OPTION-LENGTH |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	4: | INFO-CODE |		4: | INFO-CODE |
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	6: / EXTRA-TEXT ... /		6: / EXTRA-TEXT ... /
	+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+		+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
	]]></artwork>		]]></artwork>
	</figure>		<t/>
			<t>Field definition details:</t>
	<t/>		<dl newline="true">
			<dt>OPTION-CODE: </dt>
	<t>Field definition details:</t>		<dd>2 octets / 16 bits (defined in <xref target="RFC6891"
			format="default"/>) contains the value 15 for EDE.</dd>
	<t><list style="symbols">
	<t>OPTION-CODE, 2-octets/16-bits (defined in <xref target="RFC6891"
	/>]), for EDE is TBD.
	[RFC Editor: change TBD to the proper code once assigned by IANA.]</t>
	<t>OPTION-LENGTH, 2-octets/16-bits ((defined in <xref
	target="RFC6891" />]) 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).</t>
	<t>INFO-CODE, 16-bits, which is the principal contribution
	of this document. This 16-bit value, encoded in network
	(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" />.</t>
	<t>EXTRA-TEXT, a variable length, UTF-8 encoded <xref
	target="RFC5198" />, 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 MUST NOT be assumed to be; the length MUST 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.</t>
	</list></t>
	<t>The Extended DNS Error (EDE) option can be included in any
	response (SERVFAIL, NXDOMAIN, REFUSED, and even NOERROR, etc) to
	a query that includes OPT Pseudo-RR <xref target="RFC6891" />.
	This document includes a set of initial codepoints, but is
	extensible via the IANA registry defined and created in <xref
	target="IANA" />.</t>
	</section>
	<section title="Extended DNS Error Processing">
	<t>When the response grows beyond the requestor's UDP payload
	size <xref target="RFC6891" />, servers SHOULD truncate messages
	by dropping EDE options before dropping other data from packets.
	Implementations SHOULD 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 SHOULD
	avoid lengthy EXTRA-TEXT contents.</t>
	<t>When a resolver or forwarder receives an EDE option, whether		<dt>OPTION-LENGTH: </dt>
	or not (and how) to pass along EDE information on to their		<dd>2 octets / 16 bits (defined in <xref target="RFC6891" format="defau
	original client is implementation dependent. Implementations MAY		lt"/>) contains
	choose to not forward information, or they MAY choose to create		the length of the payload (everything after OPTION-LENGTH)
	a new EDE option(s) that conveys the information encoded in the		in octets and should be 2 plus the length of the EXTRA-TEXT
	received EDE. When doing so, the source of the error SHOULD be		field (which may be a zero-length string).</dd>
	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		<dt>INFO-CODE:</dt>
	extended error codes and information to be matched with any		<dd>16 bits, which is the principal contribution
	particular RCODEs. Some combinations of extended error codes and		of this document. This 16-bit value, encoded in network
	RCODEs may seem nonsensical (such as resolver-specific extended		most significant bit (MSB) byte order, provides the additional context
	error codes in responses from authoritative servers), so systems		for the
	interpreting the extended error codes MUST NOT assume that a		RESPONSE-CODE of the DNS message. The INFO-CODE serves as an
	combination will make sense. Receivers MUST be able to accept		index into the "Extended DNS Errors" registry, defined and
	EDE codes and EXTRA-TEXT in all messages, including those with a		created in <xref target="IANA" format="default"/>.</dd>
	NOERROR RCODE, but need not act on them. Applications MUST
	continue to follow requirements from applicable specifications on how to
	process RCODEs no matter what EDE values are also received.
	Senders MAY include more than one EDE option and receivers MUST
	be able to accept (but not necessarily process or act on)
	multiple EDE options in a DNS message.</t>
	</section>
	<section title="Defined Extended DNS Errors">		<dt>EXTRA-TEXT: </dt>
	<t>This document defines some initial EDE codes. The mechanism		<dd>a variable-length, UTF-8-encoded <xref target="RFC5198"
	is intended to be extensible, and additional code-points can be		format="default"/> text field that may hold additional
	registered in the "Extended DNS Errors" registry <xref		textual information. This information is intended for human
	target="IANA" />. The INFO-CODE from the EDE EDNS option is		consumption (not automated parsing). EDE text may be null
	used to serve as an index into the "Extended DNS Error" IANA		terminated but <bcp14>MUST NOT</bcp14> be assumed to be; the length <bc
	registry, the initial values for which are defined in the		p14>MUST</bcp14> be
	following sub-sections.</t>		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>
	<section anchor="errother" title="Extended DNS Error Code 0 - Other">		<t>The Extended DNS Error (EDE) option can be included in any
	<t>The error in question falls into a category that does		response (SERVFAIL, NXDOMAIN, REFUSED, even NOERROR, etc.) to
			a query that includes an OPT pseudo-RR <xref target="RFC6891" format="defau
			lt"/>.
			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</bcp1
			4> 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</bc
			p14>
			choose to not forward information, or they <bcp14>MAY</bcp14> choose to cre
			ate
			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 acce
			pt
			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		not match known extended error codes. Implementations
	SHOULD include an EXTRA-TEXT value to augment this error		<bcp14>SHOULD</bcp14> include an EXTRA-TEXT value to augment this e rror
	code with additional information.</t>		code with additional information.</t>
	</section>		</section>
			<section anchor="errbaddnskeyalg" numbered="true" toc="default">
	<section anchor="errbaddnskeyalg"		<name>Extended DNS Error Code 1 - Unsupported DNSKEY Algorithm</name>
	title="Extended DNS Error Code 1 -		<t>The resolver attempted to perform DNSSEC validation, but a DNSKEY
	Unsupported DNSKEY Algorithm">		RRset contained only unsupported DNSSEC algorithms.</t>
	<t>The resolver attempted to perform DNSSEC validation, but a DNSKEY		</section>
	RRSET contained only unsupported DNSSEC algorithms.</t>		<section anchor="errbaddsdigest" numbered="true" toc="default">
	</section>		<name>Extended DNS Error Code 2 - Unsupported DS Digest Type</name>
			<t>The resolver attempted to perform DNSSEC validation, but a DS
	<section anchor="errbaddsdigest"		RRset contained only unsupported Digest Types.</t>
	title="Extended DNS Error Code 2 - Unsupported DS		</section>
	Digest Type">		<section anchor="stalenoerror" numbered="true" toc="default">
	<t>The resolver attempted to perform DNSSEC validation, but a DS		<name>Extended DNS Error Code 3 - Stale Answer</name>
	RRSET contained only unsupported Digest Types.</t>		<t>The resolver was unable to resolve the answer within its
	</section>		time limits and decided to answer with previously cached
			data instead of answering with an error. This is typically
	<section anchor="stalenoerror"		caused by problems communicating with an authoritative
	title="Extended DNS Error Code 3 - Stale Answer">		server, possibly as result of a denial of service (DoS)
	<t>The resolver was unable to resolve the answer within its		attack against another network. (See also Code 19.)</t>
	time limits and decided to answer with previously cached		</section>
	data instead of answering with an error. This is typically		<section anchor="forgedanswer" numbered="true" toc="default">
	caused by problems communicating with an authoritative		<name>Extended DNS Error Code 4 - Forged Answer</name>
	server, possibly as result of a denial of service (DoS)		<t>For policy reasons (legal obligation or malware
	attack against another network. (See also Code 19.)</t>		filtering, for instance), an answer was forged. Note that
	</section>		this should be used when an answer is still provided, not
			when failure codes are returned instead. See Blocked (15),
	<section anchor="forgedanswer"		Censored (16), and Filtered (17) for use when returning
	title="Extended DNS Error Code 4 - Forged Answer">		other response codes.</t>
	<t>For policy reasons (legal obligation, or malware		</section>
	filtering, for instance), an answer was forged. Note that		<section anchor="errindeterminate" numbered="true" toc="default">
	this should be used when an answer is still provided, not		<name>Extended DNS Error Code 5 - DNSSEC Indeterminate</name>
	when failure codes are returned instead. See Blocked(15),		<t>The resolver attempted to perform DNSSEC validation, but
	Censored (16), and Filtered (17) for use when returning		validation ended in the Indeterminate state <xref target="RFC4035" form
	other response codes.</t>		at="default"/>.</t>
	</section>		</section>
			<section anchor="errbogus" numbered="true" toc="default">
	<section anchor="errindeterminate"		<name>Extended DNS Error Code 6 - DNSSEC Bogus</name>
	title="Extended DNS Error Code 5 - DNSSEC Indeterminate">		<t>The resolver attempted to perform DNSSEC validation, but
	<t>The resolver attempted to perform DNSSEC validation, but		validation ended in the Bogus state.</t>
	validation ended in the Indeterminate state <xref		</section>
	target="RFC4035" />.</t>		<section anchor="errexpired" numbered="true" toc="default">
	</section>		<name>Extended DNS Error Code 7 - Signature Expired</name>
			<t>The resolver attempted to perform DNSSEC validation, but
	<section anchor="errbogus"		no signatures are presently valid and some (often all) are
	title="Extended DNS Error Code 6 - DNSSEC Bogus">		expired.</t>
	<t>The resolver attempted to perform DNSSEC validation, but		</section>
	validation ended in the Bogus state.</t>		<section anchor="errprior" numbered="true" toc="default">
	</section>		<name>Extended DNS Error Code 8 - Signature Not Yet Valid</name>
			<t>The resolver attempted to perform DNSSEC validation, but
	<section anchor="errexpired"		no signatures are presently valid and at least some are
	title="Extended DNS Error Code 7 - Signature Expired">		not yet valid.</t>
	<t>The resolver attempted to perform DNSSEC validation, but		</section>
	no signatures are presently valid and some (often all) are		<section anchor="errnodnskey" numbered="true" toc="default">
	expired.</t>		<name>Extended DNS Error Code 9 - DNSKEY Missing</name>
	</section>		<t>A DS record existed at a parent, but no supported
			matching DNSKEY record could be found for the child.</t>
	<section anchor="errprior"		</section>
	title="Extended DNS Error Code 8 - Signature Not Yet Valid">		<section anchor="errnorrsig" numbered="true" toc="default">
	<t>The resolver attempted to perform DNSSEC validation, but		<name>Extended DNS Error Code 10 - RRSIGs Missing</name>
	but no signatures are presently valid and at least some are		<t>The resolver attempted to perform DNSSEC validation, but no
	not yet valid.</t>		RRSIGs could be found for at least one RRset where RRSIGs were
	</section>		expected.</t>
			</section>
	<section anchor="errnodnskey"		<section anchor="errnozonekey" numbered="true" toc="default">
	title="Extended DNS Error Code 9 - DNSKEY Missing">		<name>Extended DNS Error Code 11 - No Zone Key Bit Set</name>
	<t>A DS record existed at a parent, but no supported		<t>The resolver attempted to perform DNSSEC validation, but no Zone
	matching DNSKEY record could be found for the child.</t>		Key Bit was set in a DNSKEY.</t>
	</section>		</section>
			<section anchor="nonsec" numbered="true" toc="default">
	<section anchor="errnorrsig"		<name>Extended DNS Error Code 12 - NSEC Missing</name>
	title="Extended DNS Error Code 10 - RRSIGs Missing">		<t>The resolver attempted to perform DNSSEC validation, but
	<t>The resolver attempted to perform DNSSEC validation, but no		the requested data was missing and a covering NSEC or NSEC3
	RRSIGs could be found for at least one RRset where RRSIGs were		was not provided.</t>
	expected.</t>		</section>
	</section>		<section anchor="cachederror" numbered="true" toc="default">
			<name>Extended DNS Error Code 13 - Cached Error</name>
	<section anchor="errnozonekey"		<t>The resolver is returning the SERVFAIL RCODE from its cache.</t>
	title="Extended DNS Error Code 11 - No Zone Key Bit Set">		</section>
	<t>The resolver attempted to perform DNSSEC validation, but no Zone		<section anchor="notready" numbered="true" toc="default">
	Key Bit was set in a DNSKEY.</t>		<name>Extended DNS Error Code 14 - Not Ready</name>
	</section>		<t>The server is unable to answer the query, as it was not
			fully functional when the query was received.</t>
	<section anchor="nonsec"		</section>
	title="Extended DNS Error Code 12 - NSEC Missing">		<section anchor="errblocked" numbered="true" toc="default">
	<t>The resolver attempted to perform DNSSEC validation, but		<name>Extended DNS Error Code 15 - Blocked</name>
	the requested data was missing and a covering NSEC or NSEC3		<t>The server is unable to respond to the request because
	was not provided.</t>		the domain is on a blocklist due to an internal security policy
	</section>		imposed by the operator of the server resolving or forwarding
			the query.</t>
	<section anchor="cachederror"		</section>
	title="Extended DNS Error Code 13 - Cached Error">		<section anchor="errcensored" numbered="true" toc="default">
	<t>The resolver is returning the SERVFAIL RCODE from its cache.</t>		<name>Extended DNS Error Code 16 - Censored</name>
	</section>		<t>The server is unable to respond to the request because
			the domain is on a blocklist due to an external requirement
	<section anchor="notready"		imposed by an entity other than the operator of the server
	title="Extended DNS Error Code 14 - Not Ready">		resolving or forwarding the query. Note that how the imposed
	<t>The server is unable to answer the query as it was not		policy is applied is irrelevant (in-band DNS filtering,
	fully functional when the query was received.</t>		court order, etc.).</t>
	</section>		</section>
			<section anchor="errfiltered" numbered="true" toc="default">
	<section anchor="errblocked"		<name>Extended DNS Error Code 17 - Filtered</name>
	title="Extended DNS Error Code 15 - Blocked">		<t>The server is unable to respond to the request because
	<t>The server is unable to respond to the request because		the domain is on a blocklist as requested by the client.
	the domain is blacklisted due to an internal security policy		Functionally, this amounts to "you requested that we filter
	imposed by the operator of the server resolving or forwarding		domains like this one."</t>
	the query.</t>		</section>
	</section>		<section anchor="errprohibted" numbered="true" toc="default">
			<name>Extended DNS Error Code 18 - Prohibited</name>
	<section anchor="errcensored"		<t>An authoritative server or recursive resolver that receives a query fr
	title="Extended DNS Error Code 16 - Censored">		om
	<t>The server is unable to respond to the request because		an "unauthorized" client can annotate its REFUSED message with this
	the domain is blacklisted due to an external requirement		code. Examples of "unauthorized" clients are recursive queries from
	imposed by an entity other than the operator of the server		IP addresses outside the network, blocklisted IP addresses, local
	resolving or forwarding the query. Note that how the imposed		policy, etc.</t>
	policy is applied is irrelevant (in-band DNS filtering,		</section>
	court order, etc).</t>		<section anchor="stalenx" numbered="true" toc="default">
	</section>		<name>Extended DNS Error Code 19 - Stale NXDOMAIN Answer</name>
			<t>The resolver was unable to resolve an answer within its
	<section anchor="errfiltered"		configured time limits and decided to answer with a
	title="Extended DNS Error Code 17 - Filtered">		previously cached NXDOMAIN answer instead of answering with
	<t>The server is unable to respond to the request because		an error. This may be caused, for example, by problems
	the domain is blacklisted as requested by the client.		communicating with an authoritative server, possibly as
	Functionally, this amounts to "you requested that we filter		result of a denial of service (DoS) attack against another
	domains like this one."</t>		network. (See also Code 3.) </t>
	</section>		</section>
			<section anchor="errlame" numbered="true" toc="default">
	<section anchor="errprohibted"		<name>Extended DNS Error Code 20 - Not Authoritative</name>
	title="Extended DNS Error Code 18 - Prohibited">		<t>An authoritative server that receives a query with the Recursion
	<t>An authoritative server or recursive resolver that receives a query		Desired (RD) bit clear,
	from		or when it is not configured for recursion for a domain for which it is
	an "unauthorized" client can annotate its REFUSED message with this		not authoritative, <bcp14>SHOULD</bcp14> include this EDE code in the RE
	code. Examples of "unauthorized" clients are recursive queries from		FUSED
	IP addresses outside the network, blacklisted IP addresses, local		response. A resolver that receives a query with the RD bit clear
	policy, etc.</t>		<bcp14>SHOULD</bcp14> include this EDE code in the REFUSED response.</t>
	</section>		</section>
			<section anchor="deprecated" numbered="true" toc="default">
	<section anchor="stalenx"		<name>Extended DNS Error Code 21 - Not Supported</name>
	title="Extended DNS Error Code 19 - Stale NXDOMAIN Answer">		<t>The requested operation or query is not supported.</t>
	<t>The resolver was unable to resolve an answer within its		</section>
	configured time limits and decided to answer with a		<section anchor="noreachable" numbered="true" toc="default">
	previously cached NXDOMAIN answer instead of answering with		<name>Extended DNS Error Code 22 - No Reachable Authority</name>
	an error. This may be caused, for example, by problems		<t>The resolver could not reach any of the authoritative name servers
	communicating with an authoritative server, possibly as		(or they potentially refused to reply).</t>
	result of a denial of service (DoS) attack against another		</section>
	network. (See also Code 3.) </t>		<section anchor="networkerror" numbered="true" toc="default">
			<name>Extended DNS Error Code 23 - Network Error</name>
	</section>		<t>An unrecoverable error occurred while communicating with
			another server.</t>
	<section anchor="errlame"		</section>
	title="Extended DNS Error Code 20 - Not Authoritative">		<section anchor="invaliddata" numbered="true" toc="default">
	<t>An authoritative server that receives a query with the RD bit clear		<name>Extended DNS Error Code 24 - Invalid Data</name>
	,		<t>The authoritative server cannot answer with data for
	or when it is not configured for recursion for a domain for which it is		a zone it is otherwise configured to support. Examples of
	not authoritative SHOULD include this EDE code in the REFUSED		this include its most recent zone being too old or having
	response. A resolver that receives a query with the RD bit clear		expired.</t>
	SHOULD include this EDE code in the REFUSED response.</t>		</section>
	</section>		</section>
			<section numbered="true" toc="default">
	<section anchor="deprecated"		<name>IANA Considerations</name>
	title="Extended DNS Error Code 21 - Not Supported">		<section numbered="true" toc="default">
	<t>The requested operation or query is not supported.</t>		<name>A New Extended DNS Error Code EDNS Option</name>
	</section>		<t>This document defines a new EDNS(0) option, entitled
			"Extended DNS Error", with the assigned value of 15 from the "DNS
	<section anchor="noreachable"		EDNS0 Option Codes (OPT)" registry:
	title="Extended DNS Error Code 22 - No Reachable Authority">		</t>
	<t>The resolver could not reach any of the authoritative name servers
	(or they potentially refused to reply).</t>
	</section>
	<section anchor="networkerror"
	title="Extended DNS Error Code 23 - Network Error">
	<t>An unrecoverable error occurred while communicating with
	another server.</t>
	</section>
	<section anchor="invaliddata"
	title="Extended DNS Error Code 24 - Invalid Data">
	<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 title="IANA Considerations">
	<section title="A New Extended DNS Error Code EDNS Option">
	<t>This document defines a new EDNS(0) option, entitled
	"Extended DNS Error", assigned a value of TBD from the "DNS
	EDNS0 Option Codes (OPT)" registry [to be removed upon
	publication:
	[http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns
	-parameters-11]</t>
	<t><figure>
	<artwork><![CDATA[Value Name Status Reference
	TBD Extended DNS Error Standard [ This document ]]]></artwork>
	</figure></t>
	</section>
	<section title="New Registry for Extended DNS Error Codes" anchor="IANA">
	<t>IANA is requested to create and maintain a new registry
	table called "Extended DNS Error Codes" on the "Domain Name
	System (DNS) Parameters" web page as follows:</t>
	<t>Registry Name: Extended DNS Error Codes</t>
	<t>Registration Procedures:</t>
	<t><list style="symbols">
	<t>0 - 49151: First come, first served.</t>
	<t>49152 - 65535: Private use.</t>
	</list></t>
	<t>Reference: [this document]</t>
	<t>The Extended DNS Error Codes registry is a table with
	three columns: INFO-CODE, Purpose, and Reference. The initial
	contents is as below with [this document] added to
	each reference given.</t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">0</t>
	<t hangText="Purpose:">Other Error</t>
	<t hangText="Reference:"><xref target="errother" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">1</t>
	<t hangText="Purpose:">Unsupported DNSKEY Algorithm</t>
	<t hangText="Reference:"><xref target="errbaddnskeyalg" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">2</t>
	<t hangText="Purpose:">Unsupported DS Digest Type</t>
	<t hangText="Reference:"><xref target="errbaddsdigest" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">3</t>
	<t hangText="Purpose:">Stale Answer</t>
	<t hangText="Reference:"><xref target="stalenoerror" />,
	<xref target="RFC8767" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">4</t>
	<t hangText="Purpose:">Forged Answer</t>
	<t hangText="Reference:"><xref target="forgedanswer" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">5</t>
	<t hangText="Purpose:">DNSSEC Indeterminate</t>
	<t hangText="Reference:"><xref target="errindeterminate" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">6</t>
	<t hangText="Purpose:">DNSSEC Bogus</t>
	<t hangText="Reference:"><xref target="errbogus" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">7</t>
	<t hangText="Purpose:">Signature Expired</t>
	<t hangText="Reference:"><xref target="errexpired" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">8</t>
	<t hangText="Purpose:">Signature Not Yet Valid</t>
	<t hangText="Reference:"><xref target="errprior" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">9</t>
	<t hangText="Purpose:">DNSKEY Missing</t>
	<t hangText="Reference:"> <xref target="errnodnskey" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">10</t>
	<t hangText="Purpose:">RRSIGs Missing</t>
	<t hangText="Reference:"><xref target="errnorrsig" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">11</t>
	<t hangText="Purpose:">No Zone Key Bit Set</t>
	<t hangText="Reference:"><xref target="errnozonekey" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">
	<t hangText="INFO-CODE:">12</t>
	<t hangText="Purpose:">NSEC Missing</t>
	<t hangText="Reference:"><xref target="nonsec" /></t>
	</list></t>
	<t><list style="hanging" hangIndent="10">		<table anchor="ext-DNS">
	<t hangText="INFO-CODE:">13</t>		<thead>
	<t hangText="Purpose:">Cached Error</t>		<tr>
	<t hangText="Reference:"><xref target="cachederror" /></t>		<th> Value </th>
	</list></t>		<th> Name </th>
			<th> Status </th>
			<th> Reference </th>
			</tr>
			</thead>
	<t><list style="hanging" hangIndent="10">		<tbody>
	<t hangText="INFO-CODE:">14</t>		<tr>
	<t hangText="Purpose:">Not Ready.</t>		<td>15</td>
	<t hangText="Reference:"><xref target="notready" /></t>		<td>Extended DNS Error</td>
	</list></t>		<td>Standard</td>
			<td>RFC 8914</td>
			</tr>
			</tbody>
	<t><list style="hanging" hangIndent="10">		</table>
	<t hangText="INFO-CODE:">15</t>		</section>
	<t hangText="Purpose:">Blocked</t>		<section anchor="IANA" numbered="true" toc="default">
	<t hangText="Reference:"><xref target="errblocked" /></t>		<name>New Registry for Extended DNS Error Codes</name>
	</list></t>		<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>
	<t><list style="hanging" hangIndent="10">		<table anchor="reg_proc">
	<t hangText="INFO-CODE:">16</t>		<thead>
	<t hangText="Purpose:">Censored</t>		<tr>
	<t hangText="Reference:"><xref target="errcensored" /></t>		<th>Range</th>
	</list></t>		<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><list style="hanging" hangIndent="10">		<t>The "Extended DNS Error Codes" registry is a table with
	<t hangText="INFO-CODE:">17</t>		three columns: INFO-CODE, Purpose, and Reference. The initial
	<t hangText="Purpose:">Filtered</t>		content is as below.</t>
	<t hangText="Reference:"><xref target="errfiltered" /></t>		<table>
	</list></t>		<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>
	<t><list style="hanging" hangIndent="10">		<tr>
	<t hangText="INFO-CODE:">18</t>		<td>22 </td>
	<t hangText="Purpose:">Prohibited</t>		<td>No Reachable Authority </td>
	<t hangText="Reference:"><xref target="errprohibted" /></t>		<td> <xref target="noreachable" format="default"/> </td>
	</list></t>		</tr>
	<t><list style="hanging" hangIndent="10">		<tr>
	<t hangText="INFO-CODE:">19</t>		<td>23 </td>
	<t hangText="Purpose:">Stale NXDomain Answer</t>		<td>Network Error </td>
	<t hangText="Reference:"><xref target="stalenx" /></t>		<td> <xref target="networkerror" format="default"/> </td>
	</list></t>		</tr>
	<t><list style="hanging" hangIndent="10">		<tr>
	<t hangText="INFO-CODE:">20</t>		<td>24 </td>
	<t hangText="Purpose:">Not Authoritative</t>		<td>Invalid Data </td>
	<t hangText="Reference:"><xref target="errlame" /></t>		<td> <xref target="invaliddata" format="default"/> </td>
	</list></t>		</tr>
	<t><list style="hanging" hangIndent="10">		<tr>
	<t hangText="INFO-CODE:">21</t>		<td>25-49151</td>
	<t hangText="Purpose:">Not Supported</t>		<td>Unassigned</td>
	<t hangText="Reference:"><xref target="deprecated" /></t>		<td></td>
	</list></t>		</tr>
			<tr>
			<td>49152-65535</td>
			<td>Reserved for Private Use</td>
			<td><xref target="IANA"/></td>
			</tr>
			</tbody>
			</table>
	<t><list style="hanging" hangIndent="10">		</section>
	<t hangText="INFO-CODE:">22</t>		</section>
	<t hangText="Purpose:">No Reachable Authority</t>		<section anchor="security" numbered="true" toc="default">
	<t hangText="Reference:"><xref target="noreachable" /></t>		<name>Security Considerations</name>
	</list></t>		<t>Though DNSSEC continues to be deployed, unfortunately a
			significant number of clients (~11% according to <xref target="GeoffValidat
			ion" 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 answe
			rs
			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.
	<t><list style="hanging" hangIndent="10">		An example
	<t hangText="INFO-CODE:">23</t>		of this is the Prohibited EDE code (18), which may leak the fact
	<t hangText="Purpose:">Network Error</t>		that the name is on a blocklist.</t>
	<t hangText="Reference:"><xref target="networkerror" /></t>		</section>
	</list></t>		</middle>
			<back>
			<references>
			<name>References</name>
			<references>
			<name>Normative References</name>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.2119.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.4035.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.5198.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.6891.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.8174.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.8499.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.8767.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.2845.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.2931.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.8094.xml"/>
			<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
			nce.RFC.8484.xml"/>
	<t><list style="hanging" hangIndent="10">		<reference anchor="GeoffValidation" target="http://www.potaroo.net/presen
	<t hangText="INFO-CODE:">24</t>		tations/2016-06-27-dnssec.pdf">
	<t hangText="Purpose:">Invalid Data</t>		<front>
	<t hangText="Reference:"><xref target="invaliddata" /></t>		<title abbrev="Validation today">A quick review of DNSSEC Validation
	</list></t>		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><list style="hanging" hangIndent="10">		<t>The authors wish to thank <contact fullname=" Joe Abley"/>, <contact
	<t hangText="INFO-CODE:">25-65535</t>		fullname="Mark Andrews"/>, <contact fullname="Tim April"/>, <contact
	<t hangText="Purpose:">Unassigned</t>		fullname="Vittorio Bertola"/>, <contact fullname="Stephane
	<t hangText="Reference:"><xref target="IANA" /></t>		Bortzmeyer"/>, <contact fullname="Vladimir Cunat"/>, <contact
	</list></t>		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 (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>		</section>
	</section>		</back>
	<section anchor="security" title="Security Considerations">
	<t>Though DNSSEC continues to be deployed, unfortunately a
	significant number of clients (~11% according to <xref
	target="GeoffValidation"/>) 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 which
	DNSSEC should provide.</t>
	<t>EDE information is unauthenticated information, unless
	secured by a form of secured DNS transaction such as <xref
	target="RFC2845"/>, <xref target="RFC2931"/>, <xref
	target="RFC8094"/> or <xref target="RFC8484" />. An attacker (e.g a MITM o
	r malicious
	recursive server) could insert an extended error response into
	untrusted data &mdash; although ideally clients and resolvers
	would not trust any unauthenticated information. As such, EDE
	content should be treated only as diagnostic information and
	MUST NOT alter DNS protocol processing. Until all DNS answers
	are authenticated via DNSSEC or the other mechanisms mentioned
	above, there are some tradeoffs. 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 Response Codes (RCODEs) also
	contain no authentication and can be just as easily manipulated.
	</t>
	<t>By design, EDE potentially exposes additional information
	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 blacklist.</t>
	</section>
	<section title="Acknowledgements">
	<t>The authors wish to thank Joe Abley, Mark Andrews, Tim April,
	Vittorio Bertola, Stephane Bortzmeyer, Vladimir Cunat, Ralph
	Dolmans, Peter DeVries, Peter van Dijk, Mats Dufberg, Donald
	Eastlake, Bob Harold, Paul Hoffman, Geoff Huston, Shane Kerr,
	Edward Lewis, Carlos M. Martinez, George Michelson, Eric Orth,
	Michael Sheldon, Puneet Sood, Petr Spacek, Ondrej Sury, John
	Todd, Loganaden Velvindron, and Paul Vixie. They also vaguely
	remember discussing this with a number of people over the years,
	but have forgotten who all they were -- if you were one of them,
	and are not listed, please let us know and we'll acknowledge
	you.</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>
	</middle>
	<back>
	<references title="Normative References">
	<?rfc include='reference.RFC.2119' ?>
	<?rfc include='reference.RFC.4035' ?>
	<?rfc include='reference.RFC.5198' ?>
	<?rfc include='reference.RFC.6891' ?>
	<?rfc include='reference.RFC.8174' ?>
	<?rfc include='reference.RFC.8499' ?>
	<?rfc include='reference.RFC.8767' ?>
	</references>
	<references title="Informative References">
	<?rfc include='reference.RFC.2845' ?>
	<?rfc include='reference.RFC.2931' ?>
	<?rfc include='reference.RFC.8094' ?>
	<?rfc include='reference.RFC.8484' ?>
	<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&rsquo;s Internet</title>
	<author fullname="Geoff Huston, APNIC">
	<organization>IANA</organization>
	</author>
	<date month="June" year="2016"/>
	</front>
	</reference>
	</references>
	</back>
	</rfc>		</rfc>
End of changes. 29 change blocks.
	719 lines changed or deleted		703 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/