On Tue, 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://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/ > > 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 > I have a few more (random) thoughts/musings about the RRR architecture and elements involved for EPP activity. These are things that were probably minor when the number of gTLDs was small, there were fewer Registrars, etc. Also, I don't think it is necessary to address these in the short term. Identifying them allows thinking about long term approaches, however. The host objects that are referenced might be same-registry things (so glue is provided with DNS responses), or different-registry things (no glue). This leads to redundancy (same objects being defined in multiple places), potential conflicts (first to register), inconsistencies, etc. However, those host objects in multiple Registries *should* always be the same real-world things that are referenced. Having a way to facilitate any of the kinds of checks and balances being discussed for different-registry as well as same-registry host object references is one potential issue. E.g. deletion of host objects, requirement for consent on references, owning Registrar, etc. are all things that might work better with some kind of correlation to real-world hosts and their respective owners. Similarly, it might be the case that Registrars could nominate some sort of default server(s) as substitutes (or sacrificial servers) to replace references to deleted host objects. This might scale better if there was some way to share/coordinate/dereference the original host objects and substitutes/sacrificials across Registries. This could avoid the NxM scaling problem (N Registrars, M Registries). It might be the case that the requirement for Registrars to supply their own substitute/sacrificial servers could end up in e.g. ICANN accreditation agreements, for example. This concept would not preclude outsourcing of such servers to third parties, I don't think. These ideas would seem to point in the direction of a model containing a more centralized "host Registry", that might only be used for inter-Registry EPP-related transactional activity, but not for storage of any canonical Host information (Registrar, glue), except by reference to the corresponding Registry (based on the name of the Host). I'm not sure if that would be feasible, or how that would be managed/controlled, etc. or whether that would work for non-gTLD cases (such as CCTLDs). Again, these are musings, not actual proposals or anything. Feedback on these is definitely welcome. Brian
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
