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

[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 any more time trying to offer advice to
you in this thread.

/me tunes out

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

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

[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 supposed to answer.

I apologize for this. I am having issues with my email provider when I try
to send an email to the list.

After reading the full conversation again, it appears there was a
misunderstanding. You thought dnsmasq was a caching DNS resolver, but it is
a caching DNS forwarder [1]. This confused me, but now what you said makes
sense.

On 09.10.2017 06:45, Ralph Seichter wrote:
> As for running a resolver properly: Follow my sound advice or don't. If
> you don't, please just let me know your node fingerprints, so I can set
> ExcludeExitNodes accordingly. ;-)

As you said before, using the ISP resolver is a valid option, and this is
why I am going to do it, with the help of dnsmasq or another caching DNS
forwarder. Do you maintain your request for my node fingerprints ?

Regards

[1] https://packages.debian.org/stable/dnsmasq
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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:
>
>
> # 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 ?



Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 08:03:49 UTC 2017:
> 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 involve the
> necessary minimum set of servers for each query.

Just a side note: it is not necessarily better to ask directly to a root name
server. In particular if the attacker is the root name server (
https://en.wikipedia.org/wiki/Root_name_server ) or if the attacker monitors
the traffic going in and out of the root name server (in this case, using ISP
DNS server can be better). What I want to point out is this : 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. 



Igor Mitrofanov igor.n.mitrofanov at gmail.com , Sun Oct 8 16:34:53 UTC 2017
> 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 all, links between the host and the DNS
> servers.

I agree in the case where the exit relay operator don't use his/her ISP DNS
server (they don't exist, or they are misconfigured, or they have shown
malicious behaviour, or the operator just doesn't want to). In the case where
the relay operator wants to use his/her ISP DNS server, I think it's not useful
to send part of DNS queries randomly to open DNS servers, because the ISP is
aware of all the DNS traffic anyway, and nobody else can tell whether the DNS
traffic out of the ISP comes from a Tor relay or from a standard ISP's customer.



Toralf Förster toralf.foerster at gmx.de , Sun Oct 8 16:54:43 UTC 2017:
> so just 10% of all DNS queries are cached, the vast majority is forwarded to
> the DNS server of my ISP.

Interesting. Could you tell approximately what is the average Tor traffic per
second on your relay ? Maybe I will increase the number of cached entries to
100 000.



Toralf Förster toralf.foerster at gmx.de , Sun Oct 8 17:08:47 UTC 2017:
> I'm just too lazy till now to switch to another DNS cache, which has a
> reliable working DNSSEC (dnsmasq does that well AFAICT).

Is DNSSEC of any use for caching purpose ? The first time you retrieve a
correspondance between a domain name and an IP address, you use DNSSEC, then you
put this information in cache. The second time, you retrieve the information
from the cache, DNSSEC may not be useful, is it ?



Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 17:22:22 UTC 2017:
> If the ISP hosting the Tor node has resolvers for their customers, these can
> be used as well, since the ISP sees all outgoing traffic anyway, but I can't
> think of any reason to use third-party resolvers (especially the infamous
> Google 8.8.x.x) beyond the hosting ISP.

If ISP DNS server is good, I can't neither. But otherwise, I think that using
several open DNS servers selected randomly is better than using only one and
always the same open DNS server. First, because if the attacker is the open DNS
server, it's obviously a bad thing. Second, because if the attacker is not an
open DNS server, he/she needs to monitor a larger part of the network (he/she
needs to listen to traffic between the exit relay and all of the open DNS
servers in the list, instead of just one).

>
> The historic notion of "don't contact upstream resolvers directly" from a time
> where traffic was expensive is no longer valid, especially for a Tor node
> where the key goal is to make it harder for third party actors to analyse what
> the node is doing.

If the attacker can listen the traffic between the exit node and the upstream
resolver, I don't think contacting the upstream resolver directly is better than
contacting it indirectly. Same thing if the attacker is the upstream resolver.

>
> I don't know what you call "a full DNS server"? A caching resolver should, by
> its nature, contact all upstream nameservers as 

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

[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 data if the
initial lookup with minimal QNAME fails.

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

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

[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 all
> root zone servers, he could not see the necessary follow-up queries on
> TLD level (e.g. country domains, or .com, .net, etc.) and beyond. If I
> looked up host.somedomain.fr, a root zone snoop might show my interest
> in a French domain, but nothing else.

This is only true if your resolver implements QNAME minimisation:
https://tools.ietf.org/html/rfc7816

> Currently, when a resolver receives the query "What is the  record for 
> www.example.com?", it sends to the root (assuming a cold resolver, whose 
> cache is empty) the very same question. Sending the full QNAME to the 
> authoritative name server is a tradition, not a protocol requirement.

Does the version of the recursive resolver you're using
do this?

Or does it send only the minimal name required?

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

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

[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" seems IP version agnostic (I have disabled IPv6
on my relay so I don't know this for sure).

> Interesting. Could you tell approximately what is the average Tor traffic per
> second on your relay ? Maybe I will increase the number of cached entries to
> 100 000.

I am afraid you cannot increase it without recompiling dnsmasq from
source. It has a hardcoded limit of 10k.

I believe that cache efficiency can be tuned with *ttl config
parameters, but it would take considerable time to tune it. I also bet
it depends on the Exit policy of your relay - the more ports you
allow, the more requests will miss the cache.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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
involved anyway. As of today, that will be one of thirteen servers, and
I'd be extremely surprised if an attacker could monitor them all.

> 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 all
root zone servers, he could not see the necessary follow-up queries on
TLD level (e.g. country domains, or .com, .net, etc.) and beyond. If I
looked up host.somedomain.fr, a root zone snoop might show my interest
in a French domain, but nothing else.

> If the attacker can listen the traffic between the exit node and the
> upstream resolver, I don't think contacting the upstream resolver
> directly is better than contacting it indirectly.

So what? If the attacker can hack your ISP's infrastructure to listen
in, this whole discussion is academic. Otherwise, "the upstream
resolver" varies with each individual query, unless one configures the
upstream servers manually. Hence, leaving the local resolver to freely
choose upstream servers is preferable.

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

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

[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 trying to communicate; I hope I was not too
long-winded. Keeping the number of involved servers as low as possible
is important for Tor nodes, and I'm happy to live with the small extra
cost of running a caching resolver on my nodes to achieve this goal.

Unfortunately both individuals and ISPs seem to recommend using Google's
infamous 8.8.x.x servers, for convenience if for no other reason. If I
can avoid it, I will personally not use servers located in Mountain View
(that's where GeoIP tells me these machines are) or elsewhere in the US,
where the hoster might be willing or even required to keep logs of DNS
lookups that can be correlated to my hosts simply by the originating IP
addresses.

> I assume, however, that most of these ISPs have no technical
> capability or business incentives to be engaged in Tor traffic
> correlation.

Quite. I choose ISPs in countries that, to the best of my knowledge,
have laws that would make it difficult and time-consuming for the NSA,
GCHQ or other intelligence services to get access to logs by legal
means.

> I am making an assumption that Tor relays sending DNS requests to a
> large and diverse number of destinations can make practical DNS-assisted
> traffic correlation prohibitively expensive.

That's what I hope, and I am trying to do my part to increase that cost.

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

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

[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:
>
>
> # 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 ?



Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 08:03:49 UTC 2017:
> 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 involve the
> necessary minimum set of servers for each query.

Just a side note: it is not necessarily better to ask directly to a root name
server. In particular if the attacker is the root name server (
https://en.wikipedia.org/wiki/Root_name_server ) or if the attacker monitors
the traffic going in and out of the root name server (in this case, using ISP
DNS server can be better). What I want to point out is this : 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. 



Igor Mitrofanov igor.n.mitrofanov at gmail.com , Sun Oct 8 16:34:53 UTC 2017
> 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 all, links between the host and the DNS
> servers.

I agree in the case where the exit relay operator don't use his/her ISP DNS
server (they don't exist, or they are misconfigured, or they have shown
malicious behaviour, or the operator just doesn't want to). In the case where
the relay operator wants to use his/her ISP DNS server, I think it's not useful
to send part of DNS queries randomly to open DNS servers, because the ISP is
aware of all the DNS traffic anyway, and nobody else can tell whether the DNS
traffic out of the ISP comes from a Tor relay or from a standard ISP's customer.



Toralf Förster toralf.foerster at gmx.de , Sun Oct 8 16:54:43 UTC 2017:
> so just 10% of all DNS queries are cached, the vast majority is forwarded to
> the DNS server of my ISP.

Interesting. Could you tell approximately what is the average Tor traffic per
second on your relay ? Maybe I will increase the number of cached entries to
100 000.



Toralf Förster toralf.foerster at gmx.de , Sun Oct 8 17:08:47 UTC 2017:
> I'm just too lazy till now to switch to another DNS cache, which has a
> reliable working DNSSEC (dnsmasq does that well AFAICT).

Is DNSSEC of any use for caching purpose ? The first time you retrieve a
correspondance between a domain name and an IP address, you use DNSSEC, then you
put this information in cache. The second time, you retrieve the information
from the cache, DNSSEC may not be useful, is it ?



Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 17:22:22 UTC 2017:
> If the ISP hosting the Tor node has resolvers for their customers, these can
> be used as well, since the ISP sees all outgoing traffic anyway, but I can't
> think of any reason to use third-party resolvers (especially the infamous
> Google 8.8.x.x) beyond the hosting ISP.

If ISP DNS server is good, I can't neither. But otherwise, I think that using
several open DNS servers selected randomly is better than using only one and
always the same open DNS server. First, because if the attacker is the open DNS
server, it's obviously a bad thing. Second, because if the attacker is not an
open DNS server, he/she needs to monitor a larger part of the network (he/she
needs to listen to traffic between the exit relay and all of the open DNS
servers in the list, instead of just one).

>
> The historic notion of "don't contact upstream resolvers directly" from a time
> where traffic was expensive is no longer valid, especially for a Tor node
> where the key goal is to make it harder for third party actors to analyse what
> the node is doing.

If the attacker can listen the traffic between the exit node and the upstream
resolver, I don't think contacting the upstream resolver directly is better than
contacting it indirectly. Same thing if the attacker is the upstream resolver.

>
> I don't know what you call "a full DNS server"? A caching resolver should, by
> its nature, contact all upstream nameservers as 

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

[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 we are in agreement.

I assume, however, that most of these ISPs have no technical
capability or business incentives to be engaged in Tor traffic
correlation. When it comes to Tor traffic correlation, I am more
concerned with defending Tor users against the already-known
attackers.

According to the leaked documents, there is a large, but not global,
passive adversary confirmed to intercepting and analyzing IP traffic
between targeted hosts, without the capacity to control all network
links, and without the legal authority to hack the hosts themselves. I
am making an assumption that Tor relays sending DNS requests to a
large and diverse number of destinations can make practical
DNS-assisted traffic correlation prohibitively expensive.


On Sun, Oct 8, 2017 at 12:03 PM, Ralph Seichter  wrote:
> 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 b) delegate the lookup. Case a) is preferable in regards to
> profiling because it does not involve additional third-party servers
> that have nothing to do with the query. Case b) involves third-party
> servers, so it offers more points where traffic can be analysed. Looking
> up host.somedomain.tld should, if no cached data is available, only
> involve one of the root zone servers, one server for the tld zone, and
> one server for the somedomain zone. It should not involve a resolver run
> by Google or other parties that have no business in knowing that my Tor
> node just looked up host.somedomain.tld.
>
>> Yes, Unbound follows the recursive protocol and works with the
>> hierarchy from the root DNS servers down, but your ISP can still
>> observe your entire DNS activity.
>
> I have explicitly stated "If the ISP hosting the Tor node has resolvers
> for their customers, these can be used as well, *since the ISP sees all
> outgoing traffic anyway*". Are you deliberately trying to misunderstand
> me?
>
> -Ralph
> ___
> tor-relays mailing list
> 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

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

[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 b) delegate the lookup. Case a) is preferable in regards to
profiling because it does not involve additional third-party servers
that have nothing to do with the query. Case b) involves third-party
servers, so it offers more points where traffic can be analysed. Looking
up host.somedomain.tld should, if no cached data is available, only
involve one of the root zone servers, one server for the tld zone, and
one server for the somedomain zone. It should not involve a resolver run
by Google or other parties that have no business in knowing that my Tor
node just looked up host.somedomain.tld.

> Yes, Unbound follows the recursive protocol and works with the
> hierarchy from the root DNS servers down, but your ISP can still
> observe your entire DNS activity.

I have explicitly stated "If the ISP hosting the Tor node has resolvers
for their customers, these can be used as well, *since the ISP sees all
outgoing traffic anyway*". Are you deliberately trying to misunderstand
me?

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

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

[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 let it do its magic")
does not make your Exit relay any more secure.

Unbound's upstream requests can be intercepted and used in traffic
correlation just like any other. Yes, Unbound follows the recursive
protocol and works with the hierarchy from the root DNS servers down,
but your ISP can still observe your entire DNS activity. This is very
similar to running dnsmasq configured to work the DNS server hosted by
the ISP (which then performs the recursive functions) - except in my
case there isn't one.

On Sun, Oct 8, 2017 at 10:59 AM, Ralph Seichter  wrote:
> 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, and set your /etc/resolv.conf to "nameserver 127.0.0.1". Unbound
> will contact upstream servers as required. You don't have to configure
> *any* upstream servers manually.
>
> See https://en.wikipedia.org/wiki/Domain_Name_System "Address resolution
> mechanism" for what will happen under the hood.
>
> -Ralph
>
> ___
> tor-relays mailing list
> 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

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

[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, and set your /etc/resolv.conf to "nameserver 127.0.0.1". Unbound
will contact upstream servers as required. You don't have to configure
*any* upstream servers manually.

See https://en.wikipedia.org/wiki/Domain_Name_System "Address resolution
mechanism" for what will happen under the hood.

-Ralph

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

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

[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
>> 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
> behavioural analysis of the node outside the ISP hosting the node, is to
> not manually configure any upstream servers at all for the caching
> resolver running on the Tor node. That way, only upstream servers that
> are actually required to resolve individual queries are contacted.
>
> If the ISP hosting the Tor node has resolvers for their customers, these
> can be used as well, since the ISP sees all outgoing traffic anyway, but
> I can't think of any reason to use third-party resolvers (especially the
> infamous Google 8.8.x.x) beyond the hosting ISP.
>
> The historic notion of "don't contact upstream resolvers directly" from
> a time where traffic was expensive is no longer valid, especially for a
> Tor node where the key goal is to make it harder for third party actors
> to analyse what the node is doing.
>
>> I have not seen any research papers that would indicate that the cost
>> of running a full DNS server on an Exit relay is worthwhile and that
>> it improves anonymity substantially more compared to a lightweight
>> cache resolver.
>
> I don't know what you call "a full DNS server"? A caching resolver
> should, by its nature, contact all upstream nameservers as required,
> including the root zone servers. There is no need for Unbound, BIND or
> similar resolver software to delegate queries only to a manually
> configured and therefore limited list of nameservers. Just let these
> resolvers do their job. From what I see on my nodes, the cost of Unbound
> is negligible, compared to what Tor itself requires.
>
> Unless you can produce research papers that show it is *not* worth
> letting my resolvers contact upstream nameservers as they consider
> necessary, I'll stick to advocating what I wrote above. ;-)
>
> -Ralph
> ___
> tor-relays mailing list
> 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

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

[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
behavioural analysis of the node outside the ISP hosting the node, is to
not manually configure any upstream servers at all for the caching
resolver running on the Tor node. That way, only upstream servers that
are actually required to resolve individual queries are contacted.

If the ISP hosting the Tor node has resolvers for their customers, these
can be used as well, since the ISP sees all outgoing traffic anyway, but
I can't think of any reason to use third-party resolvers (especially the
infamous Google 8.8.x.x) beyond the hosting ISP.

The historic notion of "don't contact upstream resolvers directly" from
a time where traffic was expensive is no longer valid, especially for a
Tor node where the key goal is to make it harder for third party actors
to analyse what the node is doing.

> I have not seen any research papers that would indicate that the cost
> of running a full DNS server on an Exit relay is worthwhile and that
> it improves anonymity substantially more compared to a lightweight
> cache resolver.

I don't know what you call "a full DNS server"? A caching resolver
should, by its nature, contact all upstream nameservers as required,
including the root zone servers. There is no need for Unbound, BIND or
similar resolver software to delegate queries only to a manually
configured and therefore limited list of nameservers. Just let these
resolvers do their job. From what I see on my nodes, the cost of Unbound
is negligible, compared to what Tor itself requires.

Unless you can produce research papers that show it is *not* worth
letting my resolvers contact upstream nameservers as they consider
necessary, I'll stick to advocating what I wrote above. ;-)

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

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

[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 has a reliable 
working DNSSEC (dnsmasq does that well AFAICT).


- -- 
Toralf
PGP C4EACDDE 0076E94E
-BEGIN PGP SIGNATURE-

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdpbnxccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTlY7AP4hEXFloV1HD9Wp5Gt8rvqhZxCL
dwNZOhTdIxIDwdTv4QD/fvboXG9uW0gdEUgbkhlyFcfxHwBjQZC77BJFAY7eJ6s=
=zbrJ
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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 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 addresses can be cached.
>
> The stats of dnsmasq my exit relay shows after 6 hours :
>
> Oct  8 18:51:17 mr-fox dnsmasq[19806]: cache size 1, 203238/1102103 cache 
> insertions re-used unexpired cache entries.
> Oct  8 18:51:17 mr-fox dnsmasq[19806]: queries forwarded 444146, queries 
> answered locally 42117
> Oct  8 18:51:17 mr-fox dnsmasq[19806]: DNSSEC memory in use 120768, max 
> 173280, allocated 84
>
> so just 10% of all DNS queries are cached, the vast majority is forwarded to 
> the DNS server of my ISP.
>
> - --
> Toralf
> PGP C4EACDDE 0076E94E
> -BEGIN PGP SIGNATURE-
>
> iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdpYUxccdG9yYWxmLmZv
> ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTlOlAP0RNGzXHqM7blXf/TmaAagKoWW2
> Gb2/YGRwC0yeZ+qOAAD+P7EN2GQ5bdpoVG4eBq17Hq3y6Qoegyh/CRyI5rZWQpc=
> =Yd69
> -END PGP SIGNATURE-
> ___
> tor-relays mailing list
> 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

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

[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 addresses can be cached.

The stats of dnsmasq my exit relay shows after 6 hours :

Oct  8 18:51:17 mr-fox dnsmasq[19806]: cache size 1, 203238/1102103 cache 
insertions re-used unexpired cache entries.
Oct  8 18:51:17 mr-fox dnsmasq[19806]: queries forwarded 444146, queries 
answered locally 42117
Oct  8 18:51:17 mr-fox dnsmasq[19806]: DNSSEC memory in use 120768, max 173280, 
allocated 84

so just 10% of all DNS queries are cached, the vast majority is forwarded to 
the DNS server of my ISP.

- -- 
Toralf
PGP C4EACDDE 0076E94E
-BEGIN PGP SIGNATURE-

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdpYUxccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTlOlAP0RNGzXHqM7blXf/TmaAagKoWW2
Gb2/YGRwC0yeZ+qOAAD+P7EN2GQ5bdpoVG4eBq17Hq3y6Qoegyh/CRyI5rZWQpc=
=Yd69
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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 all, links between the host and the DNS
servers.

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. With little to no
outgoing DNS traffic from the host, DNS-assisted correlation
("DefecTor") becomes impractical for anyone, including the hosting
provider. Combined with very low resource utilization of dnsmasq,
running it on an Exit node improves anonymity for the majority of Tor
users at almost zero cost. The only scenario where a cache does not
help is resolving rare hostnames that nobody has visited yet, but even
in this case, with multiple upstream DNS servers only an adversary
controlling the AS is guaranteed to intercept the request.

I have not seen any research papers that would indicate that the cost
of running a full DNS server on an Exit relay is worthwhile and that
it improves anonymity substantially more compared to a lightweight
cache resolver. If you know of any, please share, and I'll be happy to
change my mind.

- Igor

On Sun, Oct 8, 2017 at 1:03 AM, Ralph Seichter  wrote:
> 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 involve the necessary minimum
> set of servers for each query.
>
> -Ralph
> ___
> tor-relays mailing list
> 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

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

[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 seems 
to do a similar job, or ?

- -- 
Toralf
PGP C4EACDDE 0076E94E
-BEGIN PGP SIGNATURE-

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdnz5BccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTsd+AP9mIQdw/4P7dJd69xtw5GuybBO+
jQemJaz4feSOHrA2/gD/Th7sSDh28edMI+y4SpzXx5ZtegD5Oqpqd/CGdiSrE8s=
=LsZX
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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 involve the necessary minimum
set of servers for each query.

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

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

[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
> 
> server=8.8.8.8
> 
> server=8.20.247.20
> 
> server=64.6.65.6

IMO there's absolutely no advantage of using external DNS servers.
The AS of the Tor exit Relay will already see the in and outgoing traffic.
So this will just spread out information to therd parties too w/o any 
additional security.

There're a lot of papers around that topic, eg. in [ 1]



[1] https://nymity.ch/tor-dns/


- -- 
Toralf
PGP C4EACDDE 0076E94E
-BEGIN PGP SIGNATURE-

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdnYCxccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTid0AP4nEna1cQ22acUjf3NmFAn7vZuk
nIrP8yFjIcFk+sbmjgD/UlS7E0boHEUDotMmplvpiWU5L/YkMofa9Zep93D76Jw=
=2LgX
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

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

[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" (https://www.unbound.net) instead. It supports DNSSEC
and is very easy to configure. Here's a config file for a Tor node with
both IPv4 and IPv6 interfaces:

  # /etc/unbound/unbound.conf
  server:
interface: 127.0.0.1
interface: ::1
root-hints: "/etc/unbound/named.cache"
log-queries: no
verbosity: 0

Optional: If your node has multiple IP addresses and you want to use a
specific one (usually one not used for Tor) for outbound connections,
add the line "outgoing-interface: {your-ip-here}" to unbound.conf.

While "log-queries: no" is the default setting, I always add it anyway,
in case the unbound authors decide to change this in future releases,
however unlikely.

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

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

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

 

# Only listen on loopback

interface=lo

bind-interfaces

 

# 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

server=8.8.8.8

server=8.20.247.20

server=64.6.65.6

 

# Performance

cache-size=1

dns-forward-max=2048

 

# No DHCP or TFTP

no-dhcp-interface=1

 

3. The value of dns-forward-max is just a rough guess for a high-capacity Exit 
relay. Please feel free to tune it.

4. Use ss or netstat to make sure that dnsmasq only opens port 53 on the 
loopback interface (lo, 127.0.0.01) and does not listen on any external network 
interfaces.

5. If you have iptables configured, please make sure you allow traffic to port 
53 from 127.0.0.1.

6. You can find the IP addresses of some public DNS servers here: 
https://www.lifewire.com/free-and-public-dns-servers-2626062.

7. Consider adding any DNS servers that your ISP may provide (ask them).

8. PLEASE exclude any DNS servers that attempt to censor/filter any web 
addresses (such as “Comodo Secure DNS”).

9. I recommend picking DNS servers with the lowest ping latency to your Tor 
relay (i.e. try pinging them manually).

 

Thanks for running a Tor relay!

- Igor

 

-Original Message-
From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of 
jpmvtd...@laposte.net
Sent: Saturday, October 7, 2017 10:39 AM
To: tor-relays@lists.torproject.org
Subject: [tor-relays] dnsmasq configuration for an exit relay (Debian)

 

Hello,

 

I am looking for instructions on how to configure dnsmasq on a Debian exit 
relay (in order to cache DNS queries).

 

It looks like this package could introduce vulnerabilities if not handled 
properly, because it provides more than just local DNS cache.

 

If I had to install it without any advice, I would do this :

 

 

1) Install dnsmaq package with the command  "aptitude install dnsmask" .

 

2) Make sure that the first line of the file /etc/resolv.conf is  "nameserver 
127.0.0.1"  (see   
https://wiki.debian.org/HowTo/dnsmasq#Local_Caching ).

 

3) Make sure that the file /etc/dnsmasq.conf contains the line  
"listen-address=127.0.0.1"  (to restrict dnsmasq to the local system).

 

4) Set the cache size to 1 by adding or editing this line  
"cache-size=1"  in the file /etc/dnsmasq.conf  (as suggested by Igor 
Mitrofanov here  
 
https://lists.torproject.org/pipermail/tor-relays/2017-August/012708.html ).

 

5) Reboot (is it necessary ?).

 

 

Does anyone think that this procedure could start a daemon listening on a port 
of my server ? Or is it safe to do this on my exit relay ?

 

Regards

___

tor-relays mailing list

  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

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

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

iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWdkrfRccdG9yYWxmLmZv
ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTocnAP0YrkDKaBbkuE3aRwJfRROKiAOx
nQP7KoP6J2YpaLYjhQD+JFyTmVTJLykpfrksuqJLqWLRBMJVOh5hpB3CkphKeGE=
=pNbC
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays