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
<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.mitchell@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.com@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
> DNSOP@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
>