Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

["Gould, James" <[e-mail]>]

James,

I find your historic EPP server policies to be very interesting.  I provide comments embedded with your points below with a “JG – “ prefix.

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]> on behalf of James Mitchell <[e-mail]>
Date: Tuesday, July 25, 2023 at 5:39 PM
To: "Hollenbeck, Scott" <shollenbeck=[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host

Feedback my own and not from IANA.

If I recall correctly, the approach I took when building an EPP server several years ago was:

  *   allow deletion of domains with linked subordinate hosts – there is no need to prevent this if the registrar can simply rename the subordinate hosts and free themselves of this restriction

JG - Allowing the deletion of the parent domain with a set of linked child hosts can result in an extremely large OLTP transaction and more importantly can result in severe DNS delegation issues.  This is even more for the bad case of an accidently or maliciously deletion.  There is no way for the registry to know whether the deletion is a good case or a bad case, and with both cases the size of the OLTP transaction can result in system stability issues.  I would not leave the lame delegations, so that means a cascade delete from the parent domain to all child hosts and all name server links to those child hosts.  Imagine if registrar accidentally or maliciously deleted a large ISP domain name (e.g., isp.example) with a large set of child hosts that are linked to thousands of domain names.  There are other bad things a registrar could do, such as putting the clientHold status on the ISP domain name, but that can be easily reversed.  Bad deletes and updates can be protected via a registry lock service, but otherwise the registry needs to reduce the blast radius based on the data it has available.



  *   when the domain is removed from DNS (deletion, but also client/serverHold) then the delegation and any glue is removed from the DNS – queries for the name result in NXDomain. I believe we left lame delegations from other domains for simplicity, but these lame nameservers could also have been pulled from the DNS.

JG – Leaving the lame nameserver delegations in place would be a referential integrity issue in the registry database, assuming that the name server object model is being used.


  *   when the domain is purged, purge all subordinate hosts, including all their nameserver associations, and remove those records from the DNS. At this point there are no NS records with target at or below the deleted domain - no lame delegations.

JG – This moves the large OLTP transaction problem to the backend with the purge.  The DNS resolution issues would have occurred upfront when the parent domain is deleted.


  *   domains with one remaining name server remain published in the DNS

JG – The number of domains linked to the deleted child hosts is non-deterministic, so there will be some that still have active delegating name servers and some that have none after the delete and purge.

It may be worth noting that we used a narrow glue policy - only publish glue address records for name servers below the delegation. A wide glue policy may require slightly different actions to prevent promoting glue records to authoritative.

JG – The glue could be required for all internal hosts.

Host rename always seemed a dangerous operation – we ended up allowing it but restricted to renaming hosts within the same domain, eg ns1.example.com to nsa.example.com, but not to nsa.another-example.com.

JG – The host rename is a real use case that can certainly include renaming outside of the parent domain.  To handle the rename outside of the parent domain with the restricted policy, the registrar would need to create a new internal host or external host and require all linked domain names to be updated to point to it instead of the old host.  There can be thousands of linked domain names that would need to be updated and there is no formal method of communication to inform them to update their domain names.  Did a registrar have an issue with this restriction?

I was not okay with allowing a third-party registrar to prevent deletion of a domain by creating subordinate hosts, and I was not okay by allowing one registrar to change the delegation for another domain (through a rename outside the existing domain boundary).

JG – Is there a use case of wanting to prevent the deletion of a domain by creating child hosts?  This may be a valid use case, but I simply haven’t come across it.

Best,
James Mitchell

On Jul 11, 2023, at 12:07 PM, Hollenbeck, Scott <shollenbeck=[e-mail]> wrote:
Folks, we could really use feedback from people with DNS expertise to help
document a set of best practices for managing existing DNS delegations at the
TLD level when EPP domain and host objects are deleted. As described in this
draft:

https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/__;!!PtGJab4!41ouVfZv-H-PkXJbxqURrX_y9d7JQb9SgFWJPcgp_h5k9ANClcwQBC_sayAWJb2Vf3GsszmkeckGNdzGeTAzkX7_dChe_p3b2Lnb-bPfrw$ [datatracker[.]ietf[.]org]

EPP includes recommendations to not blindly delete objects associated with
existing delegations because, among other reasons, doing so can lead to DNS
resolution failure. That's led some domain name registrars to implement
creative practices that expose domains to risks of both lame delegation [1]
and management hijacking. The draft includes descriptions of current known
practices and suggests that some should be avoided, some are candidates for
"best", and there are others that haven't been used that might also be
candidates for "best". The authors would like to learn if others agree with
our assessments and/or can suggest improvements.

Please help. ICANN's SSAC is also looking at this issue and expert opinions
will help us improve DNS resolution resilience. I plan to mention this quickly
at IETF-117 given that the WG agenda is already full, but on-list discussion
would be extremely valuable.

Scott

[1] As described in draft-ietf-dnsop-rfc8499bis.

_______________________________________________
DNSOP mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!41ouVfZv-H-PkXJbxqURrX_y9d7JQb9SgFWJPcgp_h5k9ANClcwQBC_sayAWJb2Vf3GsszmkeckGNdzGeTAzkX7_dChe_p3b2Ll6XinPdw$ [ietf[.]org]