Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP)
draft-hollenbeck-regext-epp-delete-bcp-00

REGEXT Working Group                                       S. Hollenbeck
Internet-Draft                                             Verisign Labs
Intended status: Best Current Practice                        W. Carroll
Expires: 25 December 2023                                       Verisign
                                                            23 June 2023

Best Practices for Deletion of Domain and Host Objects in the Extensible
                      Provisioning Protocol (EPP)
               draft-hollenbeck-regext-epp-delete-bcp-00

Abstract

   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 includes
   guidance concerning those 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 practices to
   delete domain and host objects that reduce the risk of DNS resolution
   failure and maintain client-server data consistency.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 25 December 2023.

Copyright Notice

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

Hollenbeck & Carroll    Expires 25 December 2023                [Page 1]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   4
   3.  Rationale for "SHOULD NOT be deleted" . . . . . . . . . . . .   4
     3.1.  DNS Considerations  . . . . . . . . . . . . . . . . . . .   4
     3.2.  Client-Server Consistency Considerations  . . . . . . . .   4
     3.3.  Relational Consistency Considerations . . . . . . . . . .   5
   4.  Host Object Renaming Risk . . . . . . . . . . . . . . . . . .   5
   5.  Practices to Avoid for Domain and Host Object Deletion  . . .   6
     5.1.  Avoid Renaming to External, Presumed Non-Existent
           Hosts . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Avoid Renaming to Non-DNS Hosts . . . . . . . . . . . . .   6
     5.3.  Avoid Renaming to Non-Authoritative Hosts . . . . . . . .   6
     5.4.  Avoid Renaming to "as112.arpa"  . . . . . . . . . . . . .   7
   6.  Best Current Practices for Domain and Host Object Deletion  .   7
     6.1.  Rename to a Host Object Maintained by the Client  . . . .   7
     6.2.  Allow Explicit Delete of Host Objects . . . . . . . . . .   7
   7.  Potential Practices for Domain and Host Object Deletion . . .   7
     7.1.  Community Sacrificial Name Server Service . . . . . . . .   8
     7.2.  Options for Allowed Delete of Associated Host Objects . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Section 3.2.2 of RFC 5731 [RFC5731] 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:

Hollenbeck & Carroll    Expires 25 December 2023                [Page 2]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

   "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 [RFC5732] 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 [RFC5732] 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
   [RFC1912]).  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

Hollenbeck & Carroll    Expires 25 December 2023                [Page 3]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

   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.

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 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.

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 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.

Hollenbeck & Carroll    Expires 25 December 2023                [Page 4]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

3.3.  Relational Consistency Considerations

   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.

4.  Host Object Renaming Risk

   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.

Hollenbeck & Carroll    Expires 25 December 2023                [Page 5]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

   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.

5.  Practices to Avoid for Domain and Host Object Deletion

5.1.  Avoid Renaming to External, Presumed Non-Existent Hosts

   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 [risky-bizness] has described how malicious actors have
   registered these parent domains and created child host objects to
   take control of DNS resolution for associated domains.

5.2.  Avoid Renaming to Non-DNS Hosts

   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 [risky-bizness-irtf].  However, the
   ".alt" pseudo-TLD is intended for use in non-DNS contexts
   [I-D.ietf-dnsop-alt-tld].  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.

5.3.  Avoid Renaming to Non-Authoritative Hosts

   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
   [I-D.ietf-dnsop-caching-resolution-failures].

Hollenbeck & Carroll    Expires 25 December 2023                [Page 6]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

5.4.  Avoid Renaming to "as112.arpa"

   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"
   [risky-bizness-irtf].  This is a misuse of AS112, which is for
   reverse lookups on non-unique IPs, primarily so local admins can
   sinkhole non-global traffic [RFC7535].  Unexpected AS112 traffic has
   previously caused problems with intrusion detection systems and
   firewalls [RFC6305].

6.  Best Current Practices for Domain and Host Object Deletion

6.1.  Rename to a Host Object Maintained by the Client

   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 [risky-bizness].

   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 [RFC8023].

6.2.  Allow Explicit Delete of Host Objects

   The recommendations in RFC 5731 [RFC5731] 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.

7.  Potential Practices for Domain and Host Object Deletion

Hollenbeck & Carroll    Expires 25 December 2023                [Page 7]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

7.1.  Community Sacrificial Name Server Service

   Consistent with the recommendations in RFC 5731 [RFC5731], 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 [RFC8023] 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.

7.2.  Options for Allowed Delete of Associated Host Objects

   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.

8.  IANA Considerations

   This document does not contain any instructions for IANA.

9.  Security Considerations

   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
   [RFC5731]) 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

Hollenbeck & Carroll    Expires 25 December 2023                [Page 8]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

   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.

10.  Acknowledgments

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

11.  References

11.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>.

   [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>.

   [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>.

11.2.  Informative References

   [RFC1912]  Barr, D., "Common DNS Operational and Configuration
              Errors", RFC 1912, DOI 10.17487/RFC1912, February 1996,
              <https://www.rfc-editor.org/info/rfc1912>.

   [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>.

Hollenbeck & Carroll    Expires 25 December 2023                [Page 9]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

   [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>.

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

   [I-D.ietf-dnsop-alt-tld]
              Kumari, W. A. and P. E. Hoffman, "The ALT Special Use Top
              Level Domain", Work in Progress, Internet-Draft, draft-
              ietf-dnsop-alt-tld-25, 4 May 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
              alt-tld-25>.

   [I-D.ietf-dnsop-caching-resolution-failures]
              Wessels, D., Carroll, W., and M. Thomas, "Negative Caching
              of DNS Resolution Failures", Work in Progress, Internet-
              Draft, draft-ietf-dnsop-caching-resolution-failures-03, 21
              June 2023, <https://datatracker.ietf.org/doc/html/draft-
              ietf-dnsop-caching-resolution-failures-03>.

Appendix A.  Change Log

   1.  Initial version.

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/

Hollenbeck & Carroll    Expires 25 December 2023               [Page 10]
Internet-Draft   Domain and Host Object Deletion in EPP        June 2023

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

Hollenbeck & Carroll    Expires 25 December 2023               [Page 11]