With DNSSEC, I know that anyone asking for IP addresses of my web server will get the correct address, and in the future it may be possible to use TLSA records (and/or HTTPS records) so that the user’s web browser can be certain that it is connecting to the correct site, with the correct key. The only weak point is that the user might be using a DNS resolver which may be correctly checking the DNSSEC signatures, but the DNS replies, sent from the resolver to the user, are not signed, only “authenticated” by the AD bit. (This is where DoT – or even, blech, DoH – might actually help.) Or the user could run their own local resolver with no untrusted path between their device and their resolver, closing the gap completely.
Contrast that with using no DNSSEC, only DoH (or DoT). The user asks the resolver for the IP address (and possibly HTTPS/TLSA records), and the resolver asks the authoriative DNS server for the information. But the whole conversation between the resolver and the authoritative DNS server is completely unsigned, and can be manipulated at will by any middlemen. Also, it is not even TCP (which is hard, but not impossible) to manipulate as a man-in-the-middle, but DNS is most often UDP. But let’s say there is no manipulation here. How do you trust the identity of the resolver? Because they have a nice certificate from “Honest Achmed's Used Cars and Certificates”¹, which says they they are indeed the DoH resolver the user has configured? The same problem also applies to the web site certificate; how can you trust it, when any CA in the world can issue any certificate at will?
