That a registrar can change the delegation of a domain managed by another registrar, point it to anywhere (which led to this discussion), without the consent of the registrant. As noted, I allowed renaming, but restricted it to within the existing domain boundary – the registrant trusted example.com when they delegated to ns1.example.com.
Assuming the legitimate case where a host is actually being renamed, this only works when the registry is superordinate to the host – no registrar should have permission to rename the host alexia.ns.cloudflare.com in the .example registry (who would it be?). Therefore, in the .example registry, a rename for alexia.ns.cloudflare.com requires domain updates for each domain delegated to that nameserver. Rename is effectively a mechanism for bulk update that only works in one registry. Aside, renaming affects only one side of the delegation. The registrant (or their DNS provider) needs to be involved to resolve the inconsistency between the delegation and authoritative NS records. I understand there are cases where rename could be beneficial, such as if/when GoDaddy rename one of their name servers, but it seemed to me like a premature optimization in the protocol. Ultimately, if a registrar is going to delete a domain, they’ll make it happen, and other domains delegated to hosts subordinate to that domain will be in some form of trouble. The goal of the registry should be to minimize the fallout. James From: Q Misell <q...@as207960.net> Date: Tuesday, July 25, 2023 at 3:05 PM To: James Mitchell <james.mitch...@iana.org> Cc: "Hollenbeck, Scott" <shollenbeck=40verisign....@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org> Subject: Re: [regext] [Ext] [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host > Host rename always seemed a dangerous operation Why so? ________________________________ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 [find-and-update.company-information.service.gov.uk]<https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!PtGJab4!7pILx59EsrjEUjevdEz_6zA2qrNGGSRp7uQ2EqHozGH8QFxu_g8Oom8qChbqkLoNT6sZfb8KT30XhGtxM2KEB_Rh$>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 [ico.org.uk]<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!PtGJab4!7pILx59EsrjEUjevdEz_6zA2qrNGGSRp7uQ2EqHozGH8QFxu_g8Oom8qChbqkLoNT6sZfb8KT30XhGtxM4N8zlQ-$>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Tue, 25 Jul 2023 at 14:39, James Mitchell <james.mitch...@iana.org<mailto:james.mitch...@iana.org>> wrote: 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 · 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. · 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. · domains with one remaining name server remain published in the DNS 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. 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 [ns1.example.com]<https://urldefense.com/v3/__http:/ns1.example.com__;!!PtGJab4!7pILx59EsrjEUjevdEz_6zA2qrNGGSRp7uQ2EqHozGH8QFxu_g8Oom8qChbqkLoNT6sZfb8KT30XhGtxM3sF-M9h$> to nsa.example.com [nsa.example.com]<https://urldefense.com/v3/__http:/nsa.example.com__;!!PtGJab4!7pILx59EsrjEUjevdEz_6zA2qrNGGSRp7uQ2EqHozGH8QFxu_g8Oom8qChbqkLoNT6sZfb8KT30XhGtxM2X3dtFG$>, but not to nsa.another-example.com [nsa.another-example.com]<https://urldefense.com/v3/__http:/nsa.another-example.com__;!!PtGJab4!7pILx59EsrjEUjevdEz_6zA2qrNGGSRp7uQ2EqHozGH8QFxu_g8Oom8qChbqkLoNT6sZfb8KT30XhGtxM8HsVRH5$>. 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). Best, James Mitchell On Jul 11, 2023, at 12:07 PM, Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org<mailto: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$<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<mailto:dn...@ietf.org> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dnsop__;!!PtGJab4!41ouVfZv-H-PkXJbxqURrX_y9d7JQb9SgFWJPcgp_h5k9ANClcwQBC_sayAWJb2Vf3GsszmkeckGNdzGeTAzkX7_dChe_p3b2Ll6XinPdw$<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<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!7pILx59EsrjEUjevdEz_6zA2qrNGGSRp7uQ2EqHozGH8QFxu_g8Oom8qChbqkLoNT6sZfb8KT30XhGtxM890rg2o$>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
