RFC 9874

Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)

📅 published September 2025, from ietf

Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP) 🎀

okay bestie, this is RFC 9874 💖 It's a Best Current Practice (so it's BCP 244 🧚), published by the IETF in September 2025 with ISSN 2070-1721. The authors are S. Hollenbeck and W. Carroll from Verisign Labs, plus G. Akiwate from Stanford University. The title block doesn't list any RFCs it obsoletes or updates, so it's standing on its own 💅

Abstract 🦋

EPP has commands that let clients delete domain and host objects, and both of those are used to publish info in the Domain Name System (DNS). EPP already has guidance to avoid DNS resolution disruptions and keep data consistent, but relationships between objects can make that guidance really hard to follow 😭 So some EPP clients came up with their own deletion habits, and some of those habits have unintended effects on DNS resolution and security.

This document writes down the best current practices, and it also proposes some new potential practices for deleting domain and host objects. The goal is to lower the risk of DNS resolution failure and keep client and server data consistent ✨

Status of This Memo 📜

This memo documents an Internet Best Current Practice.

This document is a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on BCPs is in Section 2 of RFC 7841.

For the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9874 🔗

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read them carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 📄

Table of Contents 🌸

1.  Introduction
2.  Conventions Used in This Document
3.  Rationale for "SHOULD NOT be deleted"
  3.1.  DNS Considerations
  3.2.  Client-Server Consistency Considerations
  3.3.  Relational Consistency Considerations
4.  Host Object Renaming Risk
5.  Analysis of Practices for Domain and Host Object Deletion
  5.1.  Renaming to Sacrificial Hosts
    5.1.1.  Practice Benefits
    5.1.2.  Practice Detriments
    5.1.3.  Observed Practices for Renaming to Sacrificial Hosts
      5.1.3.1.  Renaming to External, Presumed Non-Existent Hosts
        5.1.3.1.1.  Practice Benefits
        5.1.3.1.2.  Practice Detriments
      5.1.3.2.  Renaming to "AS112.ARPA"
        5.1.3.2.1.  Practice Benefits
        5.1.3.2.2.  Practice Detriments
      5.1.3.3.  Renaming to Non-Authoritative Hosts
        5.1.3.3.1.  Practice Benefits
        5.1.3.3.2.  Practice Detriments
      5.1.3.4.  Renaming to Client-Maintained Dedicated Sacrificial
              Name Server Host Objects
        5.1.3.4.1.  Practice Benefits
        5.1.3.4.2.  Practice Detriments
    5.1.4.  Potential Practices for Renaming to Sacrificial Hosts
      5.1.4.1.  Renaming to Pseudo-TLD
        5.1.4.1.1.  Practice Benefits
        5.1.4.1.2.  Practice Detriments
      5.1.4.2.  Renaming to Existing Special-Use TLD
        5.1.4.2.1.  Renaming to Reserved TLD
      5.1.4.3.  Renaming to a Special-Use Domain
        5.1.4.3.1.  Practice Benefits
        5.1.4.3.2.  Practice Detriments
      5.1.4.4.  Renaming to Community Sacrificial Name Server
              Service
        5.1.4.4.1.  Practice Benefits
        5.1.4.4.2.  Practice Detriments
  5.2.  Deletion of Hosts
    5.2.1.  Observed Practices for Deletion of Hosts
      5.2.1.1.  Implicit Deletion of Affected Host Objects
        5.2.1.1.1.  Practice Benefits
        5.2.1.1.2.  Practice Detriments
      5.2.1.2.  Inform Affected Clients
        5.2.1.2.1.  Practice Benefits
        5.2.1.2.2.  Practice Detriments
    5.2.2.  Potential Practices for Deletion of Hosts
      5.2.2.1.  Request Explicit Deletion of Affected Host Objects
        5.2.2.1.1.  Practice Benefits
        5.2.2.1.2.  Practice Detriments
      5.2.2.2.  Provide Additional Deletion Details
        5.2.2.2.1.  Practice Benefits
        5.2.2.2.2.  Practice Detriments
      5.2.2.3.  Allow Explicit Deletion of a Domain with Restore
              Capability
        5.2.2.3.1.  Practice Benefits
        5.2.2.3.2.  Practice Detriments
6.  Recommendations
7.  IANA Considerations
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 💖

Section 3.2.2 of [RFC5731] has some text that led a few domain name registrars (acting as EPP clients) to adopt an operational practice: renaming name server host objects so they could delete domain objects. Here's that text:

A domain object SHOULD NOT 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" SHOULD NOT be deleted until host
"ns1.example.com" has either been deleted or renamed to exist in a
different superordinate domain.

Section 3.2.2 of [RFC5732] has similar text about deleting host objects:

A host name object SHOULD NOT 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 SHOULD NOT 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 host object.

These recommendations set up a real dilemma 😩 Say the sponsoring client for "example.com" wants to delete "example.com", but its host object "ns1.example.com" is also tied to domain objects sponsored by a different client. The guidance says don't delete the host object because of those associated domains. But the client can't directly update those domains, since another client sponsors them. Every EPP operator that has implemented host object support runs into this situation.

Section 3.2.5 of [RFC5732] covers host object renaming:

Host name changes can have an impact on associated objects that
refer to the host object.  A host name change SHOULD NOT 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 directly MUST
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 the client.

Section 1.1 of [RFC5732] describes external hosts. Some EPP clients have built operational practices that use host object renaming to break the association between a domain object and a host object. But the specific way a host object gets renamed can cause DNS delegation failures and bring real risks to management control 🚨 If the new external host points at an unregistered domain, a malicious actor could register that domain, create the host object, and take over DNS resolution for the domain that used to be associated with "ns1.example.com". If the new external host offers an authoritative DNS service but the domain isn't assigned to an account, a malicious actor could add the domain to a service account and hijack DNS resolution functionality. If the new external host offers recursive DNS service or no DNS service at all, DNS requests for the domain end up with SERVFAIL messages or other errors. Aggressive requeries from DNS resolvers can then generate huge numbers of spurious DNS queries for a domain that can't be resolved. Also, renaming a host object to the name of an external host can't be reversed by the EPP client 😱

This document covers the rationale behind the "SHOULD NOT be deleted" text in [RFC5731] and [RFC5732], along with the risk that comes with host object renaming. Section 5 has a detailed analysis of the practices that have been used, and that can be used, to reduce that risk. Section 6 has the specific best-practice recommendations 🍓

2. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Rationale for "SHOULD NOT be deleted" 🧠

3.1. DNS Considerations

The big thing to think about when deleting domain and host objects is what it does to DNS resolution 🌐 Deleting a domain object makes every name server tied to its subordinate host objects unresolvable. Deleting a host object makes any domain delegated to that name server unresolvable. The text in [RFC5731] and [RFC5732] was written to push clients toward taking singular, discrete steps to delete objects, so DNS resolution keeps working.

There's also a hijacking problem. If host objects are allowed to stick around after their superordinate domain object is deleted, a malicious actor may reregister that domain object, and then they could control resolution for those host objects and for the domains associated with them 👀 That setup also creates orphan glue, as described in [SAC048].

3.2. Client-Server Consistency Considerations

A server that implicitly deletes subordinate host objects in response to a request to delete a domain object can end up with a data inconsistency. The EPP client and the EPP server can have different ideas about what's still registered after a <delete> command gets processed 🤔 The text in [RFC5731] and [RFC5732] was written to encourage clients to take singular, discrete steps when deleting objects, so client-server data stays consistent. Experience suggests this inconsistency poses little operational risk, which is honestly a relief 🫶

3.3. Relational Consistency Considerations

Some EPP implementations depend on the hierarchical relationship between domain objects and host objects, and that relationship can live in a relational database 🗄️ When that's the case, deleting a domain object without dealing with its existing subordinate host objects can cause relational consistency and integrity issues. The text in [RFC5731] and [RFC5732] was written to lower the risk of those issues coming up when objects get deleted implicitly.

4. Host Object Renaming Risk ✨

okay so, as [RFC5731] explains, you can delete a domain object even when its host objects are managed by other clients 👀. You do it by renaming the host object so it lives under a different superordinate domain. This comes up a lot when the sponsoring client can't disassociate a host object from a domain object that someone else manages 💀. Only that other client is allowed to change their own domain object, and the EPP server won't process a delete request until the host object is disassociated. Picture it like this:

Domain object "domain1.example" is registered by ClientX.

Domain object "domain2.example" is registered by ClientY.

Subordinate host object "ns1.domain1.example" is registered and
associated with domain object "domain1.example" by ClientX.

Host object "ns1.domain1.example" is associated with domain object
"domain2.example" by ClientY.

So ClientX wants to delete domain1.example 🥺. They can edit domain1.example to remove the association with ns1.domain1.example, but they can't remove that host from domain2.example, because domain2.example belongs to ClientY and ClientX can't even tell that relationship exists. Only ClientY can change domain2.example. If ClientY doesn't do it, ClientX has to rename ns1.domain1.example so that domain1.example can finally be deleted.

ClientX renames ns1.domain1.example to ns1.example.org. That makes it an external host and satisfies the EPP server's subordinate host object disassociation requirement ✅. The renamed ns1.example.org is what people call a "sacrificial" host [Risky-BIZness] 🫠.

Here's the scary part 😱. If the domain example.org doesn't exist, this practice opens the door to DNS resolution hijacking. Someone could register example.org and create a subordinate host object named ns1.example.org. That name server would then get DNS queries for every domain delegated to it, so its operator could respond in potentially malicious ways 🚨.

5. Analysis of Practices for Domain and Host Object Deletion 🔍

EPP servers have a whole buffet of practices for deleting domain and host objects 🍓. The scope of any practice discussed here covers three things: the EPP server that adopts it, the domains that server manages, and the associated host objects. "Associated" is defined in [RFC5731] and [RFC5732]. The practices in this document fall into two big categories. One is renaming objects to use sacrificial hosts. The other is letting objects be deleted even when there are existing data relationships. Each category gets its own section below. If you want the bigger picture on how these practices affect registries and registrars, [SAC125] has some extra insight 🧠.

5.1. Renaming to Sacrificial Hosts 🎀

Sacrificial hosts are hosts whose name is meant to break an existing relationship between a domain object and a host object. So they either get renamed to an external host, or they get associated with a different domain object on the EPP server 🔄. This first group of deletion practices uses sacrificial hosts and leans on the EPP server's existing support for renaming host objects.

5.1.1. Practice Benefits 💖

Affected domains stay delegated in the zone 🏡. Registrars and registrants of those domains may be able to figure out what the change was for 🕵️‍♀️.

5.1.2. Practice Detriments 😩

Zones get crowded with irrelevant records 🗑️. And registrars and registrants of affected domains are required to clean them up.

5.1.3. Observed Practices for Renaming to Sacrificial Hosts 👀

5.1.3.1. Renaming to External, Presumed Non-Existent Hosts 🌫️

As we covered above, this practice renames subordinate host objects to an external host so the superordinate domain object can be deleted. The deleting EPP client presumes the external host doesn't exist, but usually nobody actually checks 🙃. This practice has been observed in use. This practice MUST NOT be used.

⚠️ bestie, this one is a hard no. The MUST NOT is there for a reason.

5.1.3.1.1. Practice Benefits 💅

The main benefit is convenience for the deleting EPP client. That client doesn't have to run an authoritative DNS service or handle any traffic 😌.

5.1.3.1.2. Practice Detriments 💀

Malicious actors have registered these parent domains and created child host objects so they can take over DNS resolution for the associated domains [Risky-BIZness] 😈. The sponsoring clients of those associated domains aren't told about the change. If all of a domain's hosts get renamed, the associated domains might stop resolving entirely. If they stay associated with existent hosts, they might still resolve. In that case, their partial vulnerability to hijacking is harder to spot 🫣.

5.1.3.2. Renaming to "AS112.ARPA" 🌐

Some domain registrars, acting as EPP clients, have renamed host objects to subdomains of "AS112.ARPA" or "EMPTY.AS112.ARPA" [Risky-BIZness-IRTF]. This practice has been observed in use.

5.1.3.2.1. Practice Benefits 💖

The main benefit is convenience for the deleting EPP client. That client doesn't have to run an authoritative DNS service or handle any traffic 😌.

5.1.3.2.2. Practice Detriments 😬

This is a misuse of AS112. AS112 is meant for reverse lookups on non-unique IPs, mostly so local admins can sinkhole non-global traffic [RFC7535]. "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]). Unexpected AS112 traffic has caused problems with intrusion detection systems and firewalls before [RFC6305] 🚩. Local administrators can potentially hijack requests 😱. And AS112 infrastructure must be maintained.

5.1.3.3. Renaming to Non-Authoritative Hosts 🫥

Some domain registrars, acting as EPP clients, have kept host objects with glue records pointing to prominent public recursive DNS services. This practice has been observed in use. This practice MUST NOT be used.

🚫 same energy as the last one, bestie. Don't do it.

5.1.3.3.1. Practice Benefits 💅

The main benefit is convenience for the deleting EPP client. That client doesn't have to run an authoritative DNS service or handle any traffic 😌.

5.1.3.3.2. Practice Detriments 📉

Queries for the associated domains come back with SERVFAIL or other failure responses. Some recursive name server implementations may aggressively requery for those responses, which can lead to huge numbers of queries for domains that can't be resolved [RFC9520] 🌪️.

5.1.3.4. Renaming to Client-Maintained Dedicated Sacrificial Name Server Host Objects 🛡️

EPP clients MAY rename the host object being deleted to a sacrificial name server host object that the client maintains itself 🫶. This means the client has to keep up the registration of that sacrificial name server's superordinate domain. The client may look into long registration periods, plus registrar and registry lock services, to maintain and protect both the superordinate domain and the host object. Failing to maintain these registrations has let domain hijacks happen [Risky-BIZness] 😭.

The client-maintained dedicated sacrificial name server MUST resolve to one or more IP addresses, and the client MUST operate an authoritative DNS name server on those addresses. The name server MAY provide any valid response ✨.

This practice has been observed in use 👩‍💻.

5.1.3.4.1. Practice Benefits 🥰

Associated domains can't be hijacked 🙌. They stay in the zone and keep valid DNS records plus a responsive DNS service. That service might return responses that flag a problem with a domain's delegation, like non-existence or controlled interruption IP addresses [RFC8023] 🚦.

5.1.3.4.2. Practice Detriments 🥲

This requires that the client maintain the registration of the sacrificial name server's superordinate domain. The client may look into long registration periods, plus registrar and registry lock services, to maintain and protect both the superordinate domain and the host object. Failing to maintain these registrations has let domain hijacks happen [Risky-BIZness].

Failure responses may cause aggressive requerying (see Section 5.1.3.3.2) 🔁.

5.1.4. Potential Practices for Renaming to Sacrificial Hosts 🔮

5.1.4.1. Renaming to Pseudo-TLD 🧚

Clients may rename host objects to use ".alt" or another non-DNS pseudo-TLD (Top-Level Domain), as suggested in [Risky-BIZness-IRTF]. This practice has not been observed in use. This practice MUST NOT be used.

5.1.4.1.1. Practice Benefits 💖

The main benefit is convenience for the deleting EPP client. That client doesn't have to run an authoritative DNS service or handle any traffic 😌. Dependent domains can't be hijacked through the registration of these identifiers and their delegation in the DNS 🛑.

5.1.4.1.2. Practice Detriments 🙈

The ".alt" pseudo-TLD is supposed to be used "to signify that this is an alternative (non-DNS) namespace and should not be looked up in a DNS context" [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 lead to unpredictable resolver behaviors 🌀. These identifiers may also be registered in non-DNS namespaces, which could lead to hijacking vulnerabilities in other systems 😵.

5.1.4.2. Renaming to Existing Special-Use TLD 🧩

Clients may rename host objects to a special-use TLD that can't resolve in the DNS. Several variations have been suggested. This practice has not been observed in use.

5.1.4.2.1. Renaming to Reserved TLD 🔒

Clients may rename host objects to use a reserved special-use [RFC6761] TLD, as suggested in [Risky-BIZness].

5.1.4.2.1.1. Practice Benefits 💅

The main benefit is convenience for the deleting EPP client. These TLDs are already reserved and won't resolve, and the deleting EPP client doesn't have to run an authoritative DNS service or handle any traffic 😌. Dependent domains can't be hijacked.

5.1.4.2.1.2. Practice Detriments 🤔

Using TLDs reserved for special purposes [RFC6761] may be confusing unless the community has designated a domain for this purpose (see "sacrificial.invalid" in Sections 5.1.4.3 and 6) 🫤. On top of that, EPP server policy may prevent their use altogether.

5.1.4.3. Renaming to a Special-Use Domain ✨

okay so clients could rename hosts to a special-use domain, or to any subdomain under one 🎀 the domain could be a special-use SLD (Second-Level Domain) like sacrificial.invalid, or a brand new reserved TLD like .sacrificial. using this domain would basically announce "hey, I'm making a sacrificial host" 💅 if a new TLD like that gets created through IETF or ICANN processes, IANA would add it to the "Special-Use Domain Name" registry 📝 nobody has actually used this practice yet 🥺 now, the questions from [RFC6761] are giving main character energy, so let's go through them:

  1. these names aren't expected to be visible to human users 👀 but the purpose of these domains is expected to be recognizable to humans, which is the whole point 💖
  2. application software isn't expected to recognize these names as special or treat them differently from any other allowed domain name 🫶
  3. name resolution APIs and libraries aren't expected to recognize these names as special either, so they treat them like any other allowed domain name 🌸
  4. caching name servers aren't expected to recognize these names as special or treat them differently from other allowed domain names 🧚
  5. authoritative name servers aren't expected to recognize them as special either, and they're treated like any other allowed domain name 💜 requests to the root for this domain would get an NXDOMAIN response [RFC9499] 💀
  6. DNS server operators will treat this domain and its subdomains the same as any other allowed names in the DNS 🦋
  7. DNS registries and registrars won't be able to register this domain, and they must deny requests to register it or any of its subdomains 🔥

5.1.4.3.1. Practice Benefits 💅

this option gives clarity about what registrars are up to when they rename hosts 🎀 it would also make it easier for registrars of affected domains to spot renamed hosts 👀 it's also super convenient for the deleting EPP client 🫶 that client isn't required to maintain an authoritative DNS service or receive traffic 💖 and dependent domains can't be hijacked through someone registering these identifiers and delegating them in the DNS 🛡️ iconic, honestly 😭

5.1.4.3.2. Practice Detriments 💀

this would need cooperation and policy changes from registrars and registries 🥺

5.1.4.4. Renaming to Community Sacrificial Name Server Service 🌈

okay, this one is a whole community project ✨ a new service could be created that's specifically meant for renaming host records 💅 it would need name servers that can answer every query with an NXDOMAIN or a controlled interruption IP address [RFC8023] 🔥 without delegating any domains or records 🧚 the service could use a new special-use TLD made through ICANN or IETF processes, like ".sacrificial" 🎀 or it could be an IAB request asking IANA to delegate an SLD under ".arpa", like "sacrificial-nameserver.arpa" 🌸 or it could be a contracted sinkhole service run by ICANN or other DNS ecosystem actors 💜 nobody has used this practice in the wild yet 🥺

5.1.4.4.1. Practice Benefits 💖

this is super convenient for the deleting EPP client 🫶 that client isn't required to maintain an authoritative DNS service or receive traffic 🦋 the associated domains aren't vulnerable to hijacking 🛡️ it would give everyone a well-understood, industry-standard solution, so registrars and registrants can easily spot associated domains that have been affected 👀 infrastructure operators could watch traffic to find affected associated domains that bring in a lot of traffic, then try to contact the registrars and registrants 📞 and economies of scale would bring down overall costs for the industry, compared with every client running its own independent service 💰 bestie, that's genius 👑

5.1.4.4.2. Practice Detriments 🙈

some entity has to maintain the infrastructure for the service 😭

5.2. Deletion of Hosts 🧚

okay, this is the second group of practices 💅 it's based on EPP server support for letting objects get deleted even when they have existing data relationships 🌸 the recommendations in [RFC5731] are meant to keep things consistent 🎀 but they aren't requirements, so it's kinda up to the server 🤷‍♀️

5.2.1. Observed Practices for Deletion of Hosts 🦋

5.2.1.1. Implicit Deletion of Affected Host Objects 🔥

EPP servers may relax their constraints and let sponsoring clients delete host objects without checking 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 ✅

5.2.1.1.1. Practice Benefits 💅

this is convenient for the deleting EPP client 🫶 that client isn't required to maintain an authoritative DNS service or receive traffic 🌸 and the associated domains aren't vulnerable to hijacking 🛡️

5.2.1.1.2. Practice Detriments 💀

this could result in domains with no name servers being removed from the zone, or domains with only one name server left in the zone 😱 deletions could affect large numbers of associated domains, which could put a lot of strain on domain registries 🥺

5.2.1.2. Inform Affected Clients 📣

the sponsoring clients of affected domain objects may also be told about the change, for example through the EPP Change Poll extension [RFC8590] 💌 this practice has been observed in use ✅

5.2.1.2.1. Practice Benefits 💖

updates help achieve the goals of client-server data consistency and minimal interruptions to resolution 🌈 the sponsoring clients of affected domain objects can update their database to reflect the change, and they'd be able to tell the domain's registrant 🎀 the sponsoring clients can also automatically update the affected domains to use another authoritative host 🫶

5.2.1.2.2. Practice Detriments 🙈

this change needs extra development on the part of EPP servers and clients 🛠️ there may be scalability concerns if large numbers of domain objects get updated in a single transaction 😵

5.2.2. Potential Practices for Deletion of Hosts 🔮

5.2.2.1. Request Explicit Deletion of Affected Host Objects 💅

sponsoring clients that request deletion of host objects would explicitly ask for them to be disassociated from domain objects sponsored by other clients 🎀 this practice has not been observed in use 🥺

5.2.2.1.1. Practice Benefits 🦋

registries wouldn't have to unilaterally take responsibility for deletion 👑 the deleting EPP client isn't required to maintain an authoritative DNS service or receive traffic 🌸 and the associated domains aren't vulnerable to hijacking 🛡️

5.2.2.1.2. Practice Detriments 💀

this could result in domains with no name servers being removed from the zone, or domains with only one name server left in the zone 😱 deletions could affect large numbers of associated domains, putting a lot of strain on domain registries 🥺

5.2.2.2. Provide Additional Deletion Details 🔍

the EPP server may give the deleting EPP client more details about the affected objects 🧚 the deleting EPP client may get a response, for example using the msg, reason, or msgQ elements of the EPP response [RFC5730], saying that deleting the host object would affect domain objects sponsored by another client 💌 it may also get details about those objects, for example through the EPP poll command 📬 this practice has not been observed in use 🥺

5.2.2.2.1. Practice Benefits 💖

the deleting EPP client would be able to better understand and assess the potential harms of deleting the host object 🧠 depending on what the message says, the deleting EPP client might choose extra actions, like delaying the deletion until manual approval comes through, renaming the host objects, or informing affected EPP clients 🌈 this gives EPP clients more flexibility around deletion 🎀 for example, they might only go ahead with deletions that have no impact on other clients 🫶

5.2.2.2.2. Practice Detriments 🙈

this change would need extra development on the part of EPP servers and clients 🛠️ there may be scalability concerns if large numbers of domain objects get updated in a single transaction 😵 and the EPP server has to figure out the relevant information to give the EPP client for its assessment 🧐

5.2.2.3. Allow Explicit Deletion of a Domain with Restore Capability 🦋

explicitly deleting a domain name with a cascade purge of subordinate host objects and their associations with other domains might be impossible to undo 😱 that raises the potential negative effects of malicious or accidental actions 💀

to reduce that risk 🛡️, EPP servers can allow explicit deletion of a domain with subordinate host objects associated with other domains, but only when the associations can be restored with the <restore> operation described in [RFC3915] 🔄

to allow restores, EPP servers may keep the subordinate host objects in a pendingDelete status and keep their associations with other domains 🧚 this makes the objects unavailable in the DNS and gives a preview of the deletion 👀

if the action was malicious, accidental, or had negative side effects, the domain, its subordinate host objects, and their associations with other domains can be restored with the <restore> operation [RFC3915] during the redemption period 💖 the purge of the domain will line up with purging the subordinate host objects and their associations at the end of the pending delete period [RFC3915] ⏳

because there could be a huge number of associations, the server can handle them asynchronously, for example by adding and removing them from DNS, and purge them that way 🌸

this practice has not been observed in use 🥺

5.2.2.3.1. Practice Benefits 💅

this practice lets clients directly delete the domains they need, since the server fully supports restoring the associations during the redemption period 🎀 managing the domain and its subordinate hosts gets simpler for the client, because they can explicitly delete the domain and still have the ability to undo a destructive malicious or accidental action 🛡️ iconic 👑

5.2.2.3.2. Practice Detriments 💀

when it's easier for a client to explicitly delete a domain with subordinate hosts that have associations, there's a higher risk of inadvertent side effects in a single delete command 😱 EPP already has the risk of inadvertent side effects, like adding the "clientHold" status to the domain, which would affect DNS resolution of the subordinate hosts and their associated delegations 🙈 being able to easily roll back the command is key to keeping that impact small 🔄 another issue is how big the database transaction could get when disabling, re-enabling, or purging the subordinate host associations, since there's no limit on how many associations a delegated domain can have 📈 servers can break the disable, re-enable, or purge of those associations into smaller transactions by doing it asynchronously 🧩

6. Recommendations 🎀

okay bestie, this is the part where we get to the big recs 💅 EPP servers and clients MUST implement one of the following practices to delete domain and host objects with minimal undesired side effects:

  • Rename host objects to a sacrificial name server host object maintained by the client (see Section 5.1.3.4).
  • Delete host objects and associations with the restore option (see Section 5.2.2.3) based on explicit client requests (see Section 5.2.2.1). Provide requesting clients additional deletion details (see Section 5.2.2.2), and inform affected clients of changes (see Section 5.2.1.2).
  • Rename host objects to a sacrificial name server host object that uses a special-use domain (see Section 5.1.4.3) that avoids the special-use domain issues described in [RFC8244]. Use of sacrificial.invalid (see Section 5.1.4.3) as the parent domain for the host objects is RECOMMENDED to avoid the overhead of creating a new TLD using either IETF or ICANN processes, which offers no additional operational benefit 🌸

All other practices described in Section 5 are NOT RECOMMENDED due to undesired side effects. so those are a hard no, babe 🙅‍♀️

7. IANA Considerations 🌈

Nothing for IANA to do here ✨ This document has no IANA actions.

8. Security Considerations 💀

okay, this section is lowkey the most dramatic one, so buckle up 😭 This document describes guidance found in [RFC5731] and [RFC5732] about deleting domain and host objects as an EPP client. That guidance sometimes means host objects have to be renamed so they become "external" hosts (see Section 1.1 of [RFC5731]), just so they meet an EPP server's rules for disassociating host objects before the domain object can be deleted. And here's the scary part: host object renaming can open up a risk of DNS resolution hijack under certain operational conditions 🙈 This document gives guidance meant to cut down on the risk of DNS resolution failure or hijacking while you're deleting EPP domain or host objects. We're protecting our people 🫶

Child domains that rely on host objects tied to domain objects sponsored by a different EPP client for DNS resolution might be protected from hijacking by using DNSSEC 🔐 Their resolution might also be shielded from the effects of deletion by using host objects associated with multiple domain objects. Heads up though: DNSSEC and multiple host objects may interfere with using controlled interruption IP addresses to alert registrants to DNS changes 👀 So EPP clients can periodically scan sponsored domains for association with sacrificial name servers and alert end users about those domains. Keep watch, bestie 🦋

Now the really unhinged part 💅 If the victim isn't using DNSSEC, an attacker who gets control of a single name server can use DNSSEC to take over the victim domain completely, if the registry operator and registrar process for automated DS maintenance doesn't bother to check all name servers for consistency in CDS/CDNSKEY records 😱 In that case the domain ends up with DS records derived from the attacker's CDS/CDNSKEY records if, by chance, the queries happen to hit the attacker-controlled name server. After that, validating resolvers will no longer accept responses from the legitimate name servers. And it gets worse: with CSYNC, an attacker may update the domain NS records and remove the legitimate name servers entirely. Not me gasping at this 💀

9. References 📚

9.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3915]  Hollenbeck, S., "Domain Registry Grace Period Mapping for
           the Extensible Provisioning Protocol (EPP)", RFC 3915,
           DOI 10.17487/RFC3915, September 2004,
           <https://www.rfc-editor.org/info/rfc3915>.

[RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
           STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
           <https://www.rfc-editor.org/info/rfc5730>.

[RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
           Domain Name Mapping", STD 69, RFC 5731,
           DOI 10.17487/RFC5731, August 2009,
           <https://www.rfc-editor.org/info/rfc5731>.

[RFC5732]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
           Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732,
           August 2009, <https://www.rfc-editor.org/info/rfc5732>.

[RFC6761]  Cheshire, S. and M. Krochmal, "Special-Use Domain Names",
           RFC 6761, DOI 10.17487/RFC6761, February 2013,
           <https://www.rfc-editor.org/info/rfc6761>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8244]  Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain
           Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244,
           October 2017, <https://www.rfc-editor.org/info/rfc8244>.

[RFC9476]  Kumari, W. and P. Hoffman, "The .alt Special-Use Top-Level
           Domain", RFC 9476, DOI 10.17487/RFC9476, September 2023,
           <https://www.rfc-editor.org/info/rfc9476>.

9.2. Informative References

[RFC6305]  Abley, J. and W. Maton, "I'm Being Attacked by
           PRISONER.IANA.ORG!", RFC 6305, DOI 10.17487/RFC6305, July
           2011, <https://www.rfc-editor.org/info/rfc6305>.

[RFC7535]  Abley, J., Dickson, B., Kumari, W., and G. Michaelson,
           "AS112 Redirection Using DNAME", RFC 7535,
           DOI 10.17487/RFC7535, May 2015,
           <https://www.rfc-editor.org/info/rfc7535>.

[RFC8023]  Thomas, M., Mankin, A., and L. Zhang, "Report from the
           Workshop and Prize on Root Causes and Mitigation of Name
           Collisions", RFC 8023, DOI 10.17487/RFC8023, November
           2016, <https://www.rfc-editor.org/info/rfc8023>.

[RFC8590]  Gould, J. and K. Feher, "Change Poll Extension for the
           Extensible Provisioning Protocol (EPP)", RFC 8590,
           DOI 10.17487/RFC8590, May 2019,
           <https://www.rfc-editor.org/info/rfc8590>.

[RFC9499]  Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219,
           RFC 9499, DOI 10.17487/RFC9499, March 2024,
           <https://www.rfc-editor.org/info/rfc9499>.

[RFC9520]  Wessels, D., Carroll, W., and M. Thomas, "Negative Caching
           of DNS Resolution Failures", RFC 9520,
           DOI 10.17487/RFC9520, December 2023,
           <https://www.rfc-editor.org/info/rfc9520>.

[Risky-BIZness]
           Akiwate, G., Savage, S., Voelker, G., and K. Claffy,
           "Risky BIZness: Risks Derived from Registrar Name
           Management", IMC '21: Proceedings of the 21st ACM Internet
           Measurement Conference, DOI 10.1145/3487552.3487816,
           November 2021, <https://doi.org/10.1145/3487552.3487816>.

[Risky-BIZness-IRTF]
           Akiwate, G., Savage, S., Voelker, G., and K. Claffy,
           "Risky BIZness: Risks Derived from Registrar Name
           Management", IETF 115 Proceedings, November 2022,
           <https://datatracker.ietf.org/doc/slides-115-irtfopen-
           risky-bizness-risks-derived-from-registrar-name-
           management/>.

[SAC048]   ICANN Security and Stability Advisory Committee, "SSAC
           Comment on Orphan Glue Records in the Draft Applicant
           Guidebook", SAC 048, 12 May 2011,
           <https://itp.cdn.icann.org/en/files/security-and-
           stability-advisory-committee-ssac-reports/sac-048-en.pdf>.

[SAC125]   ICANN Security and Stability Advisory Committee, "SSAC
           Report on Registrar Nameserver Management", SAC 125, 9 May
           2024, <https://itp.cdn.icann.org/en/files/security-and-
           stability-advisory-committee-ssac-reports/sac-
           125-09-05-2024-en.pdf>.

Acknowledgments 🫶

The authors want to thank these lovely people for their contributions to this document: David Blacka, Brian Dickson, James Gould, Pawel Kowalik, Mario Loffredo, James Mitchell, Matthew Thomas, Peter Thomassen, and Duane Wessels 💖

Authors' Addresses 💜

Scott Hollenbeck
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Email: shollenbeck@verisign.com
URI:   https://www.verisignlabs.com/


William Carroll
Verisign Labs
12061 Bluemont Way
Reston, VA 20190
United States of America
Phone: +1 703 948-3200
Email: wicarroll@verisign.com
URI:   https://verisign.com


Gautam Akiwate
Stanford University
450 Jane Stanford Way
Stanford, CA 94305
United States of America
Phone: +1 650 723-2300
Email: gakiwate@cs.stanford.edu
URI:   https://cs.stanford.edu/~gakiwate/
📦 where this page comes from