Diff: rfc9874.original.xml

	rfc9874.original.xml	rfc9874.xml
	<?xml version="1.0" encoding="utf-8"?>	<?xml version="1.0" encoding="utf-8"?>

	<?xml-model href="rfc7991bis.rnc"?>
	<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
	<!DOCTYPE rfc [	<!DOCTYPE rfc [

	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>


	<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="bcp" docName="draft-ie
		tf-regext-epp-delete-bcp-10" number="9874" ipr="trust200902" obsoletes="" update
	<?rfc tocInclude="yes"?>	s="" submissionType="IETF" xml:lang="en" version="3" consensus="true" tocInclude
	<?rfc tocDepth="7"?>	="true" tocDepth="5" sortRefs="true" symRefs="true">
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>


	<rfc
	xmlns:xi="http://www.w3.org/2001/XInclude"
	category="bcp"
	docName="draft-ietf-regext-epp-delete-bcp-10"
	ipr="trust200902"
	obsoletes=""
	updates=""
	submissionType="IETF"
	xml:lang="en"
	version="3"
	consensus="true"
	tocInclude="true"
	tocDepth="5"
	>
	<front>	<front>
	<title abbrev="Domain and Host Object Deletion in EPP">Best Practices fo r Deletion of Domain	<title abbrev="Domain and Host Object Deletion in EPP">Best Practices fo r Deletion of Domain
	and Host Objects in the Extensible Provisioning Protocol (EPP)</titl e>	and Host Objects in the Extensible Provisioning Protocol (EPP)</titl e>

		<!--[rfced] This document has been assigned a new BCP number.
		Please let us know if this is not correct (i.e., it should be part of an existin
		g BCP).

		See the complete list of BCPs here:
		https://www.rfc-editor.org/bcps
		-->

		<seriesInfo name="RFC" value="9874"/>
		<seriesInfo name="BCP" value="244"/>

		<!--[rfced] We note that Scott Hollenbeck and William Carroll have the same
		authors' address listed. However, Scott's organization is listed as "Verisign
		Labs", while William's is "Verisign". Should these be made consistent?
		-->

	<author initials="S." surname="Hollenbeck" fullname="Scott Hollenbeck">	<author initials="S." surname="Hollenbeck" fullname="Scott Hollenbeck">
	<organization>Verisign Labs</organization>	<organization>Verisign Labs</organization>
	<address>	<address>
	<postal>	<postal>
	<street>12061 Bluemont Way</street>	<street>12061 Bluemont Way</street>
	<city>Reston</city>	<city>Reston</city>
	<region>VA</region>	<region>VA</region>
	<code>20190</code>	<code>20190</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<email>shollenbeck@verisign.com</email>	<email>shollenbeck@verisign.com</email>
	<uri>https://www.verisignlabs.com/</uri>	<uri>https://www.verisignlabs.com/</uri>
	</address>	</address>
	</author>	</author>

	<author initials="W." surname="Carroll" fullname="William Carroll">	<author initials="W." surname="Carroll" fullname="William Carroll">
	<organization>Verisign</organization>	<organization>Verisign</organization>
	<address>	<address>
	<postal>	<postal>
	<street>12061 Bluemont Way</street>	<street>12061 Bluemont Way</street>
	<city>Reston</city>	<city>Reston</city>
	<region>VA</region>	<region>VA</region>
	<code>20190</code>	<code>20190</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone>+1 703 948-3200</phone>	<phone>+1 703 948-3200</phone>
	<email>wicarroll@verisign.com</email>	<email>wicarroll@verisign.com</email>
	<uri>https://verisign.com</uri>	<uri>https://verisign.com</uri>
	</address>	</address>
	</author>	</author>

	<author initials="G." surname="Akiwate" fullname="Gautam Akiwate">	<author initials="G." surname="Akiwate" fullname="Gautam Akiwate">
	<organization>Stanford University</organization>	<organization>Stanford University</organization>
	<address>	<address>
	<postal>	<postal>
	<street>450 Jane Stanford Way</street>	<street>450 Jane Stanford Way</street>
	<city>Stanford</city>	<city>Stanford</city>
	<region>CA</region>	<region>CA</region>
	<code>94305</code>	<code>94305</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>
	<phone>+1 650 723-2300</phone>	<phone>+1 650 723-2300</phone>
	<email>gakiwate@cs.stanford.edu</email>	<email>gakiwate@cs.stanford.edu</email>
	<uri>https://cs.stanford.edu/~gakiwate/</uri>	<uri>https://cs.stanford.edu/~gakiwate/</uri>
	</address>	</address>
	</author>	</author>


	<date />	<date month="September" year="2025"/>
	<area>Applications</area>	<area>ART</area>
	<workgroup>REGEXT Working Group</workgroup>	<workgroup>regext</workgroup>
	<keyword>EPP</keyword>	<keyword>EPP</keyword>
	<abstract>	<abstract>
	<t>The Extensible Provisioning Protocol (EPP) includes commands for clients to delete	<t>The Extensible Provisioning Protocol (EPP) includes commands for clients to delete
	domain and host objects, both of which are used to publish infor mation in the Domain	domain and host objects, both of which are used to publish infor mation in the Domain
	Name System (DNS). EPP also includes guidance for deletions that is intended	Name System (DNS). EPP also includes guidance for deletions that is intended
	to avoid DNS resolution disruptions and maintain data consistenc y. However,	to avoid DNS resolution disruptions and maintain data consistenc y. However,
	operational relationships between objects can make that guidance difficult to	operational relationships between objects can make that guidance difficult to
	implement. Some EPP clients have developed operational practices to delete those	implement. Some EPP clients have developed operational practices to delete those
	objects that have unintended impacts on DNS resolution and secur ity. This document	objects that have unintended impacts on DNS resolution and secur ity. This document
	describes best current practices and proposes new potential practices to delete	describes best current practices and proposes new potential practices to delete
	domain and host objects that reduce the risk of D NS resolution failure and maintain	domain and host objects that reduce the risk of D NS resolution failure and maintain
	client-server data consistency.</t>	client-server data consistency.</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>

	<section anchor="introduction" title="Introduction">	<section anchor="introduction"><name>Introduction</name>
	<t>Section 3.2.2 of RFC 5731 <xref target="RFC5731" /> contains text	<t><xref target="RFC5731" section="3.2.2"/> contains text that has l
	that has led some	ed some
	domain name registrars (acting as EPP clients) to adopt an opera tional practice of	domain name registrars (acting as EPP clients) to adopt an opera tional practice of

	re-naming name server host objects so that they can delete domai	renaming name server host objects so that they can delete domain
	n objects:</t>	objects:</t>
	<t>"A domain object <bcp14>SHOULD NOT</bcp14> be deleted if subordin
	ate host objects are associated	<blockquote><t>A domain object <bcp14>SHOULD NOT</bcp14> be delet
		ed if subordinate host objects are associated
	with the domain object. For example, if domain "example.com" exi sts and host object	with the domain object. For example, if domain "example.com" exi sts and host object
	"ns1.example.com" also exists, then domain "example.com" <bcp14> SHOULD NOT</bcp14> be deleted until	"ns1.example.com" also exists, then domain "example.com" <bcp14> SHOULD NOT</bcp14> be deleted until
	host "ns1.example.com" has either been deleted or renamed to exi st in a different	host "ns1.example.com" has either been deleted or renamed to exi st in a different

	superordinate domain."</t>	superordinate domain.</t></blockquote>
	<t>Similarly, Section 3.2.2 of RFC 5732 <xref target="RFC5732" /> co
	ntains this text	<t>Similarly, <xref target="RFC5732" section="3.2.2"/> contains this
		text
	regarding deletion of host objects:</t>	regarding deletion of host objects:</t>

	<t>"A host name object <bcp14>SHOULD NOT</bcp14> be deleted if the h
	ost object is associated with any	<blockquote><t>A host name object <bcp14>SHOULD NOT</bcp14> be delet
		ed if the host object is associated with any
	other object. For example, if the host object is associated with a domain object,	other object. For example, if the host object is associated with a domain object,
	the host object <bcp14>SHOULD NOT</bcp14> be deleted until the e xisting association has been	the host object <bcp14>SHOULD NOT</bcp14> be deleted until the e xisting association has been
	broken. Deleting a host object without first breaking existing a ssociations can	broken. Deleting a host object without first breaking existing a ssociations can
	cause DNS resolution failure for domain objects that refer to th e deleted host	cause DNS resolution failure for domain objects that refer to th e deleted host

	object."</t>	object.</t></blockquote>

	<t>These recommendations create a dilemma when the sponsoring client for "example.com"	<t>These recommendations create a dilemma when the sponsoring client for "example.com"
	intends to delete "example.com" but its associated host object " ns1.example.com" is	intends to delete "example.com" but its associated host object " ns1.example.com" is
	also associated with domain objects sponsored by another client. It is advised not	also associated with domain objects sponsored by another client. It is advised not
	to delete the host object due to its associated domain objects. However, the	to delete the host object due to its associated domain objects. However, the
	associated domain objects cannot be directly updated because the y are sponsored by	associated domain objects cannot be directly updated because the y are sponsored by
	another client. This situation affects all EPP operators that ha ve implemented	another client. This situation affects all EPP operators that ha ve implemented
	support for host objects.</t>	support for host objects.</t>

	<t>Section 3.2.5 of RFC 5732 <xref target="RFC5732" /> describes hos	<t><xref target="RFC5732" section="3.2.5"/> describes host object re
	t object renaming:</t>	naming:</t>
	<t>"Host name changes can have an impact on associated objects that
	refer to the host	<blockquote><t>Host name changes can have an impact on associated ob
		jects that refer to the host
	object. A host name change <bcp14>SHOULD NOT</bcp14> require add itional updates of associated	object. A host name change <bcp14>SHOULD NOT</bcp14> require add itional updates of associated
	objects to preserve existing associations, with one exception: c hanging an external	objects to preserve existing associations, with one exception: c hanging an external
	host object that has associations with objects that are sponsore d by a different	host object that has associations with objects that are sponsore d by a different

	client. Attempts to update such hosts directly MUST fail with EP P error code 2305.	client. Attempts to update such hosts directly <bcp14>MUST</bcp1 4> fail with EPP error code 2305.
	The change can be provisioned by creating a new external host wi th a new name and	The change can be provisioned by creating a new external host wi th a new name and
	any needed new attributes, and subsequently updating the other o bjects sponsored by	any needed new attributes, and subsequently updating the other o bjects sponsored by

	the client."</t>	the client.</t></blockquote>
	<t>Section 1.1 of RFC 5732 includes a description of external hosts.	<t><xref target="RFC5732" section="1.1"/> includes a description of
	Some EPP	external hosts. Some EPP
	clients have developed operational practices that use host objec t renaming to break	clients have developed operational practices that use host objec t renaming to break
	association between a domain object and host object. Note that t he specific	association between a domain object and host object. Note that t he specific
	method used to rename the host object can create DNS delegation failures and introduce	method used to rename the host object can create DNS delegation failures and introduce
	risks of loss of management control. If the new external host re fers	risks of loss of management control. If the new external host re fers
	to an unregistered domain, then a malicious actor may register t he domain and create	to an unregistered domain, then a malicious actor may register t he domain and create
	the host object to gain control of DNS resolution for the domain previously associated	the host object to gain control of DNS resolution for the domain previously associated
	with "ns1.example.com". If the new external host offers an autho ritative DNS service but	with "ns1.example.com". If the new external host offers an autho ritative DNS service but
	the domain is not assigned to an account, then a malicious actor may add the domain	the domain is not assigned to an account, then a malicious actor may add the domain

	to a service account and gain control of (hijack) DNS resolution functionality. If the	to a service account and gain control of (i.e., hijack) DNS reso lution functionality. If the
	new external host	new external host
	offers recursive DNS service or no DNS service, then DNS request s for the domain	offers recursive DNS service or no DNS service, then DNS request s for the domain

	will result in SERVFAIL messages or other errors. Aggressive re- queries by DNS	will result in SERVFAIL messages or other errors. Aggressive req ueries by DNS
	resolvers may then create large numbers of spurious DNS queries for an unresolvable	resolvers may then create large numbers of spurious DNS queries for an unresolvable
	domain. Note that renaming a host object to a name of an externa l host cannot be	domain. Note that renaming a host object to a name of an externa l host cannot be

	reversed by the EPP client.</t>	reversed by the EPP client.</t>

		<!--[rfced] For clarity, may we add citations to [RFC5731] and [RFC5732] in
		this sentence?

		Original:
		This document describes the rationale for the "SHOULD NOT be deleted"
		text and the risk associated with host object renaming.

		Perhaps:
		This document describes the rationale for the "SHOULD NOT be deleted"
		text in [RFC5731] and [RFC5732] as well as the risk associated with
		host object renaming.
		-->

	<t>This document describes the rationale for the "<bcp14>SHOULD NOT< /bcp14> be deleted" text and the risk	<t>This document describes the rationale for the "<bcp14>SHOULD NOT< /bcp14> be deleted" text and the risk
	associated with host object renaming. <xref target="practice-ana lysis" /> includes a detailed analysis	associated with host object renaming. <xref target="practice-ana lysis" /> includes a detailed analysis
	of the practices that have been and can be used to mitigate that risk.	of the practices that have been and can be used to mitigate that risk.
	<xref target="recommendations" /> includes specific recommendati ons for the best practices.</t>	<xref target="recommendations" /> includes specific recommendati ons for the best practices.</t>
	</section>	</section>

	<section title="Conventions Used in This Document">	<section><name>Conventions Used in This Document</name>
	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "	<t>
	<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	bcp14>SHOULD</bcp14>", "<bcp14>SHOULD	IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMEN	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	DED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this docume	RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	nt are	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	to be interpreted as described in BCP 14 <xref target="RFC2119"	be interpreted as
	/> <xref	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	target="RFC8174" /> when, and only when, they appear in all	when, and only when, they appear in all capitals, as shown here.
	capitals, as shown	</t>
	here.</t>
	</section>	</section>

	<section anchor="rationale" title='Rationale for "SHOULD NOT be deleted"	<section anchor="rationale"><name>Rationale for "<bcp14>SHOULD NOT</bcp1
	'>	4> be deleted"</name>
	<section anchor="dns-cons" title="DNS Considerations">	<section anchor="dns-cons"><name>DNS Considerations</name>

		<!-- [rfced] FYI - Some sentences cite RFCs 5731 and 5732 but did not
		include cite tags. We have added cite tags to these citations. For example:

		Original:
		The text in RFCs 5731 and 5732 was written to
		encourage clients to take singular, discrete steps to delete objects
		in a way that avoids breaking DNS resolution functionality.

		Current:
		The text in [RFC5731] and [RFC5732] was written to
		encourage clients to take singular, discrete steps to delete objects
		in a way that avoids breaking DNS resolution functionality.
		-->

	<t>The primary consideration when deleting domain and host objec ts concerns the	<t>The primary consideration when deleting domain and host objec ts concerns the
	potential impact on DNS resolution. Deletion of a domain obj ect will make all	potential impact on DNS resolution. Deletion of a domain obj ect will make all
	name servers associated with subordinate host objects unreso lvable. Deletion of	name servers associated with subordinate host objects unreso lvable. Deletion of
	a host object will make any domain that has been delegated t o the associated	a host object will make any domain that has been delegated t o the associated

	name server unresolvable. The text in RFCs 5731 and 5732 was written to	name server unresolvable. The text in <xref target="RFC5731" /> and <xref target="RFC5732"/> was written to
	encourage clients to take singular, discrete steps to delete objects in a way	encourage clients to take singular, discrete steps to delete objects in a way
	that avoids breaking DNS resolution functionality. Additiona lly, allowing host	that avoids breaking DNS resolution functionality. Additiona lly, allowing host
	objects to exist after deletion of their superordinate domai n object invites	objects to exist after deletion of their superordinate domai n object invites

	hijacking, as a malicious actor may re-register the domain o bject, potentially	hijacking, as a malicious actor may reregister the domain ob ject, potentially
	controlling resolution for the host objects and for their as sociated domain	controlling resolution for the host objects and for their as sociated domain

	objects. It also creates orphan glue as described in SAC048 (<xref target="SAC048" />).</t>	objects. It also creates orphan glue as described in <xref t arget="SAC048"/>.</t>
	</section>	</section>

	<section anchor="client-server-cons" title="Client-Server Consistenc y Considerations">	<section anchor="client-server-cons"><name>Client-Server Consistency Considerations</name>
	<t>A server that implicitly deletes subordinate host objects in response to a	<t>A server that implicitly deletes subordinate host objects in response to a
	request to delete a domain object can create a data inconsis tency condition in	request to delete a domain object can create a data inconsis tency condition in
	which the EPP client and the EPP server have different views of what remains	which the EPP client and the EPP server have different views of what remains

	registered after processing a <delete> command. The te	registered after processing a <delete> command. The te
	xt in RFCs 5731 and	xt in <xref target="RFC5731"/> and
	5732 was written to encourage clients to take singular, disc	<xref target="RFC5732"/> was written to encourage clients to
	rete steps to delete	take singular, discrete steps to delete
	objects in a way that maintains client-server data consisten cy. Experience	objects in a way that maintains client-server data consisten cy. Experience
	suggests that this inconsistency poses li ttle operational risk.</t>	suggests that this inconsistency poses li ttle operational risk.</t>
	</section>	</section>

	<section anchor="relational-cons" title="Relational Consistency Cons	<section anchor="relational-cons"><name>Relational Consistency Consi
	iderations">	derations</name>

		<!--[rfced] To improve readability, may we update "as can" to "which can"
		below?

		Original:
		Implementations of EPP can have dependencies on the hierarchical
		domain object/host object relationship, as can exist in a relational
		database.

		Perhaps:
		Implementations of EPP can have dependencies on the hierarchical
		domain object/host object relationship, which can exist in a relational
		database.
		-->

	<t>Implementations of EPP can have dependencies on the hierarchi cal domain	<t>Implementations of EPP can have dependencies on the hierarchi cal domain

	object/host object relationship, as can exist in a relationa l database. In such	object / host object relationship, as can exist in a relatio nal database. In such
	instances, deletion of a domain object without addressing th e existing	instances, deletion of a domain object without addressing th e existing
	subordinate host objects can cause relational consistency an d integrity issues.	subordinate host objects can cause relational consistency an d integrity issues.

	The text in RFCs 5731 and 5732 was written to reduce the ris k of these issues	The text in <xref target="RFC5731"/> and <xref target="RFC57 32"/> was written to reduce the risk of these issues
	arising as a result of implicit object deletion.</t>	arising as a result of implicit object deletion.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="renaming-risk" title="Host Object Renaming Risk">	<section anchor="renaming-risk"><name>Host Object Renaming Risk</name>
	<t>As described in RFC 5731, it is possible to delete a domain objec	<t>As described in <xref target="RFC5731"/>, it is possible to delet
	t that has associated	e a domain object that has associated
	host objects that are managed by other clients by renaming the h ost object to exist	host objects that are managed by other clients by renaming the h ost object to exist
	in a different superordinate domain. This is commonly required w hen the sponsoring	in a different superordinate domain. This is commonly required w hen the sponsoring
	client is unable to disassociate a host object from a domain obj ect managed by	client is unable to disassociate a host object from a domain obj ect managed by
	another client because only the second client is authorized to m ake changes to their	another client because only the second client is authorized to m ake changes to their
	domain object and the EPP server requires host object disassocia tion to process a	domain object and the EPP server requires host object disassocia tion to process a
	request to delete a domain object. For example:</t>	request to delete a domain object. For example:</t>
	<t>Domain object "domain1.example" is registered by ClientX.</t>	<t>Domain object "domain1.example" is registered by ClientX.</t>
	<t>Domain object "domain2.example" is registered by ClientY.</t>	<t>Domain object "domain2.example" is registered by ClientY.</t>
	<t>Subordinate host object "ns1.domain1.example" is registered and a ssociated with	<t>Subordinate host object "ns1.domain1.example" is registered and a ssociated with
	domain object "domain1.example" by ClientX.</t>	domain object "domain1.example" by ClientX.</t>
	<t>Host object "ns1.domain1.example" is associated with domain objec t "domain2.example"	<t>Host object "ns1.domain1.example" is associated with domain objec t "domain2.example"
	by ClientY.</t>	by ClientY.</t>
	<t>ClientX wishes to delete domain object "domain1.example". It can modify domain object	<t>ClientX wishes to delete domain object "domain1.example". It can modify domain object
	"domain1.example" to remove the association of host object "ns1. domain1.example",	"domain1.example" to remove the association of host object "ns1. domain1.example",
	but	but
	ClientX cannot remove the association of host object "ns1.domain 1.example" from	ClientX cannot remove the association of host object "ns1.domain 1.example" from
	domain	domain
	object "domain2.example" because "domain2.example" is sponsored by ClientY and	object "domain2.example" because "domain2.example" is sponsored by ClientY and
	ClientX is unable to determine that relationship. Only ClientY c an	ClientX is unable to determine that relationship. Only ClientY c an

	modify domain object "domain2.example", and if they do not do so ClientX will need	modify domain object "domain2.example", and if they do not do so , ClientX will need
	to	to
	rename host object "ns1.domain1.example" so that "domain1.exampl e" can be deleted.</t>	rename host object "ns1.domain1.example" so that "domain1.exampl e" can be deleted.</t>
	<t>ClientX renames host object "ns1.domain1.example" to "ns1.example .org", creating an	<t>ClientX renames host object "ns1.domain1.example" to "ns1.example .org", creating an
	external host and meeting the EPP server's subordinate host obje ct disassociation	external host and meeting the EPP server's subordinate host obje ct disassociation
	requirement. The renamed host object "ns1.example.org" is referr ed to as a "sacrificial"	requirement. The renamed host object "ns1.example.org" is referr ed to as a "sacrificial"

	host <xref target="risky-bizness" />.</t>	host <xref target="Risky-BIZness" />.</t>
	<t>If domain "example.org" does not exist, this practice introduces a risk of DNS	<t>If domain "example.org" does not exist, this practice introduces a risk of DNS
	resolution hijacking if someone were to register the "example.or g" domain and create	resolution hijacking if someone were to register the "example.or g" domain and create
	a subordinate	a subordinate
	host object named "ns1.example.org". That name server would rece ive DNS queries for	host object named "ns1.example.org". That name server would rece ive DNS queries for
	all domains delegated to it, allowing the operator of the name s erver to respond in	all domains delegated to it, allowing the operator of the name s erver to respond in
	potentially malicious ways.</t>	potentially malicious ways.</t>
	</section>	</section>

	<section anchor="practice-analysis"	<section anchor="practice-analysis"><name>Analysis of Practices for Doma
	title="Analysis of Practices for Domain and Host Object Deletion"	in and Host Object Deletion</name>
	>
	<t>EPP servers can employ a range of practices for domain	<t>EPP servers can employ a range of practices for domain
	and host object deletion. Notably, the scope of any practice	and host object deletion. Notably, the scope of any practice
	discussed here is the EPP server that adopts the practice and th e	discussed here is the EPP server that adopts the practice and th e
	domains managed by it. The practices described in this document fall into two broad	domains managed by it. The practices described in this document fall into two broad

	categories: renaming objects to use "sacrificial" hosts, and all owing objects to be	categories: renaming objects to use sacrificial hosts and allowi ng objects to be
	deleted even if there are existing data relationships. These pra ctice categories are	deleted even if there are existing data relationships. These pra ctice categories are
	described in the following sections.	described in the following sections.
	For a broader consideration of practices and potential impacts o n registries and registrars,	For a broader consideration of practices and potential impacts o n registries and registrars,
	<xref target="SAC125" />	<xref target="SAC125" />
	offers some complementary insight.	offers some complementary insight.
	</t>	</t>

	<section anchor="renaming-overall" title="Renaming to Sacrificial Ho	<section anchor="renaming-overall"><name>Renaming to Sacrificial Hos
	sts">	ts</name>
	<t>"Sacrificial" hosts are hosts whose name is intended to remov	<t>Sacrificial hosts are hosts whose name is intended to remove
	e an existing relationship	an existing relationship
	between domain and host objects. To that end, "sacrificial" host	between domain and host objects. To that end, sacrificial hosts
	s are either renamed to an	are either renamed to an
	external host or associated with a different domain object in th e EPP server.	external host or associated with a different domain object in th e EPP server.
	The first group of deletion practices use sacrificial	The first group of deletion practices use sacrificial
	hosts leveraging existing EPP server support for renaming host objects.</t>	hosts leveraging existing EPP server support for renaming host objects.</t>

	<section anchor="renaming-overall-pros" title="Practice Benefits ">	<section anchor="renaming-overall-pros"><name>Practice Benefits< /name>
	<t>Affected domains remain delegated in the zone. Registrars and	<t>Affected domains remain delegated in the zone. Registrars and
	registrants of affected domains may be able to determine the intention	registrants of affected domains may be able to determine the intention
	of the change.</t>	of the change.</t>
	</section>	</section>

	<section anchor="renaming-overall-cons" title="Practice Detrimen ts">	<section anchor="renaming-overall-cons"><name>Practice Detriment s</name>
	<t>Zones are crowded with irrelevant records. Registrars and registrants of affected domains are required to clean them up.</t>	<t>Zones are crowded with irrelevant records. Registrars and registrants of affected domains are required to clean them up.</t>
	</section>	</section>

	<section anchor="renaming-observed" title="Observed Practices fo	<section anchor="renaming-observed"><name>Observed Practices for
	r Renaming to Sacrificial Hosts">	Renaming to Sacrificial Hosts</name>
	<section anchor="renaming-external"	<section anchor="renaming-external"><name>Renaming to Extern
	title="Renaming to External, Presumed Non-Existent Hosts	al, Presumed Non-Existent Hosts</name>
	">
	<t>As described above, this practice renames subordinate host objects to an	<t>As described above, this practice renames subordinate host objects to an
	external host in order to allow the deletion of the superordinate domain object.	external host in order to allow the deletion of the superordinate domain object.
	The	The

	external host is presumed to be non-existent by the deleting EPP client but	external host is presumed to be non-existent by the deleting EPP client, but
	no check for existence is typically performed.	no check for existence is typically performed.
	This practice has been observed in use. This practic e <bcp14>MUST NOT</bcp14> be used.	This practice has been observed in use. This practic e <bcp14>MUST NOT</bcp14> be used.
	</t>	</t>

	<section anchor="renaming-external-pros" title="Practice Benefits">	<section anchor="renaming-external-pros"><name>Practice Benefits</name>
	<t>The primary benefit is convenience for the deleti ng EPP client. The deleting	<t>The primary benefit is convenience for the deleti ng EPP client. The deleting
	EPP client is not required to	EPP client is not required to
	maintain an authoritative DNS service or receive traffic.</t>	maintain an authoritative DNS service or receive traffic.</t>
	</section>	</section>

	<section anchor="renaming-external-cons" title="Practice Detriments">	<section anchor="renaming-external-cons"><name>Practice Detriments</name>
	<t>Malicious actors have registered these parent dom ains and	<t>Malicious actors have registered these parent dom ains and
	created child host objects to take control of DN S resolution	created child host objects to take control of DN S resolution

	for associated domains <xref target="risky-bizne ss" />.</t>	for associated domains <xref target="Risky-BIZne ss" />.</t>
	<t>Sponsoring clients of the associated domains are not informed of the change.	<t>Sponsoring clients of the associated domains are not informed of the change.
	Associated domains may no longer resolve if all their hosts are renamed.	Associated domains may no longer resolve if all their hosts are renamed.
	Associated domains may still resolve if they con tinue to be associated with	Associated domains may still resolve if they con tinue to be associated with

	existent hosts, in which case their partial vuln erability to hijacking is	existent hosts; in which case, their partial vul nerability to hijacking is
	more difficult to detect.</t>	more difficult to detect.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="renaming-as112" title='Renaming to "as112.a rpa"'>	<section anchor="renaming-as112"><name>Renaming to "as112.ar pa"</name>
	<t>Some domain registrars, acting as EPP clients, have r enamed host objects	<t>Some domain registrars, acting as EPP clients, have r enamed host objects
	to subdomains of "as112.arpa" or "empty.as112.arpa" <xref	to subdomains of "as112.arpa" or "empty.as112.arpa" <xref

	target="risky-bizness-irtf" />.	target="Risky-BIZness-IRTF" />.
	This practice has been observed in use.	This practice has been observed in use.
	</t>	</t>

	<section anchor="renaming-as112-pros" title="Practice Be nefits">	<section anchor="renaming-as112-pros"><name>Practice Ben efits</name>
	<t>	<t>
	The primary benefit is convenience for the delet ing EPP client. The deleting	The primary benefit is convenience for the delet ing EPP client. The deleting
	EPP client is	EPP client is
	not required to	not required to
	maintain an authoritative DNS service or receive traffic.	maintain an authoritative DNS service or receive traffic.
	</t>	</t>
	</section>	</section>

	<section anchor="renaming-as112-cons" title="Practice De	<section anchor="renaming-as112-cons"><name>Practice Det
	triments">	riments</name>

		<!-- [rfced] We note that [RFC7535] uses "EMPTY.AS112.ARPA" rather
		than "empty.as112.arpa". Should this be updated to match [RFC7535]?

		Current:
		"empty.as112.arpa" is designed to be used with DNAME aliasing, not
		as a parent domain for sacrificial name servers (see Section 3 of
		[RFC7535]).
		-->
	<t> This is a misuse of AS112, which is for reverse lookups on non-unique IPs,	<t> This is a misuse of AS112, which is for reverse lookups on non-unique IPs,
	primarily so local admins can sinkhole non-globa l traffic <xref	primarily so local admins can sinkhole non-globa l traffic <xref
	target="RFC7535" />.	target="RFC7535" />.

	The "empty.as112.arpa" is designed to be used wi	"empty.as112.arpa" is designed to be used with D
	th DNAME aliasing, not as a parent domain for sacrificial name servers (see sect	NAME aliasing, not as a parent domain for sacrificial name servers (see <xref
	ion 3 of <xref	target="RFC7535" section="3"/>).
	target="RFC7535" />).
	Unexpected AS112 traffic has previously caus ed	Unexpected AS112 traffic has previously caus ed
	problems with intrusion detection systems and fi rewalls <xref	problems with intrusion detection systems and fi rewalls <xref
	target="RFC6305" />. Local administrators ca n potentially hijack	target="RFC6305" />. Local administrators ca n potentially hijack
	requests. AS112 infrastructure must be maintaine d. </t>	requests. AS112 infrastructure must be maintaine d. </t>
	</section>	</section>
	</section>	</section>

	<section anchor="renaming-non-provisioned" title="Renaming t o Non-Authoritative Hosts">	<section anchor="renaming-non-provisioned"><name>Renaming to Non-Authoritative Hosts</name>
	<t>Some domain registrars, acting as EPP clients, have m aintained host objects	<t>Some domain registrars, acting as EPP clients, have m aintained host objects
	with glue records pointing to prominent public recur sive DNS services.	with glue records pointing to prominent public recur sive DNS services.
	This practice has been observed in use. This practic e <bcp14>MUST NOT</bcp14> be used.	This practice has been observed in use. This practic e <bcp14>MUST NOT</bcp14> be used.
	</t>	</t>

	<section anchor="renaming-non-provisioned-pros" title="P ractice Benefits">	<section anchor="renaming-non-provisioned-pros"><name>Pr actice Benefits</name>
	<t>The primary benefit is convenience for the deleti ng EPP client. The deleting	<t>The primary benefit is convenience for the deleti ng EPP client. The deleting
	EPP client is	EPP client is
	not required to	not required to
	maintain an authoritative DNS service or receive traffic. </t>	maintain an authoritative DNS service or receive traffic. </t>
	</section>	</section>

	<section anchor="renaming-non-provisioned-cons" title="P ractice Detriments">	<section anchor="renaming-non-provisioned-cons"><name>Pr actice Detriments</name>
	<t> Queries for the associated domains result in SER VFAIL or other failure	<t> Queries for the associated domains result in SER VFAIL or other failure
	responses. Some recursive name server implementa tions may aggressively	responses. Some recursive name server implementa tions may aggressively

	re-query for these responses, potentially result ing in large numbers of	requery for these responses, potentially resulti ng in large numbers of
	queries for unresolvable domains <xref target="R FC9520" />.</t>	queries for unresolvable domains <xref target="R FC9520" />.</t>
	</section>	</section>
	</section>	</section>

	<section anchor="control-rename" title="Renaming to Client-M	<section anchor="control-rename"><name>Renaming to Client-Ma
	aintained Dedicated Sacrificial Name Server Host Objects">	intained Dedicated Sacrificial Name Server Host Objects</name>
	<t>EPP clients MAY rename the host object to be deleted	<t>EPP clients <bcp14>MAY</bcp14> rename the host object
	to a	to be deleted to a
	sacrificial name server host object maintained by the cl ient. This	sacrificial name server host object maintained by the cl ient. This
	requires that the client maintain the registration of th e sacrificial	requires that the client maintain the registration of th e sacrificial
	name server's superordinate domain. The client may cons ider long	name server's superordinate domain. The client may cons ider long
	registration periods and the use of registrar and regist ry lock	registration periods and the use of registrar and regist ry lock
	services to maintain and protect the superordinate domai n and the	services to maintain and protect the superordinate domai n and the
	host object. Failures to maintain these registrations h ave allowed	host object. Failures to maintain these registrations h ave allowed
	domain hijacks <xref	domain hijacks <xref

	target="risky-bizness" />.	target="Risky-BIZness"/>.
	</t>	</t>
	<t>	<t>

	The client-maintained dedicated sacrificial name server <bcp14>MUST</bcp14> resolve to one or more IP addresses	The client-maintained dedicated sacrificial name server <bcp14>MUST</bcp14> resolve to one or more IP addresses,
	and the client <bcp14>MUST</bcp14> operate an authoritat ive DNS name server on those addresses.	and the client <bcp14>MUST</bcp14> operate an authoritat ive DNS name server on those addresses.
	The name server <bcp14>MAY</bcp14> provide any valid res ponse.	The name server <bcp14>MAY</bcp14> provide any valid res ponse.
	</t>	</t>
	<t>	<t>
	This practice has been observed in use.	This practice has been observed in use.
	</t>	</t>

	<section anchor="control-rename-pros" title="Practice Be nefits">	<section anchor="control-rename-pros"><name>Practice Ben efits</name>
	<t> Associated domains are not able to be hijacked, remain in the zone, and have	<t> Associated domains are not able to be hijacked, remain in the zone, and have
	valid DNS records and a responsive DNS service. The service may provide	valid DNS records and a responsive DNS service. The service may provide
	responses that indicate problems with a domain's delegation, such as	responses that indicate problems with a domain's delegation, such as

	non-existence or include controlled interruption IP addresses <xref	non-existence or including controlled interrupti on IP addresses <xref
	target="RFC8023" />. </t>	target="RFC8023" />. </t>
	</section>	</section>

	<section anchor="control-rename-cons" title="Practice De triments">	<section anchor="control-rename-cons"><name>Practice Det riments</name>
	<t>This requires that the client maintain the regist ration of the sacrificial	<t>This requires that the client maintain the regist ration of the sacrificial
	name server's superordinate domain. The client m ay consider long	name server's superordinate domain. The client m ay consider long
	registration periods and the use of registrar an d registry lock services to	registration periods and the use of registrar an d registry lock services to
	maintain and protect the superordinate domain an d the host object. Failures	maintain and protect the superordinate domain an d the host object. Failures
	to maintain these registrations have allowed dom ain hijacks <xref	to maintain these registrations have allowed dom ain hijacks <xref

	target="risky-bizness" />.	target="Risky-BIZness"/>.
	</t>	</t>
	<t>Failure responses may cause aggressive requerying (see <xref target="renaming-non-provisioned-cons" />).</t>	<t>Failure responses may cause aggressive requerying (see <xref target="renaming-non-provisioned-cons" />).</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="renaming-potential" title="Potential Practices	<section anchor="renaming-potential"><name>Potential Practices f
	for Renaming to Sacrificial Hosts">	or Renaming to Sacrificial Hosts</name>
	<section anchor="renaming-pseudo-tld" title="Renaming to Pse	<section anchor="renaming-pseudo-tld"><name>Renaming to Pseu
	udo-TLD">	do-TLD</name>
	<t>Clients may rename host objects to use ".alt" or anot	<t>Clients may rename host objects to use ".alt" or anot
	her non-DNS pseudo-TLD as suggested in <xref target="risky-bizness-irtf" />.	her non-DNS pseudo-TLD (Top-Level Domain), as suggested in <xref target="Risky-B
		IZness-IRTF"/>.
	This practice has not been observed in use. This pra ctice <bcp14>MUST NOT</bcp14> be used.	This practice has not been observed in use. This pra ctice <bcp14>MUST NOT</bcp14> be used.
	</t>	</t>

	<section anchor="renaming-pseudo-tld-pros" title="Practi ce Benefits">	<section anchor="renaming-pseudo-tld-pros"><name>Practic e Benefits</name>
	<t>The primary benefit is convenience for the deleti ng	<t>The primary benefit is convenience for the deleti ng
	EPP client. The deleting EPP client is not requi red to	EPP client. The deleting EPP client is not requi red to
	maintain an authoritative DNS service or receive	maintain an authoritative DNS service or receive
	traffic. Dependent domains cannot be hijacked th rough	traffic. Dependent domains cannot be hijacked th rough
	the registration of these identifiers and delega tion in	the registration of these identifiers and delega tion in
	the DNS.</t>	the DNS.</t>
	</section>	</section>

	<section anchor="renaming-pseudo-tld-cons" title="Practi ce Detriments">	<section anchor="renaming-pseudo-tld-cons"><name>Practic e Detriments</name>
	<t>The ".alt" pseudo-TLD is to be used "to signify t hat this is an alternative	<t>The ".alt" pseudo-TLD is to be used "to signify t hat this is an alternative
	(non-DNS) namespace and should not be looked up in a DNS context" <xref	(non-DNS) namespace and should not be looked up in a DNS context" <xref
	target="RFC9476" />. Some EPP servers may re strict TLDs to valid	target="RFC9476" />. Some EPP servers may re strict TLDs to valid
	IANA-delegated TLDs. These entries would mix DNS and non-DNS protocols, risk	IANA-delegated TLDs. These entries would mix DNS and non-DNS protocols, risk
	name collisions, create confusion, and potential ly result in unpredictable	name collisions, create confusion, and potential ly result in unpredictable
	resolver behaviors. These identifiers may be reg istered in non-DNS	resolver behaviors. These identifiers may be reg istered in non-DNS
	namespaces, potentially leading to hijacking vul nerabilities based in other	namespaces, potentially leading to hijacking vul nerabilities based in other
	systems. </t>	systems. </t>
	</section>	</section>
	</section>	</section>

	<section anchor="renaming-existing-special-use" title="Renam ing to Existing Special-Use TLD">	<section anchor="renaming-existing-special-use"><name>Renami ng to Existing Special-Use TLD</name>
	<t>Clients may rename host objects to a special-use TLD that cannot resolve in the DNS. Several variations have been suggested.	<t>Clients may rename host objects to a special-use TLD that cannot resolve in the DNS. Several variations have been suggested.
	This practice has not been observed in use.</t>	This practice has not been observed in use.</t>

	<section anchor="renaming-existing-special-use-reserved"	<section anchor="renaming-existing-special-use-reserved"
	title="Renaming to Reserved TLD">	><name>Renaming to Reserved TLD</name>
	<t>Clients may rename host objects to use a reserved	<t>Clients may rename host objects to use a reserved
	special-use (<xref target="RFC6761" />) TLD	special-use <xref target="RFC6761"/> TLD,
	as suggested in <xref target="risky-bizness" />.	as suggested in <xref target="Risky-BIZness" />.
	</t>	</t>
	<section anchor="renaming-existing-special-use-pros"	<section anchor="renaming-existing-special-use-pros"
	title="Practice Benefits">	><name>Practice Benefits</name>
	<t>The primary benefit is convenience for the de leting	<t>The primary benefit is convenience for the de leting
	EPP client. These TLDs are already reserved and will not	EPP client. These TLDs are already reserved and will not
	resolve. The deleting EPP client is not requ ired to	resolve. The deleting EPP client is not requ ired to
	maintain an authoritative DNS service or rec eive	maintain an authoritative DNS service or rec eive
	traffic. Dependent domains cannot be hijacke d.</t>	traffic. Dependent domains cannot be hijacke d.</t>
	</section>	</section>

	<section anchor="renaming-existing-special-use-cons"	<section anchor="renaming-existing-special-use-cons"
	title="Practice Detriments">	><name>Practice Detriments</name>
	<t>The use of TLDs reserved for special purposes	<t>The use of TLDs reserved for special purposes
	(<xref target="RFC6761" />) may be confusing without a	<xref target="RFC6761"/> may be confusing without a
	domain designated by the community for this purp ose	domain designated by the community for this purp ose

	(see "sacrificial.invalid" in <xref target="rena ming-new-special-use" /> and <xref target="recommendations" />).	(see "sacrificial.invalid" in Sections <xref tar get="renaming-new-special-use" format="counter"/> and <xref target="recommendati ons" format="counter"/>).
	In addition, their use may be prevented by EPP s erver policy.</t>	In addition, their use may be prevented by EPP s erver policy.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="renaming-new-special-use" title="Renaming t o a Special-Use Domain">	<section anchor="renaming-new-special-use"><name>Renaming to a Special-Use Domain</name>
	<t>	<t>
	Clients would rename hosts to a special-use domain o r subdomain thereof.	Clients would rename hosts to a special-use domain o r subdomain thereof.

	The domain may be a special-use SLD (e.g., sacrifici al.invalid) or a new reserved TLD (e.g., .sacrificial).	The domain may be a special-use SLD (Second-Level Do main) (e.g., sacrificial.invalid) or a new reserved TLD (e.g., .sacrificial).
	Use of this domain would communicate the client's in tention to create a sacrificial host.	Use of this domain would communicate the client's in tention to create a sacrificial host.
	IANA would add this domain to the "Special-Use Domai n Name" registry if such a new TLD is created using either	IANA would add this domain to the "Special-Use Domai n Name" registry if such a new TLD is created using either
	IETF or ICANN processes. This practice has not been observed in use.	IETF or ICANN processes. This practice has not been observed in use.
	In terms of the questions from <xref target="RFC6761 " />:	In terms of the questions from <xref target="RFC6761 " />:
	</t>	</t>
	<ol type="1" spacing="normal" indent="adaptive" start="1 ">	<ol type="1" spacing="normal" indent="adaptive" start="1 ">
	<li derivedCounter="1.">	<li derivedCounter="1.">
	These names are not expected to be visible to hu man users.	These names are not expected to be visible to hu man users.
	However, the purpose of these domains is expecte d to be semantically recognizable to human users.	However, the purpose of these domains is expecte d to be semantically recognizable to human users.
	</li>	</li>

	skipping to change at line 438 ¶	skipping to change at line 491 ¶
	Name resolution APIs and libraries are not expec ted to recognize	Name resolution APIs and libraries are not expec ted to recognize
	these names as special or treat them differently than other allowed domain names.	these names as special or treat them differently than other allowed domain names.
	</li>	</li>
	<li derivedCounter="4.">	<li derivedCounter="4.">
	Caching name servers are not expected to recogni ze these names	Caching name servers are not expected to recogni ze these names
	as special or treat them differently than other allowed domain names.	as special or treat them differently than other allowed domain names.
	</li>	</li>
	<li derivedCounter="5.">	<li derivedCounter="5.">
	Authoritative name servers are not expected to r ecognize	Authoritative name servers are not expected to r ecognize
	these names as special or treat them differently than other allowed domain names.	these names as special or treat them differently than other allowed domain names.

	Requests to the root for this domain would resul t in NXDOMAIN response <xref target="RFC8499" />.	Requests to the root for this domain would resul t in an NXDOMAIN response <xref target="RFC8499" />.
	</li>	</li>
	<li derivedCounter="6.">	<li derivedCounter="6.">
	DNS server operators will treat this domain and its subdomains as they would any other allowed names in the DNS.	DNS server operators will treat this domain and its subdomains as they would any other allowed names in the DNS.
	</li>	</li>
	<li derivedCounter="7.">	<li derivedCounter="7.">

	DNS Registries/Registrars will not be able to re gister this domain and must deny requests to register it or its subdomains.	DNS registries/registrars will not be able to re gister this domain and must deny requests to register it or its subdomains.
	</li>	</li>
	</ol>	</ol>

	<section anchor="renaming-new-special-use-pros" titl e="Practice Benefits">	<section anchor="renaming-new-special-use-pros"><nam e>Practice Benefits</name>
	<t>	<t>
	This option would offer clarity concerning t he intentions of registrars that rename hosts.	This option would offer clarity concerning t he intentions of registrars that rename hosts.
	It would also enable registrars of affected domains ease of detection of renamed hosts.	It would also enable registrars of affected domains ease of detection of renamed hosts.
	This option is also convenient for the delet ing EPP client.	This option is also convenient for the delet ing EPP client.
	The deleting EPP client is not required to	The deleting EPP client is not required to
	maintain an authoritative DNS service or rec eive	maintain an authoritative DNS service or rec eive
	traffic.	traffic.
	Dependent domains cannot be hijacked through	Dependent domains cannot be hijacked through
	the registration of these identifiers and de legation in	the registration of these identifiers and de legation in
	the DNS.	the DNS.
	</t>	</t>
	</section>	</section>

	<section anchor="renaming-new-special-use-cons" titl e="Practice Detriments">	<section anchor="renaming-new-special-use-cons"><nam e>Practice Detriments</name>
	<t>	<t>
	This would require cooperation and policy ch anges for registrars and registries.	This would require cooperation and policy ch anges for registrars and registries.
	</t>	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="new-service" title="Renaming to Community S acrificial Name Server Service">	<section anchor="new-service"><name>Renaming to Community Sa crificial Name Server Service</name>
	<t>A new community-wide service could be created explici tly intended for use for	<t>A new community-wide service could be created explici tly intended for use for
	renaming host records. This would require maintenanc e of name servers capable of	renaming host records. This would require maintenanc e of name servers capable of
	authoritatively responding with NXDOMAIN or a contro lled interruption IP	authoritatively responding with NXDOMAIN or a contro lled interruption IP
	addresses <xref target="RFC8023" /> for all queries without delegating domains	addresses <xref target="RFC8023" /> for all queries without delegating domains

	or records. This service could use a new special-use TLD created either through	or records. This service could use a new special-use TLD created through
	ICANN or IETF processes (e.g., ".sacrificial"), as a n IAB request that IANA	ICANN or IETF processes (e.g., ".sacrificial"), as a n IAB request that IANA

	delegate a second-level domain (SLD) for ".arpa" (e. g.,	delegate an SLD for ".arpa" (e.g.,
	"sacrificial-nameserver.arpa"), or as a contracted s inkhole service by ICANN or	"sacrificial-nameserver.arpa"), or as a contracted s inkhole service by ICANN or
	other DNS ecosystem actors. This practice has not be en observed in use.</t>	other DNS ecosystem actors. This practice has not be en observed in use.</t>

	<section anchor="new-service-pros" title="Practice Benef its">	<section anchor="new-service-pros"><name>Practice Benefi ts</name>
	<t>This is convenient for the deleting EPP client. T he deleting EPP client is	<t>This is convenient for the deleting EPP client. T he deleting EPP client is
	not required to	not required to
	maintain an authoritative DNS service or receive traffic. The associated	maintain an authoritative DNS service or receive traffic. The associated
	domains are not vulnerable to hijacking.	domains are not vulnerable to hijacking.
	This would provide a well-understood, industry-s tandard solution, allowing	This would provide a well-understood, industry-s tandard solution, allowing
	registrars and registrants to easily identify as sociated domains that have	registrars and registrants to easily identify as sociated domains that have
	been affected. Infrastructure operators could mo nitor traffic to identify	been affected. Infrastructure operators could mo nitor traffic to identify
	affected associated domains that result in signi ficant traffic and attempt	affected associated domains that result in signi ficant traffic and attempt
	to contact registrars and registrants.	to contact registrars and registrants.
	Economies of scale would allow reduced overall c osts to the industry (in	Economies of scale would allow reduced overall c osts to the industry (in
	contrast to each client running an independent s ervice).</t>	contrast to each client running an independent s ervice).</t>
	</section>	</section>

	<section anchor="new-service-cons" title="Practice Detri ments">	<section anchor="new-service-cons"><name>Practice Detrim ents</name>
	<t>Some entity must maintain the infrastructure for the service.</t>	<t>Some entity must maintain the infrastructure for the service.</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="delete-overall" title="Deletion of Hosts">	<section anchor="delete-overall"><name>Deletion of Hosts</name>
	<t>The second group of practices is based on EPP server support for allowing objects to be deleted	<t>The second group of practices is based on EPP server support for allowing objects to be deleted

	even if there are existing data relationships. The recommendatio ns in RFC 5731 <xref target="RFC5731" /> are intended to	even if there are existing data relationships. The recommendatio ns in <xref target="RFC5731"/> are intended to
	maintain consistency. However, they are not requirements. </t>	maintain consistency. However, they are not requirements. </t>

	<section anchor="delete-observed" title="Observed Practices for	<section anchor="delete-observed"><name>Observed Practices for D
	Deletion of Hosts">	eletion of Hosts</name>
	<section anchor="automatic-delete" title="Implicit Delete of	<section anchor="automatic-delete"><name>Implicit Deletion o
	Affected Host Objects">	f Affected Host Objects</name>
	<t> EPP servers may relax	<t> EPP servers may relax
	their constraints and allow sponsoring clients to de lete host objects without consideration of	their constraints and allow sponsoring clients to de lete host objects without consideration of
	associations with domain objects sponsored by other clients. The registry automatically	associations with domain objects sponsored by other clients. The registry automatically
	disassociates the deleted host objects from domain o bjects sponsored by other clients.	disassociates the deleted host objects from domain o bjects sponsored by other clients.
	This practice has been observed in use.	This practice has been observed in use.
	</t>	</t>

	<section anchor="automatic-delete-pros" title="Practice Benefits">	<section anchor="automatic-delete-pros"><name>Practice B enefits</name>
	<t>	<t>
	This is convenient for the deleting EPP client. The deleting EPP client is	This is convenient for the deleting EPP client. The deleting EPP client is
	not required to	not required to
	maintain an authoritative DNS service or receive traffic. The associated	maintain an authoritative DNS service or receive traffic. The associated
	domains are not vulnerable to hijacking.	domains are not vulnerable to hijacking.
	</t>	</t>
	</section>	</section>

	<section anchor="automatic-delete-cons" title="Practice	<section anchor="automatic-delete-cons"><name>Practice D
	Detriments">	etriments</name>

		<!--[rfced] Does "removed from the zone" apply to both "domains with
		no remaining name servers" and "domains with only one remaining name
		server"? If yes, may we update this sentence as follows? Note that this
		sentence occurs in Sections 5.2.1.1.2 and 5.2.2.1.2.

		Original:
		This could result in domains with no remaining name servers being
		removed from the zone or domains with only one remaining name server.

		Perhaps:
		This could result in domains with no remaining name servers or
		with only one remaining name server being removed from the zone.
		-->

	<t>This could	<t>This could
	result in domains with no remaining name servers being removed from the zone	result in domains with no remaining name servers being removed from the zone
	or	or
	domains with only one remaining name server.	domains with only one remaining name server.
	Deletions could potentially affect large numbers of associated domains,	Deletions could potentially affect large numbers of associated domains,
	placing strain on domain registries.	placing strain on domain registries.
	</t>	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="inform-affected-client" title="Inform Affec ted Clients">	<section anchor="inform-affected-client"><name>Inform Affect ed Clients</name>
	<t> The sponsoring clients of affected domain objects ma y also be informed of	<t> The sponsoring clients of affected domain objects ma y also be informed of
	the change (e.g., through the EPP Change Poll extens ion <xref target="RFC8590" />).	the change (e.g., through the EPP Change Poll extens ion <xref target="RFC8590" />).
	This practice has been observed in use.	This practice has been observed in use.
	</t>	</t>

	<section anchor="inform-affected-client-pros" title="Pra ctice Benefits">	<section anchor="inform-affected-client-pros"><name>Prac tice Benefits</name>
	<t>Updates help achieve the goals of client-server d ata consistency	<t>Updates help achieve the goals of client-server d ata consistency
	and minimal interruptions to resolution.	and minimal interruptions to resolution.
	The sponsoring clients of affected domain object s are able to	The sponsoring clients of affected domain object s are able to
	update their database to reflect the change and would be able to inform	update their database to reflect the change and would be able to inform
	the domain's registrant.	the domain's registrant.
	The sponsoring clients can automatically update the	The sponsoring clients can automatically update the
	affected domains to use another authoritative ho st. </t>	affected domains to use another authoritative ho st. </t>
	</section>	</section>

	<section anchor="inform-affected-client-cons" title="Pra ctice Detriments">	<section anchor="inform-affected-client-cons"><name>Prac tice Detriments</name>
	<t>	<t>
	This change requires additional development on t he part of EPP	This change requires additional development on t he part of EPP
	servers and clients. There may be scalability co ncerns if large numbers	servers and clients. There may be scalability co ncerns if large numbers
	of domain objects are updated in a single transa ction.	of domain objects are updated in a single transa ction.
	</t>	</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="delete-potential" title="Potential Practices fo	<section anchor="delete-potential"><name>Potential Practices for
	r Deletion of Hosts">	Deletion of Hosts</name>
	<section anchor="explicit-delete" title="Request Explicit De	<section anchor="explicit-delete"><name>Request Explicit Del
	lete of Affected Host Objects">	etion of Affected Host Objects</name>
	<t>Sponsoring clients requesting the deletion of host ob jects would explicitly request	<t>Sponsoring clients requesting the deletion of host ob jects would explicitly request
	their disassociation from domain objects sponsored b y other clients.	their disassociation from domain objects sponsored b y other clients.
	This practice has not been observed in use.	This practice has not been observed in use.
	</t>	</t>

	<section anchor="explicit-delete-pros" title="Practice B enefits">	<section anchor="explicit-delete-pros"><name>Practice Be nefits</name>
	<t>	<t>
	Registries would not be required to unilaterally take responsibility for deletion.	Registries would not be required to unilaterally take responsibility for deletion.
	The deleting EPP client is not required to maint ain an authoritative DNS service or receive traffic.	The deleting EPP client is not required to maint ain an authoritative DNS service or receive traffic.
	The associated domains are not vulnerable to hij acking.	The associated domains are not vulnerable to hij acking.
	</t>	</t>
	</section>	</section>

	<section anchor="explicit-delete-cons" title="Practice D etriments">	<section anchor="explicit-delete-cons"><name>Practice De triments</name>
	<t>This could result in domains with no remaining na me servers being removed from the zone or domains with only one remaining name s erver.	<t>This could result in domains with no remaining na me servers being removed from the zone or domains with only one remaining name s erver.
	Deletions could potentially affect large numbers of associated domains,	Deletions could potentially affect large numbers of associated domains,
	placing strain on domain registries.	placing strain on domain registries.
	</t>	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="additional-deletion-details" title="Provide Additional Deletion Details">	<section anchor="additional-deletion-details"><name>Provide Additional Deletion Details</name>
	<t>The EPP server may provide the deleting EPP client wi th additional details of the affected	<t>The EPP server may provide the deleting EPP client wi th additional details of the affected

	objects. The deleting EPP client may receive a respo nse (e.g., using msg, reason, msgQ elements of the EPP response <xref target="RF C5730" />)	objects. The deleting EPP client may receive a respo nse (e.g., using msg, reason, or msgQ elements of the EPP response <xref target= "RFC5730" />)
	that deletion of the host object would affect	that deletion of the host object would affect
	domain objects sponsored by another client and may r eceive details about those objects (e.g., using the EPP poll command).	domain objects sponsored by another client and may r eceive details about those objects (e.g., using the EPP poll command).
	This practice has not been observed in use.	This practice has not been observed in use.
	</t>	</t>

	<section anchor="additional-deletion-details-pros" title ="Practice Benefits">	<section anchor="additional-deletion-details-pros"><name >Practice Benefits</name>
	<t>	<t>
	The deleting EPP client would be able to better understand and assess	The deleting EPP client would be able to better understand and assess
	the potential harms of host object deletion.	the potential harms of host object deletion.
	Depending on the content of the message, the del eting EPP client might	Depending on the content of the message, the del eting EPP client might
	choose additional actions, such as delaying the deletion until manual	choose additional actions, such as delaying the deletion until manual
	approval can be obtained, renaming the host obje cts, or informing	approval can be obtained, renaming the host obje cts, or informing
	affected EPP clients.	affected EPP clients.
	This would give EPP clients greater flexibility with respect to	This would give EPP clients greater flexibility with respect to
	deletion. For example, they may choose only to e xercise deletions that	deletion. For example, they may choose only to e xercise deletions that
	have no impact on other clients.	have no impact on other clients.
	</t>	</t>
	</section>	</section>

	<section anchor="additional-deletion-details-cons" title ="Practice Detriments">	<section anchor="additional-deletion-details-cons"><name >Practice Detriments</name>
	<t>	<t>
	This change would require additional development on the part of EPP	This change would require additional development on the part of EPP
	servers and clients. There may be scalability co ncerns if large numbers	servers and clients. There may be scalability co ncerns if large numbers
	of domain objects are updated in a single transa ction. The EPP server	of domain objects are updated in a single transa ction. The EPP server
	must	must
	determine the relevant information to provide fo r the EPP client's	determine the relevant information to provide fo r the EPP client's
	assessment.	assessment.
	</t>	</t>
	</section>	</section>
	</section>	</section>

	<section anchor="delete-with-restore" title="Allow Explicit Delete of Domain with Restore Capability">	<section anchor="delete-with-restore"><name>Allow Explicit D eletion of a Domain with Restore Capability</name>
	<t>	<t>
	Explicit deletion of a domain name with a	Explicit deletion of a domain name with a
	cascade purge of subordinate host objects and associ ations	cascade purge of subordinate host objects and associ ations
	with other domains may be an unrecoverable operation , increasing	with other domains may be an unrecoverable operation , increasing
	the potential negative effects of malicious or accid ental actions.	the potential negative effects of malicious or accid ental actions.
	</t>	</t>
	<t>	<t>
	To mitigate this risk, EPP servers can allow for the explicit deletion of a domain with	To mitigate this risk, EPP servers can allow for the explicit deletion of a domain with
	subordinate host objects associated with other domai ns only when the	subordinate host objects associated with other domai ns only when the

	associations can be restored by the <restore> operation described in RFC 3915 <xref target="RFC3915" />.	associations can be restored by the <restore> operation described in <xref target="RFC3915"/>.
	</t>	</t>
	<t>	<t>
	In order to allow restore, EPP servers may keep the subordinate host objects with a "pendingDelete" status	In order to allow restore, EPP servers may keep the subordinate host objects with a "pendingDelete" status
	and keep associations with other domains. This makes the objects unavailable in the DNS and	and keep associations with other domains. This makes the objects unavailable in the DNS and
	provides a preview of the deletion.	provides a preview of the deletion.
	</t>	</t>
	<t>	<t>
	If the action was malicious, accidental, or had	If the action was malicious, accidental, or had
	negative side effects, the domain, its subordinate h ost objects, and	negative side effects, the domain, its subordinate h ost objects, and
	the associations with other domains can be restored with the	the associations with other domains can be restored with the

	<restore> operation in RFC 3915 during the red emption period. The	<restore> operation <xref target="RFC3915"/> d uring the redemption period. The
	purge of the domain will correspond with the purging of the	purge of the domain will correspond with the purging of the
	subordinate hosts objects and the associations at th e end of the	subordinate hosts objects and the associations at th e end of the

	pending delete period in RFC 3915.	pending delete period <xref target="RFC3915"/>.
	</t>	</t>
	<t>	<t>
	Due to the potentially large	Due to the potentially large
	number of associations, the server can asynchronousl y update (e.g.,	number of associations, the server can asynchronousl y update (e.g.,
	add and remove from DNS) and purge the associations.	add and remove from DNS) and purge the associations.
	</t>	</t>
	<t>	<t>
	This practice has not been observed in use.	This practice has not been observed in use.
	</t>	</t>

	<section anchor="delete-with-restore-pros" title="Practi ce Benefits">	<section anchor="delete-with-restore-pros"><name>Practic e Benefits</name>
	<t>	<t>
	This practice enables the clients to directly de lete the domains that	This practice enables the clients to directly de lete the domains that
	they need since the server will fully support re storation of the	they need since the server will fully support re storation of the
	associations during the redemption period. The management of the	associations during the redemption period. The management of the
	domain and the subordinate hosts will be simplif ied for the client by	domain and the subordinate hosts will be simplif ied for the client by
	supporting the explicit deletion of the domain w ith the capability of	supporting the explicit deletion of the domain w ith the capability of
	mitigating a destructive malicious or accidental action.	mitigating a destructive malicious or accidental action.
	</t>	</t>
	</section>	</section>

	<section anchor="delete-with-restore-cons" title="Practi ce Detriments">	<section anchor="delete-with-restore-cons"><name>Practic e Detriments</name>
	<t>	<t>
	By making it easier for a client to explicitly d elete a domain having subordinate hosts	By making it easier for a client to explicitly d elete a domain having subordinate hosts
	with associations, there is higher risk of inadv ertent side effects in a single delete command.	with associations, there is higher risk of inadv ertent side effects in a single delete command.
	There is existing risk in EPP of inadvertent sid e effects, such as adding the "clientHold"	There is existing risk in EPP of inadvertent sid e effects, such as adding the "clientHold"
	status to the domain that will impact the DNS re solution of the subordinate hosts and the	status to the domain that will impact the DNS re solution of the subordinate hosts and the

	associated delegations. The ability to easily ro llback the command is key to minimize the	associated delegations. The ability to easily ro ll back the command is key to minimize the
	impact of the side effects. Another issue is the potential size of the database transaction to	impact of the side effects. Another issue is the potential size of the database transaction to
	disable, re-enable, or purge the subordinate hos t associations, since there is no limit to the	disable, re-enable, or purge the subordinate hos t associations, since there is no limit to the

	number of associations to delegated domains. Ser vers can break-up the disable, re-enable, or purge	number of associations to delegated domains. Ser vers can break up the disable, re-enable, or purge
	of the subordinate host associations into smalle r transactions by implementing it asynchronously.	of the subordinate host associations into smalle r transactions by implementing it asynchronously.
	</t>	</t>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	</section>	</section>
	</section>	</section>

	<section anchor="recommendations" title="Recommendations">	<section anchor="recommendations"><name>Recommendations</name>
	<t>EPP servers and clients <bcp14>MUST</bcp14> implement one of the following practices to delete domain and host objects with minimal undesired sid e effects:</t>	<t>EPP servers and clients <bcp14>MUST</bcp14> implement one of the following practices to delete domain and host objects with minimal undesired sid e effects:</t>
	<ul>	<ul>
	<li>Rename host objects to a sacrificial name server host object maintained by the client	<li>Rename host objects to a sacrificial name server host object maintained by the client

	(see <xref target="control-rename" format="counter" />).	(see <xref target="control-rename"/>).
	</li>	</li>
	<li>	<li>

	Delete host objects and associations with the restore optio	Delete host objects and associations with the restore optio
	n (see <xref target="delete-with-restore" format="counter" />)	n (see <xref target="delete-with-restore"/>)
	based on explicit client requests (see <xref target="explic	based on explicit client requests (see <xref target="explic
	it-delete" format="counter" />).	it-delete"/>).
	Provide requesting clients additional deletion details (see	Provide requesting clients additional deletion details (see
	<xref target="additional-deletion-details" format="counter" />)	<xref target="additional-deletion-details"/>),
	and inform affected clients of changes (see <xref target="i	and inform affected clients of changes (see <xref target="i
	nform-affected-client" format="counter" />).	nform-affected-client"/>).
	</li>	</li>
	<li>	<li>

	Rename host objects to a sacrificial name server host object	Rename host objects to a sacrificial name server host object
	that uses a special-use domain (see <xref target="renaming-new-special-use" for	that uses a special-use domain (see <xref target="renaming-new-special-use"/>)
	mat="counter" />)	that avoids the special-use domain issues described in <xref
	that avoids the special-use domain issues described in <xref	target="RFC8244"/>. Use of "sacrificial.invalid" (see <xref
	target="RFC8244" />. Use of "sacrificial.invalid" (see <xref	target="renaming-new-special-use"/>) as the parent domain fo
	target="renaming-new-special-use" format="counter" />) as th	r the host objects is
	e parent domain for the host objects is
	<bcp14>RECOMMENDED</bcp14> to avoid the overhead of creating a new TLD using either IETF or ICANN processes	<bcp14>RECOMMENDED</bcp14> to avoid the overhead of creating a new TLD using either IETF or ICANN processes
	that offers no additional operational benefit.	that offers no additional operational benefit.
	</li>	</li>
	</ul>	</ul>
	<t>All other practices described in <xref target="practice-analysi s" /> are <bcp14>NOT RECOMMENDED</bcp14> due to undesired side effects.</t>	<t>All other practices described in <xref target="practice-analysi s" /> are <bcp14>NOT RECOMMENDED</bcp14> due to undesired side effects.</t>
	</section>	</section>


	<section anchor="IANA" title="IANA Considerations">	<section anchor="IANA"><name>IANA Considerations</name>
	<t>This document does not contain any instructions for IANA.</t>	<t>This document has no IANA actions.</t>
	</section>	</section>


	<section anchor="Security" title="Security Considerations">	<section anchor="Security"><name>Security Considerations</name>
	<t>This document describes guidance found in RFCs 5731 and 5732 rega	<t>This document describes guidance found in <xref target="RFC5731"/
	rding the deletion	> and <xref target="RFC5732"/> regarding the deletion
	of domain and host objects by EPP clients. That guidance sometim es requires that	of domain and host objects by EPP clients. That guidance sometim es requires that

	host objects be renamed such that they become "external" hosts (	host objects be renamed such that they become "external" hosts (
	see Section 1.1 of	see
	RFC 5731 <xref target="RFC5731" />) in order to meet an EPP serv	<xref target="RFC5731" section="1.1"/>) in order to meet an EPP
	er's requirements	server's requirements
	for host object disassociation prior to domain object deletion. Host object renaming	for host object disassociation prior to domain object deletion. Host object renaming
	can introduce a risk of DNS resolution hijack under certain oper ational	can introduce a risk of DNS resolution hijack under certain oper ational
	conditions. This document provides guidance that is intended to reduce the risk of	conditions. This document provides guidance that is intended to reduce the risk of
	DNS resolution failure or hijacking as part of the process of de leting EPP domain or	DNS resolution failure or hijacking as part of the process of de leting EPP domain or
	host objects.</t>	host objects.</t>

	<t>Child domains that depend on host objects associated with domain objects sponsored by	<t>Child domains that depend on host objects associated with domain objects sponsored by
	another EPP client for DNS resolution may be protected from hija cking through the use	another EPP client for DNS resolution may be protected from hija cking through the use
	of DNSSEC. Their resolution may be protected from the effects of deletion by using	of DNSSEC. Their resolution may be protected from the effects of deletion by using
	host objects associated with multiple domain objects. DNSSEC and multiple	host objects associated with multiple domain objects. DNSSEC and multiple
	host objects may interfere with the use of controlled interrupti on IP addresses to alert	host objects may interfere with the use of controlled interrupti on IP addresses to alert
	registrants to DNS changes. EPP clients can periodically scan sp onsored domains for	registrants to DNS changes. EPP clients can periodically scan sp onsored domains for
	association with sacrificial name servers and alert end users co ncerning those domains.</t>	association with sacrificial name servers and alert end users co ncerning those domains.</t>

	<t>In absence of DNSSEC use by the victim, an attacker wh o gains control of a	<t>In absence of DNSSEC use by the victim, an attacker wh o gains control of a

	single nameserver can use DNSSEC to instead take over the victim domain completely	single name server can use DNSSEC to instead take over the victi m domain completely
	if the registry operator and registrar process for automated DS maintenance neglects	if the registry operator and registrar process for automated DS maintenance neglects

	to check all nameservers for consistency in CDS/CDNSKEY records. In this scenario,	to check all name servers for consistency in CDS/CDNSKEY records . In this scenario,
	the domain will end up with DS records derived from the attacker CDS/CDNSKEY records	the domain will end up with DS records derived from the attacker CDS/CDNSKEY records

	if, by chance, the queries happen to hit the attacker controlled	if, by chance, the queries happen to hit the attacker-controlled
	nameserver. Subsequently, validating	name server. Subsequently, validating
	resolvers will no longer accept responses from the legitimate na	resolvers will no longer accept responses from the legitimate na
	meservers. Moreover, with	me servers.
	the use of CSYNC an attacker may update the domain NS records re	Moreover, with
	moving the legitimate	the use of CSYNC, an attacker may update the domain NS records,
	nameservers entirely.</t>	removing the legitimate
	</section>	name servers entirely.</t>
	<section anchor="acks" title="Acknowledgments">
	<t>The authors would like to thank the following people for their co
	ntributions to this
	document: Brian Dickson, James Gould, Pawel Kowalik, Mario Loffr
	edo, James Mitchell, Matthew Thomas, Peter
	Thomassen, Duane Wessels, David Blacka.</t>
	</section>	</section>
	</middle>	</middle>
	<back>	<back>
	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.2119.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.2119.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.3915.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.3915.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.5730.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.5730.xml" />

	skipping to change at line 742 ¶	skipping to change at line 806 ¶
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.6761.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.6761.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8174.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8174.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8244.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8244.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.9476.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.9476.xml" />
	</references>	</references>
	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.6305.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.6305.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7535.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.7535.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8023.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8023.xml" />


		<!-- [rfced] Informative reference RFC 8499 has been obsoleted by RFC 9499.
		May we update the reference to point to RFC 9499? We note that "NXDOMAIN" is me
		ntioned in RFC 9499.

		RFC 8499 is cited in the text as follows:
		Requests to the root for this domain would result
		in NXDOMAIN response [RFC8499].
		-->

	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8499.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8499.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8590.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.8590.xml" />
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.9520.xml" />	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referen ce.RFC.9520.xml" />

	<reference anchor="risky-bizness" target="https://doi.org/10.114
	5/3487552.3487816">	<reference anchor="Risky-BIZness">
	<front>	<front>
	<title>Risky BIZness: Risks Derived from Registrar Name Management</title>	<title>Risky BIZness: Risks Derived from Registrar Name Management</title>
	<author fullname="Gautam Akiwate" initials="G." surname= "Akiwate" />	<author fullname="Gautam Akiwate" initials="G." surname= "Akiwate" />
	<author fullname="Stefan Savage" initials="S." surname=" Savage" />	<author fullname="Stefan Savage" initials="S." surname=" Savage" />
	<author fullname="Geoffrey M. Voelker" initials="G." sur name="Voelker" />	<author fullname="Geoffrey M. Voelker" initials="G." sur name="Voelker" />
	<author fullname="KC Claffy" initials="K." surname="Claf fy" />	<author fullname="KC Claffy" initials="K." surname="Claf fy" />
	<date year="2021" month="Nov" />	<date year="2021" month="Nov" />
	</front>	</front>

		<refcontent>IMC '21: Proceedings of the 21st ACM Internet Me
		asurement Conference</refcontent>
		<seriesInfo name="DOI" value="10.1145/3487552.3487816"/>
	</reference>	</reference>

	<reference anchor="risky-bizness-irtf"
	target="https://datatracker.ietf.org/doc/slides-115-irtfopen	<reference anchor="Risky-BIZness-IRTF" target="https://datatrack
	-risky-bizness-risks-derived-from-registrar-name-management/">	er.ietf.org/doc/slides-115-irtfopen-risky-bizness-risks-derived-from-registrar-n
		ame-management/">
	<front>	<front>
	<title>Risky BIZness: Risks Derived from Registrar Name Management</title>	<title>Risky BIZness: Risks Derived from Registrar Name Management</title>
	<author fullname="Gautam Akiwate" initials="G." surname= "Akiwate" />	<author fullname="Gautam Akiwate" initials="G." surname= "Akiwate" />
	<author fullname="Stefan Savage" initials="S." surname=" Savage" />	<author fullname="Stefan Savage" initials="S." surname=" Savage" />
	<author fullname="Geoffrey M. Voelker" initials="G." sur name="Voelker" />	<author fullname="Geoffrey M. Voelker" initials="G." sur name="Voelker" />
	<author fullname="KC Claffy" initials="K." surname="Claf fy" />	<author fullname="KC Claffy" initials="K." surname="Claf fy" />
	<date year="2022" month="Nov" />	<date year="2022" month="Nov" />
	</front>	</front>

		<refcontent>IETF 115 Proceedings</refcontent>
	</reference>	</reference>

	<reference anchor="SAC048"
	target="https://itp.cdn.icann.org/en/files/security-and-stab	<reference anchor="SAC048" target="https://it
	ility-advisory-committee-ssac-reports/sac-048-en.pdf">	p.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/
		sac-048-en.pdf">
	<front>	<front>
	<title>SSAC Comment on Orphan Glue Records in the Draft Applicant Guidebook</title>	<title>SSAC Comment on Orphan Glue Records in the Draft Applicant Guidebook</title>
	<author>	<author>
	<organization>ICANN Security and Stability Advisory Committee</organization>	<organization>ICANN Security and Stability Advisory Committee</organization>
	</author>	</author>
	<date year="2011" month="May" day="12" />	<date year="2011" month="May" day="12" />
	</front>	</front>

	<seriesInfo name="SAC" value="48"/>	<seriesInfo name="SAC" value="048"/>
	</reference>	</reference>

	<reference anchor="SAC125"
	target="https://itp.cdn.icann.org/en/files/security-and-stab	<reference anchor="SAC125" target="https://it
	ility-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf">	p.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/
		sac-125-09-05-2024-en.pdf">
	<front>	<front>
	<title>SSAC Report on Registrar Nameserver Management</t itle>	<title>SSAC Report on Registrar Nameserver Management</t itle>
	<author>	<author>
	<organization>ICANN Security and Stability Advisory Committee</organization>	<organization>ICANN Security and Stability Advisory Committee</organization>
	</author>	</author>
	<date year="2024" month="May" day="9" />	<date year="2024" month="May" day="9" />
	</front>	</front>
	<seriesInfo name="SAC" value="125"/>	<seriesInfo name="SAC" value="125"/>
	</reference>	</reference>
	</references>	</references>

	</references>	</references>
	<section title="Change Log" removeInRFC="true">
	<t>This section lists substantial changes to the document as it is b	<!--[rfced] FYI - We have alphabetized the names listed in the Acknowledgments
	eing worked on.</t>	section. We believe that was the intent as only one was out of order. Let us
	<t>00:</t>	know if you prefer the original order.
	<ol>	-->
	<li>Initial working group version.</li>
	</ol>	<section anchor="acks" numbered="false"><name>Acknowledgments</name>
	<t>01:</t>	<t>The authors would like to thank the following people for their co
	<ol>	ntributions to this
	<li>Addressed feedback received during the WG adoption request.	document: <contact fullname="David Blacka"/>, <contact fullname=
	Re-included text to indicate if approaches have been observed in practice or not	"Brian Dickson"/>, <contact fullname="James Gould"/>, <contact fullname="Pawel K
	.</li>	owalik"/>, <contact fullname="Mario Loffredo"/>, <contact fullname="James Mitche
	</ol>	ll"/>, <contact fullname="Matthew Thomas"/>, <contact fullname="Peter
	<t>02:</t>	Thomassen"/>, and <contact fullname="Duane Wessels"/>.</t>
	<ol>
	<li>Section 1: Added sentence to bridge between renaming host ob
	jects and deletion dilemma.</li>
	<li>Section 1: Noted that renaming a host object to a name of an
	external host is an operation that might not be possible to reverse.</li>
	<li>Section 4: Added mention of "sacrificial" hosts. "ns1.exampl
	e.org" is a sacrificial host.</li>
	<li>Section 5.1: Added text to give some more context on "sacri
	ficial" hosts.</li>
	<li>Section 8: Added text describing DNSSEC risk.</li>
	<li>Acknowledged Brian Dickson.</li>
	</ol>
	<t>03:</t>
	<ol>
	<li>Added reference to SAC048 in <xref target="dns-cons"/>.</li>
	<li>Added note about minimal risk in <xref target="client-server
	-cons"/>.</li>
	<li>Added context to the best practice recommendations in <xref
	target="recommendations"/>.</li>
	<li>Added "Sacrificial Name Server" to the title of <xref target
	="control-rename"/>.</li>
	</ol>
	<t>04:</t>
	<ol>
	<li>Updates to address working group last call feedback:</li>
	<li>Updated the abstract to note "new possible practices".</li>
	<li>Split <xref target="practice-analysis"/> into two sections t
	o better identify observed practices and possible practices.</li>
	<li>Added a specific recommendation to use "sacrificial.invalid"
	in <xref target="recommendations"/>.</li>
	<li>Reorganized practice description sections into subsections o
	f observed practices and potential practices.</li>
	</ol>
	<t>05:</t>
	<ol>
	<li>Move <xref target="inform-affected-client"/> into observed p
	ractices.</li>
	<li>Add clearer MUST NOT guidance on <xref target="renaming-exte
	rnal"/>, <xref target="renaming-non-provisioned"/>, and <xref target="renaming-p
	seudo-tld" />. </li>
	<li>Promoted subsection of potential options to potential practi
	ces.</li>
	<li>Removed redundant explicit delete section.</li>
	<li>Increased TOC depth.</li>
	<li>Made section headers clearer, changing "Deletion Observed Pr
	actices" and similar to "Observed Practices for Deletion of Hosts," etc.</li>
	</ol>
	<t>06:</t>
	<ol>
	<li>Add reference to SSAC125 complementary document</li>
	<li>Change recommendations to use MUST language and reference to
	RFC8244.</li>
	<li>Rewrite "Allow Explicit Delete of Domain with Restore Capabi
	lity" text for greater clarity.</li>
	</ol>
	<t>07:</t>
	<ol>
	<li>Consolidate Best Practice Recommendations <xref target="reco
	mmendations" /></li>
	<li>Make RFC 3915 normative.</li>
	</ol>
	<t>08:</t>
	<ol>
	<li>Changed subject of <xref target="recommendations" /> recomme
	ndations from "An EPP server" to "EPP servers and clients."</li>
	</ol>
	<t>09:</t>
	<ol>
	<li>Updated <xref target="renaming-as112" /> for clarity around
	empty subdomain, to remove confusing/incorrect claim around "valid" DNS name, an
	d to add DNAME mention.</li>
	<li>Added explanatory sentences to <xref target="introduction" /
	>.</li>
	<li>Explicitly state that other practices in analysis section ar
	e not recommended in <xref target="recommendations" />.</li>
	<li>Clarified sacrificial name server requirements in <xref targ
	et="control-rename" />.</li>
	</ol>
	<t>10:</t>
	<ol>
	<li>Move SAC048 URL from text to references.</li>
	<li>Rename <xref target="control-rename" /> to explicitly say "d
	edicated."</li>
	<li>Remove test/experiment in <xref target="renaming-existing-sp
	ecial-use-reserved" />.</li>
	<li>Change <xref target="control-rename" /> to require authorita
	tive DNS service (previous SHOULD changed to MUST).</li>
	</ol>
	</section>	</section>

	</back>	</back>

		<!--[rfced] FYI - As both "nameserver" and "name server" were used throughout
		the document. We have updated all instances to "name server" for consistency.
		Please review and let us know of any objections.
		-->

		<!--[rfced] FYI - We have added an expansion for the following abbreviation
		per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion
		in the document carefully to ensure correctness.

		Top-Level Domain (TLD)
		-->

		<!-- [rfced] Please review the "Inclusive Language" portion of the online
		Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
		and let us know if any changes are needed. Updates of this nature typically
		result in more precise language, which is helpful for readers.

		Note that our script did not flag any words in particular, but this should
		still be reviewed as a best practice.
		-->

	</rfc>	</rfc>

End of changes. 121 change blocks.
	354 lines changed or deleted	368 lines changed or added
This html diff was produced by rfcdiff 1.48.