<?xml version="1.0" encoding="utf-8"?><?xml-model href="rfc7991bis.rnc"?> <!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> --><!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?> <?rfc tocInclude="yes"?> <?rfc tocDepth="7"?> <?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" number="9874" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3" consensus="true" tocInclude="true" tocDepth="5">sortRefs="true" symRefs="true"> <front> <title abbrev="Domain and Host Object Deletion in EPP">Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)</title> <!--[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 existing 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"> <organization>Verisign Labs</organization> <address> <postal> <street>12061 Bluemont Way</street> <city>Reston</city> <region>VA</region> <code>20190</code><country>USA</country><country>United States of America</country> </postal> <email>shollenbeck@verisign.com</email> <uri>https://www.verisignlabs.com/</uri> </address> </author> <author initials="W." surname="Carroll" fullname="William Carroll"> <organization>Verisign</organization> <address> <postal> <street>12061 Bluemont Way</street> <city>Reston</city> <region>VA</region> <code>20190</code><country>USA</country><country>United States of America</country> </postal> <phone>+1 703 948-3200</phone> <email>wicarroll@verisign.com</email> <uri>https://verisign.com</uri> </address> </author> <author initials="G." surname="Akiwate" fullname="Gautam Akiwate"> <organization>Stanford University</organization> <address> <postal> <street>450 Jane Stanford Way</street> <city>Stanford</city> <region>CA</region> <code>94305</code><country>USA</country><country>United States of America</country> </postal> <phone>+1 650 723-2300</phone> <email>gakiwate@cs.stanford.edu</email> <uri>https://cs.stanford.edu/~gakiwate/</uri> </address> </author> <date/> <area>Applications</area> <workgroup>REGEXT Working Group</workgroup>month="September" year="2025"/> <area>ART</area> <workgroup>regext</workgroup> <keyword>EPP</keyword> <abstract> <t>The Extensible Provisioning Protocol (EPP) includes commands for clients to delete domain and host objects, both of which are used to publish information in the Domain Name System (DNS). EPP also includes guidance for deletions that is intended to avoid DNS resolution disruptions and maintain data consistency. However, operational relationships between objects can make that guidance difficult to implement. Some EPP clients have developed operational practices to delete those objects that have unintended impacts on DNS resolution and security. This document describes best current practices and proposes new potential practices to delete domain and host objects that reduce the risk of DNS resolution failure and maintain client-server data consistency.</t> </abstract> </front> <middle> <sectionanchor="introduction" title="Introduction"> <t>Section 3.2.2 of RFC 5731 <xrefanchor="introduction"><name>Introduction</name> <t><xref target="RFC5731"/>section="3.2.2"/> contains text that has led some domain name registrars (acting as EPP clients) to adopt an operational practice ofre-namingrenaming name server host objects so that they can delete domain objects:</t><t>"A<blockquote><t>A domain object <bcp14>SHOULD NOT</bcp14> be deleted if subordinate host objects are associated with the domain object. For example, if domain "example.com" exists and host object "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 exist in a different superordinatedomain."</t>domain.</t></blockquote> <t>Similarly,Section 3.2.2 of RFC 5732<xref target="RFC5732"/>section="3.2.2"/> contains this text regarding deletion of host objects:</t><t>"A<blockquote><t>A host name object <bcp14>SHOULD NOT</bcp14> be deleted if the host object is associated with any 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 existing association has been broken. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted hostobject."</t>object.</t></blockquote> <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 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 associated domain objects cannot be directly updated because they are sponsored by another client. This situation affects all EPP operators that have implemented support for host objects.</t><t>Section 3.2.5 of RFC 5732 <xref<t><xref target="RFC5732"/>section="3.2.5"/> describes host object renaming:</t><t>"Host<blockquote><t>Host name changes can have an impact on associated objects that refer to the host object. A host name change <bcp14>SHOULD NOT</bcp14> require additional updates of associated objects to preserve existing associations, with one exception: changing an external host object that has associations with objects that are sponsored by a different client. Attempts to update such hosts directlyMUST<bcp14>MUST</bcp14> fail with EPP error code 2305. The change can be provisioned by creating a new external host with a new name and any needed new attributes, and subsequently updating the other objects sponsored by theclient."</t> <t>Section 1.1 of RFC 5732client.</t></blockquote> <t><xref target="RFC5732" section="1.1"/> includes a description of external hosts. Some EPP clients have developed operational practices that use host object renaming to break association between a domain object and host object. Note that the specific 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 refers to an unregistered domain, then a malicious actor may register the domain and create 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 authoritative DNS service but 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)(i.e., hijack) DNS resolution functionality. If the new external host offers recursive DNS service or no DNS service, then DNS requests for the domain will result in SERVFAIL messages or other errors. Aggressivere-queriesrequeries by DNS 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 external host cannot be 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 associated with host object renaming. <xref target="practice-analysis" /> includes a detailed analysis of the practices that have been and can be used to mitigate that risk. <xref target="recommendations" /> includes specific recommendations for the best practices.</t> </section><section title="Conventions<section><name>Conventions Used in ThisDocument"> <t>TheDocument</name> <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" />target="RFC2119"/> <xreftarget="RFC8174" />target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectionanchor="rationale" title='Rationaleanchor="rationale"><name>Rationale for"SHOULD NOT"<bcp14>SHOULD NOT</bcp14> bedeleted"'>deleted"</name> <sectionanchor="dns-cons" title="DNS Considerations">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 objects concerns the potential impact on DNS resolution. Deletion of a domain object will make all name servers associated with subordinate host objects unresolvable. Deletion of a host object will make any domain that has been delegated to the associated name server unresolvable. The text inRFCs 5731<xref target="RFC5731"/> and5732<xref target="RFC5732"/> was written to encourage clients to take singular, discrete steps to delete objects in a way that avoids breaking DNS resolution functionality. Additionally, allowing host objects to exist after deletion of their superordinate domain object invites hijacking, as a malicious actor mayre-registerreregister the domain object, potentially controlling resolution for the host objects and for their associated domain objects. It also creates orphan glue as described inSAC048 (<xref target="SAC048" />).</t><xref target="SAC048"/>.</t> </section> <sectionanchor="client-server-cons" title="Client-Serveranchor="client-server-cons"><name>Client-Server ConsistencyConsiderations">Considerations</name> <t>A server that implicitly deletes subordinate host objects in response to a request to delete a domain object can create a data inconsistency condition in which the EPP client and the EPP server have different views of what remains registered after processing a <delete> command. The text inRFCs 5731<xref target="RFC5731"/> and5732<xref target="RFC5732"/> was written to encourage clients to take singular, discrete steps to delete objects in a way that maintains client-server data consistency. Experience suggests that this inconsistency poses little operational risk.</t> </section> <sectionanchor="relational-cons" title="Relationalanchor="relational-cons"><name>Relational ConsistencyConsiderations"> <t>ImplementationsConsiderations</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 hierarchical domain object / host object relationship, as can exist in a relational database. In such instances, deletion of a domain object without addressing the existing subordinate host objects can cause relational consistency and integrity issues. The text inRFCs 5731<xref target="RFC5731"/> and5732<xref target="RFC5732"/> was written to reduce the risk of these issues arising as a result of implicit object deletion.</t> </section> </section> <sectionanchor="renaming-risk" title="Hostanchor="renaming-risk"><name>Host Object RenamingRisk">Risk</name> <t>As described inRFC 5731,<xref target="RFC5731"/>, it is possible to delete a domain object that has associated host objects that are managed by other clients by renaming the host object to exist in a different superordinate domain. This is commonly required when the sponsoring client is unable to disassociate a host object from a domain object managed by another client because only the second client is authorized to make changes to their domain object and the EPP server requires host object disassociation to process a request to delete a domain object. For example:</t> <t>Domain object "domain1.example" is registered by ClientX.</t> <t>Domain object "domain2.example" is registered by ClientY.</t> <t>Subordinate host object "ns1.domain1.example" is registered and associated with domain object "domain1.example" by ClientX.</t> <t>Host object "ns1.domain1.example" is associated with domain object "domain2.example" by ClientY.</t> <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", but ClientX cannot remove the association of host object "ns1.domain1.example" from domain object "domain2.example" because "domain2.example" is sponsored by ClientY and ClientX is unable to determine that relationship. Only ClientY can modify domain object "domain2.example", and if they do not dososo, ClientX will need to rename host object "ns1.domain1.example" so that "domain1.example" can be deleted.</t> <t>ClientX renames host object "ns1.domain1.example" to "ns1.example.org", creating an external host and meeting the EPP server's subordinate host object disassociation requirement. The renamed host object "ns1.example.org" is referred to as a "sacrificial" host <xreftarget="risky-bizness"target="Risky-BIZness" />.</t> <t>If domain "example.org" does not exist, this practice introduces a risk of DNS resolution hijacking if someone were to register the "example.org" domain and create a subordinate host object named "ns1.example.org". That name server would receive DNS queries for all domains delegated to it, allowing the operator of the name server to respond in potentially malicious ways.</t> </section> <sectionanchor="practice-analysis" title="Analysisanchor="practice-analysis"><name>Analysis of Practices for Domain and Host ObjectDeletion" >Deletion</name> <t>EPP servers can employ a range of practices for domain and host object deletion. Notably, the scope of any practice discussed here is the EPP server that adopts the practice and the domains managed by it. The practices described in this document fall into two broad categories: renaming objects to use"sacrificial" hosts,sacrificial hosts and allowing objects to be deleted even if there are existing data relationships. These practice categories are described in the following sections. For a broader consideration of practices and potential impacts on registries and registrars, <xref target="SAC125" /> offers some complementary insight. </t> <sectionanchor="renaming-overall" title="Renaminganchor="renaming-overall"><name>Renaming to SacrificialHosts"> <t>"Sacrificial"Hosts</name> <t>Sacrificial hosts are hosts whose name is intended to remove an existing relationship between domain and host objects. To that end,"sacrificial"sacrificial hosts are either renamed to an external host or associated with a different domain object in the EPP server. The first group of deletion practices use sacrificial hosts leveraging existing EPP server support for renaming host objects.</t> <sectionanchor="renaming-overall-pros" title="Practice Benefits">anchor="renaming-overall-pros"><name>Practice Benefits</name> <t>Affected domains remain delegated in the zone. Registrars and registrants of affected domains may be able to determine the intention of the change.</t> </section> <sectionanchor="renaming-overall-cons" title="Practice Detriments">anchor="renaming-overall-cons"><name>Practice Detriments</name> <t>Zones are crowded with irrelevant records. Registrars and registrants of affected domains are required to clean them up.</t> </section> <sectionanchor="renaming-observed" title="Observedanchor="renaming-observed"><name>Observed Practices for Renaming to SacrificialHosts">Hosts</name> <sectionanchor="renaming-external" title="Renaminganchor="renaming-external"><name>Renaming to External, Presumed Non-ExistentHosts">Hosts</name> <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. The external host is presumed to be non-existent by the deleting EPPclientclient, but no check for existence is typically performed. This practice has been observed in use. This practice <bcp14>MUST NOT</bcp14> be used. </t> <sectionanchor="renaming-external-pros" title="Practice Benefits">anchor="renaming-external-pros"><name>Practice Benefits</name> <t>The primary benefit is convenience for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic.</t> </section> <sectionanchor="renaming-external-cons" title="Practice Detriments">anchor="renaming-external-cons"><name>Practice Detriments</name> <t>Malicious actors have registered these parent domains and created child host objects to take control of DNS resolution for associated domains <xreftarget="risky-bizness"target="Risky-BIZness" />.</t> <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 still resolve if they continue to be associated with existenthosts,hosts; in whichcasecase, their partial vulnerability to hijacking is more difficult to detect.</t> </section> </section> <sectionanchor="renaming-as112" title='Renaminganchor="renaming-as112"><name>Renaming to"as112.arpa"'>"as112.arpa"</name> <t>Some domain registrars, acting as EPP clients, have renamed host objects to subdomains of "as112.arpa" or "empty.as112.arpa" <xreftarget="risky-bizness-irtf"target="Risky-BIZness-IRTF" />. This practice has been observed in use. </t> <sectionanchor="renaming-as112-pros" title="Practice Benefits">anchor="renaming-as112-pros"><name>Practice Benefits</name> <t> The primary benefit is convenience for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. </t> </section> <sectionanchor="renaming-as112-cons" title="Practice Detriments">anchor="renaming-as112-cons"><name>Practice Detriments</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, primarily so local admins can sinkhole non-global traffic <xref target="RFC7535" />.The"empty.as112.arpa" is designed to be used with DNAME aliasing, not as a parent domain for sacrificial name servers (seesection 3 of<xref target="RFC7535"/>).section="3"/>). Unexpected AS112 traffic has previously caused problems with intrusion detection systems and firewalls <xref target="RFC6305" />. Local administrators can potentially hijack requests. AS112 infrastructure must be maintained. </t> </section> </section> <sectionanchor="renaming-non-provisioned" title="Renaminganchor="renaming-non-provisioned"><name>Renaming to Non-AuthoritativeHosts">Hosts</name> <t>Some domain registrars, acting as EPP clients, have maintained host objects with glue records pointing to prominent public recursive DNS services. This practice has been observed in use. This practice <bcp14>MUST NOT</bcp14> be used. </t> <sectionanchor="renaming-non-provisioned-pros" title="Practice Benefits">anchor="renaming-non-provisioned-pros"><name>Practice Benefits</name> <t>The primary benefit is convenience for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. </t> </section> <sectionanchor="renaming-non-provisioned-cons" title="Practice Detriments">anchor="renaming-non-provisioned-cons"><name>Practice Detriments</name> <t> Queries for the associated domains result in SERVFAIL or other failure responses. Some recursive name server implementations may aggressivelyre-queryrequery for these responses, potentially resulting in large numbers of queries for unresolvable domains <xref target="RFC9520" />.</t> </section> </section> <sectionanchor="control-rename" title="Renaminganchor="control-rename"><name>Renaming to Client-Maintained Dedicated Sacrificial Name Server HostObjects">Objects</name> <t>EPP clientsMAY<bcp14>MAY</bcp14> rename the host object to be deleted to a sacrificial name server host object maintained by the client. This requires that the client maintain the registration of the sacrificial name server's superordinate domain. The client may consider long registration periods and the use of registrar and registry lock services to maintain and protect the superordinate domain and the host object. Failures to maintain these registrations have allowed domain hijacks <xreftarget="risky-bizness" />.target="Risky-BIZness"/>. </t> <t> The client-maintained dedicated sacrificial name server <bcp14>MUST</bcp14> resolve to one or more IPaddressesaddresses, and the client <bcp14>MUST</bcp14> operate an authoritative DNS name server on those addresses. The name server <bcp14>MAY</bcp14> provide any valid response. </t> <t> This practice has been observed in use. </t> <sectionanchor="control-rename-pros" title="Practice Benefits">anchor="control-rename-pros"><name>Practice Benefits</name> <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 responses that indicate problems with a domain's delegation, such as non-existence orincludeincluding controlled interruption IP addresses <xref target="RFC8023" />. </t> </section> <sectionanchor="control-rename-cons" title="Practice Detriments">anchor="control-rename-cons"><name>Practice Detriments</name> <t>This requires that the client maintain the registration of the sacrificial name server's superordinate domain. The client may consider long registration periods and the use of registrar and registry lock services to maintain and protect the superordinate domain and the host object. Failures to maintain these registrations have allowed domain hijacks <xreftarget="risky-bizness" />.target="Risky-BIZness"/>. </t> <t>Failure responses may cause aggressive requerying (see <xref target="renaming-non-provisioned-cons" />).</t> </section> </section> </section> <sectionanchor="renaming-potential" title="Potentialanchor="renaming-potential"><name>Potential Practices for Renaming to SacrificialHosts">Hosts</name> <sectionanchor="renaming-pseudo-tld" title="Renaminganchor="renaming-pseudo-tld"><name>Renaming toPseudo-TLD">Pseudo-TLD</name> <t>Clients may rename host objects to use ".alt" or another non-DNS pseudo-TLD (Top-Level Domain), as suggested in <xreftarget="risky-bizness-irtf" />.target="Risky-BIZness-IRTF"/>. This practice has not been observed in use. This practice <bcp14>MUST NOT</bcp14> be used. </t> <sectionanchor="renaming-pseudo-tld-pros" title="Practice Benefits">anchor="renaming-pseudo-tld-pros"><name>Practice Benefits</name> <t>The primary benefit is convenience for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. Dependent domains cannot be hijacked through the registration of these identifiers and delegation in the DNS.</t> </section> <sectionanchor="renaming-pseudo-tld-cons" title="Practice Detriments">anchor="renaming-pseudo-tld-cons"><name>Practice Detriments</name> <t>The ".alt" pseudo-TLD is to be used "to signify that this is an alternative (non-DNS) namespace and should not be looked up in a DNS context" <xref target="RFC9476" />. Some EPP servers may restrict TLDs to valid IANA-delegated TLDs. These entries would mix DNS and non-DNS protocols, risk name collisions, create confusion, and potentially result in unpredictable resolver behaviors. These identifiers may be registered in non-DNS namespaces, potentially leading to hijacking vulnerabilities based in other systems. </t> </section> </section> <sectionanchor="renaming-existing-special-use" title="Renaminganchor="renaming-existing-special-use"><name>Renaming to Existing Special-UseTLD">TLD</name> <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> <sectionanchor="renaming-existing-special-use-reserved" title="Renaminganchor="renaming-existing-special-use-reserved"><name>Renaming to ReservedTLD">TLD</name> <t>Clients may rename host objects to use a reserved special-use(<xref target="RFC6761" />) TLD<xref target="RFC6761"/> TLD, as suggested in <xreftarget="risky-bizness"target="Risky-BIZness" />.</t> <sectionanchor="renaming-existing-special-use-pros" title="Practice Benefits">anchor="renaming-existing-special-use-pros"><name>Practice Benefits</name> <t>The primary benefit is convenience for the deleting EPP client. These TLDs are already reserved and will not resolve. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. Dependent domains cannot be hijacked.</t> </section> <sectionanchor="renaming-existing-special-use-cons" title="Practice Detriments">anchor="renaming-existing-special-use-cons"><name>Practice Detriments</name> <t>The use of TLDs reserved for special purposes(<xref target="RFC6761" />)<xref target="RFC6761"/> may be confusing without a domain designated by the community for this purpose (see "sacrificial.invalid" in Sections <xref target="renaming-new-special-use"/>format="counter"/> and <xref target="recommendations"/>).format="counter"/>). In addition, their use may be prevented by EPP server policy.</t> </section> </section> </section> <sectionanchor="renaming-new-special-use" title="Renaminganchor="renaming-new-special-use"><name>Renaming to a Special-UseDomain">Domain</name> <t> Clients would rename hosts to a special-use domain or subdomain thereof. The domain may be a special-use SLD (Second-Level Domain) (e.g., sacrificial.invalid) or a new reserved TLD (e.g., .sacrificial). Use of this domain would communicate the client's intention to create a sacrificial host. IANA would add this domain to the "Special-Use Domain Name" registry if such a new TLD is created using either IETF or ICANN processes. This practice has not been observed in use. In terms of the questions from <xref target="RFC6761" />: </t> <ol type="1" spacing="normal" indent="adaptive" start="1"> <li derivedCounter="1."> These names are not expected to be visible to human users. However, the purpose of these domains is expected to be semantically recognizable to human users. </li> <li derivedCounter="2."> Application software is not expected to recognize these names as special or treat them differently than other allowed domain names. </li> <li derivedCounter="3."> Name resolution APIs and libraries are not expected to recognize these names as special or treat them differently than other allowed domain names. </li> <li derivedCounter="4."> Caching name servers are not expected to recognize these names as special or treat them differently than other allowed domain names. </li> <li derivedCounter="5."> Authoritative name servers are not expected to recognize these names as special or treat them differently than other allowed domain names. Requests to the root for this domain would result in an NXDOMAIN response <xref target="RFC8499" />. </li> <li derivedCounter="6."> DNS server operators will treat this domain and its subdomains as they would any other allowed names in the DNS. </li> <li derivedCounter="7."> DNSRegistries/Registrarsregistries/registrars will not be able to register this domain and must deny requests to register it or its subdomains. </li> </ol> <sectionanchor="renaming-new-special-use-pros" title="Practice Benefits">anchor="renaming-new-special-use-pros"><name>Practice Benefits</name> <t> This option would offer clarity concerning the intentions of registrars that rename hosts. It would also enable registrars of affected domains ease of detection of renamed hosts. This option is also convenient for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. Dependent domains cannot be hijacked through the registration of these identifiers and delegation in the DNS. </t> </section> <sectionanchor="renaming-new-special-use-cons" title="Practice Detriments">anchor="renaming-new-special-use-cons"><name>Practice Detriments</name> <t> This would require cooperation and policy changes for registrars and registries. </t> </section> </section> <sectionanchor="new-service" title="Renaminganchor="new-service"><name>Renaming to Community Sacrificial Name ServerService">Service</name> <t>A new community-wide service could be created explicitly intended for use for renaming host records. This would require maintenance of name servers capable of authoritatively responding with NXDOMAIN or a controlled interruption IP addresses <xref target="RFC8023" /> for all queries without delegating domains or records. This service could use a new special-use TLD createdeitherthrough ICANN or IETF processes (e.g., ".sacrificial"), as an IAB request that IANA delegatea second-level domain (SLD)an SLD for ".arpa" (e.g., "sacrificial-nameserver.arpa"), or as a contracted sinkhole service by ICANN or other DNS ecosystem actors. This practice has not been observed in use.</t> <sectionanchor="new-service-pros" title="Practice Benefits">anchor="new-service-pros"><name>Practice Benefits</name> <t>This is convenient for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. The associated domains are not vulnerable to hijacking. This would provide a well-understood, industry-standard solution, allowing registrars and registrants to easily identify associated domains that have been affected. Infrastructure operators could monitor traffic to identify affected associated domains that result in significant traffic and attempt to contact registrars and registrants. Economies of scale would allow reduced overall costs to the industry (in contrast to each client running an independent service).</t> </section> <sectionanchor="new-service-cons" title="Practice Detriments">anchor="new-service-cons"><name>Practice Detriments</name> <t>Some entity must maintain the infrastructure for the service.</t> </section> </section> </section> </section> <sectionanchor="delete-overall" title="Deletionanchor="delete-overall"><name>Deletion ofHosts">Hosts</name> <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 recommendations inRFC 5731<xreftarget="RFC5731" />target="RFC5731"/> are intended to maintain consistency. However, they are not requirements. </t> <sectionanchor="delete-observed" title="Observedanchor="delete-observed"><name>Observed Practices for Deletion ofHosts">Hosts</name> <sectionanchor="automatic-delete" title="Implicit Deleteanchor="automatic-delete"><name>Implicit Deletion of Affected HostObjects">Objects</name> <t> EPP servers may relax their constraints and allow sponsoring clients to delete host objects without consideration of associations with domain objects sponsored by other clients. The registry automatically disassociates the deleted host objects from domain objects sponsored by other clients. This practice has been observed in use. </t> <sectionanchor="automatic-delete-pros" title="Practice Benefits">anchor="automatic-delete-pros"><name>Practice Benefits</name> <t> This is convenient for the deleting EPP client. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. The associated domains are not vulnerable to hijacking. </t> </section> <sectionanchor="automatic-delete-cons" title="Practice Detriments">anchor="automatic-delete-cons"><name>Practice Detriments</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 result in domains with no remaining name servers being removed from the zone or domains with only one remaining name server. Deletions could potentially affect large numbers of associated domains, placing strain on domain registries. </t> </section> </section> <sectionanchor="inform-affected-client" title="Informanchor="inform-affected-client"><name>Inform AffectedClients">Clients</name> <t> The sponsoring clients of affected domain objects may also be informed of the change (e.g., through the EPP Change Poll extension <xref target="RFC8590" />). This practice has been observed in use. </t> <sectionanchor="inform-affected-client-pros" title="Practice Benefits">anchor="inform-affected-client-pros"><name>Practice Benefits</name> <t>Updates help achieve the goals of client-server data consistency and minimal interruptions to resolution. The sponsoring clients of affected domain objects are able to update their database to reflect the change and would be able to inform the domain's registrant. The sponsoring clients can automatically update the affected domains to use another authoritative host. </t> </section> <sectionanchor="inform-affected-client-cons" title="Practice Detriments">anchor="inform-affected-client-cons"><name>Practice Detriments</name> <t> This change requires additional development on the part of EPP servers and clients. There may be scalability concerns if large numbers of domain objects are updated in a single transaction. </t> </section> </section> </section> <sectionanchor="delete-potential" title="Potentialanchor="delete-potential"><name>Potential Practices for Deletion ofHosts">Hosts</name> <sectionanchor="explicit-delete" title="Requestanchor="explicit-delete"><name>Request ExplicitDeleteDeletion of Affected HostObjects">Objects</name> <t>Sponsoring clients requesting the deletion of host objects would explicitly request their disassociation from domain objects sponsored by other clients. This practice has not been observed in use. </t> <sectionanchor="explicit-delete-pros" title="Practice Benefits">anchor="explicit-delete-pros"><name>Practice Benefits</name> <t> Registries would not be required to unilaterally take responsibility for deletion. The deleting EPP client is not required to maintain an authoritative DNS service or receive traffic. The associated domains are not vulnerable to hijacking. </t> </section> <sectionanchor="explicit-delete-cons" title="Practice Detriments">anchor="explicit-delete-cons"><name>Practice Detriments</name> <t>This could result in domains with no remaining name servers being removed from the zone or domains with only one remaining name server. Deletions could potentially affect large numbers of associated domains, placing strain on domain registries. </t> </section> </section> <sectionanchor="additional-deletion-details" title="Provideanchor="additional-deletion-details"><name>Provide Additional DeletionDetails">Details</name> <t>The EPP server may provide the deleting EPP client with additional details of the affected objects. The deleting EPP client may receive a response (e.g., using msg, reason, or msgQ elements of the EPP response <xref target="RFC5730" />) that deletion of the host object would affect domain objects sponsored by another client and may receive details about those objects (e.g., using the EPP poll command). This practice has not been observed in use. </t> <sectionanchor="additional-deletion-details-pros" title="Practice Benefits">anchor="additional-deletion-details-pros"><name>Practice Benefits</name> <t> The deleting EPP client would be able to better understand and assess the potential harms of host object deletion. Depending on the content of the message, the deleting EPP client might choose additional actions, such as delaying the deletion until manual approval can be obtained, renaming the host objects, or informing affected EPP clients. This would give EPP clients greater flexibility with respect to deletion. For example, they may choose only to exercise deletions that have no impact on other clients. </t> </section> <sectionanchor="additional-deletion-details-cons" title="Practice Detriments">anchor="additional-deletion-details-cons"><name>Practice Detriments</name> <t> This change would require additional development on the part of EPP servers and clients. There may be scalability concerns if large numbers of domain objects are updated in a single transaction. The EPP server must determine the relevant information to provide for the EPP client's assessment. </t> </section> </section> <sectionanchor="delete-with-restore" title="Allowanchor="delete-with-restore"><name>Allow ExplicitDeleteDeletion of a Domain with RestoreCapability">Capability</name> <t> Explicit deletion of a domain name with a cascade purge of subordinate host objects and associations with other domains may be an unrecoverable operation, increasing the potential negative effects of malicious or accidental actions. </t> <t> To mitigate this risk, EPP servers can allow for the explicit deletion of a domain with subordinate host objects associated with other domains only when the associations can be restored by the <restore> operation described inRFC 3915<xreftarget="RFC3915" />.target="RFC3915"/>. </t> <t> 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 provides a preview of the deletion. </t> <t> If the action was malicious, accidental, or had negative side effects, the domain, its subordinate host objects, and the associations with other domains can be restored with the <restore> operationin RFC 3915<xref target="RFC3915"/> during the redemption period. The purge of the domain will correspond with the purging of the subordinate hosts objects and the associations at the end of the pending delete periodin RFC 3915.<xref target="RFC3915"/>. </t> <t> Due to the potentially large number of associations, the server can asynchronously update (e.g., add and remove from DNS) and purge the associations. </t> <t> This practice has not been observed in use. </t> <sectionanchor="delete-with-restore-pros" title="Practice Benefits">anchor="delete-with-restore-pros"><name>Practice Benefits</name> <t> This practice enables the clients to directly delete the domains that they need since the server will fully support restoration of the associations during the redemption period. The management of the domain and the subordinate hosts will be simplified for the client by supporting the explicit deletion of the domain with the capability of mitigating a destructive malicious or accidental action. </t> </section> <sectionanchor="delete-with-restore-cons" title="Practice Detriments">anchor="delete-with-restore-cons"><name>Practice Detriments</name> <t> By making it easier for a client to explicitly delete a domain having subordinate hosts with associations, there is higher risk of inadvertent side effects in a single delete command. There is existing risk in EPP of inadvertent side effects, such as adding the "clientHold" status to the domain that will impact the DNS resolution of the subordinate hosts and the associated delegations. The ability to easilyrollbackroll back the command is key to minimize the impact of the side effects. Another issue is the potential size of the database transaction to disable, re-enable, or purge the subordinate host associations, since there is no limit to the number of associations to delegated domains. Servers canbreak-upbreak up the disable, re-enable, or purge of the subordinate host associations into smaller transactions by implementing it asynchronously. </t> </section> </section> </section> </section> </section> <sectionanchor="recommendations" title="Recommendations">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 side effects:</t> <ul> <li>Rename host objects to a sacrificial name server host object maintained by the client (see <xreftarget="control-rename" format="counter" />).target="control-rename"/>). </li> <li> Delete host objects and associations with the restore option (see <xreftarget="delete-with-restore" format="counter" />)target="delete-with-restore"/>) based on explicit client requests (see <xreftarget="explicit-delete" format="counter" />).target="explicit-delete"/>). Provide requesting clients additional deletion details (see <xreftarget="additional-deletion-details" format="counter" />)target="additional-deletion-details"/>), and inform affected clients of changes (see <xreftarget="inform-affected-client" format="counter" />).target="inform-affected-client"/>). </li> <li> Rename host objects to a sacrificial name server host object that uses a special-use domain (see <xreftarget="renaming-new-special-use" format="counter" />)target="renaming-new-special-use"/>) that avoids the special-use domain issues described in <xreftarget="RFC8244" />.target="RFC8244"/>. Use of "sacrificial.invalid" (see <xreftarget="renaming-new-special-use" format="counter" />)target="renaming-new-special-use"/>) as the 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 that offers no additional operational benefit. </li> </ul> <t>All other practices described in <xref target="practice-analysis" /> are <bcp14>NOT RECOMMENDED</bcp14> due to undesired side effects.</t> </section> <sectionanchor="IANA" title="IANA Considerations">anchor="IANA"><name>IANA Considerations</name> <t>This documentdoes not contain any instructions for IANA.</t>has no IANA actions.</t> </section> <sectionanchor="Security" title="Security Considerations">anchor="Security"><name>Security Considerations</name> <t>This document describes guidance found inRFCs 5731<xref target="RFC5731"/> and5732<xref target="RFC5732"/> regarding the deletion of domain and host objects by EPP clients. That guidance sometimes requires that host objects be renamed such that they become "external" hosts (seeSection 1.1 of RFC 5731<xref target="RFC5731"/>)section="1.1"/>) in order to meet an EPP server's requirements for host object disassociation prior to domain object deletion. Host object renaming can introduce a risk of DNS resolution hijack under certain operational conditions. This document provides guidance that is intended to reduce the risk of DNS resolution failure or hijacking as part of the process of deleting EPP domain or host objects.</t> <t>Child domains that depend on host objects associated with domain objects sponsored by another EPP client for DNS resolution may be protected from hijacking through the use 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 may interfere with the use of controlled interruption IP addresses to alert registrants to DNS changes. EPP clients can periodically scan sponsored domains for association with sacrificial name servers and alert end users concerning those domains.</t> <t>In absence of DNSSEC use by the victim, an attacker who gains control of a singlenameservername server can use DNSSEC to instead take over the victim domain completely if the registry operator and registrar process for automated DS maintenance neglects to check allnameserversname 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 if, by chance, the queries happen to hit theattacker controlled nameserver.attacker-controlled name server. Subsequently, validating resolvers will no longer accept responses from the legitimatenameservers.name servers. Moreover, with the use ofCSYNCCSYNC, an attacker may update the domain NSrecordsrecords, removing the legitimatenameserversname servers entirely.</t> </section><section anchor="acks" title="Acknowledgments"> <t>The authors would like to thank the following people for their contributions to this document: Brian Dickson, James Gould, Pawel Kowalik, Mario Loffredo, James Mitchell, Matthew Thomas, Peter Thomassen, Duane Wessels, David Blacka.</t> </section></middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3915.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5730.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5731.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5732.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6761.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8244.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9476.xml" /> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6305.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7535.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.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 mentioned 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/reference.RFC.8499.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8590.xml" /> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9520.xml" /> <referenceanchor="risky-bizness" target="https://doi.org/10.1145/3487552.3487816">anchor="Risky-BIZness"> <front> <title>Risky BIZness: Risks Derived from Registrar Name Management</title> <author fullname="Gautam Akiwate" initials="G." surname="Akiwate" /> <author fullname="Stefan Savage" initials="S." surname="Savage" /> <author fullname="Geoffrey M. Voelker" initials="G." surname="Voelker" /> <author fullname="KC Claffy" initials="K." surname="Claffy" /> <date year="2021" month="Nov" /> </front> <refcontent>IMC '21: Proceedings of the 21st ACM Internet Measurement Conference</refcontent> <seriesInfo name="DOI" value="10.1145/3487552.3487816"/> </reference> <referenceanchor="risky-bizness-irtf"anchor="Risky-BIZness-IRTF" target="https://datatracker.ietf.org/doc/slides-115-irtfopen-risky-bizness-risks-derived-from-registrar-name-management/"> <front> <title>Risky BIZness: Risks Derived from Registrar Name Management</title> <author fullname="Gautam Akiwate" initials="G." surname="Akiwate" /> <author fullname="Stefan Savage" initials="S." surname="Savage" /> <author fullname="Geoffrey M. Voelker" initials="G." surname="Voelker" /> <author fullname="KC Claffy" initials="K." surname="Claffy" /> <date year="2022" month="Nov" /> </front> <refcontent>IETF 115 Proceedings</refcontent> </reference> <reference anchor="SAC048" target="https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-048-en.pdf"> <front> <title>SSAC Comment on Orphan Glue Records in the Draft Applicant Guidebook</title> <author> <organization>ICANN Security and Stability Advisory Committee</organization> </author> <date year="2011" month="May" day="12" /> </front> <seriesInfo name="SAC"value="48"/>value="048"/> </reference> <reference anchor="SAC125" target="https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-125-09-05-2024-en.pdf"> <front> <title>SSAC Report on Registrar Nameserver Management</title> <author> <organization>ICANN Security and Stability Advisory Committee</organization> </author> <date year="2024" month="May" day="9" /> </front> <seriesInfo name="SAC" value="125"/> </reference> </references> </references><section title="Change Log" removeInRFC="true"> <t>This section lists substantial changes to the document as it is being worked on.</t> <t>00:</t> <ol> <li>Initial working group version.</li> </ol> <t>01:</t> <ol> <li>Addressed feedback received during the WG adoption request. Re-included text to indicate if approaches<!--[rfced] FYI - We havebeen observed in practice or not.</li> </ol> <t>02:</t> <ol> <li>Section 1: Added sentence to bridge between renaming host objects 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.example.org" is a sacrificial host.</li> <li>Section 5.1: Added text to give some more context on "sacrificial" 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 toalphabetized thebest practice recommendationsnames listed in<xref target="recommendations"/>.</li> <li>Added "Sacrificial Name Server" tothetitleAcknowledgments section. We believe that was the intent as only one was out of<xref target="control-rename"/>.</li> </ol> <t>04:</t> <ol> <li>Updates to address working group last call feedback:</li> <li>Updatedorder. Let us know if you prefer theabstractoriginal order. --> <section anchor="acks" numbered="false"><name>Acknowledgments</name> <t>The authors would like tonote "new possible practices".</li> <li>Split <xref target="practice-analysis"/> into two sectionsthank the following people for their contributions tobetter identify observed practicesthis document: <contact fullname="David Blacka"/>, <contact fullname="Brian Dickson"/>, <contact fullname="James Gould"/>, <contact fullname="Pawel Kowalik"/>, <contact fullname="Mario Loffredo"/>, <contact fullname="James Mitchell"/>, <contact fullname="Matthew Thomas"/>, <contact fullname="Peter Thomassen"/>, and <contact fullname="Duane Wessels"/>.</t> </section> </back> <!--[rfced] FYI - As both "nameserver" andpossible practices.</li> <li>Added a specific recommendation"name server" were used throughout the document. We have updated all instances touse "sacrificial.invalid" in <xref target="recommendations"/>.</li> <li>Reorganized practice description sections into subsections of observed practices and potential practices.</li> </ol> <t>05:</t> <ol> <li>Move <xref target="inform-affected-client"/> into observed practices.</li> <li>Add clearer MUST NOT guidance on <xref target="renaming-external"/>, <xref target="renaming-non-provisioned"/>,"name server" for consistency. Please review and<xref target="renaming-pseudo-tld" />. </li> <li>Promoted subsectionlet us know ofpotential options to potential practices.</li> <li>Removed redundant explicit delete section.</li> <li>Increased TOC depth.</li> <li>Made section headers clearer, changing "Deletion Observed Practices" and similar to "Observed Practicesany objections. --> <!--[rfced] FYI - We have added an expansion forDeletionthe following abbreviation per Section 3.6 ofHosts," etc.</li> </ol> <t>06:</t> <ol> <li>Add reference to SSAC125 complementary document</li> <li>Change recommendations to use MUST language and referenceRFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully toRFC8244.</li> <li>Rewrite "Allow Explicit Delete ofensure correctness. Top-Level Domainwith Restore Capability" text for greater clarity.</li> </ol> <t>07:</t> <ol> <li>Consolidate Best Practice Recommendations <xref target="recommendations" /></li> <li>Make RFC 3915 normative.</li> </ol> <t>08:</t> <ol> <li>Changed subject(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<xref target="recommendations" /> recommendations from "An EPP server" to "EPP servers and clients."</li> </ol> <t>09:</t> <ol> <li>Updated <xref target="renaming-as112" />this nature typically result in more precise language, which is helpful forclarity around empty subdomain, to remove confusing/incorrect claim around "valid" DNS name, and to add DNAME mention.</li> <li>Added explanatory sentences to <xref target="introduction" />.</li> <li>Explicitly statereaders. Note thatother practices in analysis section areour script did notrecommended in <xref target="recommendations" />.</li> <li>Clarified sacrificial name server requirements in <xref target="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 "dedicated."</li> <li>Remove test/experimentflag any words in<xref target="renaming-existing-special-use-reserved" />.</li> <li>Change <xref target="control-rename" /> to require authoritative DNS service (previous SHOULD changed to MUST).</li> </ol> </section> </back>particular, but this should still be reviewed as a best practice. --> </rfc>