Alexander Færøy:
I wonder if it would make more sense to have an onion-aware DNSSEC-enabled resolver *outside* of the Tor binary and have a way for Tor to query an external tool for DNS lookups.
I'm also in favor of this approach, and you can do this today with no code changes to tor at all.
CF demonstrated it even before DoH/RFC8484 was finalized: https://blog.cloudflare.com/welcome-hidden-resolver/
Such tool should be allowed to use Tor itself for transport of the actual queries. One of the best parts of Tor (in my opinion) is the Pluggable Transport subsystem. This subsystem allows external developers, researchers, and hackers to build new technology that benefits users in censored areas *without* having to alter a single line of C code in tor.git.
Let's say we had a "Pluggable DNS" layer in Tor. Users would be able to configure their Tor process to *never* use the built-in DNS subsystem in Tor, but instead outsource it to an external process that Tor spawns on startup. This process could use .onion's to reach a DNS-over-(TLS|HTTPS|TCP) server as onions themselves aren't looked up via DNS.
+ 1 for DoT and DoH over tor, especially due to the DoH implementation that is available in firefox (it would still require work on stream isolation and caching risks to ensure the usual first party isolation). In terms of achieving a big improvement on tor browser users in the context of DNS this would be the most effective path to spend coding resources on in my opinion.