Alec Muffett alec.muffett@gmail.com writes:
On 15 Nov 2017 12:18, "Iain R. Learmonth" irl@torproject.org wrote:
Is this not what TorDNSEL does? https://www.torproject.org/projects/tordnsel.html.en
Hi Iain!
Hey Alec,
thanks for the feedback.
That certainly sounds like it will give you the answer! But although it would give the right kind of answer, it is not what I am asking for.
At the scale of websites like Facebook or the New York Times, a timely response is required for the purposes of rendering a page. The benefits of solving the problem at "enterprise" scale then trickle down to implementations of all sizes.
Speaking as a programmer, it would be delightfully easy to make a DNS query and wait for a response to give you an answer... but then you have to send the query, wait for propagation, wait for a result, trust the result, debug cached versions of the results, leak the fact that all these lookups are going on, and so forth.
This all adds adds up to latency and cost, as well as leaking metadata of your lookups; plus your local DNS administrator will hate you (cf: doing name resolution for every webpage fetch for writing Apache logs, is frowned upon. Better to log the raw IP address and resolve it later if you need.
On the other hand: if you are running a local Tor daemon, a copy of the entire consensus is held locally and is (basically) definitive. You query it with near zero lookup latency, you get an instant response with no practical lag behind "real time", plus there are no men in the middle, and there is no unwanted metadata leakage.
I think it's important to point out that a Tor client is never guaranteed to hold a *definitive* consensus. Currently Tor clients can stay perfectly happy with a consensus that is up to 3 hours old, even if they don't fetch the latest one (which gets made every hour).
In general, the Tor network does not have a definitive state at any point, and different clients/relays can have different states at the same time.
If we were to create "the definitive exit node oracle" we would need a Tor client that polls the dirauths the second a new consensus comes out, and maybe even then there could be desynchs. Perhaps it's worthwhile doing such a thing, and maybe that's exactly what tordnsel is doing, but it's something that can bring extra load to the dirauths and should not be done in many instances.
Furthermore, you said that enterprises might be spooked out by tor-specific "special" HTTP headers, but now we are discussing weird tor modules that communicate with the Tor daemon to decide whether to redirect clients, so it seems to me like an equally "special" Tor setup for sysadmins.