DNSSEC is the least useful of the lot. It only authenticates, doesn't encrypt, so it's not enough on its own, you have to use it in combination with a VPN. But the VPN would be enough on its own between the client and the recursive DNS, since it does both.
Between the recursive and authoritative DNS the VPN wouldn't exist, but if the attacker is there then DNSSEC is in trouble again because it still doesn't encrypt (no confidentiality). What can be used on that path is DNSCurve, because it does encrypt even where there isn't a VPN.
The majority of domains also aren't DNSSEC signed anyway, so it doesn't even authenticate them.
You're conflating privacy with trust. DNSSEC gives you trust, the VPN gives you "last mile" privacy. DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled). Over time you can hope for DoT to gain wider adoption so more and more of the upstream resolver chain is encrypted.
DoH mitigates the "ISP selling your DNS data" threat, which practically everyone in the US faces, without forcing all your traffic onto a VPN, which not everyone wants. Meanwhile: practically no important zones are signed, so apart from the fact that DNSSEC does nothing to improve privacy, it's also not useful. DNSSEC is moribund; taking steps to enable it is a waste of time.
DoT would also mitigate it in a similar fashion. In both cases mitigate doesn't really have much meaning since, sans VPN, ISPs that are inclined to do so will quite happily continue to find ways to infer where you're browsing to (IP address and CT log correlation being the obvious choices). Ergo, if last mile privacy is you're issue, the best bet is a VPN or some improved regulation so that consumers have a choice if they want an ISP that doesn't spy on them.
DoT and DoH have virtually identical service models. The practical difference between the two is that DoT deliberately runs on a nonstandard port, so that network operators can filter it. It's not an exaggeration to say that DoT is simply DoH with a network kill switch.
When was the last time port 995 or 993 were blocked? If the same adoption happened with DoT, ISPs wouldn't have the option - customers wouldn't accept it.
Confidentiality and authentication are two different things, but the things that provide confidentiality here also provide authentication. DNSSEC only provides authentication, so then you need something else to provide confidentiality at every point in the path. At which point you would also have authentication at every point in the path, so what does that leave for DNSSEC to do?
> DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
This is true. DoH isn't the one to use between recursive and authoritative DNS servers.
> Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
DoT has a similar drawback as DoH between recursive and authoritative servers. The session establishment is expensive (more round trips, higher latency). That's not so bad for the link between the client and the recursive DNS, because you create a session once and use it for all your queries. It stinks between recursive and authoritative servers because the recursive server would need a new session for each authoritative server -- and a single recursive query can often require contacting three or more authoritative servers.
Fortunately DNSCurve has lower latency and can be used between any pair of recursive and authoritative servers that support it.
The root not supporting DNSCurve is an issue, but it has an obvious long-term solution (have the root start supporting DNSCurve), and in the meantime the recursive resolver could validate only the root with DNSSEC. The lack of privacy is much less impactful for TLD queries -- a query for your-local-oncologist.com tells an observer much more than a query for .com. Then if DNSCurve is used for the rest of the chain after the root, you have one authentication or the other for the full chain and privacy for all but the TLD query. You also then don't need any large DNSSEC records in the authoritative servers that support DNSCurve, which would otherwise be a DDoS vector.
> So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled).
I still don't see what that's even supposed to be adding over the VPN right now. The VPN handles the link between the client and the recursive resolver. You can only get authentication between recursive and authoritative servers for domains whose authoritative servers support some authentication, but hardly any of them support any authentication right now, and if you're going to add one it makes more sense for it to be DNSCurve than DNSSEC because it provides confidentiality in addition to authentication and isn't a DDoS vector.
DNSCurve sounds quite nice (I'm not at all familiar with it tbh). I agree something along those lines with DNSSEC for the last hop to the root would do it.
To be honest my main gripe is with DoH. For non-last-mile privacy/trust, there are indeed many suitable ways to tackle it.
Between the recursive and authoritative DNS the VPN wouldn't exist, but if the attacker is there then DNSSEC is in trouble again because it still doesn't encrypt (no confidentiality). What can be used on that path is DNSCurve, because it does encrypt even where there isn't a VPN.
The majority of domains also aren't DNSSEC signed anyway, so it doesn't even authenticate them.