DNS Isolation

[Escape-source]

I'm having an issue with my setup, which consists of multiple servers with anonymized relays. The problem is that when I use a tool like https://browserleaks.com/dns, it reveals all my specified server names.

I've been trying to fix the issue by experimenting with different combinations of lb_estimator and lb_strategy settings. However, I'm not sure why the random lb_strategy works the way it does, and I'm also unsure why the test results in so many ISPs and locations. Is this the expected behavior?

To replicate the issue, I've found that:

• Any combination of lb_estimator (when set to true) will result in DNS leaks, regardless of the lb_strategy setting.
• Combinations of lb_estimator (when set to false) will result in DNS leaks when lb_strategy is set to random.
• Some combinations will result in a smaller number of leaks (e.g. 2 when "ph2", but it's not consistent).
• The combination of lb_estimator (when set to false) and lb_strategy set to "p1" will work correctly, but it will always choose the same server with the lowest initial latency, which could lead to correlation.

What I'm hoping for is that when lb_estimator is set to false and lb_strategy is set to random or p1, the system will randomly choose a single server from the server names list or from the routes, regardless of its initial latency. This should result in only one ISP and one location showing up in the browserleaks.com/dns test, instead of the locations of all specified servers.

This issue template is making it hard to explain things, due to its redundant structure.
In other notes, there's seriously not much difference between "p1" and "first", yet both exist.

[jedisct1]

I'm having an issue with my setup, which consists of multiple servers with anonymized relays. The problem is that when I use a tool like https://browserleaks.com/dns, it reveals all my specified server names.

The way DNS works, is that in order to resolve a query, your computer sends it to server A. If server A doesn't have the response in its temporary cache, it's going to ask server B (and possibly more) to get the answer.

If the website (in your case browerleak) operates server B, it knows the IP of server A when server A connects to it.

Long story short, websites know what DNS resolvers you are using.

The DNS protocol or client settings can't do anything against that. But this is not a big deal. Resolvers are not meant to be secret.

[Escape-source]

I'm still unclear on how the "p1" strategy avoids revealing all server names, unlike the other options. Regardless, shouldn't it be possible to select a single random server instead of the one with the lowest latency?

DNSCrypt encrypts the DNS queries, but the fact that server names are leaking in some tests is a concern for me. If the whole server list leaks, it could allow for correlation attacks and ultimately lead to deanonymization, regardless of Tor's inherent onion routing, for example.

[welwood08]

The goal of load-balancing strategies is not anonymity, it is load-balancing (hence the name). The strategy is applied on every query with no memory of previous queries, thus any strategy which randomly chooses from more than 1 server will do that. If lb_estimator = true, the meaning of "fastest server" is updated by occasionally sending the query to a different random server. Thus it is to be expected when something like https://browserleaks.com/dns initiates many queries and load-balancing strategy/estimator settings permit, many servers are chosen.

It sounds like you're after an entirely new strategy that behaves like random on the first query and then always uses that server for every query after? If that's correct, the easiest way to achieve it is to make the random selection manually in configuration and just pick 1 server.

Regarding the existence of both p1 and first strategies, first was introduced 6 years ago in 88434fc under the name fastest. p1 was added 2 years later in 34d83f0 as a more general "any of the fastest n servers". Removing the older first strategy would have broken compatibility for no good reason.

[Escape-source]

Thank you for the explanation. I understand the situation better now. While the workaround might be an option, it's far from ideal. The single server setup compromises the anonymity aspect, which is a key concern for me. Using the same server with multiple Tor IPs would greatly undermine Tor's native anonymity and would only increase the possibility of correlation attacks, not prevent them.

My initial idea was for DNSCrypt to load the servers, and then randomly choose one relay from the specified ones, however I now understand that such a feature would be suboptimal and redundant unless some form of DNS Isolation is implemented. For those unaware, this is how Tor achieves its isolation:

• IsolateClientAddr: isolates traffic based on the client's IP address
• IsolateClientProtocol: isolates traffic based on the client's protocol (e.g. HTTP)
• IsolateDestAddr: isolates traffic based on the destination IP address
• IsolateDestPort: isolates traffic based on the destination port number

With this in mind, the title of this discussion would now resemble something like "DNS Isolation". In a nutshell, each destination IP address would get its own DNS server (or relay) from the specified list. Now, I understand that that such a feature might prove difficult to implement, but I strongly advise some fair consideration towards it, as it would prove incredibly effective against correlation.

[lifenjoiner]

IMHO:

1. The test is DNS leak test. DNS leak, means leaking your DNS queries (intention) to unrelated 3rd parties, especially when users are using a proxy/VPN; not the server knows which DNS users use.
2. There must be a DNS to resolve domains. Encrypted DNS overcomes the leakage from plain DNS.
3. The destination servers always have control, no matter which or how many DNS that users use.
4. The key is to make it clear who are the unrelated 3rd parties in different scenarios.
5. That is why Tor browser adopts "proxy DNS when using SOCKS5" is the best practice.

[Escape-source]

When I mention DNS leaks in this context, I'm not referring to the typical leakage of DNS queries to third parties. I'm aware that DNSCrypt encrypts these queries to prevent that. The real issue lies in how DNSCrypt's load-balancing strategies (such as lb_estimator and lb_strategy) can inadvertently reveal multiple server names during a DNS leak test, potentially leading to correlation attacks. With regards to anonymity, it's important to assume that every website is malevolent and will do anything to correlate traffic, even if it isn't promoted as such.

I understand that the destination servers have control over the DNS resolution process, but the goal is to minimize the information that can be gained from those queries. That's why I suggested the concept of DNS Isolation, where each destination IP address (and/or each client IP address) would use a (single) different DNS server or relay from the specified list. This would help decrease the risk of correlation by ensuring that queries for different destinations are handled by different servers, thereby reducing the likelihood of an attacker being able to link them together.

Although Tor Browser handles the "proxy DNS when using SOCKS5" option, I don't necessarily agree that it's the best practice. I prefer DNSCrypt with Anonymized Relays (and occasionally onion forwarding to Tor DNS) over DoHoT for clearnet activity. Browser DNS settings are designed for general use and don't offer the same level of control and most certainly aren't suited for more complex setups such as Tor Isolated Proxies, which I'd much rather use. Using them while already encrypting the DNS queries is slower and redundant.

[lifenjoiner]

What and how "correlation attacks" can be conducted?
If you know exactly what you are doing, that is great! I'm not arguing with or persuading you. Just don't be fooled by FUD. 😂
I think get info decrypted and tracked from the DNS provider is easier than from the Tor network.

BTW, this isolation seems going to break the load-balancing, make it much more complicated or less effective.

[Escape-source]

Back in 2017, a study titled "The Effect of DNS on Tor's Anonymity" explored the vulnerabilities of the Tor network, particularly about DNS correlation attacks. The researchers conducted various experiments that showed how certain (major) adversaries could control a significant portion of DNS requests leaving the Tor network. For instance, they found that Google handled about 33% of all DNS requests, with peaks reaching over 40%.

We further believe that relays in regions other than Western Europe or North America are likely to witness significantly different exposure of DNS queries because many websites outsource their DNS setup to providers such as Cloudflare whose points of presence are centered around Western Europe and North America. We conclude that adversaries that are unable to observe a Tor user’s TCP connection still have many opportunities to see a TCP connection’s corresponding DNS request. Such adversaries include (i) popular open DNS resolvers such as Google and OpenDNS, (ii) DNS root servers, and (iii) network adversaries located on the path to the previous two entities

The study then introduced a new type of attack called DefecTor attacks, which combine DNS traffic analysis with existing website fingerprinting techniques. After analyzing both DNS requests and the corresponding TCP traffic, attackers can completely deanonymize a user.

The study highlights a few other vulnerabilities, which I doubt to have even been solved due to the exit node's limitations. For that aspect alone, Tor is highly vulnerable and not to be used against major threat models, which brings me to appreciate the beginning of the study even more:

We have yet to learn how to build anonymity networks that resist global adversaries, provide low latency, and scale well.

Reflecting on my previous idea of DNS Isolation, I realize that it doesn't solve anything. However, I consider the load-balancing strategies used by DNSCrypt to still be a major issue, as they only serve to degrade anonymity when a larger number of servers are involved.

Thank you @jedisct1, @welwood08 and @lifenjoiner for taking part in this discussion.