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://desec.io/
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
