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

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

2017-10-08 Thread Ralph Seichter
On 08.10.17 11:46, Toralf Förster wrote: > May I asked, why you prefer unbound ? The OP was concerned than dnsmasq "could introduce vulnerabilities if not handled properly, because it provides more than just local DNS cache". In contrast, Unbound has a single purpose(*), and I found it to be a

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 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 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] Feedback wanted: letter to my university's library

2017-10-08 Thread grarpamp
> Parenthetically, even setting up a https://littlefreelibrary.org at my > condominium complex has been met with incomprehension and fear... Easier for them to do that than realize the many $thousands they paid for their education which could have been free. Indoctrination withdrawal syndrome is

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] Tor exit nodes attacking SSH?

2017-10-08 Thread grarpamp
On Wed, Aug 9, 2017 at 4:08 PM, Alexander Nasonov wrote: > m...@eugenemolotov.ru wrote: >> After that check from which ip it was logged in. This probably >> would be ip of the exit node. > > What if they "bridge" mitm-ed traffic to a different host? > > I saw a similar ssh

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

[tor-relays] unbound and DNS-over-TLS (dnsmasq configuration for an exit relay (Debian))

2017-10-08 Thread Santiago R.R.
El 08/10/17 a las 09:17, Ralph Seichter escribió: > 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

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