Thanks for the feedback, Brian. Notes below…
From: Brian Dickson <brian.peter.dick...@gmail.com> Sent: Tuesday, July 11, 2023 6:23 PM To: Hollenbeck, Scott <shollenb...@verisign.com> Cc: dnsop@ietf.org Subject: [EXTERNAL] Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. On Tue, 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://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/ <https://secure-web.cisco.com/1mD4wuR1TtAFOB2p8C83LBXV6A9T65cdm1G7UhFUnZpEar4TPD81E9IyIiSlUYG1ggp_3B5szOgXkFYbf8XGjnpeWQ_G7ZFL-GtQyiGIwF9X1FZuW6zB_c3heeRhGONxZ5UcWS6JvI1cN_T1JygemfOtWS51X7Gyw3tvesEdyP1MP92JKvWvHc0gryl8AbZ2x90gh1xnrj_6yO4efIPehHCHdzTYv720UskxvRm0RiqSUFip10kkZMCBB14DARcDxDe3S9m23OWyje4i82nZalfVn0udtYT6gHT_E2nuP47xs0yyGkDKbX27vtCSIsytS/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-hollenbeck-regext-epp-delete-bcp%2F> 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 believe the fundamental root problem is the "security model" (for lack of a better term) for EPP. I realize EPP long predates much of the efforts in the DNS world, and the fact that it didn't anticipate these problems shouldn't result in any blame. That should not excuse resistance to fixing deficiencies in EPP, if that is what is needed to resolve these issues. While there may be better or worse practices available within the current model for EPP, sticking with what EPP currently does without including the EPP model as being in scope, may be sub-optimal. [SAH] Indeed, and that’s why the draft also includes a proposal in Section 6.2 to allow for deletion when necessary. The canonical situation described in the linked draft encapsulates the model problems: it is possible (and in fact unavoidable) for unrelated EPP clients (registrants with different registrars) to interfere with what should be straightforward operations (eg deleting a host record). This issue also presents itself in permanently 100% lame delegations, where the NS delegations for a domain are pointed to a DNS provider for which the domain is unknown (not authoritative for the domain). That situation exposes the DNS provider to arbitrary levels of abuse via open (aka "public") resolvers. I think a more appropriate model would be to require (or at least facilitate) bilateral control on delegations (opt-in or opt-out, basically). For example, the registrar for the domain that is the parent of a host entry, should be able to "disavow" a particular reference (delegation to said host). It would be the responsibility of the other registrar (for the domain being disavowed) to clean up the broken delegations. This is basically giving authority to the DNS operator as a party to the situation, even if only indirectly. [SAH] Agreed as noted above. If there’s more that can be done, I’ll gladly consider adding text. Having the original host object owner provide the sacrificial target places the burden on the wrong party, somewhat analogous to "blaming the victim". Maybe having the otherwise dangling or otherwise blocking references converted to their respective in-bailiwick names might be a solution. E.g. if domain2.example had an NS record pointing to ns1.domain1.example, and domain1.example were deleted (or ns1.domain1.example were deleted), having the reference converted (by whom??) to ns1.domain2.example would suffice. But, that would also require picking a new IP address to use for the glue for that (new) host object. It's a thorny problem, a real can of worms. Seperate "thread" on the name/control issue: I think there is a corresponding "blind spot" that exists, that might also need to be addressed: the concept of ownership of IP addresses used within "glue" records. The DNS "NS" record uses a name as the target, and necessitates corresponding A/AAAA records to resolve delegations. However, the DNS protocol does not make use of names for DNS lookups by resolvers. DNS queries use addresses only. This means that unrelated glue records could point at the same IP address, even if the host records are distinct with different owners. First-to-register does not guarantee that the correct ownership could be determined by creation time (i.e. it's a race condition without a stronger mechanism.) Basically, I don't think there are any easy answers, but it definitely is a real-world problem. [SAH] For sure! That’s precisely why we’re trying to provide guidance to help address the issue in responsible ways. Brian P.S. I will admit to being the author of the concept of naming things under "empty.as112.arpa", as the creative approach that is referenced in the draft's references. It's somewhat sneaky, but in the absence of a better approach, directs abusive delegations into a black hole of sorts. I will gladly endorse any better approach that avoids the burden of third-party delegations being maintained by the first party (who may no longer be being paid if there is no longer a domain registration tied to the original sacrificial entry.) [SAH] The draft current suggests avoiding this approach in Section 5.4, but that’s based on the authors’ interpretation of RFCs 6305 and 7535. If others think differently, we’re open to making changes. Scott
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
