I’m quite worried about the number of relays using Google DNS. With Google DNS, Google gets to know a Tor exit proxied X website at X time. I don’t think they can be trusted with this information. As for privacy concerns: Google claims these logs are only stored for up to 48 hours. It worries me that the information could be demanded by the FISA Courts (Google would have to comply by law) and three letter agencies would get access to Tor user’s browsing habits. I know the same could happen with any DNS resolver although due to the size of Google Public DNS the logs are a goldmine. I have the same, if not worse concerns with Cloudflare’s Public DNS (1.1.1.1). Now I have the burden of providing an alternative, it’s only fair I do so after criticism of the use of Google DNS. My first thought is to use ISP DNS if it’s available - one of the best things about Tor is the split of trust so why aren’t we doing that with DNS? Another alternative is to use trusted recursive DNSCrypt Resolvers (for example dnscrypt.ca - there are plenty of resolvers like this so use a search engine of your choice to find them). I actually really like the idea of using DNSCrypt resolvers opposed to commercial DNS provided by ISPs. Thoughts? As always, Thanks for running Tor Exits Sent from my iPhone

On May 11, 2018, at 4:15 AM, nusenu <nusenu-lists@riseup.net> wrote:

Tyler Durden:

...

All our nodes are using a local DNS caching server and only use google as a fallback. The situation is very unlikely to change unless there is a major player on "our side" which offers a free, censorship-free, resilient and stable DNS Service.

can you describe your (hard) resolver requirements so we can try to find Google alternatives for you?

thank you for running exits! nusenu

-- https://mastodon.social/@nusenu twitter: @nusenu_

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

On 2018-05-11 14:52, Ralph Seichter wrote:

Assuming you can install whatever software you like, I recommend running your own instance of Unbound on your exit node machines. Current Unbound versions support DNSSEC validation, QNAME minimisation, etc. While using your ISP's resolvers works as a fallback, a local resolver is better and easy enough to set up.

We are currently using Unbound plus 2 ISP name servers in /etc/resolv.conf. I still occasionally see the dreaded "all nameservers have failed" message, even though the latest Tor release has fixes for DNS performance (IIRC). Kind regards, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

El 11/05/18 a las 14:52, Ralph Seichter escribió:

On 11.05.18 13:55, Nathaniel Suchy (Lunorian) wrote:

...

My first thought is to use ISP DNS if it’s available - one of the best things about Tor is the split of trust so why aren’t we doing that with DNS? Another alternative is to use trusted recursive DNSCrypt Resolvers (for example dnscrypt.ca - there are plenty of resolvers like this so use a search engine of your choice to find them).

Assuming you can install whatever software you like, I recommend running your own instance of Unbound on your exit node machines. Current Unbound versions support DNSSEC validation, QNAME minimisation, etc. While using your ISP's resolvers works as a fallback, a local resolver is better and easy enough to set up.

The inconvenient with running a "standard" local resolver from the exit relays is the queries are forwarded in clear. So ISP and others could inspect them. I think I already mentioned about DNS-over-TLS in this list, so sorry for duplicating a message, but I think it is a good alternative to encrypt the queries, even if that means relying on third parties (that can be different to Quad9, Cloudflare, etc.) as resolvers. I think https://dnsprivacy.org material worth a reading. The project also provides a list of several test resolvers available. Some of them do not log or censor traffic: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers Disclaimer: I am part of the team who runs one of the no-logging test servers. And of course, anyone can run a privacy-aware DNS resolver in a different machine, to be used to forward the queries from the relays from a privacy-aware stub resolver, such as stubby. cheers, Santiago

Ah well I should look more into the services of EDRi members :D In this case I will give it a try as a fallback instead of google and we will see how it performs. Greetings Am 11. Mai 2018 14:04:37 MESZ schrieb Christian Pietsch <christian.pietsch@digitalcourage.de>:

Hi Tyler, hi all,

On Thu, May 10, 2018 at 10:37:00PM +0000, Tyler Durden wrote:

...

The situation is very unlikely to change unless there is a major player on "our side" which offers a free, censorship-free, resilient and stable DNS Service.

You are welcome to use our free, censorship-free, resilient and stable DNS resolver: $ host dns2.digitalcourage.de dns2.digitalcourage.de has address 46.182.19.48 dns2.digitalcourage.de has IPv6 address 2a02:2970:1002:0:5054:8aff:fe12:db49

Whether you consider Digitalcourage e.V. a major player is up to you. Here is some background in English: https://digitalcourage.de/en (Tyler, I know you know us since we as an EDRi member supported your organisation's entry application.)

More specific information on our DNS relays is available in German only <https://digitalcourage.de/support/zensurfreier-dns-server> but see https://en.wikipedia.org/wiki/Digitalcourage for a summary. This is not a huge machine but it could take some more load. We have configured DNSSEC and are looking into implementing DNS-over-TLS now.

You might ask what happened to dns.digitalcourage.de. That is our older open DNS resolver. We have run it since 2009. It has been overloaded recently, and we recommend that people switch to dns2.

Cheers, C:

-- Christian Pietsch | volunteering for Digitalcourage e.V. https://digitalcourage.de | https://bigbrotherawards.de How to avoid Google: https://pad.foebud.org/google-alternatives

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

I dislike OpenNIC as they are operating their own TLDs - this would end up being confusing as some Tor Exits would allow access to OpenNIC TLDs and others would not. On 5/11/18 8:18 AM, Famicoman wrote:

OpenNIC is always an option, https://www.opennic.org

On Fri, May 11, 2018, 8:12 AM Tyler Durden <virii@enn.lu <mailto:virii@enn.lu>> wrote:

Ah well I should look more into the services of EDRi members :D

In this case I will give it a try as a fallback instead of google and we will see how it performs.

Greetings

Am 11. Mai 2018 14:04:37 MESZ schrieb Christian Pietsch <christian.pietsch@digitalcourage.de <mailto:christian.pietsch@digitalcourage.de>>:

Hi Tyler, hi all,

On Thu, May 10, 2018 at 10:37:00PM +0000, Tyler Durden wrote:

The situation is very unlikely to change unless there is a major player on "our side" which offers a free, censorship-free, resilient and stable DNS Service.

You are welcome to use our free, censorship-free, resilient and stable DNS resolver: $ host dns2.digitalcourage.de <http://dns2.digitalcourage.de> dns2.digitalcourage.de <http://dns2.digitalcourage.de> has address 46.182.19.48 dns2.digitalcourage.de <http://dns2.digitalcourage.de> has IPv6 address 2a02:2970:1002:0:5054:8aff:fe12:db49

Whether you consider Digitalcourage e.V. a major player is up to you. Here is some background in English: https://digitalcourage.de/en (Tyler, I know you know us since we as an EDRi member supported your organisation's entry application.)

More specific information on our DNS relays is available in German only <https://digitalcourage.de/support/zensurfreier-dns-server> but see https://en.wikipedia.org/wiki/Digitalcourage for a summary. This is not a huge machine but it could take some more load. We have configured DNSSEC and are looking into implementing DNS-over-TLS now.

You might ask what happened to dns.digitalcourage.de <http://dns.digitalcourage.de>. That is our older open DNS resolver. We have run it since 2009. It has been overloaded recently, and we recommend that people switch to dns2.

Cheers, C:

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

On Fri, May 11, 2018 at 10:54:06PM -0500, Andrew Deason wrote:

On Thu, 10 May 2018 22:37:00 +0000 Tyler Durden <virii@enn.lu> wrote:

...

All our nodes are using a local DNS caching server and only use google as a fallback.

I was also using google just as a fallback; I've now changed my node to just use a local resolver, with no fallback.

Thank you!

Neither the email from nusenu nor the documentation pointed to actually says which of these options is preferable. If you (nusenu) are looking to reduce the exits using these resolvers, I'd suggest explicitly also saying to not use them even as a fallback after a local resolver (assuming that's what you want). Maybe you had intended this to come across with the existing text, but I don't think it's obvious enough.

But isn't that what the subject line says? And the original email contains:

The goal is to be bellow the following thresholds within one year: not have any single remoteAS entity control more than 10% exit capacity reduce the overall remoteAS share to bellow 20% exit capacity

Maybe it would help clarifying that almost any use of the above mentioned Open DNS resolvers qualifies as using a remoteAS (therefore contributing to its control of exit capacity) - even if that resolver is configured as a fallback. Thanks again for adjusting your configuration.

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. -- https://mastodon.social/@nusenu twitter: @nusenu_

...

All our nodes are using a local DNS caching server and only use google as a fallback.

I was also using google just as a fallback; I've now changed my node to just use a local resolver, with no fallback.

Neither the email from nusenu nor the documentation pointed to actually says which of these options is preferable. If you (nusenu) are looking to reduce the exits using these resolvers, I'd suggest explicitly also saying to not use them even as a fallback after a local resolver (assuming that's what you want). Maybe you had intended this to come across with the existing text, but I don't think it's obvious enough.

Yes, I was not clear on that, thanks for your feedback I amended the text in the Tor Relay Guide aiming to clarify this. here is the diff (which includes also other changes) https://trac.torproject.org/projects/tor/wiki/TorRelayGuide?action=diff&vers... the most relevant change with regards to your comment is: was: "Don't use any of the big DNS resolvers to avoid centralization" is: "Don't use any of the big DNS resolvers as your primary or fallback DNS resolver to avoid centralization" "if you want to add a second DNS resolver as a fallback to your /etc/resolv.conf configuration, try to choose a resolver within your autonomous system and make sure it is not your first entry in that file (the first entry should be your local resolver)" -- https://mastodon.social/@nusenu twitter: @nusenu_

On Sun, May 13, 2018 at 9:34 AM, Paul <pa011@web.de> wrote:

How do i protect against overwriting best in FreeBSD (maybe there could be a hint on https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#DNSonExitRelays ) as well?

On FreeBSD, the simple default answer to the OP subject is... Attempt to undo at least some of whatever unknown things you were trying to do thus hopefully restoring the system back to the install defaults provided in base.txz of the latest release... rm /etc/resolv.conf rm /etc/resolv.conf.bak rm /etc/resolvconf.conf rm -r /var/run/resolvconf And let the system do it... /etc/rc.conf.local:local_unbound_enable=YES reboot If your interfaces are managed by dhcp / rtsold / vpn, see the manpages: resolvconf, dhclient, rtsold, openvpn And even things like this if still needed... chflags schg /etc/resolv.conv

On 13.05.18 15:34, Paul wrote:

Unfortunately the /etc/resolv.conf gets overwritten on reboot. On Linux I solved that with editing /etc/resolvconf/resolv.conf.d/base.

A perhaps easier alternative to consider: # /etc/tor/torrc ServerDNSResolvConfFile /etc/tor/resolv.conf.local # /etc/tor/resolv.conf.local nameserver 127.0.0.1 That will work even if your hoster meddles with the settings, which I have seen happen with virtual/cloud servers. -Ralph