Re: [Add] some background on split DNS with DNSSEC

[Joe Abley <[e-mail]>]

Warning! More non-actionable philosophy follows.

https://hitchhikers.fandom.com/wiki/Joo_Janta_200_Super-Chromatic_Peril_Sensitive_Sunglasses

On 9 Nov 2021, at 11:27, Eliot Lear <[e-mail]> wrote:

> On 09.11.21 17:13, Bill Woodcock wrote:
>> If what you’re saying is that when we depend upon tools to cover fragile or overly-complicated things with abstraction layers to “solve the problem” that we’re actually adding complexity and fragility, and that that’s a bad idea (“when you’re in a hole, stop digging”), then yes, I agree with that as well.
>> 
>> The biggest problem I see with standards development now is the desire to solve many problems within single monolithic protocols, rather than making small, simple, easily-comprehended modular building blocks that can be put together in different ways to solve different problems.
> 
> While I don't disagree with what you say, what I'm saying is that DNSSEC has had PLENTY of time to diffuse and hasn't done so.  In fact, I would argue that new new impediments have shown up that lend themselves to centralization, which is the risk of amplification attacks that have led secondary services to charge extra.

I don't think DNSSEC is a particularly good example of the more general problem it seems like you're both describing.

DNS is an extraordinarily resilient protocol, by which I mean it is unusually good at hiding things that are broken in ways that end users often don't realise. It seems sometimes like 80% of the DNS could be broken in some way and nobody would notice.

The requirements that DNSSEC intends to solve aren't compatible with that degree of brokenness; the simple facts that signatures have finite validity periods and there's metadata in the form of private keys that exist outside the published data of the DNS make the system more fragile and mean that operational failures that were once invisible now have consequences.

The need for validity periods turns the DNS into a ticking time bomb. The need for private keys means that operational hygiene is more operationally vital than it once was. Neither of these things are the fault of DNSSEC, but rather the fault of the requirements that DNSSEC was intended to implement, combined with the tolerance of the original protocol that allowed bad habits to persist.

The existence or non-existence of a satisfactory toolchain is orthogonal to what I would call a more fundamental problem, a problem that likely doesn't have much of a solution unless we forget about validation. Or perhaps it's not a problem, and rather a useful trigger for errors to be cleaned up, in which case yay DNSSEC!

> And my admittedly snide initial comment was meant to convey that we ought to think of taking another look at naming and security that accommodates mechanisms like split views, rather than simply says, “Those are bad!”

I agree.

Seth Breidbart's famous definition of "The Internet" was concerned with the lie that there is a single Internet from all vantage points. The idea that there is a single namespace, or even the idea that there's a single public namespace conjoined for particular clients with a single private one, is similarly problematic.

The namespace, responses to particular queries and reachability of particular nameservers all vary according to where and how queries are initiated. With transports that provide the potential for authentication, we can add "who" to that list. There are many, many, many namespaces and the problem of recognising and accommodating that simple truism is, I think, broader than a superficial treatment of enterprise "split views" and not something that can be simply stuffed back in the lamp.


Joe