> If dnssec usage was wide spread we might reach some decent maturity with the tools and protocols, but I can't see that happening any time soon.

DNSSEC's lack of maturity is a symptom of DNS itself not having a healthy ecosystem. I feel like it'd take as little as a half-percent of the people writing new HTTP tooling to noticeable improve the DNS ecosystem as a whole.

Totally. DNS was always an IETF RFC bound thing. Recently, big players just kinda started making their own decisions.

I'm not sure which is better. Having big companies control the internet is definitely bad, but the pedantry and bikeshedding the IETF offers can be equally bad.

I'd probably rather see the two cooperate/converge, but that's a pipe dream.

This sounds exactly like the age-old debates bemoaning the bureaucracy of government versus the exploitation of industry. People knowing the pain of one always look hopefully at the other.

> I feel like it'd take as little as a half-percent of the people writing new HTTP tooling to noticeable improve the DNS ecosystem as a whole.

you mean like the ppl that made it more centralized and failure prone?

Is that a dig at the DoH crowd?

My comment wasn't suggesting a HTTP background is necessary for someone to help move the DNS ecosystem forward.

it was indeed

One major problem with new security technology is that testing is generally created as the result of failure, rather than preceding the failure so that it doesn't occur in the first place. Even very basic things like verifying that a new key actually fit the intended lock (ie, that a new key correspond to the published data) is a concept that people tend to implement only once they have had experienced a failure.

One general solution is to have standardized tools with standardized testing. Transferring a domain should always involve testing the old data, testing the old keys, testing the new data, testing the new keys, testing the chain of delegation, testing the chain of trust and so on. Some TLD's has gone as far as doing basic sanity test before a domain owner is allowed to transfer a domain. (industry term is to delegate a domain, since transfer is strictly about legal ownership)

Thankfully there are initiatives to create standard tools and standard test. Zonemaster (https://zonemaster.net) is one I recommend for testing, which is the result of a collaboration between .se and .fr. There is also initiatives for tooling that create multi-signing (https://github.com/DNSSEC-Provisioning/music), which is to have multiple keys operating for the same domain.

Redundancy in HSM's are nice, but redundancy is not a replacement for testing and backup procedures. It was one of the hard lessons learned by the IT industry, especially with data. No amount of RAID will save a company if a rogue script deletes all the files, or if the database becomes corrupt. A lot of experts learned the hard way that redundancy is mostly just a complement to sanity tests and backup procedures.

This isn't new security technology. The service model for DNSSEC was designed in 1994.

The basic idea isn't excellent. It's wrong. It's firmly rooted in mid-1990s cryptography (the original design was a DOD contract to TIS); in particular, to the idea that cryptography is too expensive to do on edge systems. That's why DNSSEC's core design has offline signers (my belief is that the supposed security benefits of offline signing are back-rationalized --- remember that a best-practices "leaf" DNSSEC deployment today will have online signers, to foil enumeration attacks).

If you were to scrap DNSSEC-ter and start from scratch in 2023, there is no chance the design would look anything like DNSSEC. It would be fully encrypted for privacy. It would strike a different balance between authenticated denial and offline keys. It would use different primitives, and it would probably have a different DNS RR schema.

There are lots of implementation problems with DNSSEC, but the real issue is that the design is the best we could do in 1998, and that most of what's "improved" since then have been more effective ways to shoehorn the same model into the evolving core DNS infrastructure, rather than really improving the fundamental design.