rfc9824.original.xml		rfc9824.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version="1.0" encoding="utf-8"?>
	<!DOCTYPE rfc>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude"		<!DOCTYPE rfc [
	category="std" consensus="true"		<!ENTITY nbsp "&#160;">
	docName="draft-ietf-dnsop-compact-denial-of-existence-07"		<!ENTITY zwsp "&#8203;">
	ipr="trust200902" updates="4034, 4035" obsoletes=""		<!ENTITY nbhy "&#8209;">
	submissionType="IETF" xml:lang="en"		<!ENTITY wj "&#8288;">
	tocInclude="true" tocDepth="4"		]>
	symRefs="true" sortRefs="true" version="3">
	<!-- ***** FRONT MATTER ***** -->		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true" docName="draft-ietf-dnsop-compact-denial-of-existence-07" number="9824" ipr="tru st200902" updates="4034, 4035" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
	<front>		<front>
			<title abbrev="Compact Denial of Existence in DNSSEC">Compact Denial of Exis
	<title abbrev="Compact Denial of Existence in DNSSEC">		tence in DNSSEC</title>
	Compact Denial of Existence in DNSSEC		<seriesInfo name="RFC" value="9824"/>
	</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-dnsop-compact-denial-of-
	existence-07"/>
	<author fullname="Shumon Huque" initials="S." surname="Huque">		<author fullname="Shumon Huque" initials="S." surname="Huque">
	<organization>Salesforce</organization>		<organization>Salesforce</organization>
	<address>		<address>
	<postal>		<postal>
	<street>415 Mission Street, 3rd Floor</street>		<street>415 Mission Street, 3rd Floor</street>
	<city>San Francisco</city>		<city>San Francisco</city>
	<region>CA</region>		<region>CA</region>
	<code>94105</code>		<code>94105</code>
	<country>United States of America</country>		<country>United States of America</country>
	skipping to change at line 77 ¶		skipping to change at line 45 ¶
	<city>San Francisco</city>		<city>San Francisco</city>
	<region>CA</region>		<region>CA</region>
	<code>94107</code>		<code>94107</code>
	<country>United States of America</country>		<country>United States of America</country>
	</postal>		</postal>
	<email>elmerot@cloudflare.com</email>		<email>elmerot@cloudflare.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">		<author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
	<organization>Retired / Unaffiliated</organization>		<organization></organization>
	<address>		<address>
	<email>ogud@ogud.com</email>		<email>ogud@ogud.com</email>
	</address>		</address>
	</author>		</author>
	<date day="27" month="02" year="2025"/>		<date month="September" year="2025"/>
	<!-- Meta-data Declarations -->
			<area>OPS</area>
			<workgroup>dnsop</workgroup>
	<area>General</area>
	<workgroup>Internet Engineering Task Force</workgroup>
	<keyword>Internet-Draft</keyword>
	<keyword>DNS</keyword>		<keyword>DNS</keyword>
	<keyword>DNSSEC</keyword>		<keyword>DNSSEC</keyword>
	<keyword>Denial of Existence</keyword>		<keyword>Denial of Existence</keyword>
	<keyword>Compact Denial of Existence</keyword>		<keyword>Compact Denial of Existence</keyword>
	<keyword>Compact Answers</keyword>		<keyword>Compact Answers</keyword>
	<keyword>Black Lies</keyword>		<keyword>Black Lies</keyword>
	<keyword>NXDOMAIN</keyword>		<keyword>NXDOMAIN</keyword>
	<keyword>NODATA</keyword>		<keyword>NODATA</keyword>
	<keyword>Empty Non-Terminal</keyword>		<keyword>Empty Non-Terminal</keyword>
	skipping to change at line 100 ¶		skipping to change at line 67 ¶
	<keyword>DNSSEC</keyword>		<keyword>DNSSEC</keyword>
	<keyword>Denial of Existence</keyword>		<keyword>Denial of Existence</keyword>
	<keyword>Compact Denial of Existence</keyword>		<keyword>Compact Denial of Existence</keyword>
	<keyword>Compact Answers</keyword>		<keyword>Compact Answers</keyword>
	<keyword>Black Lies</keyword>		<keyword>Black Lies</keyword>
	<keyword>NXDOMAIN</keyword>		<keyword>NXDOMAIN</keyword>
	<keyword>NODATA</keyword>		<keyword>NODATA</keyword>
	<keyword>Empty Non-Terminal</keyword>		<keyword>Empty Non-Terminal</keyword>
	<abstract>		<abstract>
	<t>		<t>
	This document describes a technique to generate a signed DNS response		This document describes a technique to generate a signed DNS response
	on demand for a non-existent name by claiming that the name exists		on demand for a nonexistent name by claiming that the name exists
	but doesn't have any data for the queried record type. Such answers		but doesn't have any data for the queried record type. Such responses
	require only one minimally covering NSEC or NSEC3 record, allow online		require only one minimally covering NSEC or NSEC3 record, allow online
	signing servers to minimize signing operations and response sizes,		signing servers to minimize signing operations and response sizes,
	and prevent zone content disclosure.		and prevent zone content disclosure.
	</t>		</t>
	<t>		<t>
	This document updates RFC 4034 and 4035.		This document updates RFCs 4034 and 4035.
	</t>		</t>
	</abstract>		</abstract>
	<note removeInRFC="true">
	<name>Discussion Venues</name>
	<t>Source for this draft and an issue tracker can be found at
	<eref target="https://github.com/shuque/id-dnssec-compact-lies"/>.</t>
	</note>
	</front>		</front>
	<middle>		<middle>
	<section anchor="intro" numbered="true" toc="default">		<section anchor="intro">
	<name>Introduction and Motivation</name>		<name>Introduction and Motivation</name>
	<t>		<t>
	One of the functions of the Domain Name System Security Extensions		One of the functions of DNS Security Extensions
	(DNSSEC) <xref target="RFC9364" /> is		(DNSSEC) <xref target="RFC9364" /> is
	"Authenticated Denial of Existence",		"authenticated denial of existence",
	i.e., proving that a DNS name or record type does not exist.		i.e., proving that a DNS name or record type does not exist.
	Normally, this is done by means of signed NSEC or NSEC3 records.		Normally, this is done by means of signed NSEC or NSEC3 records.
	In the precomputed signature model, these records chain together		In the precomputed signature model, these records chain together
	existing names, or cryptographic hashes of them in the zone. In		existing names, or cryptographic hashes of them, in the zone. In
	the online signing model, described in NSEC and NSEC3 "White Lies"		the online signing model, described for NSEC in <xref target="RFC4470" /
	<xref target="RFC4470" /> <xref target="RFC7129" />,		> and for NSEC3 in
			<xref target="RFC7129" sectionFormat="of" section="B"/>,
	they are used to dynamically compute an epsilon		they are used to dynamically compute an epsilon
	function around the queried name. A "Type Bit Maps" field in the data		function around the QNAME. The Type Bit Maps field in the data
	of the NSEC or NSEC3 record asserts which resource record types are		of the NSEC or NSEC3 record asserts which resource record (RR) types are
	present at the name.		present at the name.
	</t>		</t>
	<t>		<t>
	The response for a non-existent name requires up to 2 signed NSEC		The response for a nonexistent name requires up to two signed NSEC
	records or up to 3 signed NSEC3 records (and for online signers,		records or up to three signed NSEC3 records (and for online signers,
	the associated cryptographic computation), to prove that (1) the		the associated cryptographic computation) to prove that (1) the
	name did not explicitly exist in the zone, and (2) that it could		name did not explicitly exist in the zone and (2) it could
	not have been synthesized by a wildcard.		not have been synthesized by a wildcard.
	</t>		</t>
	<t>		<t>
	This document describes an alternative technique, "Compact Denial		This document describes an alternative technique, "Compact Denial
	of Existence" or "Compact Answers",		of Existence" or "Compact Answers",
	to generate a signed DNS response on demand for a non-existent		to generate a signed DNS response on demand for a nonexistent
	name by claiming that the name exists but has no resource records		name by claiming that the name exists but has no resource record sets
	associated with the queried type, i.e., it returns a NODATA response		associated with the queried type, i.e., it returns a NODATA response
	rather than an NXDOMAIN response. A NODATA response, which has a		rather than an NXDOMAIN response. A NODATA response, which has a
	response code (RCODE) of NOERROR and an empty ANSWER section,		response code (RCODE) of NOERROR and an empty ANSWER section,
	requires only one NSEC or NSEC3 record matching the queried name.		requires only one NSEC or NSEC3 record matching the QNAME.
	This has two advantages: the DNS response size is smaller, and it		This has two advantages: The DNS response size is smaller, and it
	reduces the online cryptographic work involved in generating the		reduces the online cryptographic work involved in generating the
	response.		response.
	</t>		</t>
	<t>		<t>
	The use of minimally covering NSEC or NSEC3 records also prevents		The use of minimally covering NSEC or NSEC3 records also prevents
	adversaries from enumerating the entire contents of DNS zones		adversaries from enumerating the entire contents of DNS zones
	by walking the NSEC chain, or by performing an offline dictionary		by walking the NSEC chain or performing an offline dictionary
	attack on the hashes in the NSEC3 chain.		attack on the hashes in the NSEC3 chain.
	</t>		</t>
	<t>		<t>
	This document assumes a reasonable level of familiarity with DNS		This document assumes a reasonable level of familiarity with DNS
	operations and protocol terms. Much of the terminology is explained		operations and protocol terms. Much of the terminology is explained
	in further detail in "DNS Terminology" <xref target="RFC9499" />.		in further detail in "DNS Terminology" <xref target="RFC9499" />.
	</t>		</t>
	<section anchor="reserved-words"><name>Requirements Language</name>		<section anchor="reserved-words"><name>Requirements Language</name>
	<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&qu		<t>
	ot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;NO		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	T RECOMMENDED&quot;, &quot;MAY&quot;,		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	and &quot;OPTIONAL&quot; in this document are to be interpreted as described		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	in BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when,		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	and only when, they		be interpreted as
	appear in all capitals, as shown here.</t>		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>		</section>
	<section anchor="distinguish" numbered="true" toc="default">		<section anchor="distinguish">
	<name>Distinguishing non-existent names</name>		<name>Distinguishing Nonexistent Names</name>
	<t>		<t>
	This method generates NODATA responses for non-existent names		This method generates NODATA responses for nonexistent names
	that don't match a DNS wildcard. Since there are clearly no		that don't match a DNS wildcard. Since there are clearly no
	record types for such names, the NSEC Type Bit Maps field in		record types for such names, the NSEC Type Bit Maps field in
	the response will only contain the "NSEC" and "RRSIG" types		the response will only contain the NSEC and RRSIG types
	(and in the case of NSEC3 the Type Bit Maps field will be empty).		(and in the case of NSEC3, the Type Bit Maps field will be empty).
	Tools that need to accurately identify non-existent names in		Tools that need to accurately identify nonexistent names in
	responses cannot rely on this specific type bitmap because Empty		responses cannot rely on this specific type bitmap because Empty
	Non-Terminal (ENT) names (which positively exist) also have no		Non-Terminal (ENT) names (which positively exist) also have no
	record types at the name and will return exactly the same Type		record types at the name and will return exactly the same Type
	Bit Maps field.		Bit Maps field.
	</t>		</t>
	<t>		<t>
	This specification defines the use of a synthetic Resource Record		This specification defines the use of NXNAME (128), a synthetic RR
	type to signal the presence of a non-existent name. The		type to signal the presence of a nonexistent name. See <xref target="ian
	mnemonic for this RR type is "NXNAME", chosen to clearly		a"/>. The
			mnemonic for this RR type is NXNAME, chosen to clearly
	distinguish it from the response code mnemonic NXDOMAIN.		distinguish it from the response code mnemonic NXDOMAIN.
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	Type Value Meaning
	NXNAME 128 NXDOMAIN indicator for Compact Denial of Existence
	]]></artwork>
	<t>		<t>
	This RR type is added to the NSEC Type Bit Maps field for responses		This RR type is added to the NSEC Type Bit Maps field for responses
	to non-existent names, in addition to the required RRSIG and		to nonexistent names, in addition to the mandated RRSIG and
	NSEC types. If NSEC3 is being used, this RR type is the sole		NSEC types. If NSEC3 is being used, this RR type is the sole
	entry in the Type Bit Maps field. It is a "Meta-Type", as defined in		entry in the Type Bit Maps field. It is a "Meta-TYPE", as defined in
	<xref target="RFC6895" />, stores no data in a DNS zone, and		<xref target="RFC6895" />, and it stores no data in a DNS zone and
	cannot be usefully queried. <xref target="response-nxname"/>		cannot be usefully queried. <xref target="response-nxname"/>
	describes what a DNS resolver or authoritative server should		describes what a DNS resolver or authoritative server should
	do if it receives an explicit query for NXNAME.		do if it receives an explicit query for NXNAME.
	</t>		</t>
	<t>		<t>
	No special handling of this RR type is required on the part of		No special handling of this RR type is required on the part of
	DNS resolvers. However, resolvers may optionally implement the		DNS resolvers. However, resolvers may optionally implement the
	behavior described in <xref target="signaled-rcode"/>		behavior described in <xref target="signaled-rcode"/> ("Signaled Respons
	(Response Code Restoration) to better restore NXDOMAIN visibility		e Code Restoration")
			to better restore NXDOMAIN visibility
	to various applications that may remain oblivious to the new		to various applications that may remain oblivious to the new
	NXNAME signal.		NXNAME signal.
	</t>		</t>
	</section>		</section>
	<section anchor="responses" numbered="true" toc="default">		<section anchor="responses">
	<name>Generating Responses with NSEC</name>		<name>Generating Responses with NSEC</name>
	<t>		<t>
	This section describes various types of answers generated by		This section describes various types of answers generated by
	authoritative servers implementing Compact Denial of Existence		authoritative servers implementing Compact Denial of Existence
	using NSEC. <xref target="nsec3" /> describes changes needed to		using NSEC. <xref target="nsec3" /> describes changes needed to
	support NSEC3.		support NSEC3.
	</t>		</t>
	<section anchor="response-nxd" numbered="true" toc="default">		<section anchor="response-nxd">
	<name>Responses for Non-Existent Names</name>		<name>Responses for Nonexistent Names</name>
	<t>		<t>
	When the authoritative server receives a query for a non-existent		When the authoritative server receives a query for a nonexistent
	name in a zone that it serves, a NODATA response (response code		name in a zone that it serves, a NODATA response (response code
	NOERROR, empty Answer section) is generated with a dynamically		NOERROR, empty Answer section) is generated with a dynamically
	constructed NSEC record with the owner name matching the queried		constructed NSEC record with the owner name matching the
	name (QNAME) placed in the Authority section.		QNAME placed in the Authority section.
	</t>		</t>
	<t>		<t>
	The Next Domain Name field SHOULD be set to the immediate		The Next Domain Name field <bcp14>SHOULD</bcp14> be set to the immediate
	lexicographic successor of the QNAME. This is accomplished by		lexicographic successor of the QNAME. This is accomplished by
	adding a leading label with a single null (zero-value) octet.		adding a leading label with a single null (zero-value) octet.
	The Type Bit Maps field MUST only have the bits set for the		The Type Bit Maps field <bcp14>MUST</bcp14> only have the bits set for t he
	following RR Types: RRSIG, NSEC, and NXNAME.		following RR Types: RRSIG, NSEC, and NXNAME.
	</t>		</t>
	<t>		<t>
	For example, a request for the non-existing name "a.example.com."		For example, a request for the nonexistent name "a.example.com."
	would result in the following NSEC record to be generated (in DNS		would result in the generation of the following NSEC record (in DNS
	presentation format):		presentation format):
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type=""><![CDATA[
	a.example.com. 3600 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME		a.example.com. 300 IN NSEC \000.a.example.com. RRSIG NSEC NXNAME
	]]></artwork>		]]></sourcecode>
	<t>		<t>
	The NSEC record MUST have corresponding RRSIGs generated.		The NSEC record <bcp14>MUST</bcp14> have corresponding RRSIGs generated.
	</t>		</t>
	</section>		</section>
	<section anchor="response-nodata" numbered="true" toc="default">		<section anchor="response-nodata">
	<name>Responses for Non-Existent Types</name>		<name>Responses for Nonexistent Types</name>
	<t>		<t>
	When the authoritative server receives a query for a name		When the authoritative server receives a query for a name
	that exists, but has no resource record sets associated with		that exists but has no resource record sets associated with
	the queried type, it generates a NODATA response, with		the queried type, it generates a NODATA response with
	a dynamically constructed signed NSEC record in the Authority		a dynamically constructed signed NSEC record in the Authority
	Section. The owner name of the NSEC record matches the queried		section. The owner name of the NSEC record matches the QNAME.
	name. The Next Domain Name field is set to the immediate lexicographic		The Next Domain Name field is set to the immediate lexicographic
	successor of the QNAME. The Type Bit Maps field lists the available		successor of the QNAME. The Type Bit Maps field lists the available
	Resource Record types at the name.		RR types at the name.
	</t>		</t>
	<t>		<t>
	An Empty Non-Terminal is a special subset of this category,		An ENT is a special subset of this category,
	where the name has no resource record sets of any type (but		where the name has no resource record sets of any type (but
	has descendant names that do). For a query for an Empty		has descendant names that do). For a query for an ENT,
	Non-Terminal, the NSEC Type Bit Maps field will only contain RRSIG		the NSEC Type Bit Maps field will only contain RRSIG
	and NSEC. (Note that this is substantially different than the		and NSEC. (Note that this is substantially different than the
	ENT response in precomputed NSEC, where the NSEC record has the		ENT response in precomputed NSEC, where the NSEC record has the
	same type bitmap, but "covers" rather than matches the ENT, and		same type bitmap but "covers" rather than matches the ENT and
	has the Next Domain Name field set to the next lexicographic		has the Next Domain Name field set to the next lexicographic
	descendent of the ENT in the zone.)		descendant of the ENT in the zone.)
	</t>		</t>
	</section>		</section>
	<section anchor="response-wildcard" numbered="true" toc="default">		<section anchor="response-wildcard">
	<name>Responses for Wildcard Matches</name>		<name>Responses for Wildcard Matches</name>
	<t>		<t>
	For wildcard matches, the authoritative server will provide		For wildcard matches, the authoritative server will provide
	a dynamically signed response that claims that the queried		a dynamically signed response that claims that the QNAME
	name exists explicitly. Specifically, the answer RR set will		exists explicitly. Specifically, the answer RRset will
	have an RRSIG record demonstrating an exact match (i.e., the		have an RRSIG record demonstrating an exact match (i.e., the
	label count in the RRSIG RDATA will be equal to the number of		label count in the RRSIG RDATA will be equal to the number of
	labels in the query name minus the root label). This obviates		labels in the query name minus the root label). This obviates
	the need to include an NSEC record in the Authority section		the need to include an NSEC record in the Authority section
	of the response that shows that no closer match than the wildcard		of the response that shows that no closer match than the wildcard
	was possible.		was possible.
	</t>		</t>
	<t>		<t>
	For a Wildcard NODATA match (where the queried name matches		For a wildcard NODATA match (where the QNAME matches
	a wildcard but no data for the queried type exists), a response		a wildcard but no data for the queried type exists), a response
	akin to a non-wildcard NODATA is returned. The Answer section		akin to a non-wildcard NODATA is returned. The Answer section
	is empty, and the Authority section contains a single NSEC		is empty, and the Authority section contains a single NSEC
	record that matches the query name with a Type Bit Maps field		record that matches the query name with a Type Bit Maps field
	representing the list of types available at the wildcard.		representing the list of types available at the wildcard.
	</t>		</t>
	</section>		</section>
	<section anchor="response-referral" numbered="true" toc="default">		<section anchor="response-referral">
	<name>Responses for Unsigned Referrals</name>		<name>Responses for Unsigned Referrals</name>
	<t>		<t>
	Per the DNSSEC protocol, a referral to an unsigned subzone		Per the DNSSEC protocol, a referral to an unsigned subzone
	includes an NSEC record whose Owner Name matches the subzone,		includes an NSEC record whose owner name matches the subzone
	and which proves the delegation is unsigned by the absence of		and proves the delegation is unsigned by the absence of
	the DS RRtype bit in the Type Bit Maps field.		the Delegation Signer (DS) RR type bit in the Type Bit Maps field.
	</t>		</t>
	<t>		<t>
	With Compact Denial of Existence, the Next Domain Name field		With Compact Denial of Existence, the Next Domain Name field
	for this NSEC record is computed with a slightly different		for this NSEC record is computed with a slightly different
	epsilon function than the immediate lexicographic successor of		epsilon function than the immediate lexicographic successor of
	the Owner Name, as that name would then fall under the delegated		the owner name, as that name would then fall under the delegated
	subzone. Instead, the Next Domain Name field is formed by appending		subzone. Instead, the Next Domain Name field is formed by appending
	a zero octet to the first label of the Owner Name.		a zero octet to the first label of the owner name.
	</t>		</t>
	<t>		<t>
	For example, a referral response for the subzone sub.example.com		For example, a referral response for the subzone sub.example.com
	would include an NSEC record like the following:		would include an NSEC record like the following:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type=""><![CDATA[
	sub.example.com. 3600 IN NSEC sub\000.example.com. NS RRSIG NSEC		sub.example.com. 300 IN NSEC sub\000.example.com. NS RRSIG NSEC
	]]></artwork>		]]></sourcecode>
	</section>		</section>
	<section anchor="response-nxname" numbered="true" toc="default">		<section anchor="response-nxname">
	<name>Responses to explicit queries for NXNAME</name>		<name>Responses to Explicit Queries for NXNAME</name>
	<t>		<t>
	NXNAME is a meta type which should not appear anywhere in		NXNAME is a Meta-TYPE that <bcp14>SHOULD NOT</bcp14> appear anywhere in
	a DNS message apart from the NSEC type bitmap of a Compact		a DNS message apart from the NSEC type bitmap of a Compact
	Answer response for a non-existent name. If however a DNS		Answer response for a nonexistent name. However, if a DNS
	server implementing this specification receives an explicit		server implementing this specification receives an explicit
	query for the NXNAME RR type, this section describes what the		query for the NXNAME RR type, this section describes what the
	response should be.		response ought to be.
	</t>		</t>
	<t>		<t>
	If an explicit query for the NXNAME RR type is received, the		If an explicit query for the NXNAME RR type is received, the
	DNS server MUST return a Format Error (response code FORMERR).		DNS server <bcp14>MUST</bcp14> return a Format Error (response code FORM
	A resolver should not forward these queries upstream or attempt		ERR).
			A resolver <bcp14>MUST NOT</bcp14> forward these queries upstream or att
			empt
	iterative resolution. Many DNS server implementations already		iterative resolution. Many DNS server implementations already
	return errors for all types in the meta and q-type range except		return errors for all types in the range for Meta-TYPEs and QTYPEs, exce pt
	those types that are already defined to support queries.		those types that are already defined to support queries.
	</t>		</t>
	<t>		<t>
	Optionally, a DNS server MAY also include the following		Optionally, a DNS server <bcp14>MAY</bcp14> also include the following
	<xref target="RFC8914" /> Extended DNS Error (EDE) Code in the		Extended DNS Error (EDE) code <xref target="RFC8914" /> in the
	response:		response: 30 (Invalid Query Type). See <xref target="iana" />.
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[
	INFO-CODE Purpose
	30 Invalid Query Type
	]]></artwork>
	<t>		<t>
	Note that this EDE code is generally applicable to any		Note that this EDE code is generally applicable to any
	RR type that should not appear in DNS queries.		RR type that ought not appear in DNS queries.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="nsec3" numbered="true" toc="default">		<section anchor="nsec3">
	<name>Generating Responses with NSEC3</name>		<name>Generating Responses with NSEC3</name>
	<t>		<t>
	The NSEC3 protocol <xref target="RFC5155" /> uses hashed names to		NSEC3 <xref target="RFC5155" /> uses hashed names to
	provide zone enumeration defense. This protection is already better		provide zone enumeration defense. This protection is better
	provided by minimally covering NSEC records. NSEC3's Opt-Out feature		provided by minimally covering NSEC records. NSEC3's Opt-Out feature
	also provides no specific benefit for online signing implementations		also provides no specific benefit for online signing implementations
	(minimally covering NSEC3 records provide no useful Opt-Out span).		(minimally covering NSEC3 records provide no useful Opt-Out span).
	Hence, there is no known advantage to implementing Compact Denial		Hence, there is no known advantage to implementing Compact Denial
	of Existence with NSEC3. However, an existing implementation of		of Existence with NSEC3. However, an existing implementation of
	traditional NSEC3 online signing migrating to Compact Denial of		conventional NSEC3 online signing migrating to Compact Denial of
	Existence may find it simpler to do so with NSEC3 than implementing		Existence may find it simpler to do so with NSEC3 rather than implementi
			ng
	NSEC from scratch.		NSEC from scratch.
	</t>		</t>
	<t>		<t>
	For NSEC3, the functional details of the protocol remain as		For NSEC3, the functional details of the protocol remain as
	described in <xref target="responses"/>, with the following		described in <xref target="responses"/>, with the following
	changes:		changes.
	</t>		</t>
	<t>		<t>
	NSEC3 records and their signatures are dynamically generated		NSEC3 records and their signatures are dynamically generated
	instead of NSEC.		instead of NSEC.
	</t>		</t>
	<t>		<t>
	The NSEC3 parameters should be set to algorithm 1, a flags field		The NSEC3 parameters <bcp14>SHOULD</bcp14> be set to algorithm 1, a flag s field
	of 0, an additional hash iteration count of 0, and an empty salt.		of 0, an additional hash iteration count of 0, and an empty salt.
	In DNS presentation format, this is "1 0 0 -".		In DNS presentation format, this is "1 0 0 -".
	</t>		</t>
	<t>		<t>
	The Owner Name of the NSEC3 resource record is the NSEC3 hash of		The owner name of the NSEC3 resource record is the NSEC3 hash of
	the relevant domain name, encoded in Base32 with Extended Hex		the relevant domain name, encoded in Base32 with Extended Hex
	Alphabet (<xref target="RFC4648"/>, Section 7), prepended as a		Alphabet (<xref target="RFC4648" sectionFormat="comma" section="7"/>), p repended as a
	single label to the name of the zone. The Next Hashed Owner Name		single label to the name of the zone. The Next Hashed Owner Name
	is the immediate name successor of the unencoded binary form of		is the immediate name successor of the unencoded binary form of
	the previous hash, which can be computed by adding one to the		the previous hash, which can be computed by adding one to the
	binary hash value.		binary hash value.
	</t>		</t>
	<t>		<t>
	In responses for non-existent names, the Type Bit Maps field will		In responses for nonexistent names, the Type Bit Maps field will
	contain only the NXNAME meta-type. In responses to Empty Non-Terminal		contain only the NXNAME Meta-TYPE. In responses to ENT
	names, the Type Bit Maps field will be empty.		names, the Type Bit Maps field will be empty.
	</t>		</t>
	<t>		<t>
	For example, a request for the non-existent name "a.example.com."		For example, a request for the nonexistent name "a.example.com."
	would result in the following NSEC3 record to be generated:		would result in the generation of the following NSEC3 record:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<sourcecode type=""><![CDATA[
	H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - (		H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - (
	H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME )		H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME )
	]]></artwork>		]]></sourcecode>
	<t>		<t>
	Unlike Compact Denial of Existence with NSEC, no special form of		Unlike Compact Denial of Existence with NSEC, no special form of
	the next name field for unsigned referrals is needed. The Hashed		the Next Hashed Owner Name field for unsigned referrals is needed. The
	Next Owner Name field remains the NSEC3 hash of original owner		Next Hashed Owner Name field remains the NSEC3 hash of original owner
	name plus one.		name plus one.
	</t>		</t>
	</section>		</section>
	<section anchor="rcode" numbered="true" toc="default">		<section anchor="rcode">
	<name>Response Code Restoration</name>		<name>Response Code Restoration</name>
	<t>		<t>
	For non-existent names, implementations should try wherever		For nonexistent names, implementations should try
	possible, to preserve the response code value of 3 (NXDOMAIN).		to preserve the response code value of 3 (NXDOMAIN) whenever possible.
	This is generally possible for non-DNSSEC enabled queries,		This is
	namely those which do not set the DNSSEC_OK EDNS flag (DO bit).		generally possible for non-DNSSEC-enabled queries, namely those that
	For such queries, authoritative servers implementing Compact Denial		do not set the DO bit ("DNSSEC answer OK") in the EDNS0 OPT header. For
	of Existence could return a normal NXDOMAIN response. There may		such queries,
	be limited benefit to doing this however, since most modern DNS		authoritative servers implementing Compact Denial of Existence could
	resolvers are DNSSEC-aware, and by <xref target="RFC3225" />		return a normal NXDOMAIN response. However, there may be limited benefit
	Section 3, DNSSEC-aware recursive servers are required to set		to
	the DO bit on outbound queries, regardless of the status of the		doing this since most modern DNS resolvers are DNSSEC aware,
	DO bit on incoming requests.		and per <xref target="RFC3225" sectionFormat="of" section="3"/>,
			DNSSEC-aware recursive servers are required to set the DO bit on
			outbound queries, regardless of the status of the DO bit on incoming
			requests.
	</t>		</t>
	<t>		<t>
	A validating resolver that understands the NXNAME signal from an		A validating resolver that understands the NXNAME signal from an
	authoritative server could modify the response code from NOERROR		authoritative server could modify the response code from NOERROR
	to NXDOMAIN in responses they return to downstream queriers that		to NXDOMAIN in responses they return to downstream queriers that
	have not set the DO bit in their requests.		have not set the DO bit in their requests.
	</t>		</t>
	<section anchor="signaled-rcode" numbered="true" toc="default">		<section anchor="signaled-rcode">
	<name>Signaled Response Code Restoration</name>		<name>Signaled Response Code Restoration</name>
	<t>		<t>
	This section describes an optional but recommended scheme		This section describes an optional but recommended scheme
	to permit signaled restoration of the NXDOMAIN RCODE for		to permit signaled restoration of the NXDOMAIN RCODE for
	DNSSEC enabled responses. A new		DNSSEC-enabled responses. A new EDNS0
	<xref target="RFC6891">EDNS0</xref> header flag is defined		<xref target="RFC6891"></xref> header flag is defined
	in the 2nd most significant bit of the flags field in the EDNS0		in the second most significant bit of the flags field in the EDNS0
	OPT header. This flag is referred to as the		OPT header. This flag is referred to as the
	"Compact Answers OK (CO)" flag.		Compact Answers OK (CO) flag.
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	+0 (MSB) +1 (LSB)		+0 (MSB) +1 (LSB)
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	0: | EXTENDED-RCODE | VERSION |		0: | EXTENDED-RCODE | VERSION |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	2: |DO|CO| Z |		2: |DO|CO| Z |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	]]></artwork>		]]></artwork>
	<t>
			<t>
	When this flag is sent in a query by a resolver, it indicates		When this flag is sent in a query by a resolver, it indicates
	that the resolver will accept a signed NXNAME enhanced		that the resolver will accept a NODATA response with a signed NXNAME
	NODATA response for a non-existent name together with the		for a nonexistent name, together with the
	response code field set to NXDOMAIN (3).		response code field set to NXDOMAIN (3).
	</t>		</t>
	<t>		<t>
	In responses to such queries, a Compact Denial authoritative		In responses to such queries, an authoritative server implementing
	server implementing this signaling scheme, will set the Compact		both Compact Denial of Existence and this signaling scheme will set
	Answers OK EDNS header flag, and for non-existent names will		the Compact Answers OK EDNS header flag and, for nonexistent names,
	additionally set the response code field to NXDOMAIN.		will additionally set the response code field to NXDOMAIN.
	</t>		</t>
	<t>		<t>
	EDNS is a hop by hop signal, so resolvers will need to		EDNS is a hop-by-hop signal, so resolvers will need to
	record the presence of this flag in associated cache data		record the presence of this flag in associated cache data
	and respond to downstream DNSSEC enabled queriers		and respond to downstream DNSSEC-enabled queriers
	appropriately. If the querier does not set the Compact		appropriately. If the querier does not set the Compact
	Answers OK flag, the resolver will need to reset the		Answers OK flag, the resolver will need to reset the
	response code back to NOERROR (0) for an NXNAME response.		response code back to NOERROR (0) for an NXNAME response.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="operational" numbered="true" toc="default">		<section anchor="operational">
	<name>Operational Implications</name>		<name>Operational Implications</name>
	<t>		<t>
	For DNSSEC enabled queries, a signed zone at an authoritative		For DNSSEC-enabled queries, a signed zone at an authoritative
	server implementing Compact Answers will never return a response		server implementing Compact Answers will never return a response
	with a response code of NXDOMAIN, unless they have implemented		with a response code of NXDOMAIN, unless they have implemented
	the optional response code restoration feature described in		the optional response code restoration feature described in
	<xref target="signaled-rcode"/>. Similarly, resolvers not		<xref target="signaled-rcode"/>. Similarly, resolvers not
	implementing this feature will also not be able to return NXDOMAIN.		implementing this feature will also not be able to return NXDOMAIN.
	In the absence of this, tools that rely on accurately determining		In the absence of this, tools that rely on accurately determining
	non-existent names will need to infer them from the presence of		nonexistent names will need to infer them from the presence of
	the NXNAME RR type in the Type Bit Maps field of the NSEC record		the NXNAME RR type in the Type Bit Maps field of the NSEC record
	in NODATA responses from these servers.		in NODATA responses from these servers.
	</t>		</t>
	<t>		<t>
	Address lookup functions typically invoked by applications		Address lookup functions typically invoked by applications
	may need to do more work when dealing with implementations of		may need to do more work when dealing with implementations of
	Compact Answers. For example, a NODATA response to the lookup		Compact Answers. For example, a NODATA response to the lookup
	of an AAAA record for a non-existent name, can cause such		of a AAAA record for a nonexistent name can cause such
	functions to issue another query at the same name for an A record.		functions to issue another query at the same name for an A record,
	Whereas an NXDOMAIN response to the first query could suppress		whereas an NXDOMAIN response to the first query could suppress
	additional queries for other types at that name. Address lookup		additional queries for other types at that name. Address lookup
	functions could be enhanced to issue DNSSEC enabled queries and		functions could be enhanced to issue DNSSEC-enabled queries and
	to examine the NSEC Type Bit Maps field in responses to accurately		to examine the NSEC Type Bit Maps field in responses to accurately
	determine non-existent names. Note that this is less of a concern		determine nonexistent names. Note that this is less of a concern
	with Happy Eyeballs <xref target="RFC8305" /> style of connection		with
	functions that typically issue back to back DNS queries without		connection functions like Happy Eyeballs <xref target="RFC8305" /> that
			typically issue back-to-back DNS queries without
	waiting for individual responses.		waiting for individual responses.
	</t>		</t>
	<t>		<t>
	Protocol optimizations that enable DNS resolvers to synthesize		Protocol optimizations that enable DNS resolvers to synthesize
	NXDOMAIN or wildcard responses, like <xref target="RFC8020" /> and		NXDOMAIN or wildcard responses, like those described in <xref target="RF C8020" /> and
	<xref target="RFC8198" />, cannot be realized from responses		<xref target="RFC8198" />, cannot be realized from responses
	that use Compact Denial of Existence. In general, no online signing		that use Compact Denial of Existence. In general, no online signing
	scheme that employs minimally covering NSEC or NSEC3 records		scheme that employs minimally covering NSEC or NSEC3 records
	(including this one) permits RFC 8198 style NXDOMAIN or wildcard		(including this one) permits NXDOMAIN or wildcard
	response synthesis. Additionally, this protocol also precludes		response synthesis in the style described in <xref target="RFC8198" />.
	RFC 8020 style NXDOMAIN synthesis for DNSSEC enabled responses.		Additionally, this protocol also precludes
			NXDOMAIN synthesis for DNSSEC-enabled responses in the style described i
			n <xref target="RFC8020" />.
	</t>		</t>
	</section>		</section>
	<section anchor="updates" numbered="true" toc="default">		<section anchor="updates">
	<name>Updates to RFCs</name>		<name>Updates to RFCs</name>
	<section anchor="updates4034" title="Updates to RFC 4034">		<section anchor="updates4034" title="Updates to RFC 4034">
	<t>		<t><xref target="RFC4034" sectionFormat="of" section="4.1.2"/>
	<xref target="RFC4034" /> Section 4.1.2, The Type Bit Maps Field,		("The Type Bit Maps Field") states the following:</t>
	states the following:
	</t>		<blockquote>
	<ul>		<t>Bits representing pseudo-types <bcp14>MUST</bcp14> be clear, as the
	<li>		y do not appear
	Bits representing pseudo-types MUST be clear, as they do not appear		in zone data. If encountered, they <bcp14>MUST</bcp14> be ignored upo
	in zone data. If encountered, they MUST be ignored upon being read.		n being read.</t>
	</li>		</blockquote>
	</ul>
	<t>		<t>This paragraph is updated to the following:</t>
	This paragraph is updated to the following:
	</t>		<blockquote>
	<ul>		<t>Bits representing pseudo-types <bcp14>MUST</bcp14> be clear, as
	<li>		they do not appear in zone data. If encountered, they
	Bits representing pseudo-types MUST be clear, as they do not appear		<bcp14>MUST</bcp14> be ignored upon being read. There is one
	in zone data. If encountered, they MUST be ignored upon being read.		exception to this rule for Compact Denial of Existence (RFC 9824),
	There is one exception to this rule for Compact Denial of Existence		where the NXNAME pseudo-type is allowed to appear in responses to
	(RFC TBD), where the NXNAME pseudo-type is allowed to appear in		nonexistent names.</t>
	responses to non-existent names.		</blockquote>
	</li>
	</ul>		<t>
	<t>		Note: As a practical matter, no known resolver insists that
	Note: as a practical matter, no known resolver insists that		pseudo-types not be set in the NSEC Type Bit Maps field, so this
	pseudo-types must be clear in the NSEC Type Bit Maps, so this
	restriction (prior to its revision) has posed no problem for		restriction (prior to its revision) has posed no problem for
	the deployment of this mechanism.		the deployment of this mechanism.
	</t>		</t>
	</section>		</section>
	<section anchor="updates4035" title="Updates to RFC 4035">		<section anchor="updates4035">
	<t>		<name>Updates to RFC 4035</name>
	<xref target="RFC4035" /> Section 2.3, Including NSEC RRs in a Zone,		<t><xref target="RFC4035" sectionFormat="of" section="2.3"/>
	states the following:		("Including NSEC RRs in a Zone") states the following:</t>
	</t>
	<ul>		<blockquote>
	<li>
	An NSEC record (and its associated RRSIG RRset) MUST NOT be the only		<t>An NSEC record (and its associated RRSIG RRset) <bcp14>MUST
	RRset at any particular owner name. That is, the signing process		NOT</bcp14> be the only RRset at any particular owner name. That
	MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not		is, the signing process <bcp14>MUST NOT</bcp14> create NSEC or RRSIG
	the owner name of any RRset before the zone was signed. The main		RRs for owner name nodes that were not the owner name of any RRset
	reasons for this are a desire for namespace consistency between		before the zone was signed. The main reasons for this are a desire
	signed and unsigned versions of the same zone and a desire to reduce		for namespace consistency between signed and unsigned versions of
	the risk of response inconsistency in security oblivious recursive		the same zone and a desire to reduce the risk of response
	name servers.		inconsistency in security oblivious recursive name servers.</t>
	</li>		</blockquote>
	</ul>
	<t>		<t>
	This paragraph is updated to the following::		This paragraph is updated to the following:
	</t>		</t>
	<ul>
	<li>		<blockquote>
	An NSEC record (and its associated RRSIG RRset) MUST NOT be the only		<t>An NSEC record (and its associated RRSIG RRset) <bcp14>MUST NOT</bc
			p14> be the only
	RRset at any particular owner name. That is, the signing process		RRset at any particular owner name. That is, the signing process
	MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not		<bcp14>MUST NOT</bcp14> create NSEC or RRSIG RRs for owner name nodes that were not
	the owner name of any RRset before the zone was signed. The main		the owner name of any RRset before the zone was signed. The main
	reasons for this are a desire for namespace consistency between		reasons for this are a desire for namespace consistency between
	signed and unsigned versions of the same zone and a desire to reduce		signed and unsigned versions of the same zone and a desire to reduce
	the risk of response inconsistency in security oblivious recursive		the risk of response inconsistency in security oblivious recursive
	name servers. This concern only applies to implementations of DNSSEC		name servers. This concern only applies to implementations of DNSSEC
	that employ pre-computed signatures. There is an exception to this		that employ precomputed signatures. There is an exception to this
	rule for online signing implementations of DNSSEC (e.g., Minimally		rule for online signing implementations of DNSSEC (e.g., minimally
	Covering NSEC, and Compact Denial of Existence), where		covering NSEC and Compact Denial of Existence), where
	dynamically generated NSEC records can be produced for owner names		dynamically generated NSEC records can be produced for owner names
	that don't exist or are empty non-terminals.		that don't exist or are ENTs.</t>
	</li>		</blockquote>
	</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="security" numbered="true" toc="default">		<section anchor="security">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	Online signing of DNS records requires authoritative servers		Online signing of DNS records requires authoritative servers
	for the DNS zone to have access to the private signing keys.		for the DNS zone to have access to the private signing keys.
	Exposing signing keys on Internet reachable servers makes them		Exposing signing keys on Internet-reachable servers makes them
	more vulnerable to attack.		more vulnerable to attack.
	</t>		</t>
	<t>		<t>
	Additionally, generating signatures on-demand is more		Additionally, generating signatures on demand is more
	computationally intensive than returning pre-computed		computationally intensive than returning precomputed
	signatures. Although the Compact Answers scheme reduces the		signatures. Although the Compact Answers scheme reduces the
	number of online signing operations compared to previous		number of online signing operations compared to previous
	techniques like White Lies, it still may make authoritative		techniques like White Lies, it still may make authoritative
	servers more vulnerable to computational denial of service		servers more vulnerable to computational denial-of-service
	attacks than pre-computed signatures. The use of signature		attacks than precomputed signatures. The use of signature
	algorithms (like those based on Elliptic Curves) that have		algorithms (like those based on elliptic curves) that have
	a comparatively low cost for signing is recommended.		a comparatively low cost for signing is recommended.
	</t>		</t>
	<t>		<t>
	Some security tools rely on detection of non-existent		Some security tools rely on detection of nonexistent
	domain names by examining the response code field of DNS		domain names by examining the response code field of DNS
	response messages. A NOERROR code in that field rather than		response messages. A NOERROR (rather than
	NXDOMAIN will impact such tools. Implementation of the		NXDOMAIN) code in that field will impact such tools. Implementation of t
			he
	optional response code restoration scheme will help recover		optional response code restoration scheme will help recover
	NXDOMAIN visibility for these tools. Note that the DNS		NXDOMAIN visibility for these tools. Note that the DNS
	header is not cryptographically protected, so the response		header is not cryptographically protected, so the response
	code field cannot be authenticated. Thus inferring the status		code field cannot be authenticated. Thus, inferring the status
	of a response from signed data in the body of the DNS message		of a response from signed data in the body of the DNS message
	is actually more secure. These tools could be enhanced to		is actually more secure. These tools could be enhanced to
	recognize the (signed) NXNAME signal.		recognize the (signed) NXNAME signal.
	</t>		</t>
	<t>		<t>
	Because this method does not allow for aggressive negative		Because this method does not allow for aggressive negative
	caching among resolvers, it allows for certain types		caching among resolvers, it allows for certain types
	of denial-of-service attacks to be more effective. This		of denial-of-service attacks to be more effective. This
	includes so-called Pseudorandom Subdomain Attacks		includes so-called Pseudorandom Subdomain Attacks
	<xref target="PRSD-ATTACK" format="default"/>, where random names		<xref target="PRSD-ATTACK" format="default"/>, where random names
	are queried, either directly via botnets or across a wide		are queried, either directly via botnets or across a wide
	range of public resolver services, in order to intentionally		range of public resolver services, in order to intentionally
	generate non-existence responses from the authoritative		generate nonexistent responses from the authoritative
	servers for a domain. If the resolver cannot synthesize NXDOMAIN		servers for a domain. If the resolver cannot synthesize NXDOMAIN
	responses from NSEC records, it must pass all queries on to the		responses from NSEC records, it must pass all queries on to the
	domain's authority servers, making resource exhaustion more likely		domain's authority servers, making resource exhaustion more likely
	at those latter servers, if those servers do not have the capacity		at those latter servers if they do not have the capacity
	to absorb those additional queries.		to absorb those additional queries.
	</t>		</t>
	<t>		<t>
	If the motivating aspects of this specification (minimizing		If the motivating aspects of this specification (minimizing
	response size and computational costs) are not a concern,		response size and computational costs) are not a concern,
	DNSSEC deployments can opt for a different method (e.g.,		DNSSEC deployments can opt for a different method (e.g.,
	traditional online signing or pre-computed signatures),		conventional online signing or precomputed signatures)
	and avoid imposing the challenges of NXDOMAIN visibility.		and avoid imposing the challenges of NXDOMAIN visibility.
	</t>		</t>
	</section>		</section>
	<section anchor="acks" numbered="true" toc="default">		<section anchor="iana">
	<name>Acknowledgements</name>
	<t>
	The Compact Answers technique (then called "Black Lies") was
	originally proposed in
	<xref target="BLACK-LIES" format="default"/> by Filippo Valsorda
	and Olafur Gudmundsson, and implemented by Cloudflare. The Empty
	Non-Terminal distinguisher RR type was originally proposed in
	<xref target="ENT-SENTINEL" format="default"/> by Shumon Huque,
	and deployed by NS1.
	The NXNAME type is based on the FDOM type proposed in
	<xref target="NXDOMAIN-TYPE" format="default"/> by Gudmundsson
	and Valsorda.
	</t>
	<t>
	Especially detailed discussions on many technical aspects of this
	document were conducted with Paul Vixie, Jan Vcelak, Viktor Dukhovni,
	Ed Lewis, and John Levine. The authors would also like to thank
	the many other members of the IETF DNS Operations working group
	for helpful comments and discussions.
	</t>
	</section>
	<section anchor="iana" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>		<t>
	IANA is requested to do the following:		IANA has allocated the following in
	</t>		the "Resource Record (RR) TYPEs" registry in the "Domain Name System (DN
	<t>		S) Parameters"
	Allocate a new DNS Resource Record type code for NXNAME from		registry group, from the range for Meta-TYPEs.
	the "Resource Record (RR) Types" registry in the "DNS parameters"		A lower number in this range lowers the size of the
	registry group, from the meta type range. Specifically, the lowest
	available number (currently 128) in the meta types range is
	requested to be allocated. A lower number lowers the size of the
	Type Bit Maps field, which reduces the overall size of the DNS		Type Bit Maps field, which reduces the overall size of the DNS
	response message.		response message.
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table>
	Type Value Meaning		<thead>
	NXNAME 128 NXDOMAIN indicator for Compact Denial of Existence		<tr><th>Type</th><th>Value</th><th>Meaning</th><th>Reference</th></tr>
	]]></artwork>		</thead>
			<tbody>
			<tr>
			<td>NXNAME</td>
			<td>128</td>
			<td>NXDOMAIN indicator for Compact Denial of Existence</td>
			<td>RFC 9824</td>
			</tr>
			</tbody>
			</table>
	<t>		<t>
	Allocate the "Compact Answers OK" flag in the "EDNS Header Flags		IANA has also allocated the following flag in the "EDNS Header Flags
	(16 bits)" registry in the "Domain Name System (DNS) Parameters"		(16 bits)" registry in the "Domain Name System (DNS) Parameters"
	registry group. Set the Flag field to "CO", as described in		registry group. This flag is described in <xref target="signaled-rcode"/
	<xref target="signaled-rcode"/>.		>.
	</t>		</t>
			<table anchor="blah">
			<name></name>
			<thead>
			<tr>
			<th>Bit</th>
			<th>Flag</th>
			<th>Description</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>Bit 1</td>
			<td>CO</td>
			<td>Compact Answers OK</td>
			<td>RFC 9824</td>
			</tr>
			</tbody>
			</table>
	<t>		<t>
	Allocate a code point for "Invalid Query Type" in the		Last, IANA has allocated the following code point in the
	"Extended DNS Error Codes" registry in the "Domain Name System		"Extended DNS Error Codes" registry in the "Domain Name System
	(DNS) Parameters" registry group, as described in		(DNS) Parameters" registry group. This code point is described in
	<xref target="response-nxname"/>.		<xref target="response-nxname"/>.
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<table>
	INFO-CODE Purpose		<thead>
	30 Invalid Query Type		<tr>
	]]></artwork>		<th>INFO-CODE</th>
			<th>Purpose</th>
			<th>Reference</th>
			</tr>
			</thead>
			<tbody>
			<tr>
			<td>30</td>
			<td>Invalid Query Type</td>
			<td>RFC 9824</td></tr>
			</tbody>
			</table>
	</section>		</section>
	</middle>		</middle>
	<!-- *****BACK MATTER ***** -->
	<back>		<back>
			<displayreference target="I-D.valsorda-dnsop-black-lies" to="COMPACT"/>
			<displayreference target="I-D.huque-dnsop-blacklies-ent" to="ENT-SENTINEL"/>
			<displayreference target="I-D.ogud-fake-nxdomain-type" to="NXDOMAIN-TYPE"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	ence.RFC.2119.xml"/>		119.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
	ence.RFC.3225.xml"/>		225.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	ence.RFC.4034.xml"/>		034.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	ence.RFC.4035.xml"/>		035.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	ence.RFC.4470.xml"/>		470.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
	ence.RFC.4648.xml"/>		648.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
	ence.RFC.5155.xml"/>		155.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	ence.RFC.6891.xml"/>		891.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
	ence.RFC.6895.xml"/>		895.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ence.RFC.8174.xml"/>		174.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ence.RFC.8914.xml"/>		914.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	ence.RFC.9364.xml"/>		364.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
	ence.RFC.7129.xml"/>		129.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ence.RFC.8020.xml"/>		020.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ence.RFC.8198.xml"/>		198.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ence.RFC.8305.xml"/>		305.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
	ence.RFC.9499.xml"/>		499.xml"/>
	<reference anchor="BLACK-LIES"
	target="https://tools.ietf.org/html/draft-valsorda-dnsop-black-		<reference anchor="I-D.valsorda-dnsop-black-lies" target="https://datatracker.ie
	lies">		tf.org/doc/html/draft-valsorda-dnsop-black-lies-00">
	<front>		<front>
	<title>Compact DNSSEC Denial of Existence or Black Lies</title>		<title>Compact DNSSEC Denial of Existence or Black Lies</title>
	<author fullname="Filippo Valsorda" initials="F" surname="Valsorda" />		<author fullname="Filippo Valsorda" initials="F." surname="Valsorda">
	<author fullname="Olafur Gudmundsson" initials="O" surname="Gudmundsso		<organization>CloudFlare Inc.</organization>
	n" />		</author>
	<date />		<author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
	</front>		<organization>CloudFlare Inc.</organization>
	</reference>		</author>
	<reference anchor="ENT-SENTINEL"		<date day="21" month="March" year="2016"/>
	target="https://www.ietf.org/archive/id/draft-huque-dnsop-black		</front>
	lies-ent-01.html">		<seriesInfo name="Internet-Draft" value="draft-valsorda-dnsop-black-lies-00"/>
	<front>		</reference>
	<title>Empty Non-Terminal Sentinel for Black Lies</title>
	<author fullname="Shumon Huque" initials="S" surname="Huque" />		<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.h
	<date />		uque-dnsop-blacklies-ent.xml"/>
	</front>
	</reference>		<reference anchor="I-D.ogud-fake-nxdomain-type" target="https://datatracker.ietf
	<reference anchor="NXDOMAIN-TYPE"		.org/doc/html/draft-ogud-fake-nxdomain-type-00">
	target="https://tools.ietf.org/html/draft-ogud-fake-nxdomain-ty		<front>
	pe/">		<title>Signaling NSEC record owner name nonexistence</title>
	<front>		<author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
	<title>Signaling NSEC record owner name nonexistence</title>		<organization>CloudFlare Inc.</organization>
	<author fullname="Olafur Gudmundsson" initials="O" surname="Gudmundsso		</author>
	n" />		<author fullname="Filippo Valsorda" initials="F." surname="Valsorda">
	<author fullname="Filippo Valsorda" initials="F" surname="Valsorda" />		<organization>CloudFlare Inc.</organization>
	<date />		</author>
	</front>		<date day="7" month="May" year="2015"/>
	</reference>		</front>
			<seriesInfo name="Internet-Draft" value="draft-ogud-fake-nxdomain-type-00"/>
			</reference>
	<reference anchor="PRSD-ATTACK"		<reference anchor="PRSD-ATTACK"
	target="https://conference.apnic.net/data/39/dnswatertortureonq tnet_1425130417_1425507043.pptx">		target="https://conference.apnic.net/data/39/dnswatertortureonq tnet_1425130417_1425507043.pptx">
	<front>		<front>
	<title>Water Torture: A Slow Drip DNS DDoS Attack on QTNet</title>		<title>Water Torture: A Slow Drip DNS DDoS Attack on QTNet</title>
	<author fullname="Kei Nishida" initials="K" surname="Nishida" />		<author fullname="Kei Nishida" initials="K" surname="Nishida" />
	<date />		<date />
	</front>		</front>
	</reference>		</reference>
	</references>		</references>
	</references>		</references>
	<section anchor="other-approaches" numbered="true" removeInRFC="false"		<section anchor="other-approaches">
	toc="include" pn="section-appendix.a">
	<name>Other Approaches</name>		<name>Other Approaches</name>
	<t>		<t>
	In the past, some implementations of Compact Denial of Existence		In the past, some implementations of Compact Denial of Existence
	have used other means to differentiate NXDOMAIN from Empty		have used other means to differentiate NXDOMAIN from ENTs.
	Non-Terminals.
	</t>		</t>
	<t>		<t>
	One method employed by both Cloudflare and Amazon Route53 for		One method employed by both Cloudflare and Amazon Route53 for
	a period of time was the following: for responses to Empty		a period of time was the following: For responses to ENTs,
	Non-Terminals, they synthesized the NSEC Type Bit Maps to include		they synthesized the NSEC Type Bit Maps field to include
	all record types supported except for the queried type. This		all record types supported except for the queried type. This
	method has the undesirable effect of no longer being able to		method has the undesirable effect of no longer being able to
	reliably determine the existence of ENTs, and of making the Type		reliably determine the existence of ENTs and of making the Type
	Bit Maps field larger than it needs to be. It also has the potential		Bit Maps field larger than it needs to be. It also has the potential
	to confuse validators and others tools that infer type existence		to confuse validators and others tools that infer type existence
	from the NSEC record.		from the NSEC record.
	</t>		</t>
	<t>		<t>
	Another way to distinguish NXDOMAIN from ENT is to		Another way to distinguish NXDOMAIN from ENT is to
	define the synthetic Resource Record type for ENTs instead,		define the synthetic RR type for ENTs instead,
	as specified in <xref target="ENT-SENTINEL" format="default"/>.		as specified in <xref target="I-D.huque-dnsop-blacklies-ent" format="def
			ault"/>.
	This method was successfully deployed in the field by NS1 for a		This method was successfully deployed in the field by NS1 for a
	period of time. This typically imposes less work on the server		period of time. This typically imposes less work on the server
	since NXDOMAIN responses are a lot more common than ENTs. At the		since NXDOMAIN responses are a lot more common than ENTs. At the
	time it was deployed, it also allowed a common bitmap pattern		time it was deployed, it also allowed a common bitmap pattern
	("NSEC RRSIG") to identify NXDOMAIN across this and other		("NSEC RRSIG") to identify NXDOMAIN across this and other
	implementations that returned a broad bitmap pattern for Empty		implementations that returned a broad bitmap pattern for
	Non-Terminals. However, the advantage of the NXNAME RR type is		ENTs. However, the advantage of the NXNAME RR type is
	that it explicitly identifies NXDOMAIN responses, and allows		that it explicitly identifies NXDOMAIN responses and allows
	them to be distinguished conclusively from potential ENT responses		them to be distinguished conclusively from potential ENT responses
	in other online signing NSEC implementations.		in other online signing NSEC implementations.
	</t>		</t>
	</section>		</section>
	<section anchor="implementations" numbered="true" removeInRFC="false"		<section anchor="implementations">
	toc="include" pn="section-appendix.b">
	<name>Historical Implementation Notes</name>		<name>Historical Implementation Notes</name>
	<t>		<t>
	At the time of publication, the basic Compact Denial of Existence		At the time of publication, the basic Compact Denial of Existence
	method using NSEC is implemented by Cloudflare, NS1, Amazon Route53,		method using NSEC is implemented by Cloudflare, NS1, Amazon Route53,
	and Knot DNS's optional online signing module. From early 2021 until		and Knot DNS's optional online signing module. From early 2021 until
	November 2023, NS1 had deployed the Empty Non-Terminal distinguisher		November 2023, NS1 had deployed the ENT distinguisher
	<xref target="ENT-SENTINEL" format="default"/> using the private		<xref target="I-D.huque-dnsop-blacklies-ent" format="default"/> using th
			e private
	RR type code 65281. A version of the NXNAME distinguisher using		RR type code 65281. A version of the NXNAME distinguisher using
	the private RR type code 65238 was deployed by both Cloudflare		the private RR type code 65238 was deployed by both Cloudflare
	(from July 2023) and NS1 (from November 2023) until roughly		(from July 2023) and NS1 (from November 2023) until roughly
	September 2024. Since September 2024 both Cloudflare and NS1 have		September 2024. Since September 2024, both Cloudflare and NS1 have
	deployed NXNAME using the officially allocated code point of 128.		deployed NXNAME using the officially allocated code point of 128.
	Oracle Cloud Initiative implemented Compact Denial of Existence		Oracle Cloud Initiative implemented Compact Denial of Existence
	using NSEC3 in October 2024.		using NSEC3 in October 2024.
	</t>		</t>
	</section>		</section>
			<section anchor="acks" numbered="false">
			<name>Acknowledgements</name>
			<t>The Compact Answers technique was
			originally proposed in <xref target="I-D.valsorda-dnsop-black-lies"
			format="default"/> by <contact fullname="Filippo Valsorda"/> and
			<contact fullname="Olafur Gudmundsson"/> and implemented by
			Cloudflare. The ENT distinguisher RR type was originally
			proposed in <xref target="I-D.huque-dnsop-blacklies-ent"
			format="default"/> by <contact fullname="Shumon Huque"/> and deployed by
			NS1. The NXNAME type is based on the FDOM type proposed in <xref
			target="I-D.ogud-fake-nxdomain-type" format="default"/> by Gudmundsson
			and Valsorda.</t>
			<t>Especially detailed discussions on many technical aspects of this
			document were conducted with <contact fullname="Paul Vixie"/>, <contact
			fullname="Jan Včelák"/>, <contact fullname="Viktor Dukhovni"/>, <contact
			fullname="Ed Lewis"/>, and <contact fullname="John Levine"/>. The
			authors would also like to thank the many other members of the IETF DNS
			Operations Working Group for helpful comments and discussions.</t>
			</section>
	</back>		</back>
	</rfc>		</rfc>
End of changes. 142 change blocks.
	423 lines changed or deleted		440 lines changed or added
This html diff was produced by rfcdiff 1.48.