Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-10 Thread Ralph Seichter
On 09.10.2017 16:25, jpmvtd...@laposte.net wrote: > You thought dnsmasq was a caching DNS resolver, but it is a caching > DNS forwarder Hold on: Now *you* are deciding what *I* supposedly thought? :-D Since you read my mind, you can see what I am going to think next, and I don't need to waste

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-09 Thread jpmvtd261
Hello, On 09.10.2017 06:45, Ralph Seichter wrote: > This time you appear to combine a repetition of your old replies to > several distinct list messages from various authors with a fresh mix of > replies? Sorry, but I have no desire to wade through this just to figure > out which parts I am

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread jpmvtd261
Hello, Thanks for your interest. Disclaimer : this is a (too) big email. Igor Mitrofanov igor.n.mitrofanov at gmail.com , Sun Oct 8 03:41:19 UTC 2017: > 2. You can start by editing /etc/dnsmasq.conf as follows: > >

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Ralph Seichter
On 08.10.17 22:40, teor wrote: > This is only true if your resolver implements QNAME minimisation [...] > Does the version of the recursive resolver you're using do this? Unbound implements this, and via qname-minimisation-strict one can even disable the default fallback of sending full QNAME

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread teor
On 8 Oct 2017, at 16:24, Ralph Seichter wrote: >> who is aware of the query is not all that matters ; the apparent >> origin of the query also matters, depending of the position of the >> attacker. > > Sure, but keep in mind: Even if an attacker could gain access to

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Igor Mitrofanov
>> # Only listen on loopback >> >> interface=lo >> bind-interfaces > > What is your opinion about the config line "listen-address=127.0.0.1" advised > in https://wiki.debian.org/HowTo/dnsmasq#Local_Caching ? It should have a similar effect, except that 127.0.0.1 is IPv4 only, while "interface=lo"

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Ralph Seichter
On 08.10.17 21:40, jpmvtd...@laposte.net wrote: > Disclaimer : this is a (too) big email. Seriously? Can you really not answer to individual messages? ;-) > it is not necessarily better to ask directly to a root name server. Yes it is; for uncached lookups, one of the root zone servers must be

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Ralph Seichter
On 08.10.17 21:23, Igor Mitrofanov wrote: > you seem to be more concerned with minimizing the number of hosts > involved in a DNS lookup, and you (correctly) believe that running a > recursive resolver yourself, as opposed to delegating it, decreases > that number. Yes, that's what I have been

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread jpmvtd261
Hello, Thanks for your interest. Disclaimer : this is a (too) big email. Igor Mitrofanov igor.n.mitrofanov at gmail.com , Sun Oct 8 03:41:19 UTC 2017: > 2. You can start by editing /etc/dnsmasq.conf as follows: > >

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Igor Mitrofanov
Ralph, you seem to be more concerned with minimizing the number of hosts involved in a DNS lookup, and you (correctly) believe that running a recursive resolver yourself, as opposed to delegating it, decreases that number. If a DNS provider like Hurrican Electric is your main concern, then I think

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Ralph Seichter
On 08.10.17 20:48, Igor Mitrofanov wrote: > Unbound's upstream requests can be intercepted and used in traffic > correlation just like any other. I thought I expressed myself clearly enough, but I'll try one more time. Unbound, or any other resolver, can either a) perform the recursive lookup or

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Igor Mitrofanov
Please see the RFC that describes the recursive resolution algorithm: https://tools.ietf.org/html/rfc1034. Unbound is a simple recursive resolver. If it does not know the IP, it has to ask - there is no way around asking. The fact that you do not know what network links Unbound relies on ("just

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Ralph Seichter
On 08.10.17 19:48, Igor Mitrofanov wrote: > My hosting provider runs no DNS servers and recommends using 8.8.x.x, > so I have to pick something. You don't have to pick, and this is not meant to be patronising. Install Unbound with the few lines of configuration I posted earlier in this thread,

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Igor Mitrofanov
My hosting provider runs no DNS servers and recommends using 8.8.x.x, so I have to pick something. On Sun, Oct 8, 2017 at 10:22 AM, Ralph Seichter wrote: > On 08.10.17 18:34, Igor Mitrofanov wrote: > >> Unless configured otherwise, Dnsmasq chooses a server from the list

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Ralph Seichter
On 08.10.17 18:34, Igor Mitrofanov wrote: > Unless configured otherwise, Dnsmasq chooses a server from the list > randomly, so the more servers the operator specifies in dnsmasq.conf, > the less traffic each server gets. The "proper" way, meaning the way resulting in the smallest surface for

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Toralf Förster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2017 07:03 PM, Igor Mitrofanov wrote: > Toralf, thanks for the data. Has that 10% stabilized, or is it still > growing for your node? No, it is rather decreasing over time. I'm just too lazy till now to switch to another DNS cache, which

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Igor Mitrofanov
Toralf, thanks for the data. Has that 10% stabilized, or is it still growing for your node? On Sun, Oct 8, 2017 at 9:54 AM, Toralf Förster wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 10/08/2017 06:34 PM, Igor Mitrofanov wrote: >> With a large-enough

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Toralf Förster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2017 06:34 PM, Igor Mitrofanov wrote: > With a large-enough cache and sufficient uptime dnsmasq effectively > becomes a mini-DNS server that stores IP addresses for the vast > majority of sites that Tor users ever visit. NAK, just 10,000

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Igor Mitrofanov
Unless configured otherwise, Dnsmasq chooses a server from the list randomly, so the more servers the operator specifies in dnsmasq.conf, the less traffic each server gets. This increases the diversity of DNS requests, complicating traffic analysis for any adversary that controls some, but not

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Toralf Förster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2017 09:17 AM, Ralph Seichter wrote: > Unless you have a particular reason to use "dnsmasq", I strongly suggest > you use "unbound" (https://www.unbound.net) instead. May I asked, why you prefer unbound ? AFAIK there's pdns-recursor which

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Ralph Seichter
On 08.10.17 09:47, Toralf Förster wrote: > IMO there's absolutely no advantage of using external DNS servers. "No advantage" is putting it too mildly. Manually specifying upstream servers runs contrary to the very reason to have a resolver on the Tor node in the first place, which is to only

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Toralf Förster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/08/2017 05:41 AM, Igor Mitrofanov wrote: > Here's what I personally recommend: > # DNS servers > > no-resolv > > no-poll > > no-hosts > > server=8.8.4.4 > > server=8.26.56.26 > > server=74.82.42.42 > > server=64.6.64.6 > >

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-08 Thread Ralph Seichter
On 07.10.17 19:39, jpmvtd...@laposte.net wrote: > It looks like this package could introduce vulnerabilities if not > handled properly, because it provides more than just local DNS cache. Unless you have a particular reason to use "dnsmasq", I strongly suggest you use "unbound"

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-07 Thread Igor Mitrofanov
Here's what I personally recommend: 1. Make sure that /etc/resolv.conf contains 127.0.0.1 only. Ensure you have no DNS servers specified in /etc/network/interfaces. This will ensure that all DNS traffic will go through dnsmasq. 2. You can start by editing /etc/dnsmasq.conf as follows:

Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)

2017-10-07 Thread Toralf Förster
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/07/2017 07:39 PM, jpmvtd...@laposte.net wrote: > 5) Reboot (is it necessary ?). No, not at all. Just restart/reload dnsmasq if you change its config. - -- Toralf PGP C4EACDDE 0076E94E -BEGIN PGP SIGNATURE-