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

-----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 10000, 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 999984

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

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 m16+tor@monksofcool.net 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

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 m16+tor@monksofcool.net 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

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 m16+tor@monksofcool.net 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

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 required, including the root zone servers.

Unless I am mistaken, dnsmasq, configured as mentionned in my first email ( https://lists.torproject.org/pipermail/tor-relays/2017-October/013203.html ), does not do any resolving. It does not contact any upstream nameserver ever. It just caches DNS informations, and when these informations are not enough, it forwards the query to a DNS server (choosen randomly from the list in its config file).

--------------------------------------------------------------------------------

Igor Mitrofanov igor.n.mitrofanov at gmail.com , Sun Oct 8 16:34:53 UTC 2017

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.

Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 17:22:22 UTC 2017:

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. ;-)

I read something relevant. I think you already read it, but here it is ( https://nymity.ch/tor-dns/tor-dns.pdf page 13 ):

Exit relay operators face a dilemma: they must either operate their own resolver, which exposes DNS queries to network adversaries; or, they must use a third-party DNS resolver, which exposes DNS queries to a third party. Clearly, the goal is to minimize exposure of DNS requests, but there are several dimensions to this. In lieu of substantial DNS protocol improvements, we envision three extreme design points, in which all exit relays use (i) Google’s DNS resolver; (ii) their own, local resolver; or (iii) the resolver provided by their ISP.

If all exit relays were to use Google’s public resolver, the company would obtain metadata about the activity of all Tor users, which runs counter to Tor’s design goal of distributing trust. We clearly should avoid this scenario. Fifield et al.’s [18] censorship circumvention system meek used to use Google’s cloud infrastructure to tunnel the traffic of censored users up until May 2016 [17]. While the system was operational, thousands of meek clients selected exit relays that use Google’s public resolver, which means that Google saw both traffic entering and, partially, exiting the Tor network, allowing the company to mount DefecTor attacks. Next, consider a Tor network that only uses local resolvers. In this case, Tor is fully independent of third-party resolvers, at the cost of each iterative DNS query being exposed to a diverse set of ASes in the network, allowing several parties to learn the DNS queries of Tor users. Finally, all exit relays could simply use their ISP-provided resolver. This would minimize the network exposure of DNS requests as resolvers are frequently in the same AS as exit relays, and AS-level adversaries would be unable to distinguish between DNS requests from exit relays and unrelated ISP customers. However, this setup introduces the possibility of misconfigured and censored DNS resolvers [49, § 4.1]. Besides, just a few ASes—OVH, for example—host a disproportionate amount of exit relays, turning them into the very centralized data sinks that Tor aims to avoid.

Considering the above, we believe that exit relay operators should avoid public resolvers such as Google and OpenDNS. Instead, they should either use the resolvers provided by their ISP, or run their own, particularly if the operator’s ISP already hosts many other exit relays. Local resolvers can further be configured to minimize information leakage, by enabling QNAME minimization [7]. There likely is a measurable performance difference between a local resolver and Google’s resolver, but we believe that this difference pales in comparison to other performance issues in Tor such as head-of-line blocking.

Finally, Tor can fix the Tor clipping bug we discovered and consider significantly increasing the minimum TTL for the DNS cache at exit relays to make DefecTor attacks less precise. This adjustment requires finding the longest acceptable TTL that does not have a notable negative detriment to user experience. Further, as soon as the clipping bug is fixed, website operators of sensitive websites can opt to increase the TTL of their DNS records.

So this is why I choose to use only dnsmasq and my ISP's DNS server :

- I am not the most skilled system admin or network engineer, so fully understanding and managing a simple cache is more suited to me than running my own DNS resolver ("Local resolvers can further be configured to minimize information leakage, by enabling QNAME minimization"). - The exit share of my ISP is small. - I think my ISP is skilled enough to not misconfigure their DNS servers.

I am vulnerable to malicious behaviour of my ISP's DNS server, but if my ISP is malicious, my relay is compromised anyway.

Although in the end I think a balance between local resolvers and ISP resolvers would be good. In this paper ( https://nymity.ch/tor-dns/tor-dns.pdf ) they say that 12% of exit relays have that config : {they use a local DNS resolver AND that resolver use the same IP address as Tor}. I think that they can't count those who use a local DNS resolver but contact upstream resolver on an IP different than the Tor IP.

This paper does not talk about what Igor talks about: they speak about exit relays who use always the same open DNS server, but not about exit relays who choose an open DNS server randomly from a list (different server for each query).

--------------------------------------------------------------------------------

Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 19:03:23 UTC 2017:

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.

I think you made it clear. The thing is, I (and maybe Igor) don't think it's that simple to declare it preferable. There are cases where it is, and there are cases where it is not. Which one you choose is a matter of personal taste, skill and network environment (ISP reputation ...), at least while no one ruled it with a good research paper.

--------------------------------------------------------------------------------

Regards

On 8 Oct 2017, at 16:24, Ralph Seichter m16+tor@monksofcool.net 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 AAAA 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

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 required, including the root zone servers.

Unless I am mistaken, dnsmasq, configured as mentionned in my first email ( https://lists.torproject.org/pipermail/tor-relays/2017-October/013203.html ), does not do any resolving. It does not contact any upstream nameserver ever. It just caches DNS informations, and when these informations are not enough, it forwards the query to a DNS server (choosen randomly from the list in its config file).

--------------------------------------------------------------------------------

Igor Mitrofanov igor.n.mitrofanov at gmail.com , Sun Oct 8 16:34:53 UTC 2017

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.

Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 17:22:22 UTC 2017:

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. ;-)

I read something relevant. I think you already read it, but here it is ( https://nymity.ch/tor-dns/tor-dns.pdf page 13 ):

Exit relay operators face a dilemma: they must either operate their own resolver, which exposes DNS queries to network adversaries; or, they must use a third-party DNS resolver, which exposes DNS queries to a third party. Clearly, the goal is to minimize exposure of DNS requests, but there are several dimensions to this. In lieu of substantial DNS protocol improvements, we envision three extreme design points, in which all exit relays use (i) Google’s DNS resolver; (ii) their own, local resolver; or (iii) the resolver provided by their ISP.

If all exit relays were to use Google’s public resolver, the company would obtain metadata about the activity of all Tor users, which runs counter to Tor’s design goal of distributing trust. We clearly should avoid this scenario. Fifield et al.’s [18] censorship circumvention system meek used to use Google’s cloud infrastructure to tunnel the traffic of censored users up until May 2016 [17]. While the system was operational, thousands of meek clients selected exit relays that use Google’s public resolver, which means that Google saw both traffic entering and, partially, exiting the Tor network, allowing the company to mount DefecTor attacks. Next, consider a Tor network that only uses local resolvers. In this case, Tor is fully independent of third-party resolvers, at the cost of each iterative DNS query being exposed to a diverse set of ASes in the network, allowing several parties to learn the DNS queries of Tor users. Finally, all exit relays could simply use their ISP-provided resolver. This would minimize the network exposure of DNS requests as resolvers are frequently in the same AS as exit relays, and AS-level adversaries would be unable to distinguish between DNS requests from exit relays and unrelated ISP customers. However, this setup introduces the possibility of misconfigured and censored DNS resolvers [49, § 4.1]. Besides, just a few ASes—OVH, for example—host a disproportionate amount of exit relays, turning them into the very centralized data sinks that Tor aims to avoid.

Considering the above, we believe that exit relay operators should avoid public resolvers such as Google and OpenDNS. Instead, they should either use the resolvers provided by their ISP, or run their own, particularly if the operator’s ISP already hosts many other exit relays. Local resolvers can further be configured to minimize information leakage, by enabling QNAME minimization [7]. There likely is a measurable performance difference between a local resolver and Google’s resolver, but we believe that this difference pales in comparison to other performance issues in Tor such as head-of-line blocking.

Finally, Tor can fix the Tor clipping bug we discovered and consider significantly increasing the minimum TTL for the DNS cache at exit relays to make DefecTor attacks less precise. This adjustment requires finding the longest acceptable TTL that does not have a notable negative detriment to user experience. Further, as soon as the clipping bug is fixed, website operators of sensitive websites can opt to increase the TTL of their DNS records.

So this is why I choose to use only dnsmasq and my ISP's DNS server :

- I am not the most skilled system admin or network engineer, so fully understanding and managing a simple cache is more suited to me than running my own DNS resolver ("Local resolvers can further be configured to minimize information leakage, by enabling QNAME minimization"). - The exit share of my ISP is small. - I think my ISP is skilled enough to not misconfigure their DNS servers.

I am vulnerable to malicious behaviour of my ISP's DNS server, but if my ISP is malicious, my relay is compromised anyway.

Although in the end I think a balance between local resolvers and ISP resolvers would be good. In this paper ( https://nymity.ch/tor-dns/tor-dns.pdf ) they say that 12% of exit relays have that config : {they use a local DNS resolver AND that resolver use the same IP address as Tor}. I think that they can't count those who use a local DNS resolver but contact upstream resolver on an IP different than the Tor IP.

This paper does not talk about what Igor talks about: they speak about exit relays who use always the same open DNS server, but not about exit relays who choose an open DNS server randomly from a list (different server for each query).

--------------------------------------------------------------------------------

Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 19:03:23 UTC 2017:

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.

I think you made it clear. The thing is, I (and maybe Igor) don't think it's that simple to declare it preferable. There are cases where it is, and there are cases where it is not. Which one you choose is a matter of personal taste, skill and network environment (ISP reputation ...), at least while no one ruled it with a good research paper.

--------------------------------------------------------------------------------

Regards

Under the assumption of a non compromised ISP, and under the assumption of an attacker able to listen to traffic going to 50% of DNS servers (queries to root and TLD like .com, .org, .net):

1) When a Tor exit relay do a DNS query to a rarely visited domain using its ISP DNS server, and that ISP DNS server resolves that query by contacting ".com" or ".org" DNS server, do you think it's possible that the attacker knows whether this query comes from the Tor network or from a regular ISP's customer ? Do you think there are some benefits in hiding Tor DNS traffic in a larger DNS traffic pool ?

2) Still under the previously stated assumptions, when a Tor exit relay do a DNS query to a rarely visited domain, using, this time, its own resolver, who contacts with its own IP address (publicly known as a Tor IP) ".com" or ".org" DNS server, do you think it's possible that the attacker knows whether this query comes from the Tor network or not ?

----------------------------------------------------------

I think you are more knowledgeable than me on that subject, but I allow myself to insist because it looks like you are in contradiction with this paper page 13 and 14 : https://nymity.ch/tor-dns/tor-dns.pdf .

In particular, one of the author (Philipp Winter) says in this blog post ( https://freedom-to-tinker.com/2016/09/29/the-effect-of-dns-on-tors-anonymity... ) about the paper : "Our results show that while running local DNS resolvers on exit relays has its benefits, it also means that DNS requests are very exposed to network-level adversaries.". It means that both approaches have advantages and disadvantages, possibly depending on the situation, or on the assumptions we make.

On the other hand, you say that a local DNS resolver is always better than using our ISP DNS server, no matter what.

Ralph Seichter m16+tor at monksofcool.net , Sun Oct 8 20:24:52 UTC 2017

...

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.

I don't know what to think about that contradiction.

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

...

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

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

El 08/10/17 a las 09:17, Ralph Seichter escribió:

On 07.10.17 19:39, jpmvtd261@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.

I would also suggest to use DNS-over-TLS, so (exit) relays could be able to encrypt their queries to a privacy-aware DNS resolver, such as those found in: https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers

server: ssl-upstream: yes

forward-zone: name: "." forward-addr: 2001:470:1c:76d::53@853 # dkg - dns.cmrg.net forward-addr: 199.58.81.218@853 # dkg - dns.cmrg.net forward-addr: 2a04:b900:0:100::37@853 # getdnsapi.net forward-addr: 185.49.141.37@853 # getdnsapi.net forward-addr: 2001:913::8@853 # LDN forward-addr: 80.67.188.188@853 # LDN ...

Other more privacy-aware option is to use the Stubby DNS privacy daemon, but it is still to experimental:

https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+Stubby

El 09/10/17 a las 09:32, Ralph Seichter escribió:

On 08.10.2017 23:05, Santiago R.R. wrote:

...

I would also suggest to use DNS-over-TLS, so (exit) relays could be able to encrypt their queries to a privacy-aware DNS resolver [...]

I like SSL for the resulting cost increase in listening to a connection.

AFAIU, some recursive implementations already support TCP fast open (RFC7413) to reduce the cost of opening a connection. They also pipeline to send multiple queries over a single TCP connection.

However, the Unbound documentation states:

ssl-upstream: <yes or no> Enabled (sic) or disable whether the upstream queries use SSL only for transport. Default is no. Useful in tunneling scenarios.

Do you have any data on the percentage of queries that fail with SSL *only* because upstream nameservers don't support SSL? I imagine the majority of servers don't support it (my own authoritative nameservers among them).

No, I don't. And I suppose you're right, the majority of upstream nameservers don't support it. Related RFCs are quite recent, so it's not surprising. My stubby resolver works well, and I don't realize about issues querying external domains.

Also, manually adding forward-zone entries implies trusting specific servers beyond the regular root zone servers, which rubs me the wrong way.

Yes, indeed. I trust the people running the relays I listed.

And there is also DNSSEC, where available.

-- Santiago