Any of them, since DNSSEC validation doesn't occur in stub resolvers, but is instead delegated to the caches (the "DNS servers" you or DHCP configures).
DNSSEC was designed in the mid-1990s, before protocol designers understood crypto, and it was carefully designed to minimize cryptography. Several other bad attributes fall out of that decision as well.
> Any of them, since DNSSEC validation doesn't occur in stub resolvers.
By that logic, because someone could write a browser that will accept invalid certificates and/or show everything as secure etc, TLS in general is fundamentally broken so we should never use it.
A bad implementation isn't reason to abandon the concept.
I don't understand this objection. No, as a fact, DNSSEC resolution happens at DNS servers. No browser does DANE at all (the two that tried --- Firefox and Chrome --- rescinded their support). But when they do, they'll be using a stub resolver just like everyone else, because that is how the protocol is designed.
Edit: TL;DR: I'm not saying TLS is fundamentally broken.
Also: Unless you need to support fucking ancient client devices/user agents, I urge you to drop SSL (and upgrade to as recent a TLS version as possible)
Re-read what I wrote, and what I replied to.
A lot of DNSSEC/DANE detractors claim that its effectively useless and unusable, because currently a lot of DNS stub resolvers (e.g. home routers) don't do DNSSEC verification.
My response is that you can use the same argument to make anything useless, if you introduce a terrible implementation.
Let's try a different example separated from certificates to make it clearer:
IE6 was a fucking terrible web browser as far as web standards go. Therefore, web standards are useless and should be abandoned.
It's not that stub resolvers don't do DNSSEC validation. They can't. They get a single bit in the header from their upstream recursive cache telling them whether validation succeeded or failed. That's it.
If you want better than that, you can't use a stub resolver. You have to embed an entire recursive cache server in every endpoint.
DNSSEC was designed in the mid-1990s, before protocol designers understood crypto, and it was carefully designed to minimize cryptography. Several other bad attributes fall out of that decision as well.