+regext IMHO, this draft should take a position on which is the actual best (even if not current) practice, and then provide arguments to that point. Or maybe provide pros/cons for each, because evaluating which to do has different criteria for different people.
Also, I don't believe either of the items listed in section 6 are "best". A client sponsored sacrificial nameserver means that a registrar must establish security practices around that nameserver over the lifetime of all domains using it. Additionally, can registrar A simply start using the sacrificial nameserver of registrar B? I don't know, but if so then that's not good. WRT to behavioral changes in EPP, the downside is that registrars will need to keep track of which registries implement the new behavior as it is unlikely that all registries will switch at the same time. And EPP changes may require downstream changes in customer portals, etc... -andy On Wed, Jul 12, 2023 at 8:47 AM Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org> wrote: > > 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: dn...@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> 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 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 > dn...@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
