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. Greetings nusenu:

Dear Exit Relay Operators,

I'd like to invite you to check your exit's DNS resolver by having a look at the following list of exits using resolvers outside their AS (especially if it is Google, OpenDNS, Quad9 or Cloudflare).

You can search the list for you contactinfo, relay nickname or relay fingerprint (first 8 characters):

https://gist.github.com/nusenu/cb766ff7945fafd9f90ee7f211a2508f#file-tor-dns...

I extended the "DNS on Exit Relays" section in the Tor Relay Guide to include specific instructions what is recommended for Tor exit operators with regards to DNS on exit relays.

https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#DNSonExitRelays

If you found yourself on the list above and changed your DNS to a local (same host or same AS) resolver or found a false-positive, please drop me an email (off-list is also ok).

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

the longer version of this can be found at: https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca

thanks for helping with DNS decentralization on the tor network, nusenu

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

-- Frënn vun der Ënn A.S.B.L. (NGO) e. virii@enn.lu (GPG: 0xce8c12f32a2cf11b) t. +352-27-40-20-30-4 w. https://enn.lu/

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

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 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

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. 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. -- Andrew Deason adeason@dson.org

On Sat, 12 May 2018 04:50:29 +0000 Matthew Finkel <matthew.finkel@gmail.com> wrote:

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

The subject line I think does effectively say to not use them as fallbacks, but indirectly. It requires some inferring by the relay operator and so it's easy for an operator to arrive at a different conclusion. The text you quoted immediately above (and the medium.com post) I think is not clear about this at all; it talks about an entity "controlling" dns traffic. If google's dns is set as a fallback, does google "control" my exit's dns traffic? The answer to that seems subjective to me; or if objective, then at least not obvious for the casual operator. The email and the guide page says to "not use" those dns services, but it tends to frame the issue as an either-or decision. That is, you guys are telling relay operators e.g. "if you have your resolv.conf set to google's dns, you should instead point to localhost and set up unbound". What if I just have google's dns as a fallback; does that count as "using" it? IMO, the text doesn't (explicitly) say. You can argue that the relay operator should infer that this does count, but if it was explicitly spelled out, there is less room for error. (The list of relays of course is one way of very explicitly spelling this out, by identifying problematic relays. That's the only way I found out that I was considered using google's dns.) It also would make it clear that trying to make dns resolution more "robust" (by providing fallbacks) is not considered by you to be worth the privacy implications of using those resolvers. 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. I don't mean to make a big deal about this; I'm just trying to explain some of what was going through my head when reading this stuff. "Fixing" it can be very simple, like just adding a small phrase like "don't use these, even as a fallback" or "don't mention anywhere in resolv.conf", like you said. -- Andrew Deason adeason@dson.org

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_

On Sat, 12 May 2018 08:54:00 +0000 nusenu <nusenu-lists@riseup.net> wrote:

"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)"

So is a non-overused same-AS fallback resolver preferable to having no fallback resolver, or the other way around? Or perhaps this doesn't matter so much, because the big problem right now is just the reliance on the 'big' resolvers....? -- Andrew Deason adeason@dson.org

sounds like something that could be scripted. Quoting nusenu (2018-05-10 22:16:00)

Dear Exit Relay Operators,

I'd like to invite you to check your exit's DNS resolver by having a look at the following list of exits using resolvers outside their AS (especially if it is Google, OpenDNS, Quad9 or Cloudflare).

You can search the list for you contactinfo, relay nickname or relay fingerprint (first 8 characters):

https://gist.github.com/nusenu/cb766ff7945fafd9f90ee7f211a2508f#file-tor-dns...

I extended the "DNS on Exit Relays" section in the Tor Relay Guide to include specific instructions what is recommended for Tor exit operators with regards to DNS on exit relays.

https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#DNSonExitRelays

If you found yourself on the list above and changed your DNS to a local (same host or same AS) resolver or found a false-positive, please drop me an email (off-list is also ok).

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

the longer version of this can be found at: https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca

thanks for helping with DNS decentralization on the tor network, 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 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