Hi David, (apologies for the long delay in replying) No doubt that making a set of addresses "golden" + RPKI is an attractive lever to effect rapid change (and might also come with its own pile of risks). I guess my use of agile didn't come across how I anticipated. There is a balance to be struck between "rapid" and globally responsible, trustworthy, transparent, and predicable. I would love to see code, to automagically update the hints files, rolled into DNS codebases ASAP or even better - 10 years ago. (Yes, I acknowledge the lag in getting that across the line.) In the end I would rather see this addressed once the new shiny RSS governance body is established. I also believe that it will take years to convince the incumbent RSOs to switch over to golden addresses (which already has a long tail) or hand the addresses they currently have and use to IANA (in your example). Cheers, Terry
On 10 Oct 2024, at 3:06 AM, David Conrad <david.conrad@layer9.tech> wrote:
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