> 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 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. 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> 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 to nsa.example.com, but not to nsa.another-example.com. > > > > 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> 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 >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
