On 16.10.16 14:33, Tom van der Woerdt wrote:

Why doesn't Tor just link with a dns recursor, instead of relying on the user to get the configuration right?

It is not Tor's job to meddle with resolving DNS entries, and the notion of "getting it right" varies. Asking Tor operators to think about their resolvers is one thing, but interfering is quite a different story.

-Ralph

On 16.10.16 14:52, Tom van der Woerdt wrote:

If it affects the anonymity of users, it's Tor's job, no?

Tor cannot know what the "correct" resolver configuration is, because this depends on requirements/limitations of local infrastructure. Using public resolvers like 8.8.8.8 might be plain laziness, or because that's the only resolver a firewall will allow connections to.

That's just one of the reasons DNS resolving is delegated to a dedicated service in the first place.

-Ralph

Unbound does cache DNS entries, but there was also serious discussion about whether or not the cache is a privacy risk/anonymity leak, but I feel it's worth the trade-off since public DNS servers do the same thing.

On Sun, Oct 16, 2016 at 2:23 PM, Petrusko petrusko@riseup.net wrote:

Humm, I've not checked on the torproject website, tuto how to build a relay/exit... It can be nice to link a tutorial : how to set up quickly and easily a DNS resolver to increase privacy ?

May be exit operators can understand it's not really a big job to apt-get install unbound (an example) and use root DNS servers. I've always read using root DNS is not very good for speed... but if I'm not wrong Unbound (and others) have a cache ?

16/10/2016 12:52, Toralf Förster :

...

Adding different nameserver= lines to /etc/resolv.conf than 8.8.8.8 shouldn't be a big thing, or ?

-- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

---

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

TL;DR, if I understand how Tor relays work, Unbound (or any local DNS server) should see a request for example.com coming from localhost or 127.0.0.1. It answers the request, stores it in cache just in case, rinse and repeat. The machine running the exit relay is the one that makes the DNS request, so the only thing you'd get from looking at the DNS cache would be a "Top 100 Websites This Tor Relay Visits" sort of list.

From what I could find, a DNS cache contains the hostname and its

associated IP address, nothing more. From what I understand, even if a DNS cache saved the source of the request, it should save "127.0.0.1" or "localhost" as the source, since exit nodes are the source of the request, and simply forward the response back to the client.

I couldn't find anything specific about Unbound, but it seems like there isn't a proper way to read the DNS cache anyway unless you can somehow decode the binary file. I suppose if you know the specific cache file, you could copy it to a different machine with Unbound installed, and possibly extract data from that, but this theory assumes the cache is saved to the hard drive, and it's probably only stored in RAM.

On Sun, Oct 16, 2016 at 2:33 PM, Petrusko petrusko@riseup.net wrote:

Is there a way to know "who" has made this DNS query by reading the cache ? May be you can know there are 30 people have looked for google.com during the last 5 minutes, but "who" has made those DNS queries looks like difficult ? (I'm not an expert on hacking :p )

16/10/2016 21:28, Tristan :

...

Unbound does cache DNS entries, but there was also serious discussion about whether or not the cache is a privacy risk/anonymity leak, but I feel it's worth the trade-off since public DNS servers do the same thing.

-- Petrusko PubKey EBE23AE5 C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5

---

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

On 10/16/2016 04:54 PM, Petrusko wrote:

Thx for this share.

But I'm not sure how Unbound is "speaking" with the roots DNS servers... Somewhere I've read that DNS queries can be forwarded by a "man in the middle", and the server operator can't be sure about this :s An ISP is able to do it with your "private server" hosted behind your ISP's router...

I see DNSsec to crypt DNS queries from a client to a server, but for sure it's not possible to use it with roots DNS servers...

My VPS host uses 8.8.8.8 for DNS by default. I think it's configured in their DHCP settings or something because 8.8.8.8 will end up in /etc/resolv.conf every time the VPS restarts. Consequently, I have to keep an eye on /etc/resolv.conf to ensure that it always points to my Unbound instance. I take immediate action if this is not the case.

The dnscrypt repository on Github has a list of public DNS servers. I point my Unbound instance at one of them and I give Unbound as much RAM as I can to ensure that it caches as much as possible. In this way, I can reduce the frequency of lookups to external server. I have had limited success with DNSSEC. I eventually had to disable it because too many requests were failing (including torproject.org) and I was not able to correct the issue. DNSCrypt works just fine though if you can find a server that supports it.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 10/17/2016 04:37 AM, Jesse V wrote:

Consequently, I have to keep an eye on /etc/resolv.conf to ensure that it always points to my Unbound instance. I take immediate action if this is not the case.

Shouldn't /etc/resolv.conf.{head,tail} automate this ?

- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7

# chattr +i /etc/resolv.conf

Exact it works fine :)

Le 17/10/2016 à 09:49, Peter Palfrader a écrit :

On Sun, 16 Oct 2016, Jesse V wrote:

...

The dnscrypt repository on Github has a list of public DNS servers. I point my Unbound instance at one of them

Your unbound should probably just be recursive itself instead of relying on open 3rd party nameservers.

(As for /etc/resolv.conf, I usually just put nameserver 127.0.0.1 in there and chattr +i the file so it doesn't get munged by whatever magic is current this year.)

On 10/17/2016 12:34 PM, Hoshpak wrote:

...

# chattr +i /etc/resolv.conf

Exact it works fine :)

Please only do this if your are sure your server is not running in a Virtuozzo/OpenVZ container environment. On Virtuozzo, the startup procedure includes scripts that rewrite resolv.conf and fail if they can't write to it. In these cases you could be left with an unbootable container and have to raise a support ticket with your ISP to make them "fix" the issue by removing the immutable bit and starting the container again.

Thank you very much for that tip. Cronjob is probably the way to go then.

Got problems overnight. On all servers traffic died down and looks like below - what went wrong please? Here is what I did:

apt-get install dnsmasq

/etc/resolv.conf nameserver 127.0.0.1

/etc/dnsmasq.conf server=216.87.84.211 #open.nic us server=84.200.69.80 #dns.watch us server=84.200.70.40 #dns.watch us server=194.150.168.168 server=62.113.203.99 server=188.165.200.156 server=5.9.49.12 server=193.183.98.154 server=46.101.89.89 cache-size=10000 conf-file=usr/share/dnsmasq-base/trust-anchors.conf dnssec dnssec-check-unsigned

etc/init.d/dnsmasq restart

vnstat -h eth0 ^ r | rt rt rt | rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt r rt rt rt rt rt | rt rt rt rt rt rt rt rt r r r rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt rt -+---------------------------------------------------------------------------> | 12 13 14 15 16 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 10/17/2016 07:00 PM, pa011 wrote:

What servers do I put in /etc/dnsmasq.conf to get this solved best?

Currently I do just use nameservers from my ISP (Hetzner) :

mr-fox ~ # grep ^server /etc/dnsmasq.conf server=2a01:4f8:0:a0a1::add:1010 server=2a01:4f8:0:a102::add:9999 server=2a01:4f8:0:a111::add:9898 server=213.133.98.98 server=213.133.99.99 server=213.133.100.100

before (till yesterday) I had these too :

#server=194.150.168.168 #server=84.200.69.80 #server=84.200.70.40 #server=81.3.27.54 #server=5.153.48.164

but from the mentioned PDF I got the impression to just use the ISP nameservers + a local cache - which I'm trying now.

BTW The advantage of dnsmasq is to use more than 3 nameservers.

And this is the command I do use to check dnsmasq:

pkill -USR1 dnsmasq; sleep 1; tail -n 20 /var/log/syslog | grep -A 100 'dnsmasq.*: time'

- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7