Peter, This moves beyond the protocol itself and into operational concerns of chosen policies. Based on the language in the EPP RFCs, the registry can choose various policies on which hosts require glue (e.g., all internal hosts, only in-bailiwick hosts), what pre-conditions need to be met to delete a host (e.g., no linked domains, only linked domains from same sponsoring registrar, independent of linked domains), what pre-conditions need to be met to delete a domain (e.g., no linked child hosts, only linked child hosts to domains from same sponsoring registrar, independent of linked child hosts), and how to implement the deletion to meet the data integrity and performance requirements of the system (e.g., don't allow lame delegations by implementing a cascade delete upfront, allow lame delegations and perform cascade delete later). The protocol doesn't dictate the policy in this case but does include guidance in the form of normative SHOULDs with an eye on maximizing data integrity. EPP is for provisioning and not bulk transactions, which is why the size of the OLTP transaction is material when it comes to operations. My preference is to have small transactions that don't have undefined sizes due to having no maximum number of child hosts and no maximum number of domains linked to the child hosts.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/26/23, 1:26 PM, "Peter Thomassen" <pe...@desec.io <mailto:pe...@desec.io>> wrote: 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. James, On 7/26/23 06:22, Gould, James wrote: > * 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 > > JG - [...] I would not leave the lame delegations, so that means a cascade > delete from the parent domain to all child hosts and all name server links to > those child hosts. Imagine if registrar accidentally or maliciously deleted a > large ISP domain name (e.g., isp.example) with a large set of child hosts > that are linked to thousands of domain names. There are other bad things a > registrar could do, such as putting the clientHold status on the ISP domain > name, but that can be easily reversed. Bad deletes and updates can be > protected > via a registry lock service, but otherwise the registry needs to reduce the > blast radius based on the data it has available. I don't agree with this characterization. It's not the protocol's task to limit the kind of operations that can be done, including ones with large impact. The protocol's job is to ensure that requests are authenticated, and if they are, that they are executed consistently. Of course, one might introduce measures protecting against the execution of unintended operations -- but that shouldn't be done at the cost of consistency. In fact, that gets us in the situation we're in now. The right place for such measures is before sending a request (e.g., in the registrar's system), or before executing the request (e.g., by requiring out-of-band confirmation). Note that the size of the transaction is rather secondary to its impact: in your large ISP domain example, deleting it may cause a large cascading transaction, but much smaller transactions may have comparable impact. (For example, if a (malicious?) registrant change occurs for isp.example and the new registrant sets new NS records for the delegation, the same number of domains is impacted.) > * 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. > > JG – This moves the large OLTP transaction problem to the backend with the > purge. Yes. That's good! Peter -- https://secure-web.cisco.com/1BNxy1WbO00swY7YlTazQsxg69G_7d9ief2UAmb9I3jaw6_7HMpoZXdeiB_o3jax2EXYl98OepTh0bEnTldOGO6IknSVSwk6vtGwV4_R-YaA6BvzdVhUQbtDUKdSXw5aajtRG8n3LMmmwTPFoCQOdcrEh7qqXKBP91xqurEPD6UEXvEJS8e6Gz8kE1vSbtpqYrM_-YO-S7r1R-4dBkTnSASq70LeeW004ZZs0eFFSVJiQ0m7Ozg_bQvnA3ZVWaw8f1WVxsiCgS0_HILF1aek_zQakDrTGp18csHcG4gYmhGc/https%3A%2F%2Fdesec.io%2F <https://secure-web.cisco.com/1BNxy1WbO00swY7YlTazQsxg69G_7d9ief2UAmb9I3jaw6_7HMpoZXdeiB_o3jax2EXYl98OepTh0bEnTldOGO6IknSVSwk6vtGwV4_R-YaA6BvzdVhUQbtDUKdSXw5aajtRG8n3LMmmwTPFoCQOdcrEh7qqXKBP91xqurEPD6UEXvEJS8e6Gz8kE1vSbtpqYrM_-YO-S7r1R-4dBkTnSASq70LeeW004ZZs0eFFSVJiQ0m7Ozg_bQvnA3ZVWaw8f1WVxsiCgS0_HILF1aek_zQakDrTGp18csHcG4gYmhGc/https%3A%2F%2Fdesec.io%2F> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
