rfc9824v1.txt		rfc9824.txt
	Internet Engineering Task Force (IETF) S. Huque		Internet Engineering Task Force (IETF) S. Huque
	Request for Comments: 9824 Salesforce		Request for Comments: 9824 Salesforce
	Updates: 4034, 4035 C. Elmerot		Updates: 4034, 4035 C. Elmerot
	Category: Standards Track Cloudflare		Category: Standards Track Cloudflare
	ISSN: 2070-1721 O. Gudmundsson		ISSN: 2070-1721 O. Gudmundsson
	Retired/Unaffiliated		September 2025
	August 2025
	Compact Denial of Existence in DNSSEC		Compact Denial of Existence in DNSSEC
	Abstract		Abstract
	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
	but doesn't have any data for the queried record type. Such answers		doesn't have any data for the queried record type. Such responses
	require only one minimally covering NSEC or NSEC3 record, allow		require only one minimally covering NSEC or NSEC3 record, allow
	online signing servers to minimize signing operations and response		online signing servers to minimize signing operations and response
	sizes, and prevent zone content disclosure.		sizes, and prevent zone content disclosure.
	This document updates RFCs 4034 and 4035.		This document updates RFCs 4034 and 4035.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	skipping to change at line 56 ¶		skipping to change at line 55 ¶
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Revised BSD License text as described in Section 4.e of the		include Revised BSD License text as described in Section 4.e of the
	Trust Legal Provisions and are provided without warranty as described		Trust Legal Provisions and are provided without warranty as described
	in the Revised BSD License.		in the Revised BSD License.
	Table of Contents		Table of Contents
	1. Introduction and Motivation		1. Introduction and Motivation
	1.1. Requirements Language		1.1. Requirements Language
	2. Distinguishing Non-existent Names		2. Distinguishing Nonexistent Names
	3. Generating Responses with NSEC		3. Generating Responses with NSEC
	3.1. Responses for Non-existent Names		3.1. Responses for Nonexistent Names
	3.2. Responses for Non-existent Types		3.2. Responses for Nonexistent Types
	3.3. Responses for Wildcard Matches		3.3. Responses for Wildcard Matches
	3.4. Responses for Unsigned Referrals		3.4. Responses for Unsigned Referrals
	3.5. Responses to Explicit Queries for NXNAME		3.5. Responses to Explicit Queries for NXNAME
	4. Generating Responses with NSEC3		4. Generating Responses with NSEC3
	5. Response Code Restoration		5. Response Code Restoration
	5.1. Signaled Response Code Restoration		5.1. Signaled Response Code Restoration
	6. Operational Implications		6. Operational Implications
	7. Updates to RFCs		7. Updates to RFCs
	7.1. Updates to RFC 4034		7.1. Updates to RFC 4034
	7.2. Updates to RFC 4035		7.2. Updates to RFC 4035
	skipping to change at line 87 ¶		skipping to change at line 86 ¶
	Acknowledgements		Acknowledgements
	Authors' Addresses		Authors' Addresses
	1. Introduction and Motivation		1. Introduction and Motivation
	One of the functions of DNS Security Extensions (DNSSEC) [RFC9364] is		One of the functions of DNS Security Extensions (DNSSEC) [RFC9364] is
	"authenticated denial of existence", i.e., proving that a DNS name or		"authenticated denial of existence", i.e., proving that a DNS name or
	record type does not exist. Normally, this is done by means of		record type does not exist. Normally, this is done by means of
	signed NSEC or NSEC3 records. In the precomputed signature model,		signed NSEC or NSEC3 records. In the precomputed signature model,
	these records chain together existing names, or cryptographic hashes		these records chain together existing names, or cryptographic hashes
	of them, in the zone. In the online signing model, described in NSEC		of them, in the zone. In the online signing model, described for
	and NSEC3 "White Lies" [RFC4470] [RFC7129], they are used to		NSEC in [RFC4470] and for NSEC3 in Appendix B of [RFC7129], they are
	dynamically compute an epsilon function around the queried name. The		used to dynamically compute an epsilon function around the QNAME.
	Type Bit Maps field in the data of the NSEC or NSEC3 record asserts		The Type Bit Maps field in the data of the NSEC or NSEC3 record
	which resource record (RR) types are present at the name.		asserts which resource record (RR) types are present at the name.
	The response for a non-existent name requires up to two signed NSEC		The response for a nonexistent name requires up to two signed NSEC
	records or up to three 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 name		the associated cryptographic computation) to prove that (1) the name
	did not explicitly exist in the zone and (2) it could not have been		did not explicitly exist in the zone and (2) it could not have been
	synthesized by a wildcard.		synthesized by a wildcard.
	This document describes an alternative technique, "Compact Denial of		This document describes an alternative technique, "Compact Denial of
	Existence" or "Compact Answers", to generate a signed DNS response on		Existence" or "Compact Answers", to generate a signed DNS response on
	demand for a non-existent name by claiming that the name exists but		demand for a nonexistent name by claiming that the name exists but
	has no resource records associated with the queried type, i.e., it		has no resource record sets associated with the queried type, i.e.,
	returns a NODATA response rather than an NXDOMAIN response. A NODATA		it returns a NODATA response rather than an NXDOMAIN response. A
	response, which has a response code (RCODE) of NOERROR and an empty		NODATA response, which has a response code (RCODE) of NOERROR and an
	ANSWER section, requires only one NSEC or NSEC3 record matching the		empty ANSWER section, requires only one NSEC or NSEC3 record matching
	queried name. This has two advantages: The DNS response size is		the QNAME. This has two advantages: The DNS response size is
	smaller, and it reduces the online cryptographic work involved in		smaller, and it reduces the online cryptographic work involved in
	generating the response.		generating the response.
	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 by		adversaries from enumerating the entire contents of DNS zones by
	walking the NSEC chain or performing an offline dictionary attack on		walking the NSEC chain or performing an offline dictionary attack on
	the hashes in the NSEC3 chain.		the hashes in the NSEC3 chain.
	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" [RFC9499].		in further detail in "DNS Terminology" [RFC9499].
	1.1. Requirements Language		1.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2. Distinguishing Non-existent Names		2. Distinguishing Nonexistent Names
	This method generates NODATA responses for non-existent names that		This method generates NODATA responses for nonexistent names that
	don't match a DNS wildcard. Since there are clearly no record types		don't match a DNS wildcard. Since there are clearly no record types
	for such names, the NSEC Type Bit Maps field in the response will		for such names, the NSEC Type Bit Maps field in the response will
	only contain the NSEC and RRSIG types (and in the case of NSEC3, the		only contain the NSEC and RRSIG types (and in the case of NSEC3, the
	Type Bit Maps field will be empty). Tools that need to accurately		Type Bit Maps field will be empty). Tools that need to accurately
	identify non-existent names in responses cannot rely on this specific		identify nonexistent names in responses cannot rely on this specific
	type bitmap because Empty Non-Terminal (ENT) names (which positively		type bitmap because Empty Non-Terminal (ENT) names (which positively
	exist) also have no record types at the name and will return exactly		exist) also have no record types at the name and will return exactly
	the same Type Bit Maps field.		the same Type Bit Maps field.
	This specification defines the use of a synthetic RR type to signal		This specification defines the use of NXNAME (128), a synthetic RR
	the presence of a non-existent name. The mnemonic for this RR type		type to signal the presence of a nonexistent name. See Section 9.
	is NXNAME, chosen to clearly distinguish it from the response code		The mnemonic for this RR type is NXNAME, chosen to clearly
	mnemonic NXDOMAIN.		distinguish it from the response code mnemonic NXDOMAIN.
	+========+=======+=============================+
	| TYPE | Value | Meaning |
	+========+=======+=============================+
	| NXNAME | 128 | NXDOMAIN indicator for |
	| | | Compact Denial of Existence |
	+--------+-------+-----------------------------+
	Table 1
	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 NSEC		to nonexistent names, in addition to the mandated RRSIG and NSEC
	types. If NSEC3 is being used, this RR type is the sole entry in the		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 [RFC6895],		Type Bit Maps field. It is a "Meta-TYPE", as defined in [RFC6895],
	and it stores no data in a DNS zone and cannot be usefully queried.		and it stores no data in a DNS zone and cannot be usefully queried.
	Section 3.5 describes what a DNS resolver or authoritative server		Section 3.5 describes what a DNS resolver or authoritative server
	should do if it receives an explicit query for NXNAME.		should do if it receives an explicit query for NXNAME.
	No special handling of this RR type is required on the part of DNS		No special handling of this RR type is required on the part of DNS
	resolvers. However, resolvers may optionally implement the behavior		resolvers. However, resolvers may optionally implement the behavior
	described in Section 5.1 ("Signaled Response Code Restoration") to		described in Section 5.1 ("Signaled Response Code Restoration") to
	better restore NXDOMAIN visibility to various applications that may		better restore NXDOMAIN visibility to various applications that may
	remain oblivious to the new NXNAME signal.		remain oblivious to the new NXNAME signal.
	3. Generating Responses with NSEC		3. Generating Responses with NSEC
	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 using		authoritative servers implementing Compact Denial of Existence using
	NSEC. Section 4 describes changes needed to support NSEC3.		NSEC. Section 4 describes changes needed to support NSEC3.
	3.1. Responses for Non-existent Names		3.1. Responses for Nonexistent Names
	When the authoritative server receives a query for a non-existent		When the authoritative server receives a query for a nonexistent name
	name in a zone that it serves, a NODATA response (response code		in a zone that it serves, a NODATA response (response code NOERROR,
	NOERROR, empty Answer section) is generated with a dynamically		empty Answer section) is generated with a dynamically constructed
	constructed NSEC record with the owner name matching the queried name		NSEC record with the owner name matching the QNAME placed in the
	(QNAME) placed in the Authority section.		Authority section.
	The Next Domain Name field SHOULD be set to the immediate		The Next Domain Name field SHOULD be set to the immediate
	lexicographic successor of the QNAME. This is accomplished by adding		lexicographic successor of the QNAME. This is accomplished by adding
	a leading label with a single null (zero-value) octet. The Type Bit		a leading label with a single null (zero-value) octet. The Type Bit
	Maps field MUST only have the bits set for the following RR Types:		Maps field MUST only have the bits set for the following RR Types:
	RRSIG, NSEC, and NXNAME.		RRSIG, NSEC, and NXNAME.
	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 generation of the following NSEC record (in DNS		would result in the generation of the following NSEC record (in DNS
	presentation format):		presentation format):
	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
	The NSEC record MUST have corresponding RRSIGs generated.		The NSEC record MUST have corresponding RRSIGs generated.
	3.2. Responses for Non-existent Types		3.2. Responses for Nonexistent Types
	When the authoritative server receives a query for a name that exists		When the authoritative server receives a query for a name that exists
	but has no resource record sets associated with the queried type, it		but has no resource record sets associated with the queried type, it
	generates a NODATA response with a dynamically constructed signed		generates a NODATA response with a dynamically constructed signed
	NSEC record in the Authority section. The owner name of the NSEC		NSEC record in the Authority section. The owner name of the NSEC
	record matches the queried name. The Next Domain Name field is set		record matches the QNAME. The Next Domain Name field is set to the
	to the immediate lexicographic successor of the QNAME. The Type Bit		immediate lexicographic successor of the QNAME. The Type Bit Maps
	Maps field lists the available RR types at the name.		field lists the available RR types at the name.
	An Empty Non-Terminal is a special subset of this category, where the		An ENT is a special subset of this category, where the name has no
	name has no resource record sets of any type (but has descendant		resource record sets of any type (but has descendant names that do).
	names that do). For a query for an Empty Non-Terminal, the NSEC Type		For a query for an ENT, the NSEC Type Bit Maps field will only
	Bit Maps field will only contain RRSIG and NSEC. (Note that this is		contain RRSIG and NSEC. (Note that this is substantially different
	substantially different than the ENT response in precomputed NSEC,		than the ENT response in precomputed NSEC, where the NSEC record has
	where the NSEC record has the same type bitmap but "covers" rather		the same type bitmap but "covers" rather than matches the ENT and has
	than matches the ENT and has the Next Domain Name field set to the		the Next Domain Name field set to the next lexicographic descendant
	next lexicographic descendant of the ENT in the zone.)		of the ENT in the zone.)
	3.3. Responses for Wildcard Matches		3.3. Responses for Wildcard Matches
	For wildcard matches, the authoritative server will provide a		For wildcard matches, the authoritative server will provide a
	dynamically signed response that claims that the queried name exists		dynamically signed response that claims that the QNAME exists
	explicitly. Specifically, the answer RRset will have an RRSIG record		explicitly. Specifically, the answer RRset will have an RRSIG record
	demonstrating an exact match (i.e., the label count in the RRSIG		demonstrating an exact match (i.e., the label count in the RRSIG
	RDATA will be equal to the number of labels in the query name minus		RDATA will be equal to the number of labels in the query name minus
	the root label). This obviates the need to include an NSEC record in		the root label). This obviates the need to include an NSEC record in
	the Authority section of the response that shows that no closer match		the Authority section of the response that shows that no closer match
	than the wildcard was possible.		than the wildcard was possible.
	For a wildcard NODATA match (where the queried name matches a		For a wildcard NODATA match (where the QNAME matches a wildcard but
	wildcard but no data for the queried type exists), a response akin to		no data for the queried type exists), a response akin to a non-
	a non-wildcard NODATA is returned. The Answer section is empty, and		wildcard NODATA is returned. The Answer section is empty, and the
	the Authority section contains a single NSEC record that matches the		Authority section contains a single NSEC record that matches the
	query name with a Type Bit Maps field representing the list of types		query name with a Type Bit Maps field representing the list of types
	available at the wildcard.		available at the wildcard.
	3.4. Responses for Unsigned Referrals		3.4. Responses for Unsigned Referrals
	Per the DNSSEC protocol, a referral to an unsigned subzone includes		Per the DNSSEC protocol, a referral to an unsigned subzone includes
	an NSEC record whose owner name matches the subzone and proves the		an NSEC record whose owner name matches the subzone and proves the
	delegation is unsigned by the absence of the Delegation Signer (DS)		delegation is unsigned by the absence of the Delegation Signer (DS)
	RR type bit in the Type Bit Maps field.		RR type bit in the Type Bit Maps field.
	With Compact Denial of Existence, the Next Domain Name field for this		With Compact Denial of Existence, the Next Domain Name field for this
	NSEC record is computed with a slightly different epsilon function		NSEC record is computed with a slightly different epsilon function
	than the immediate lexicographic successor of the owner name, as that		than the immediate lexicographic successor of the owner name, as that
	name would then fall under the delegated subzone. Instead, the Next		name would then fall under the delegated subzone. Instead, the Next
	Domain Name field is formed by appending a zero octet to the first		Domain Name field is formed by appending a zero octet to the first
	label of the owner name.		label of the owner name.
	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:
	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
	3.5. Responses to Explicit Queries for NXNAME		3.5. Responses to Explicit Queries for NXNAME
	NXNAME is a Meta-TYPE that should not appear anywhere in a DNS		NXNAME is a Meta-TYPE that SHOULD NOT appear anywhere in a DNS
	message apart from the NSEC type bitmap of a Compact Answer response		message apart from the NSEC type bitmap of a Compact Answer response
	for a non-existent name. However, if a DNS server implementing this		for a nonexistent name. However, if a DNS server implementing this
	specification receives an explicit query for the NXNAME RR type, this		specification receives an explicit query for the NXNAME RR type, this
	section describes what the response should be.		section describes what the response ought to be.
	If an explicit query for the NXNAME RR type is received, the DNS		If an explicit query for the NXNAME RR type is received, the DNS
	server MUST return a Format Error (response code FORMERR). A		server MUST return a Format Error (response code FORMERR). A
	resolver should not forward these queries upstream or attempt		resolver MUST NOT forward these queries upstream or attempt iterative
	iterative resolution. Many DNS server implementations already return		resolution. Many DNS server implementations already return errors
	errors for all types in the range for Meta-TYPEs and QTYPEs, except		for all types in the range for Meta-TYPEs and QTYPEs, except those
	those types that are already defined to support queries.		types that are already defined to support queries.
	Optionally, a DNS server MAY also include the following Extended DNS		Optionally, a DNS server MAY also include the following Extended DNS
	Error (EDE) code [RFC8914] in the response:		Error (EDE) code [RFC8914] in the response: 30 (Invalid Query Type).
			See Section 9.
	+===========+====================+
	| INFO-CODE | Purpose |
	+===========+====================+
	| 30 | Invalid Query Type |
	+-----------+--------------------+
	Table 2
	Note that this EDE code is generally applicable to any RR type that		Note that this EDE code is generally applicable to any RR type that
	should not appear in DNS queries.		ought not appear in DNS queries.
	4. Generating Responses with NSEC3		4. Generating Responses with NSEC3
	NSEC3 [RFC5155] uses hashed names to provide zone enumeration		NSEC3 [RFC5155] uses hashed names to provide zone enumeration
	defense. This protection is already better provided by minimally		defense. This protection is better provided by minimally covering
	covering NSEC records. NSEC3's Opt-Out feature also provides no		NSEC records. NSEC3's Opt-Out feature also provides no specific
	specific benefit for online signing implementations (minimally		benefit for online signing implementations (minimally covering NSEC3
	covering NSEC3 records provide no useful Opt-Out span). Hence, there		records provide no useful Opt-Out span). Hence, there is no known
	is no known advantage to implementing Compact Denial of Existence		advantage to implementing Compact Denial of Existence with NSEC3.
	with NSEC3. However, an existing implementation of traditional NSEC3		However, an existing implementation of conventional NSEC3 online
	online signing migrating to Compact Denial of Existence may find it		signing migrating to Compact Denial of Existence may find it simpler
	simpler to do so with NSEC3 rather than implementing NSEC from		to do so with NSEC3 rather than implementing NSEC from scratch.
	scratch.
	For NSEC3, the functional details of the protocol remain as described		For NSEC3, the functional details of the protocol remain as described
	in Section 3, with the following changes.		in Section 3, with the following changes.
	NSEC3 records and their signatures are dynamically generated instead		NSEC3 records and their signatures are dynamically generated instead
	of NSEC.		of NSEC.
	The NSEC3 parameters should be set to algorithm 1, a flags field of		The NSEC3 parameters SHOULD be set to algorithm 1, a flags field of
	0, an additional hash iteration count of 0, and an empty salt. In		0, an additional hash iteration count of 0, and an empty salt. In
	DNS presentation format, this is "1 0 0 -".		DNS presentation format, this is "1 0 0 -".
	The owner name of the NSEC3 resource record is the NSEC3 hash of the		The owner name of the NSEC3 resource record is the NSEC3 hash of the
	relevant domain name, encoded in Base32 with Extended Hex Alphabet		relevant domain name, encoded in Base32 with Extended Hex Alphabet
	([RFC4648], Section 7), prepended as a single label to the name of		([RFC4648], Section 7), prepended as a single label to the name of
	the zone. The Next Hashed Owner Name is the immediate name successor		the zone. The Next Hashed Owner Name is the immediate name successor
	of the unencoded binary form of the previous hash, which can be		of the unencoded binary form of the previous hash, which can be
	computed by adding one to the binary hash value.		computed by adding one to the binary hash value.
	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-		contain only the NXNAME Meta-TYPE. In responses to ENT names, the
	Terminal names, the Type Bit Maps field will be empty.		Type Bit Maps field will be empty.
	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 generation of the following NSEC3 record:		would result in the generation of the following NSEC3 record:
	H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - (		H64KFA4P1ACER2EBPS9QSDK6DNP8B3JQ.example.com. IN NSEC3 1 0 0 - (
	H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME )		H64KFA4P1ACER2EBPS9QSDK6DNP8B3JR NXNAME )
	Unlike Compact Denial of Existence with NSEC, no special form of the		Unlike Compact Denial of Existence with NSEC, no special form of the
	next name field for unsigned referrals is needed. The Next Hashed		Next Hashed Owner Name field for unsigned referrals is needed. The
	Owner Name field remains the NSEC3 hash of original owner name plus		Next Hashed Owner Name field remains the NSEC3 hash of original owner
	one.		name plus one.
	5. Response Code Restoration		5. Response Code Restoration
	For non-existent names, implementations should try to preserve the		For nonexistent names, implementations should try to preserve the
	response code value of 3 (NXDOMAIN) whenever possible. This is		response code value of 3 (NXDOMAIN) whenever possible. This is
	generally possible for non-DNSSEC-enabled queries, namely those that		generally possible for non-DNSSEC-enabled queries, namely those that
	do not set the DNSSEC_OK EDNS flag (DO bit). For such queries,		do not set the DO bit ("DNSSEC answer OK") in the EDNS0 OPT header.
	authoritative servers implementing Compact Denial of Existence could		For such queries, authoritative servers implementing Compact Denial
	return a normal NXDOMAIN response. However, there may be limited		of Existence could return a normal NXDOMAIN response. However, there
	benefit to doing this since most modern DNS resolvers are DNSSEC		may be limited benefit to doing this since most modern DNS resolvers
	aware, and per Section 3 of [RFC3225], DNSSEC-aware recursive servers		are DNSSEC aware, and per Section 3 of [RFC3225], DNSSEC-aware
	are required to set the DO bit on outbound queries, regardless of the		recursive servers are required to set the DO bit on outbound queries,
	status of the DO bit on incoming requests.		regardless of the status of the DO bit on incoming requests.
	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 to		authoritative server could modify the response code from NOERROR to
	NXDOMAIN in responses they return to downstream queriers that have		NXDOMAIN in responses they return to downstream queriers that have
	not set the DO bit in their requests.		not set the DO bit in their requests.
	5.1. Signaled Response Code Restoration		5.1. Signaled Response Code Restoration
	This section describes an optional but recommended scheme to permit		This section describes an optional but recommended scheme to permit
	signaled restoration of the NXDOMAIN RCODE for DNSSEC-enabled		signaled restoration of the NXDOMAIN RCODE for DNSSEC-enabled
	skipping to change at line 360 ¶		skipping to change at line 342 ¶
	flag.		flag.
	+0 (MSB) +1 (LSB)		+0 (MSB) +1 (LSB)
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	0: | EXTENDED-RCODE | VERSION |		0: | EXTENDED-RCODE | VERSION |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	2: |DO|CO| Z |		2: |DO|CO| Z |
	+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	When this flag is sent in a query by a resolver, it indicates that		When this flag is sent in a query by a resolver, it indicates that
	the resolver will accept a signed NXNAME enhanced NODATA response for		the resolver will accept a NODATA response with a signed NXNAME for a
	a non-existent name, together with the response code field set to		nonexistent name, together with the response code field set to
	NXDOMAIN (3).		NXDOMAIN (3).
	In responses to such queries, a Compact Denial authoritative server		In responses to such queries, an authoritative server implementing
	implementing this signaling scheme will set the Compact Answers OK		both Compact Denial of Existence and this signaling scheme will set
	EDNS header flag and, for non-existent names, will additionally set		the Compact Answers OK EDNS header flag and, for nonexistent names,
	the response code field to NXDOMAIN.		will additionally set the response code field to NXDOMAIN.
	EDNS is a hop-by-hop signal, so resolvers will need to record the		EDNS is a hop-by-hop signal, so resolvers will need to record the
	presence of this flag in associated cache data and respond to		presence of this flag in associated cache data and respond to
	downstream DNSSEC-enabled queriers appropriately. If the querier		downstream DNSSEC-enabled queriers appropriately. If the querier
	does not set the Compact Answers OK flag, the resolver will need to		does not set the Compact Answers OK flag, the resolver will need to
	reset the response code back to NOERROR (0) for an NXNAME response.		reset the response code back to NOERROR (0) for an NXNAME response.
	6. Operational Implications		6. Operational Implications
	For DNSSEC-enabled queries, a signed zone at an authoritative server		For DNSSEC-enabled queries, a signed zone at an authoritative server
	implementing Compact Answers will never return a response with a		implementing Compact Answers will never return a response with a
	response code of NXDOMAIN, unless they have implemented the optional		response code of NXDOMAIN, unless they have implemented the optional
	response code restoration feature described in Section 5.1.		response code restoration feature described in Section 5.1.
	Similarly, resolvers not implementing this feature will also not be		Similarly, resolvers not implementing this feature will also not be
	able to return NXDOMAIN. In the absence of this, tools that rely on		able to return NXDOMAIN. In the absence of this, tools that rely on
	accurately determining non-existent names will need to infer them		accurately determining nonexistent names will need to infer them from
	from the presence of the NXNAME RR type in the Type Bit Maps field of		the presence of the NXNAME RR type in the Type Bit Maps field of the
	the NSEC record in NODATA responses from these servers.		NSEC record in NODATA responses from these servers.
	Address lookup functions typically invoked by applications may need		Address lookup functions typically invoked by applications may need
	to do more work when dealing with implementations of Compact Answers.		to do more work when dealing with implementations of Compact Answers.
	For example, a NODATA response to the lookup of a AAAA record for a		For example, a NODATA response to the lookup of a AAAA record for a
	non-existent name can cause such functions to issue another query at		nonexistent name can cause such functions to issue another query at
	the same name for an A record, whereas an NXDOMAIN response to the		the same name for an A record, whereas an NXDOMAIN response to the
	first query could suppress additional queries for other types at that		first query could suppress additional queries for other types at that
	name. Address lookup functions could be enhanced to issue DNSSEC-		name. Address lookup functions could be enhanced to issue DNSSEC-
	enabled queries and to examine the NSEC Type Bit Maps field in		enabled queries and to examine the NSEC Type Bit Maps field in
	responses to accurately determine non-existent names. Note that this		responses to accurately determine nonexistent names. Note that this
	is less of a concern with connection functions like Happy Eyeballs		is less of a concern with connection functions like Happy Eyeballs
	[RFC8305] that typically issue back-to-back DNS queries without		[RFC8305] that typically issue back-to-back DNS queries without
	waiting for individual responses.		waiting for individual responses.
	Protocol optimizations that enable DNS resolvers to synthesize		Protocol optimizations that enable DNS resolvers to synthesize
	NXDOMAIN or wildcard responses, like those described in [RFC8020] and		NXDOMAIN or wildcard responses, like those described in [RFC8020] and
	[RFC8198], cannot be realized from responses that use Compact Denial		[RFC8198], cannot be realized from responses that use Compact Denial
	of Existence. In general, no online signing scheme that employs		of Existence. In general, no online signing scheme that employs
	minimally covering NSEC or NSEC3 records (including this one) permits		minimally covering NSEC or NSEC3 records (including this one) permits
	NXDOMAIN or wildcard response synthesis in the style described in		NXDOMAIN or wildcard response synthesis in the style described in
	skipping to change at line 427 ¶		skipping to change at line 409 ¶
	| Bits representing pseudo-types MUST be clear, as they do not		| Bits representing pseudo-types MUST be clear, as they do not
	| appear in zone data. If encountered, they MUST be ignored upon		| appear in zone data. If encountered, they MUST be ignored upon
	| being read.		| being read.
	This paragraph is updated to the following:		This paragraph is updated to the following:
	| Bits representing pseudo-types MUST be clear, as they do not		| Bits representing pseudo-types MUST be clear, as they do not
	| appear in zone data. If encountered, they MUST be ignored upon		| appear in zone data. If encountered, they MUST be ignored upon
	| being read. There is one exception to this rule for Compact		| being read. There is one exception to this rule for Compact
	| Denial of Existence (RFC 9824), where the NXNAME pseudo-type is		| Denial of Existence (RFC 9824), where the NXNAME pseudo-type is
	| allowed to appear in responses to non-existent names.		| allowed to appear in responses to nonexistent names.
	|
	| Note: As a practical matter, no known resolver insists that		Note: As a practical matter, no known resolver insists that pseudo-
	| pseudo-types must be clear in the NSEC Type Bit Maps, so this		types not be set in the NSEC Type Bit Maps field, so this restriction
	| restriction (prior to its revision) has posed no problem for the		(prior to its revision) has posed no problem for the deployment of
	| deployment of this mechanism.		this mechanism.
	7.2. Updates to RFC 4035		7.2. Updates to RFC 4035
	Section 2.3 of [RFC4035] ("Including NSEC RRs in a Zone") states the		Section 2.3 of [RFC4035] ("Including NSEC RRs in a Zone") states the
	following:		following:
	| An NSEC record (and its associated RRSIG RRset) MUST NOT be the		| An NSEC record (and its associated RRSIG RRset) MUST NOT be the
	| only RRset at any particular owner name. That is, the signing		| only RRset at any particular owner name. That is, the signing
	| process MUST NOT create NSEC or RRSIG RRs for owner name nodes		| process MUST NOT create NSEC or RRSIG RRs for owner name nodes
	| that were not the owner name of any RRset before the zone was		| that were not the owner name of any RRset before the zone was
	skipping to change at line 463 ¶		skipping to change at line 445 ¶
	| that were not the owner name of any RRset before the zone was		| that were not the owner name of any RRset before the zone was
	| signed. The main reasons for this are a desire for namespace		| signed. The main reasons for this are a desire for namespace
	| consistency between signed and unsigned versions of the same zone		| consistency between signed and unsigned versions of the same zone
	| and a desire to reduce the risk of response inconsistency in		| and a desire to reduce the risk of response inconsistency in
	| security oblivious recursive name servers. This concern only		| security oblivious recursive name servers. This concern only
	| applies to implementations of DNSSEC that employ precomputed		| applies to implementations of DNSSEC that employ precomputed
	| signatures. There is an exception to this rule for online signing		| signatures. There is an exception to this rule for online signing
	| implementations of DNSSEC (e.g., minimally covering NSEC and		| implementations of DNSSEC (e.g., minimally covering NSEC and
	| Compact Denial of Existence), where dynamically generated NSEC		| Compact Denial of Existence), where dynamically generated NSEC
	| records can be produced for owner names that don't exist or are		| records can be produced for owner names that don't exist or are
	| empty non-terminals.		| ENTs.
	8. Security Considerations		8. Security Considerations
	Online signing of DNS records requires authoritative servers for the		Online signing of DNS records requires authoritative servers for the
	DNS zone to have access to the private signing keys. Exposing		DNS zone to have access to the private signing keys. Exposing
	signing keys on Internet-reachable servers makes them more vulnerable		signing keys on Internet-reachable servers makes them more vulnerable
	to attack.		to attack.
	Additionally, generating signatures on demand is more computationally		Additionally, generating signatures on demand is more computationally
	intensive than returning precomputed signatures. Although the		intensive than returning precomputed signatures. Although the
	Compact Answers scheme reduces the number of online signing		Compact Answers scheme reduces the number of online signing
	operations compared to previous techniques like White Lies, it still		operations compared to previous techniques like White Lies, it still
	may make authoritative servers more vulnerable to computational		may make authoritative servers more vulnerable to computational
	denial-of-service attacks than precomputed signatures. The use of		denial-of-service attacks than precomputed signatures. The use of
	signature algorithms (like those based on elliptic curves) that have		signature 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.
	Some security tools rely on detection of non-existent domain names by		Some security tools rely on detection of nonexistent domain names by
	examining the response code field of DNS response messages. A		examining the response code field of DNS response messages. A
	NOERROR (rather than NXDOMAIN) code in that field will impact such		NOERROR (rather than NXDOMAIN) code in that field will impact such
	tools. Implementation of the optional response code restoration		tools. Implementation of the optional response code restoration
	scheme will help recover NXDOMAIN visibility for these tools. Note		scheme will help recover NXDOMAIN visibility for these tools. Note
	that the DNS header is not cryptographically protected, so the		that the DNS header is not cryptographically protected, so the
	response code field cannot be authenticated. Thus, inferring the		response code field cannot be authenticated. Thus, inferring the
	status of a response from signed data in the body of the DNS message		status of a response from signed data in the body of the DNS message
	is actually more secure. These tools could be enhanced to recognize		is actually more secure. These tools could be enhanced to recognize
	the (signed) NXNAME signal.		the (signed) NXNAME signal.
	Because this method does not allow for aggressive negative caching		Because this method does not allow for aggressive negative caching
	among resolvers, it allows for certain types of denial-of-service		among resolvers, it allows for certain types of denial-of-service
	attacks to be more effective. This includes so-called Pseudorandom		attacks to be more effective. This includes so-called Pseudorandom
	Subdomain Attacks [PRSD-ATTACK], where random names are queried,		Subdomain Attacks [PRSD-ATTACK], where random names are queried,
	either directly via botnets or across a wide range of public resolver		either directly via botnets or across a wide range of public resolver
	services, in order to intentionally generate non-existent responses		services, in order to intentionally generate nonexistent responses
	from the authoritative servers for a domain. If the resolver cannot		from the authoritative servers for a domain. If the resolver cannot
	synthesize NXDOMAIN responses from NSEC records, it must pass all		synthesize NXDOMAIN responses from NSEC records, it must pass all
	queries on to the domain's authority servers, making resource		queries on to the domain's authority servers, making resource
	exhaustion more likely at those latter servers if they do not have		exhaustion more likely at those latter servers if they do not have
	the capacity to absorb those additional queries.		the capacity to absorb those additional queries.
	If the motivating aspects of this specification (minimizing response		If the motivating aspects of this specification (minimizing response
	size and computational costs) are not a concern, DNSSEC deployments		size and computational costs) are not a concern, DNSSEC deployments
	can opt for a different method (e.g., traditional online signing or		can opt for a different method (e.g., conventional online signing or
	precomputed signatures) and avoid imposing the challenges of NXDOMAIN		precomputed signatures) and avoid imposing the challenges of NXDOMAIN
	visibility.		visibility.
	9. IANA Considerations		9. IANA Considerations
	IANA has allocated the following in the "Resource Record (RR) TYPEs"		IANA has allocated the following in the "Resource Record (RR) TYPEs"
	registry in the "Domain Name System (DNS) Parameters" registry group,		registry in the "Domain Name System (DNS) Parameters" registry group,
	from the range for Meta-TYPEs. A lower number in this range lowers		from the range for Meta-TYPEs. A lower number in this range lowers
	the size of the Type Bit Maps field, which reduces the overall size		the size of the Type Bit Maps field, which reduces the overall size
	of the DNS response message.		of the DNS response message.
	+========+=======+=============================+===========+		+========+=======+=============================+===========+
	| Type | Value | Meaning | Reference |		| Type | Value | Meaning | Reference |
	+========+=======+=============================+===========+		+========+=======+=============================+===========+
	| NXNAME | 128 | NXDOMAIN indicator for | RFC 9824 |		| NXNAME | 128 | NXDOMAIN indicator for | RFC 9824 |
	| | | Compact Denial of Existence | |		| | | Compact Denial of Existence | |
	+--------+-------+-----------------------------+-----------+		+--------+-------+-----------------------------+-----------+
	Table 3		Table 1
	IANA has also allocated the following 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. This flag is described in Section 5.1.		registry group. This flag is described in Section 5.1.
	+=======+======+====================+===========+		+=======+======+====================+===========+
	| Bit | Flag | Description | Reference |		| Bit | Flag | Description | Reference |
	+=======+======+====================+===========+		+=======+======+====================+===========+
	| Bit 1 | CO | Compact Answers OK | RFC 9824 |		| Bit 1 | CO | Compact Answers OK | RFC 9824 |
	+-------+------+--------------------+-----------+		+-------+------+--------------------+-----------+
	Table 4		Table 2
	Last, IANA has allocated the following code point in the "Extended		Last, IANA has allocated the following code point in the "Extended
	DNS Error Codes" registry in the "Domain Name System (DNS)		DNS Error Codes" registry in the "Domain Name System (DNS)
	Parameters" registry group. This code point is described in		Parameters" registry group. This code point is described in
	Section 3.5.		Section 3.5.
	+===========+====================+===========+		+===========+====================+===========+
	| INFO-CODE | Purpose | Reference |		| INFO-CODE | Purpose | Reference |
	+===========+====================+===========+		+===========+====================+===========+
	| 30 | Invalid Query Type | RFC 9824 |		| 30 | Invalid Query Type | RFC 9824 |
	+-----------+--------------------+-----------+		+-----------+--------------------+-----------+
	Table 5		Table 3
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at line 613 ¶		skipping to change at line 595 ¶
	Lawrence, "Extended DNS Errors", RFC 8914,		Lawrence, "Extended DNS Errors", RFC 8914,
	DOI 10.17487/RFC8914, October 2020,		DOI 10.17487/RFC8914, October 2020,
	<https://www.rfc-editor.org/info/rfc8914>.		<https://www.rfc-editor.org/info/rfc8914>.
	[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,		[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
	RFC 9364, DOI 10.17487/RFC9364, February 2023,		RFC 9364, DOI 10.17487/RFC9364, February 2023,
	<https://www.rfc-editor.org/info/rfc9364>.		<https://www.rfc-editor.org/info/rfc9364>.
	10.2. Informative References		10.2. Informative References
	[BLACK-LIES]		[COMPACT] Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of
	Valsorda, F. and O. Gudmundsson, "Compact DNSSEC Denial of
	Existence or Black Lies", Work in Progress, Internet-		Existence or Black Lies", Work in Progress, Internet-
	Draft, draft-valsorda-dnsop-black-lies-00, 21 March 2016,		Draft, draft-valsorda-dnsop-black-lies-00, 21 March 2016,
	<https://datatracker.ietf.org/doc/html/draft-valsorda-		<https://datatracker.ietf.org/doc/html/draft-valsorda-
	dnsop-black-lies-00>.		dnsop-black-lies-00>.
	[ENT-SENTINEL]		[ENT-SENTINEL]
	Huque, S., "Empty Non-Terminal Sentinel for Black Lies",		Huque, S., "Empty Non-Terminal Sentinel for Black Lies",
	Work in Progress, Internet-Draft, draft-huque-dnsop-		Work in Progress, Internet-Draft, draft-huque-dnsop-
	blacklies-ent-01, 27 July 2021,		blacklies-ent-01, 27 July 2021,
	<https://datatracker.ietf.org/doc/html/draft-huque-dnsop-		<https://datatracker.ietf.org/doc/html/draft-huque-dnsop-
	skipping to change at line 663 ¶		skipping to change at line 644 ¶
	DOI 10.17487/RFC8305, December 2017,		DOI 10.17487/RFC8305, December 2017,
	<https://www.rfc-editor.org/info/rfc8305>.		<https://www.rfc-editor.org/info/rfc8305>.
	[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,		[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
	RFC 9499, DOI 10.17487/RFC9499, March 2024,		RFC 9499, DOI 10.17487/RFC9499, March 2024,
	<https://www.rfc-editor.org/info/rfc9499>.		<https://www.rfc-editor.org/info/rfc9499>.
	Appendix A. Other Approaches		Appendix A. Other Approaches
	In the past, some implementations of Compact Denial of Existence have		In the past, some implementations of Compact Denial of Existence have
	used other means to differentiate NXDOMAIN from Empty Non-Terminals.		used other means to differentiate NXDOMAIN from ENTs.
	One method employed by both Cloudflare and Amazon Route53 for a		One method employed by both Cloudflare and Amazon Route53 for a
	period of time was the following: For responses to Empty Non-		period of time was the following: For responses to ENTs, they
	Terminals, they synthesized the NSEC Type Bit Maps to include all		synthesized the NSEC Type Bit Maps field to include all record types
	record types supported except for the queried type. This method has		supported except for the queried type. This method has the
	the undesirable effect of no longer being able to reliably determine		undesirable effect of no longer being able to reliably determine the
	the existence of ENTs and of making the Type Bit Maps field larger		existence of ENTs and of making the Type Bit Maps field larger than
	than it needs to be. It also has the potential to confuse validators		it needs to be. It also has the potential to confuse validators and
	and others tools that infer type existence from the NSEC record.		others tools that infer type existence from the NSEC record.
	Another way to distinguish NXDOMAIN from ENT is to define the		Another way to distinguish NXDOMAIN from ENT is to define the
	synthetic RR type for ENTs instead, as specified in [ENT-SENTINEL].		synthetic RR type for ENTs instead, as specified in [ENT-SENTINEL].
	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 since		period of time. This typically imposes less work on the server since
	NXDOMAIN responses are a lot more common than ENTs. At the time it		NXDOMAIN responses are a lot more common than ENTs. At the time it
	was deployed, it also allowed a common bitmap pattern ("NSEC RRSIG")		was deployed, it also allowed a common bitmap pattern ("NSEC RRSIG")
	to identify NXDOMAIN across this and other implementations that		to identify NXDOMAIN across this and other implementations that
	returned a broad bitmap pattern for Empty Non-Terminals. However,		returned a broad bitmap pattern for ENTs. However, the advantage of
	the advantage of the NXNAME RR type is that it explicitly identifies		the NXNAME RR type is that it explicitly identifies NXDOMAIN
	NXDOMAIN responses and allows them to be distinguished conclusively		responses and allows them to be distinguished conclusively from
	from potential ENT responses in other online signing NSEC		potential ENT responses in other online signing NSEC implementations.
	implementations.
	Appendix B. Historical Implementation Notes		Appendix B. Historical Implementation Notes
	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 [ENT-SENTINEL]
	[ENT-SENTINEL] using the private RR type code 65281. A version of		using the private RR type code 65281. A version of the NXNAME
	the NXNAME distinguisher using the private RR type code 65238 was		distinguisher using the private RR type code 65238 was deployed by
	deployed by both Cloudflare (from July 2023) and NS1 (from November		both Cloudflare (from July 2023) and NS1 (from November 2023) until
	2023) until roughly September 2024. Since September 2024, both		roughly September 2024. Since September 2024, both Cloudflare and
	Cloudflare and NS1 have deployed NXNAME using the officially		NS1 have deployed NXNAME using the officially allocated code point of
	allocated code point of 128. Oracle Cloud Initiative implemented		128. Oracle Cloud Initiative implemented Compact Denial of Existence
	Compact Denial of Existence using NSEC3 in October 2024.		using NSEC3 in October 2024.
	Acknowledgements		Acknowledgements
	The Compact Answers technique (then called "Black Lies") was		The Compact Answers technique was originally proposed in [COMPACT] by
	originally proposed in [BLACK-LIES] by Filippo Valsorda and Olafur		Filippo Valsorda and Olafur Gudmundsson and implemented by
	Gudmundsson and implemented by Cloudflare. The Empty Non-Terminal		Cloudflare. The ENT distinguisher RR type was originally proposed in
	distinguisher RR type was originally proposed in [ENT-SENTINEL] by		[ENT-SENTINEL] by Shumon Huque and deployed by NS1. The NXNAME type
	Shumon Huque and deployed by NS1. The NXNAME type is based on the		is based on the FDOM type proposed in [NXDOMAIN-TYPE] by Gudmundsson
	FDOM type proposed in [NXDOMAIN-TYPE] by Gudmundsson and Valsorda.		and Valsorda.
	Especially detailed discussions on many technical aspects of this		Especially detailed discussions on many technical aspects of this
	document were conducted with Paul Vixie, Jan Včelák, Viktor Dukhovni,		document were conducted with Paul Vixie, Jan Včelák, Viktor Dukhovni,
	Ed Lewis, and John Levine. The authors would also like to thank the		Ed Lewis, and John Levine. The authors would also like to thank the
	many other members of the IETF DNS Operations Working Group for		many other members of the IETF DNS Operations Working Group for
	helpful comments and discussions.		helpful comments and discussions.
	Authors' Addresses		Authors' Addresses
	Shumon Huque		Shumon Huque
	skipping to change at line 733 ¶		skipping to change at line 713 ¶
	Email: shuque@gmail.com		Email: shuque@gmail.com
	Christian Elmerot		Christian Elmerot
	Cloudflare		Cloudflare
	101 Townsend St.		101 Townsend St.
	San Francisco, CA 94107		San Francisco, CA 94107
	United States of America		United States of America
	Email: elmerot@cloudflare.com		Email: elmerot@cloudflare.com
	Olafur Gudmundsson		Olafur Gudmundsson
	Retired/Unaffiliated
	Email: ogud@ogud.com		Email: ogud@ogud.com
End of changes. 55 change blocks.
	158 lines changed or deleted		137 lines changed or added
This html diff was produced by rfcdiff 1.48.