Not being an EPP expert, it seems to me that if the below works (which it seems
to have?), it addresses pretty much all concerns in a very reasonable way.
Would there be any reasons for not making this the recommended practice?
Peter
On 7/25/23 14:39, James Mitchell 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
<[email protected]> 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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
