James, My comments are embedded below with JG2.
In summary, the concept of leveraging the domain pending delete period to cascade down to the child hosts and host to domain links (e.g., name servers), with the ability to rollback with a domain restore command, is interesting to investigate for mitigating the impact of accidental or malicious domain deletes that contain linked child hosts. This could help address the primary use case of wanting to delete a domain with linked child hosts. Thanks, -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: James Mitchell <james.mitch...@iana.org> Date: Wednesday, July 26, 2023 at 11:32 PM To: James Gould <jgo...@verisign.com> Cc: "shollenbeck=40verisign....@dmarc.ietf.org" <shollenbeck=40verisign....@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org> Subject: [EXTERNAL] Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Thanks! Replies with a JM. On Jul 26, 2023, at 6:22 AM, Gould, James <jgo...@verisign.com> wrote: 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 <image001.png> James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com [verisigninc.com]<https://secure-web.cisco.com/160fAXNDyvsXLV4kkwOIPJJwuV4F8swt9yx_3X6HhssqAPWXb5IXpVt3M_PvIcFKTM4pVE32Hw525OWMcX9IYnaIQWOU3QlCGG4ZtW0bw7cBUGSJfKxXwKU5dinag66jTVKfCjD7x8cmwrNu9vqEuhauQzopdw6rJHWJ_tgJwEfiQDO77d4SsgV44D_45tGSGYJ2tGHWyim7hdVcyZvHw_9bqEfigZE2OpXZeb_ZLqVzG5eh5Y1mIGytXIFZK4TBEKztWhzimI08pRXt3vYod9J8a5f5noDOdhYpShJtEIS8/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fverisigninc.com%2F__%3B%21%21PtGJab4%214EOVPv3pQzi9j_6Q5q8H2h7_lqdAfhHjwPNrJpkx65NazWCl5z6OPf0HSnw6BpgwfvozE4uro8hg1NPx_JjmuRSxMtk%24> From: regext <regext-boun...@ietf.org> on behalf of James Mitchell <james.mitch...@iana.org> Date: Tuesday, July 25, 2023 at 5:39 PM To: "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org> Cc: "regext@ietf.org" <regext@ietf.org> 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: 1. 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. JM: A counter point, while probably less likely, a registrar could accidentally rename those hosts, which would have an equivalent blast radius that also results in large transactions. I understand that you’re working at a much larger scale - I was working with 2-3 million domains. The problem with a rename is that a registrar might not be able to undo it, esp when renaming to an external host. However an accidental delete could be reversed while the domain is in the pending delete hold down period. Yes, Registry lock and clientDeleteProhibted are tools that can reduce the likelihood of an accident, but we all know that if those tools aren’t used, we’re one EPP command away from an accident. I’d wager that a registrar’s delete code is probably going to iterate over the subordinate hosts renaming them all before issuing the delete, because anybody can create junk subordinate hosts for the domain, and you force them to delete or rename those hosts to issue the delete domain command. JG2 – I agree that the renaming of the host can have an equivalent blast radius, but it is an update to a single host record with the host object model so there is no large transaction issue. Rolling back the host rename should be straight forward with a subsequent host rename, which will work for internal hosts but cannot be done for external hosts based on the MUST fail language in RFC 5732. The ability to rollback with the delete depends on when the child hosts and the name server links are deleted, which could occur at the time of the delete command or at the time of the purge after the pending delete period. If all child hosts are not linked, they can certainly be deleted at the time of the delete command and the purge after the pending delete period will only delete the domain record. Cascading the pending delete down to the child hosts is an interesting idea that could be undone easily with the domain restore command. This would help with the accidental or malicious use case. The domain and hosts with the pending delete status would not resolve in DNS, so issues would be seen quickly and there is the ability to roll it back. I was never sure if registry lock applied to subordinate hosts - I assume it would cover them to some degree otherwise it would present a gap in protection. Regardless, a registry lock concept could be applied to hosts either directly or indirectly. JG2 – Yes, the registry lock can be applied to hosts, but it’s not heavily used. 1. 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. JM - The delete results in the domain entering a hold down period that can be undone (eg pendingDelete). There are no referential integrity issues as other domains retain their reference to the subordinate hosts, that are by association pending delete. The deleted domain is pulled from the DNS immediately. My reference to lame delegations was that I recall leaving in the DNS the other NS records that target hosts that are pending delete. These “lame” delegations would be cleaned up both in the database and DNS when the deleted domain and its subordinate hosts are purged. I also recall preventing the creation of hosts while the parent domain is pending delete. JG2 – Yes, when the domain is in the pending delete status new child hosts cannot be created. I believe that if the child hosts were not deleted at the time of the domain delete command and went into the pending delete status, then I don’t believe the NS records should be included in DNS, but that adds complexity for DNS since the inclusion of the NS record would need to consider that status of the linked host record. The concept would be to get a preview of what would happen when the domain, child hosts, and name server links are purged. 1. 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. JM: Exactly. Catch any accidents up front. 1. 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. JM: Delegation issues would occur upfront (as they would with a rename). Those domains with one or more name servers not affected by the delete/rename would continue to resolve. 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? JM: I don’t recall any issues, though I think it wasn’t widely used in the prior iteration of the registry. JG2 – Good to know, thanks. I understand that the registry for .com and .net will likely see more renames as I assume a greater number of hosting providers probably use those TLDs and even rename between the TLDs. An EPP rename in your registry can’t be replicated in other registries because there is no method to authenticate the change - every other registry has to deal with individual updates. How do you propose to support a legitimate renaming of ns1.example.co.uk for all domains in com/net - who has the authority to make the change? JG2 – The sponsorship of the external hosts is based on a first-come-first-serve basis, where there is a single namespace. The “MUST fail language in RFC 5732” applies to updates to external hosts where there a links from domains sponsored by a different registrar, so ns1.example.co.uk will likely not be allowed to be renamed. The lack of the ability to update the external host can make rollback of a host rename not possible. 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. JM: I could go to a registrar and change my domains NS records to anything.example.com “by accident”, then fix my mistake. My registrar will create that host. Now the registrar of example.com can’t delete the domain until they delete or rename anything.example.com. This is not abuse. Could it be abused? I don’t know. JG2 – This sounds like a potential accidental use case and not a purposeful abuse use case. This is something to keep an eye on. James Best, James Mitchell On Jul 11, 2023, at 12:07 PM, Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org> 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 dn...@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!41ouVfZv-H-PkXJbxqURrX_y9d7JQb9SgFWJPcgp_h5k9ANClcwQBC_sayAWJb2Vf3GsszmkeckGNdzGeTAzkX7_dChe_p3b2Ll6XinPdw$ [ietf[.]org]
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
