I don't know how everyone else feels about this - rather than using a secondary resolver in the event Unbound fails - why not let the query fail and the user have to try again? Is there any reason to risk letting a third party resolver possibly log exit node DNS queries?
nusenu:
Andrew Deason:
An operator may think they're not "using" google's dns because they're pointed at localhost first, and their local resolver is working, so they shouldn't normally be using the fallback so it doesn't matter. Obviously that's not true, otherwise such relays wouldn't be identified in that list :) I imagine it's not _as_ bad as depending on google's dns first, but maybe that is an insignificant difference.
yes there appear to be rather different interpretations as to when secondary resolvers (lines coming after the first nameserver line in /etc/resolv.conf) are actually contacted. So far I can tell it does not only depend on the functioning of the primary resolver, but yes I believe it makes a significant difference if you use a resolver in the first or secondary position (unless you enabled round-robin).
Next time I measure, I aim to better differentiate what relays use what resolver as primary or secondary resolver.
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays