[ivanr]

In what way does DoH provide end-to-end security? It doesn't, unless you adopt a different definition of "end-to-end" where the "server end" is an entity that's different from the domain name owner, but you're somehow trusting it to serve the correct/unaltered DNS entries. And even then, they can be tricked/coerced/whatever into serving unauthentic information.

For true end-to-end DNS security (as in authentication of domain owners), our only option is DNSSEC.

At best, you can argue that DoH solves a bigger problem.

[tptacek]

If you have an end-to-end secure transport to the authority, you've factored out several of the attacks (notably: transaction-driven cache poisoning) that have, at times, formed the rationale for deploying DNSSEC. The most obvious example here is Kaminsky's attack, and the txid attacks that preceded it, which had mitigations in non-BIND DNS software but didn't in BIND specifically because DNSSEC was thought to be the proper fix. Those kinds of attacks would be off the table in a universal DOH/DOT/DOQ world, in some of the same sense that they would be if DNS just universally used TCP.

"True" DNS security isn't a term that means anything to me. Posit a world in which DNSSEC deployment is universal, rather than the sub-5% single digit deployment it has today. There are still attacks on the table, most notably from DNS TLD operators themselves. We choose to adopt a specific threat model and then evaluate attacks against it. This is a persistent problem when discussing DNSSEC (esp. vs. things like DOH). because DNSSEC advocates tend to fall back on a rhetorical crutch of what "true" security of authoritative data meant, as if that had some intuitively obvious meaning for operators.

In a world where DNS message transports are all end-to-end secure, there really isn't much of a reason at all to deploy DNSSEC; again: if you're worried about people injecting bogus data to get certificates issued, your real concern should be your registrar account.