lets stop using central big DNS resolvers (Google, Level3, OpenDNS, Quad9, Cloudflare)
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_
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:
-- 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/
Tyler Durden:
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_
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 11.05.18 13:55, Nathaniel Suchy (Lunorian) 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. -Ralph
On 2018-05-11 14:52, Ralph Seichter wrote:
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ó:
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
Hi Tyler, hi all, On Thu, May 10, 2018 at 10:37:00PM +0000, Tyler Durden wrote:
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
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>:
-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
OpenNIC is always an option, https://www.opennic.org On Fri, May 11, 2018, 8:12 AM Tyler Durden <virii@enn.lu> 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. 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 Fri, May 11, 2018 at 10:54:06PM -0500, Andrew Deason wrote:
Thank you!
But isn't that what the subject line says? And the original email contains:
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.
On Sat, 12 May 2018 04:50:29 +0000 Matthew Finkel <matthew.finkel@gmail.com> wrote:
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:
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_
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 Sat, 12 May 2018 08:54:00 +0000 nusenu <nusenu-lists@riseup.net> wrote:
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
Am 11.05.2018 um 00:16 schrieb nusenu:
Thank you for giving another helpful push on that nusenu !! I changed my Linux exits. Unfortunately the /etc/resolv.conf gets overwritten on reboot. On Linux I solved that with editing /etc/resolvconf/resolv.conf.d/base. In that file, i put in the info as i would in resolv.conf. nameserver 127.0.0.1 Then i told resolvconf to regenerate resolv.conf sudo resolvconf -u 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? Where can I find an Update of https://gist.github.com/nusenu/cb766ff7945fafd9f90ee7f211a2508f#file-tor-dns... ? How can one find out which DNS resolver an exit uses? Thanks Paul
On 2018-05-13 15:34, Paul wrote:
If you use localhost (or in fact any fixed ip) for a resolver, you don't need the resolvconf package at all. Just uninstall it and you won't need to work around it. Another thing that can overwrite resolv.conf is DHCP client, if your relay is on DHCP for some reason. That can be stopped by configuring DHCP to *not* ask for DNS info. With the ISC DHCP client which was the default one at least until Debian jessie, that's done by editing /etc/dhcp/dhclient.conf . -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
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
Paul:
I changed my Linux exits. > Unfortunately the /etc/resolv.conf gets overwritten on reboot.
Good point, updated the relay guide to cover this. -- https://mastodon.social/@nusenu twitter: @nusenu_
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
participants (14)
-
Alex Xu -
Alexander Dietrich -
Andrew Deason -
Christian Pietsch -
Famicoman -
grarpamp -
Ian Zimmerman -
Matthew Finkel -
Nathaniel Suchy (Lunorian) -
nusenu -
Paul -
Ralph Seichter -
Santiago R.R. -
Tyler Durden