Default should be to choose from a random list of .onion service resolvers known to be running their own local resolver. Possibly rotate resolver each Q query or N seconds. This is a decent upgrade from defaulting to exit nodes which often resolve directly by upstream google or comcast.
If we agree, let’s talk about implementation and I will contribute it if necessary. If not, let’s riddle out why not.
testing note: dns ip leak test to determine that resolver is handling his own resolver cache. Resolver’s clearnet IP probably doesn’t need to be secret.
inquiry: best way to perform test? Perform dig on host which returns final upstream resolver? What if no cache hit though?
Should be implemented in Tor and/or Tor Browser by upstream torproject.org first. Therefore, could you please suggest this, contribute this to upstream please and keep us posted here?
If it doesn’t make users more fingerprintable and doesn’t impact cloudflare hosted site access then I don’t see why not. In the case of the latter TBB using Cloudflare’s onion resolver seemed the compromise they reached to stop ruining everyone’s browsing experience AFAIK. Exit DNS resolution has a documented impact on anonymity and so it might be best to avoid indeed.
@Trioxin if you can confirm from Tor upstream that doing o doesn’t have any negative impacts then it would give us a green light. The way things are currently implemented isn;t the ideal, but because changing a system’s DNS resolution mechanism is out of scope for the Tor project. We however are in a position to do so if good.
Just to make sure we’re all on the same page:
If system DNS settings are changed in Whonix, this has no effect on Tor Browser whatsoever. One could even disable system DNS in Whonix.
(This is an optional configuration documented here: Stream Isolation)
Tor Browser would still be fully functional. This is because Tor Browser talks directly to a Tor SocksPort.
In other words, even if we filled up lets say /etc/resolv.conf with onion DNS servers (if this is how this is supposed to be implemented), Tor Browser wouldn’t benefit from it. The only applications benefiting from it would be those using system default networking (system default DNS). I.e. applications not configured to use a Tor SocksPort using proxy settings or a socksifier (torsocks).
Therefore if resolving DNS over onion is an improvement indeed (Tor Project opinion required), then it’s still best if this is directly implemented in Tor. In theory would be best if Tor Project modified Tor so that all, Tor SocksPorts and Tor’s DnsPort use onions rather than Tor exit relays for DNS resolution.
It could be more fingerprintable because DNS resolution over onion might take longer than DNS resolution over Tor exit relays. For system default networking Whonix is using Tor’s TransPort and for system default DNS Whonix is using Tor’s DnsPort. This is how it is supposed to be implemented.
(According to TransparentProxy · Wiki · Legacy / Trac · GitLab)
Tor provides DnsPort.
While redirecting traffic to Tor’s DnsPort isn’t something that Tor currently doing (that is the task for the system administrator or a distribution such as Whonix), yet Tor provides a fine platform for system DNS resolution. Therefore I don’t think this is out of scope for Tor Project. To paraphrase “catch the traffic using iptables and redirect it to Tor’s TransPort / DnsPort”.
Since when does Tor Browser use Cloudflare’s onion resolver? I cannot find any reference for that.
In any case, if something can be improved related to DNS over Tor, then it’s best to report this to Tor Project first. Both Tor Browser or even better Tor developers could decide to pick this up.