From: dns-operations <dns-operations-boun...@dns-oarc.net> on behalf of Joe Abley <jab...@strandkip.nl> Date: Saturday, April 27, 2024 at 02:50 To: Warren Kumari <war...@kumari.net> Cc: "dns-operations@lists.dns-oarc.net Operations" <dns-operations@lists.dns-oarc.net> Subject: [Ext] Re: [dns-operations] A request for "data"
>It's a big Internet. There is a lot of surprising stuff in it. I find it's >usually a mistake to imagine that anybody knows >how all of it works just because they know how some of it works. Thinking the >opposite and turning over rocks >can reveal some interesting things. (Apparently, this became a run-on email as I thought about Joe’s message.) That last point is why I’m asking. I’m facing a dilemma. On the one hand, accommodating and enabling a diverse set of possible operational models is a noble goal. Avoiding “one way of addressing something” leads to a more resilient and vibrant system. Resisting a natural progression of “economies of scale” to be uniform in manner potentially pays off in the long run if the uniform approach caves in under its own weight. Coincidently, I am reading through an article on “rewilding the Internet” on this, the URL appeared in RIPE mailing list, reinforcing that notion. On the other hand, securing an operational platform is greatly challenged when the requirements are wide open, when the set of permissible actions is large. Deciding whether a state of the system is “safe” or “at risk” or “in abuse” is increasingly difficult as the number of states grows. This encourages monoculture, which is seen as root cause of many historic collapses, but is driven by some operational experiences I’ve come across. I’ve been reeling from a comment made to me a few months ago by a long-time operator of a ccTLD. “Complexity causes consolidation.” This was said in the context that the more complex a protocol is, the fewer experts there will be who can deploy and operate it, which results in consolidation. As an example, the world of email, it’s gotten so hard to run that relying on a commercial email provider is recommended. Another “bon mot” I heard from a management figure in the past is “I don’t want any more Swiss army knives” while addressing a development team. The issue was that the team had been spending time on general solutions to what they thought were problems while the operational staff needed specific solutions to tasks at hand, resulting in wasted efforts and mishaps at the operational terminals. My takeaway from that is that, to support operations, protocols, and the tools to deploy them, need to get simpler, more specific. This is a bit of the division of macroeconomics vs. microeconomics at play. Sometimes what’s best for a society is not the same thing as what’s best for a specific player. “Grazing of the commons” is probably an embodiment of this friction. Along a different dimension is the distinction between vulnerabilities discovered “via packets” - that is an active attack detected by looking at server logs and activity - versus a vulnerability discovered by a study of a system’s design. The former represents a current event, one needing attention as harm is being done. The latter represents a threat that hasn’t materialized. It’s clear that the former needs action, there would be an immediate payoff, the latter may or may not deserve action as it is not known whether a malicious actor has been aware of the possibility or has been aware and decided there was no reason to exploit it. This is different, it’s not “Swiss army knives” and “consolidation” but knowing where to work. It’s certainly more important to address issues that will have a tangible benefit versus issues that may be purely theoretical. Sometimes you need to let a situation become a “festering wound” before treating it if only because at that point it will be clearer what the treatment ought to be. (I learned that very early in my career.) I realize that conceptually trust anchors can play a role and in cases just as Joe listed in his email. The question is whether these situations were playing out anywhere or perceived to be a future threat. My hypothesis is that if trust anchors only matter for the root of a DNS namespace (“a namespace” as a nod to networks that are separate from the global public Internet) then how they are defined, implemented, managed, and deployed could be much simpler than the general-purpose solutions we now have. So, for now, I’m looking for any case where trust anchors are in use (outside of the root zone). …with a parting shot at that old DLV service…while it was in place, it got very little love, less that it deserved in my book… (https://kb.isc.org/docs/iscs-dnssec-look-aside-validation-registry)
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
