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

Section 3.2.2 of RFC 5731 contains text that has led some domain name registrars (acting as EPP clients) to adopt an operational practice of re-naming name server host objects so that they can delete domain objects: "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." Similarly, Section 3.2.2 of RFC 5732 contains this text regarding deletion of 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 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. Section 3.2.5 of RFC 5732 describes 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 RFC 5732 includes a description of external hosts. Note that the specific method used to rename the host object can introduce risks of lame delegation (see Section 2.8 of RFC 1912 ). 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) 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. Aggressive re-queries 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 is an operation that might not be possible to reverse. This document describes the rationale for the "SHOULD NOT be deleted" text, the risk associated with host object renaming, and the best practices that can be used to mitigate that risk.

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 when, and only when, they appear in all capitals, as shown here.

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 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. Additionally, allowing host objects to exist after deletion of their superordinate domain object invites hijacking, as a malicious actor may re-register the domain object, potentially controlling resolution for the host objects and for their associated domain objects.

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 in RFCs 5731 and 5732 was written to encourage clients to take singular, discrete steps to delete objects in a way that maintains client-server data consistency.

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 in RFCs 5731 and 5732 was written to reduce the risk of these issues arising as a result of implicit object deletion.

As described in RFC 5731, it's 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: Domain object "domain1.example" is registered by ClientX. Domain object "domain2.example" is registered by ClientY. Subordinate host object "ns1.domain1.example" is registered by ClientX. Host object "ns1.domain1.example" is associated with domain object "domain1.example" by ClientX. Host object "ns1.domain1.example" is associated with domain object "domain2.example" by ClientY. 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 do so ClientX will need to rename host object "ns1.domain1.example" so that "domain1.example" can be deleted. 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. 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.

EPP clients MUST NOT rename host objects to presumably non-existent external host names (e.g., "ns1.example.com" to "ns1.example.org") or a non-existent parent domain in the authoritative repository (e.g., ".org"). EPP servers might not confirm that these hosts exist, are resolvable, or offer authoritative service for associated domains. Research has described how malicious actors have registered these parent domains and created child host objects to take control of DNS resolution for associated domains.

EPP clients MUST NOT rename host objects to ".alt" or other non-DNS labels. Researchers have suggested that clients rename host objects to use the ".alt" pseudo-TLD . However, the ".alt" pseudo-TLD is intended for use in non-DNS contexts . EPP servers SHOULD NOT deliberately add name server entries for non-DNS labels. These entries would mix DNS and non-DNS protocols, risk name collisions, create confusion, and potentially result in unpredictable resolver behaviors.

EPP clients MUST NOT knowingly rename host objects to point to services that are not authoritative for affected child domains. Some domain registrars, acting as EPP clients, have maintained host objects with glue records pointing to prominent public recursive DNS services. Queries for the associated domains result in SERVFAIL or other failure responses. Some recursive name server implementations may aggressively re-query for these responses, potentially resulting in large numbers of queries for unresolvable domains .

EPP clients SHOULD NOT rename host objects to subdomains of "as112.arpa". Some domain registrars, acting as EPP clients, have begun renaming host objects to subdomains of "as112.arpa" . This is a misuse of AS112, which is for reverse lookups on non-unique IPs, primarily so local admins can sinkhole non-global traffic . Unexpected AS112 traffic has previously caused problems with intrusion detection systems and firewalls .

EPP clients MAY rename to 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 . The sacrificial name server should run a DNS resolution service capable of responding with an authoritative non-error, non-failure response for requests made for associated domains. The service SHOULD provide responses that indicate problems with a domain's delegation, such as non-existence or include controlled interruption IP addresses .

The recommendations in RFC 5731 are intended to maintain consistency. However, they are not requirements. EPP servers MAY relax their constraints and allow sponsoring clients to delete host objects and disassociate them from domain objects sponsored by other clients. This could result in domains with no remaining name servers being removed from the zone or domains with only one remaining name server.

Consistent with the recommendations in RFC 5731 , 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 for all queries without delegating domains or records. This service could use a new special-use TLD created either through ICANN or IETF processes (e.g., ".sacrificial"), as an IAB request that IANA delegate a second-level domain (SLD) for ".arpa" (e.g., "sacrificial-nameserver.arpa"), or as a contracted sinkhole service by ICANN or other DNS ecosystem actors.

As noted previously, EPP servers can allow clients to delete host objects and disassociate them from domain objects. EPP servers can require that the EPP client explicitly request the deletion of the host object before taking this action. This may require that the EPP server provide the EPP client with additional details of the affected objects. The deleting EPP client may receive a message that deletion of the host object would affect domain objects sponsored by another client and may receive details about those objects. The sponsoring clients of affected domain objects can also be informed of the change.

This document does not contain any instructions for IANA.

This document describes guidance found in RFCs 5731 and 5732 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 (see Section 1.1 of RFC 5731 ) 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 hijacking 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. 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.

The authors would like to thank the following people for their contributions to this document: Matthew Thomas, Peter Thomassen.