-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Second, an imaginary nameserver ns.example.com /might/ block the same hosts as www.example.com, but why would it? The hosts provide very different services.
This is correct. Most blocking of Tor is not done by some upstream NOC that has control over all the traffic passing through its servers, but by some WAF or major CDN, neither of which are going to be used by a nameserver. That is, Tor is more likely to be blocked by Cloudflare, Akamai, Imunify360, Securi, etc. Likewise, nameservers that block Tor often do so separately from the domains that they manage, often by importing bulk IP blacklists that unfortunately contain Tor addresses. Access is then denied by the resolver software itself.
That would provide a DNS resolver fallback, but also a privacy leak. Your ISP could block your own resolver to force fallback to theirs.
In my view, the threat model is one of passive collection of data which is individually not particularly sensitive, but cumulatively gives an unnecessarily-large insight into traffic. A malicious ISP would be unlikely to gain much from forcing fallback for a single node.
Also, the Tor exit X making connections to some destination Y does not place the initiating Tor client Z at risk, what with Z and X being separated by the Tor circuit.
I recall there being several papers which showed that DNS privacy is more important than it seems. When exit X makes a connection to Y on behalf of client Z, there is a risk if anyone on the path been X and Y collude with anyone on the path from Z to its guard. When using a local recursive resolver, far more entities learn information about the communication between X and Y.
Overall, I see the deployment of a local caching resolver (without fallback to ISP resolvers) like Unbound as sufficient
I agree. Although it does have some downsides, I think the upsides outweigh them. The only problem is the IPv4 shortage. :) Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmj858kACgkQBh18rEKN 1gs+nBAAhAEa6pzZVIBASVe09VUk4poA63ldBDJdqu+INrVMPS42j73NKq0TvnHk 7rqOQtHF8xdCznmy6/Abv+aOgpAPSR9miwmJojp0zzw3VZGtdCzUihuPaDtCSkTa uLrVSF90j7vC/T3nIB2FyAYqK3jLNdJzm22+9xyfDmivnutrqSsq7EubYIFktyuz 1mBteVBuBTvJvKrnafPNI+CFp6cYDoJdrkBgCsxfNswcS6VT2VUb6dEZGgOjov9R 6yyRAVkHbkSis8Wo4QOwEnyv4+XxV7UrubHnWS6vE3shxhiUSo6mXpE+dvD0RApZ uM/KSHEMLT9dDI0oukoNwgLg9XuT0IIBw4PddkHE6+8XirXpRa5O3GEBCuJ6EO+W eD6LZFonAib/VISM33wOdBBUB2NNPMP3aV2a3cs7hxPXO56SIAekUDJV/PJVp2XB 1iOr0HdKChxA/yQvwcQQMht2nPZUjLCmkoS0LzPOZv3EKC7Htw0FC7OZvnPtRmAv 8nqPWQIHjnfUmzTtab3SjUMY8LeBNxpRwmv9gNyLyfxfsuBjCWaycg3oZW3wE6y0 nJ9uClU7vaAMbEfJn6R5xYrzMA0k0PZKGzWGzCkd+Mcs1XxJKfpyIBiTlQf8X3p5 BBeznSTJkRIH5Tk6KqkTr21q40cu2nupCNZoLqp/yvZIkB7mirM= =xzyZ -----END PGP SIGNATURE-----