Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host
On Tue, Jul 11, 2023 at 07:06:49PM +, Hollenbeck, Scott wrote: > https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/ > > 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. Thanks for reaching out, I'll do my best to share what I hope is a sensible perspective. But first some followups to already posted feedback. On Tue, Jul 11, 2023 at 03:22:40PM -0700, Brian Dickson wrote: > 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. Just checking the intent here, I think you're saying the "disavowal" is potentially a case-by-case option. So that e.g. at the time that DNS service for a domain is discontinued, the DNS operator (perhaps via their registrar) should be able to break drop NS records from a *particular* delegation. This is an interesting proposal. It reasonably aligns with the operational reality that it takes mutual agreement between two parties to provide working DNS for a domain that isn't self-hosted. In the DANE/DNSSEC survey, I am tracking almost ~350k zones (out of ~22.8M) with no SEP, roughly half of which are just lame delegations (the listed servers return "REFUSED"), but for various reasons it is difficult for the former DNS operator to get the delegations terminated. The chief difficulty here is that this does not work for "external" nameserver objects. If we're really going to solve this problem, the solution should I think also work for the case when the nameserver and the client zone live in different registries. We need a protocol by which such disavowal can happen regardless of where the nameserver might be found. Of course if that's too difficult to solve in a timely manner, and we can reduce barriers in host object management within a registry, that's fine too, and the larger goal need not hold up progress on the more focused problem. > 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. In the most typical situation, the servers in question will have for some time already discontinued DNS service for the objects to be removed, and the dependent domain loses nothing (only gains!) from having the no longer willing nameservers deleted. Therefore, my take is that the delegation NS record should be simply removed from the dependent zone. No renaming, or other steps to paper over the issue. Subsequent replacement is up to the owner of the dependent zone. Indeed if everything was done optimally, the dependent delegations would have proactively switched to working nameservers first. Now we do want to prevent accidents, and so deletion of host objects that are still used as nameservers by zones not being deleted should perhaps require some form of confirmation that some dependencies are being forcibly broken. How to do that, and whether confirmation should actually require the requesting party to submit a second request, ... is user interface design that should be discussed with care. I don't claim to have the right answer on how to balance safety vs. usability. > 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.) Explicit disavowal should be able to solve this too, if the IP addresses targetted can be reasonably safely (multiple samples over a period of time, or a confirmed request from the point of contact for the IP space, ...) determined to be refusing service for the disavowed zones. So my own position is that: - The host object owner should be able to delete it at will, with any friction solely to help avoid difficult to recover accidents, rather than prevent the nameserver owner/operator from discontinuing service. - The dependent zones would then have the corresponding nameserver
Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host
On Tue, Jul 11, 2023 at 12:07 PM Hollenbeck, Scott 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
Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host
> -Original Message- > From: Andrew Newton > Sent: Thursday, July 13, 2023 1:00 PM > To: Hollenbeck, Scott > Cc: brian.peter.dick...@gmail.com; dnsop@ietf.org; Registration Protocols > Extensions > 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. > > +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. [SAH] We'd like to get there with community input. Consider what's in the draft now as an attempt to prompt discussion. > 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. [SAH] Maybe "better than the practices to be discouraged" is a better way to describe them. I like the idea of adding pros and cons to better explain how even "better" or "best" practices might not be enough to remove all risk. > 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... [SAH] Yes, but we do have experience with deploying EPP extensions. I think this part is manageable. Scott ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host
+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 wrote: > > Thanks for the feedback, Brian. Notes below… > > > > From: Brian Dickson > Sent: Tuesday, July 11, 2023 6:23 PM > To: Hollenbeck, Scott > 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 > 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 author
Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host
Thanks for the feedback, Brian. Notes below… From: Brian Dickson Sent: Tuesday, July 11, 2023 6:23 PM To: Hollenbeck, Scott 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 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
Re: [DNSOP] Best Practices for Managing Existing Delegations When Deleting a Domain or Host
On Tue, Jul 11, 2023 at 12:07 PM Hollenbeck, Scott 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. 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. 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/ 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. 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
