* Nick Weaver via tor-relays: > If DNS is being blocked from a Tor exit the site itself that is being > resolved is also likely to be blocked, so it should be a rarer case > than you'd otherwise expect.
I disagree with your assumption of "if a nameserver for example.com blocks the Tor exit, somehost.example.com will likely block the exit as well" (I am of course paraphrasing). First, many domains use third-party DNS hosts. 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. As for the rarity of blocks, I think you have a better point there. > So just run a local recursive resolver ON the exit node, but with a > small patch so if the recursive resolver fails to resolve a name you > have a fallback to a separate recursive resolver, the one that is run > by the ISP where you are running your Tor node That would provide a DNS resolver fallback, but also a privacy leak. Your ISP could block your own resolver to force fallback to theirs. It depends on how cautious/paranoid one wants to be in this matter. I recommend local, caching resolvers on Tor guards or middle nodes, but for exits this matters less, due to the next point you mentioned: > And the privacy implication is very low: after all, the ISP can see > the final traffic anyway [...] Indeed. 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. Overall, I see the deployment of a local caching resolver (without fallback to ISP resolvers) like Unbound as sufficient, and I already mentioned dnscrypt-proxy as an alternative. I prefer Unbound, with its small footprint, simple configuration and DNSSEC support. -Ralph _______________________________________________ tor-relays mailing list -- [email protected] To unsubscribe send an email to [email protected]
