Terry, On Oct 8, 2024, at 5:32 PM, Terry Manderson via rssac-caucus <rssac-caucus@icann.org> wrote:
More deeply I think it further promotes ossification in a system that should be more agile.
If you want “agility” (ignoring “why?"), in the current system, there are two vectors for change: (1) changing the address listed in the hints; or (2) changing the operator that is announcing the address. Historically, as has been shown empirically by the long tail of queries to old addresses (1) has been problematic, requiring changes to _millions_ of independently operated recursive resolvers, many of which are likely unmanaged. (2) would require changing network operators and a couple of ROAs. One of these seems _far_ more agile than the other to me.
Lastly I fear for a process concern should a root server operator be deemed as non-performing or unsuitable (whichever way the governance constructs decree) and is to be removed - but the RSO doesn't want to cooperate. Having that RSO in control of a set of "golden identifiers" means a smooth transition is unlikely to be achievable. I would think a smoother approach would be to change the hints file (yes, putting effort into making the hints file more agile across all DNS codebases) and the NS records in the root zone in participation with an incoming RSO.
We have seen how long it takes for changes to DNS codebases to be deployed, even when it is standardized and there is clear need. And there are likely a bunch of security considerations to updating the configuration information for root servers in all the world’s resolvers that would need some careful thought. Ignoring the question of when dealing with non-performing or unsuitable RSOs will be resolved, with the increased deployment of RPKI (now > 50% I hear), the ROA of the root prefix from the non-performing or unsuitable root operator would be marked as invalid by <IANA,one or more RIRs,the Great Spaghetti Monster> and be dropped by folks who have configured their routing filters that way, with the ROA of the new root operator being marked as valid, therefore being accepted. This change would presumably be implemented within hours to days as opposed to years (if ever). Regards, -drc