rfc9874v1.txt		rfc9874.txt
	Internet Engineering Task Force (IETF) S. Hollenbeck		Internet Engineering Task Force (IETF) S. Hollenbeck
	Request for Comments: 9874 Verisign Labs		Request for Comments: 9874 W. Carroll
	BCP: 244 W. Carroll		BCP: 244 Verisign Labs
	Category: Best Current Practice Verisign		Category: Best Current Practice G. Akiwate
	ISSN: 2070-1721 G. Akiwate		ISSN: 2070-1721 Stanford University
	Stanford University
	September 2025		September 2025
	Best Practices for Deletion of Domain and Host Objects in the Extensible		Best Practices for Deletion of Domain and Host Objects in the Extensible
	Provisioning Protocol (EPP)		Provisioning Protocol (EPP)
	Abstract		Abstract
	The Extensible Provisioning Protocol (EPP) includes commands for		The Extensible Provisioning Protocol (EPP) includes commands for
	clients to delete domain and host objects, both of which are used to		clients to delete domain and host objects, both of which are used to
	publish information in the Domain Name System (DNS). EPP also		publish information in the Domain Name System (DNS). EPP also
	skipping to change at line 74 ¶		skipping to change at line 73 ¶
	3.3. Relational Consistency Considerations		3.3. Relational Consistency Considerations
	4. Host Object Renaming Risk		4. Host Object Renaming Risk
	5. Analysis of Practices for Domain and Host Object Deletion		5. Analysis of Practices for Domain and Host Object Deletion
	5.1. Renaming to Sacrificial Hosts		5.1. Renaming to Sacrificial Hosts
	5.1.1. Practice Benefits		5.1.1. Practice Benefits
	5.1.2. Practice Detriments		5.1.2. Practice Detriments
	5.1.3. Observed Practices for Renaming to Sacrificial Hosts		5.1.3. Observed Practices for Renaming to Sacrificial Hosts
	5.1.3.1. Renaming to External, Presumed Non-Existent Hosts		5.1.3.1. Renaming to External, Presumed Non-Existent Hosts
	5.1.3.1.1. Practice Benefits		5.1.3.1.1. Practice Benefits
	5.1.3.1.2. Practice Detriments		5.1.3.1.2. Practice Detriments
	5.1.3.2. Renaming to "as112.arpa"		5.1.3.2. Renaming to "AS112.ARPA"
	5.1.3.2.1. Practice Benefits		5.1.3.2.1. Practice Benefits
	5.1.3.2.2. Practice Detriments		5.1.3.2.2. Practice Detriments
	5.1.3.3. Renaming to Non-Authoritative Hosts		5.1.3.3. Renaming to Non-Authoritative Hosts
	5.1.3.3.1. Practice Benefits		5.1.3.3.1. Practice Benefits
	5.1.3.3.2. Practice Detriments		5.1.3.3.2. Practice Detriments
	5.1.3.4. Renaming to Client-Maintained Dedicated Sacrificial		5.1.3.4. Renaming to Client-Maintained Dedicated Sacrificial
	Name Server Host Objects		Name Server Host Objects
	5.1.3.4.1. Practice Benefits		5.1.3.4.1. Practice Benefits
	5.1.3.4.2. Practice Detriments		5.1.3.4.2. Practice Detriments
	5.1.4. Potential Practices for Renaming to Sacrificial Hosts		5.1.4. Potential Practices for Renaming to Sacrificial Hosts
	skipping to change at line 192 ¶		skipping to change at line 191 ¶
	not assigned to an account, then a malicious actor may add the domain		not assigned to an account, then a malicious actor may add the domain
	to a service account and gain control of (i.e., hijack) DNS		to a service account and gain control of (i.e., hijack) DNS
	resolution functionality. If the new external host offers recursive		resolution functionality. If the new external host offers recursive
	DNS service or no DNS service, then DNS requests for the domain will		DNS service or no DNS service, then DNS requests for the domain will
	result in SERVFAIL messages or other errors. Aggressive requeries by		result in SERVFAIL messages or other errors. Aggressive requeries by
	DNS resolvers may then create large numbers of spurious DNS queries		DNS resolvers may then create large numbers of spurious DNS queries
	for an unresolvable domain. Note that renaming a host object to a		for an unresolvable domain. Note that renaming a host object to a
	name of an external host cannot be reversed by the EPP client.		name of an external host cannot be reversed by the EPP client.
	This document describes the rationale for the "SHOULD NOT be deleted"		This document describes the rationale for the "SHOULD NOT be deleted"
	text and the risk associated with host object renaming. Section 5		text in [RFC5731] and [RFC5732] as well as the risk associated with
	includes a detailed analysis of the practices that have been and can		host object renaming. Section 5 includes a detailed analysis of the
	be used to mitigate that risk. Section 6 includes specific		practices that have been and can be used to mitigate that risk.
	recommendations for the best practices.		Section 6 includes specific recommendations for the best practices.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	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.
	3. Rationale for "SHOULD NOT be deleted"		3. Rationale for "SHOULD NOT be deleted"
	skipping to change at line 237 ¶		skipping to change at line 236 ¶
	inconsistency condition in which the EPP client and the EPP server		inconsistency condition in which the EPP client and the EPP server
	have different views of what remains registered after processing a		have different views of what remains registered after processing a
	<delete> command. The text in [RFC5731] and [RFC5732] was written to		<delete> command. The text in [RFC5731] and [RFC5732] was written to
	encourage clients to take singular, discrete steps to delete objects		encourage clients to take singular, discrete steps to delete objects
	in a way that maintains client-server data consistency. Experience		in a way that maintains client-server data consistency. Experience
	suggests that this inconsistency poses little operational risk.		suggests that this inconsistency poses little operational risk.
	3.3. Relational Consistency Considerations		3.3. Relational Consistency Considerations
	Implementations of EPP can have dependencies on the hierarchical		Implementations of EPP can have dependencies on the hierarchical
	domain object / host object relationship, as can exist in a		domain object / host object relationship, which can exist in a
	relational database. In such instances, deletion of a domain object		relational database. In such instances, deletion of a domain object
	without addressing the existing subordinate host objects can cause		without addressing the existing subordinate host objects can cause
	relational consistency and integrity issues. The text in [RFC5731]		relational consistency and integrity issues. The text in [RFC5731]
	and [RFC5732] was written to reduce the risk of these issues arising		and [RFC5732] was written to reduce the risk of these issues arising
	as a result of implicit object deletion.		as a result of implicit object deletion.
	4. Host Object Renaming Risk		4. Host Object Renaming Risk
	As described in [RFC5731], it is possible to delete a domain object		As described in [RFC5731], it is possible to delete a domain object
	that has associated host objects that are managed by other clients by		that has associated host objects that are managed by other clients by
	skipping to change at line 293 ¶		skipping to change at line 292 ¶
	risk of DNS resolution hijacking if someone were to register the		risk of DNS resolution hijacking if someone were to register the
	"example.org" domain and create a subordinate host object named		"example.org" domain and create a subordinate host object named
	"ns1.example.org". That name server would receive DNS queries for		"ns1.example.org". That name server would receive DNS queries for
	all domains delegated to it, allowing the operator of the name server		all domains delegated to it, allowing the operator of the name server
	to respond in potentially malicious ways.		to respond in potentially malicious ways.
	5. Analysis of Practices for Domain and Host Object Deletion		5. Analysis of Practices for Domain and Host Object Deletion
	EPP servers can employ a range of practices for domain and host		EPP servers can employ a range of practices for domain and host
	object deletion. Notably, the scope of any practice discussed here		object deletion. Notably, the scope of any practice discussed here
	is the EPP server that adopts the practice and the domains managed by		is the EPP server that adopts the practice, the domains managed by
	it. The practices described in this document fall into two broad		it, and the associated host objects where "associated" is described
	categories: renaming objects to use sacrificial hosts and allowing		in [RFC5731] and [RFC5732]. The practices described in this document
	objects to be deleted even if there are existing data relationships.		fall into two broad categories: renaming objects to use sacrificial
	These practice categories are described in the following sections.		hosts and allowing objects to be deleted even if there are existing
	For a broader consideration of practices and potential impacts on		data relationships. These practice categories are described in the
	registries and registrars, [SAC125] offers some complementary		following sections. For a broader consideration of practices and
	insight.		potential impacts on registries and registrars, [SAC125] offers some
			complementary insight.
	5.1. Renaming to Sacrificial Hosts		5.1. Renaming to Sacrificial Hosts
	Sacrificial hosts are hosts whose name is intended to remove an		Sacrificial hosts are hosts whose name is intended to remove an
	existing relationship between domain and host objects. To that end,		existing relationship between domain and host objects. To that end,
	sacrificial hosts are either renamed to an external host or		sacrificial hosts are either renamed to an external host or
	associated with a different domain object in the EPP server. The		associated with a different domain object in the EPP server. The
	first group of deletion practices use sacrificial hosts leveraging		first group of deletion practices use sacrificial hosts leveraging
	existing EPP server support for renaming host objects.		existing EPP server support for renaming host objects.
	skipping to change at line 351 ¶		skipping to change at line 351 ¶
	Malicious actors have registered these parent domains and created		Malicious actors have registered these parent domains and created
	child host objects to take control of DNS resolution for associated		child host objects to take control of DNS resolution for associated
	domains [Risky-BIZness].		domains [Risky-BIZness].
	Sponsoring clients of the associated domains are not informed of the		Sponsoring clients of the associated domains are not informed of the
	change. Associated domains may no longer resolve if all their hosts		change. Associated domains may no longer resolve if all their hosts
	are renamed. Associated domains may still resolve if they continue		are renamed. Associated domains may still resolve if they continue
	to be associated with existent hosts; in which case, their partial		to be associated with existent hosts; in which case, their partial
	vulnerability to hijacking is more difficult to detect.		vulnerability to hijacking is more difficult to detect.
	5.1.3.2. Renaming to "as112.arpa"		5.1.3.2. Renaming to "AS112.ARPA"
	Some domain registrars, acting as EPP clients, have renamed host		Some domain registrars, acting as EPP clients, have renamed host
	objects to subdomains of "as112.arpa" or "empty.as112.arpa"		objects to subdomains of "AS112.ARPA" or "EMPTY.AS112.ARPA"
	[Risky-BIZness-IRTF]. This practice has been observed in use.		[Risky-BIZness-IRTF]. This practice has been observed in use.
	5.1.3.2.1. Practice Benefits		5.1.3.2.1. Practice Benefits
	The primary benefit is convenience for the deleting EPP client. The		The primary benefit is convenience for the deleting EPP client. The
	deleting EPP client is not required to maintain an authoritative DNS		deleting EPP client is not required to maintain an authoritative DNS
	service or receive traffic.		service or receive traffic.
	5.1.3.2.2. Practice Detriments		5.1.3.2.2. Practice Detriments
	This is a misuse of AS112, which is for reverse lookups on non-unique		This is a misuse of AS112, which is for reverse lookups on non-unique
	IPs, primarily so local admins can sinkhole non-global traffic		IPs, primarily so local admins can sinkhole non-global traffic
	[RFC7535]. "empty.as112.arpa" is designed to be used with DNAME		[RFC7535]. "EMPTY.AS112.ARPA" is designed to be used with DNAME
	aliasing, not as a parent domain for sacrificial name servers (see		aliasing, not as a parent domain for sacrificial name servers (see
	Section 3 of [RFC7535]). Unexpected AS112 traffic has previously		Section 3 of [RFC7535]). Unexpected AS112 traffic has previously
	caused problems with intrusion detection systems and firewalls		caused problems with intrusion detection systems and firewalls
	[RFC6305]. Local administrators can potentially hijack requests.		[RFC6305]. Local administrators can potentially hijack requests.
	AS112 infrastructure must be maintained.		AS112 infrastructure must be maintained.
	5.1.3.3. Renaming to Non-Authoritative Hosts		5.1.3.3. Renaming to Non-Authoritative Hosts
	Some domain registrars, acting as EPP clients, have maintained host		Some domain registrars, acting as EPP clients, have maintained host
	objects with glue records pointing to prominent public recursive DNS		objects with glue records pointing to prominent public recursive DNS
	skipping to change at line 516 ¶		skipping to change at line 516 ¶
	these names as special or treat them differently than other		these names as special or treat them differently than other
	allowed domain names.		allowed domain names.
	4. Caching name servers are not expected to recognize these names as		4. Caching name servers are not expected to recognize these names as
	special or treat them differently than other allowed domain		special or treat them differently than other allowed domain
	names.		names.
	5. Authoritative name servers are not expected to recognize these		5. Authoritative name servers are not expected to recognize these
	names as special or treat them differently than other allowed		names as special or treat them differently than other allowed
	domain names. Requests to the root for this domain would result		domain names. Requests to the root for this domain would result
	in an NXDOMAIN response [RFC8499].		in an NXDOMAIN response [RFC9499].
	6. DNS server operators will treat this domain and its subdomains as		6. DNS server operators will treat this domain and its subdomains as
	they would any other allowed names in the DNS.		they would any other allowed names in the DNS.
	7. DNS registries/registrars will not be able to register this		7. DNS registries/registrars will not be able to register this
	domain and must deny requests to register it or its subdomains.		domain and must deny requests to register it or its subdomains.
	5.1.4.3.1. Practice Benefits		5.1.4.3.1. Practice Benefits
	This option would offer clarity concerning the intentions of		This option would offer clarity concerning the intentions of
	skipping to change at line 597 ¶		skipping to change at line 597 ¶
	5.2.1.1.1. Practice Benefits		5.2.1.1.1. Practice Benefits
	This is convenient for the deleting EPP client. The deleting EPP		This is convenient for the deleting EPP client. The deleting EPP
	client is not required to maintain an authoritative DNS service or		client is not required to maintain an authoritative DNS service or
	receive traffic. The associated domains are not vulnerable to		receive traffic. The associated domains are not vulnerable to
	hijacking.		hijacking.
	5.2.1.1.2. Practice Detriments		5.2.1.1.2. Practice Detriments
	This could result in domains with no remaining name servers being		This could result in domains with no name servers being removed from
	removed from the zone or domains with only one remaining name server.		the zone or domains with only one name server remaining in the zone.
	Deletions could potentially affect large numbers of associated		Deletions could potentially affect large numbers of associated
	domains, placing strain on domain registries.		domains, placing strain on domain registries.
	5.2.1.2. Inform Affected Clients		5.2.1.2. Inform Affected Clients
	The sponsoring clients of affected domain objects may also be		The sponsoring clients of affected domain objects may also be
	informed of the change (e.g., through the EPP Change Poll extension		informed of the change (e.g., through the EPP Change Poll extension
	[RFC8590]). This practice has been observed in use.		[RFC8590]). This practice has been observed in use.
	5.2.1.2.1. Practice Benefits		5.2.1.2.1. Practice Benefits
	skipping to change at line 640 ¶		skipping to change at line 640 ¶
	5.2.2.1.1. Practice Benefits		5.2.2.1.1. Practice Benefits
	Registries would not be required to unilaterally take responsibility		Registries would not be required to unilaterally take responsibility
	for deletion. The deleting EPP client is not required to maintain an		for deletion. The deleting EPP client is not required to maintain an
	authoritative DNS service or receive traffic. The associated domains		authoritative DNS service or receive traffic. The associated domains
	are not vulnerable to hijacking.		are not vulnerable to hijacking.
	5.2.2.1.2. Practice Detriments		5.2.2.1.2. Practice Detriments
	This could result in domains with no remaining name servers being		This could result in domains with no name servers being removed from
	removed from the zone or domains with only one remaining name server.		the zone or domains with only one name server remaining in the zone.
	Deletions could potentially affect large numbers of associated		Deletions could potentially affect large numbers of associated
	domains, placing strain on domain registries.		domains, placing strain on domain registries.
	5.2.2.2. Provide Additional Deletion Details		5.2.2.2. Provide Additional Deletion Details
	The EPP server may provide the deleting EPP client with additional		The EPP server may provide the deleting EPP client with additional
	details of the affected objects. The deleting EPP client may receive		details of the affected objects. The deleting EPP client may receive
	a response (e.g., using msg, reason, or msgQ elements of the EPP		a response (e.g., using msg, reason, or msgQ elements of the EPP
	response [RFC5730]) that deletion of the host object would affect		response [RFC5730]) that deletion of the host object would affect
	domain objects sponsored by another client and may receive details		domain objects sponsored by another client and may receive details
	skipping to change at line 854 ¶		skipping to change at line 854 ¶
	[RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson,		[RFC7535] Abley, J., Dickson, B., Kumari, W., and G. Michaelson,
	"AS112 Redirection Using DNAME", RFC 7535,		"AS112 Redirection Using DNAME", RFC 7535,
	DOI 10.17487/RFC7535, May 2015,		DOI 10.17487/RFC7535, May 2015,
	<https://www.rfc-editor.org/info/rfc7535>.		<https://www.rfc-editor.org/info/rfc7535>.
	[RFC8023] Thomas, M., Mankin, A., and L. Zhang, "Report from the		[RFC8023] Thomas, M., Mankin, A., and L. Zhang, "Report from the
	Workshop and Prize on Root Causes and Mitigation of Name		Workshop and Prize on Root Causes and Mitigation of Name
	Collisions", RFC 8023, DOI 10.17487/RFC8023, November		Collisions", RFC 8023, DOI 10.17487/RFC8023, November
	2016, <https://www.rfc-editor.org/info/rfc8023>.		2016, <https://www.rfc-editor.org/info/rfc8023>.
	[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", RFC 8499, DOI 10.17487/RFC8499, January
	2019, <https://www.rfc-editor.org/info/rfc8499>.
	[RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the		[RFC8590] Gould, J. and K. Feher, "Change Poll Extension for the
	Extensible Provisioning Protocol (EPP)", RFC 8590,		Extensible Provisioning Protocol (EPP)", RFC 8590,
	DOI 10.17487/RFC8590, May 2019,		DOI 10.17487/RFC8590, May 2019,
	<https://www.rfc-editor.org/info/rfc8590>.		<https://www.rfc-editor.org/info/rfc8590>.
			[RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
			RFC 9499, DOI 10.17487/RFC9499, March 2024,
			<https://www.rfc-editor.org/info/rfc9499>.
	[RFC9520] Wessels, D., Carroll, W., and M. Thomas, "Negative Caching		[RFC9520] Wessels, D., Carroll, W., and M. Thomas, "Negative Caching
	of DNS Resolution Failures", RFC 9520,		of DNS Resolution Failures", RFC 9520,
	DOI 10.17487/RFC9520, December 2023,		DOI 10.17487/RFC9520, December 2023,
	<https://www.rfc-editor.org/info/rfc9520>.		<https://www.rfc-editor.org/info/rfc9520>.
	[Risky-BIZness]		[Risky-BIZness]
	Akiwate, G., Savage, S., Voelker, G., and K. Claffy,		Akiwate, G., Savage, S., Voelker, G., and K. Claffy,
	"Risky BIZness: Risks Derived from Registrar Name		"Risky BIZness: Risks Derived from Registrar Name
	Management", IMC '21: Proceedings of the 21st ACM Internet		Management", IMC '21: Proceedings of the 21st ACM Internet
	Measurement Conference, DOI 10.1145/3487552.3487816,		Measurement Conference, DOI 10.1145/3487552.3487816,
	skipping to change at line 913 ¶		skipping to change at line 913 ¶
	Scott Hollenbeck		Scott Hollenbeck
	Verisign Labs		Verisign Labs
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	United States of America		United States of America
	Email: shollenbeck@verisign.com		Email: shollenbeck@verisign.com
	URI: https://www.verisignlabs.com/		URI: https://www.verisignlabs.com/
	William Carroll		William Carroll
	Verisign		Verisign Labs
	12061 Bluemont Way		12061 Bluemont Way
	Reston, VA 20190		Reston, VA 20190
	United States of America		United States of America
	Phone: +1 703 948-3200		Phone: +1 703 948-3200
	Email: wicarroll@verisign.com		Email: wicarroll@verisign.com
	URI: https://verisign.com		URI: https://verisign.com
	Gautam Akiwate		Gautam Akiwate
	Stanford University		Stanford University
	450 Jane Stanford Way		450 Jane Stanford Way
End of changes. 14 change blocks.
	32 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.48.