Hey fellas,
just came across this sub to discuss my torrenting issue.
I am using linux, have a mullvad subscription and use qbittorrent. Because I read something about VPN-killswitches not being 100% reliable, I also bound the network interface from my mullvad-VPN to the qbittorrent-client.
Now something, what is kind of weird. I started a testrun over night with some legal torrents. In the morning I saw, that the downloads where finished and also seeding. The mullvad client said, that it was connected. But when I wanted to make a “torrent-IP-leak-test” online, I realized, that I couldn’t open any website, because the “website couldn’t be found” (firefox btw).
So I tried to ping 8.8.8.8, which worked, so I assume it must be something wrong on a DNS-level. In terminal I also checked if the Mullvad network interface was still connected, and it was. After I made a simple reconnect to the VPN-server via the MV-client, everything was normal again.
My first guess was, that this issue possibly occurs, because my ISP does an automatic reconnect in the middle of the night.
Now I’m wondering if that setup still can be considered safe. Did you experience similar problems? Is it a threat to privacy?
Using Debian if that’s important.
~sp3ctre
+++EDIT+++
Observation 1: The source of the issue must be the automatic reconnect in my router (required from ISP) in the middle of the night. It encountered too, when I chose another reconnect-time. A manual reconnect in the router interface led to the same issue. Interestingly, pulling the plug from the router doesn’t lead to it.
Observation 2: Since I wasn’t able to check my external IP without being able to DNS-resolve these “ip-check-websites”, I decided to go the direct way via IP of the website (found via who.is), which worked for some websites. Turns out, at least my IP-address seems not to leak (its my VPN-IP). These special torrent-IP-check-websites won’t work at all, if the DNS can’t be resolved at the beginning of the process (when putting the test-torrent into the list).
I will try if it makes any difference, when I turn of my alternative-DNS in the router. Will also try some other VPN-servers.
Thought so too. As described above, I tried pinging 8.8.8.8., which worked out. Didn’t try reaching 8.8.8.8. via browser though.
I also have an alternative privacy-friendly DNS set up in my router. Not sure, if that can be a problem. Normally, the DNS of Mullvad is used.
But another question is: Could that be a privacy-risk? Torrenting works without DNS-resolving, doesn’t it?
Well, if the trackers are specified as names (and a quick peek at some random torrent shows that most if not all all), those do have to be resolved to IP adresses and if that DNS query is happening outside the VPN then your ISP as well as the DNS server being queried can see you’re interest in those names (and it wouldn’t be hard to determine with a high probability that you are indeed torrenting something, though WHAT you are torrenting can’t really be determined by you merely accessing certain servers which have torrent trackers active, unless a specific server only tracks a single torrent, which would be pretty weird).
Things like peers aren’t DNS resolved since they already come as IP adresses.
So when it comes to torrenting as far as I know all that the DNS can leak is the information that you ARE torrenting but not specifically WHAT you are torrenting.
It’s more in things were you’re constantly doing DNS queries, such as browsing, that DNS leaking can endanger you privacy: if for example somebody is going to “hotsheepbestialityporn.com”, somebody at their ISP could determine that person’s very specific sexual tastes from seeing the DNS queries for hotsheepbestialityporn.com coming in the open from their connection.
Interesting!
So if I get it right: Only when starting a torrent, some DNS needs to be resolved? And when the torrent is already running not?
So in my case a possible DNS leak occurs somewhere in the middle of the night. Not right from the beginning.
Look, I’m extrapolating from the general rule to the specific case of torrenting.
The general rule is that, because the IP protocol requires numerical addresses to connect to a remote machine, if what you have is a site name you have to translate that name into a numerical address before you can actually establish a connection, and a DNS query is how you translate site names into their numerical IP addresses.
Now, if you look at the contents of a tracker, what you see are not numerical addresses but site names, so those must be translated into numerical addresses before your client can connect to those trackers, hence DNS queries are done to do that translation.
Meanwhile, if you look at the “peers” section in an active torrent in your torrenting program, you see that they all have numerical IP addresses, not site names. This makes sense for two reasons:
Hence my conclusion is that the torrenting protocol itself will only deal with site names (which require DNS queries before network connections can be made to them) for the entrance into the protocol (i.e. start up and connect to trackers) and then deal with everything else using numerical IP addresses only, both because almost no peer will actually have a site name and because it’s low performance and doesn’t make sense to get site names from peers and have to resolve those into numerical addresses when then peer itself already knows its numerical address and can directly provide it. Certainly that’s how I would design it.
Now, since I didn’t actually read the protocol or logged the network connections in a machine torrenting to see what’s going one, I’m not absolutely certain there are now DNS queries at all after the initial resolution of the trackers of a torrent. I am however confident that it is so because that makes sense from a programming point of view.
I understand the basic concept of DNS but I am just a little unsure in which part of the process it takes effect. Thanks for your point of view!
As part of a websites DNS info they have to provide a TTL (time to live). This value can be just about anything but is often in the 30s to 5m range, and serves as an instruction on how long a client should cache the IP address locally before checking for updates.
This is because IP addresses can change, and you don’t want to experience hours of downtime for all clients every time your IP changes.
Every time your client queries your tracker for server updates (every few minutes, give or take, based on tracker preferences) it should follow your system DNS settings, which should involve checking your local cache, then going to the upstream server indicated in your system DNS settings.
If your system is set to a DNS server outside of your local network (e.g., 8.8.8.8) that request should go through your VPN
If your system is set to use a local DNS server (e.g., 192.168.X.X…), typically either done through something like a pi-hole, or if your router sets itself as the DNS server then forwards all requests, this MIGHT create a DNS leak around your VPN.
A good VPN like Mullvad should have an option to force their own DNS settings when enabled to prevent this leak.
Let’s say the torrent started with a working DNS and the issue occured some hours later. Maybe the client wants to check for IP-updates then, but won’t find any, because DNS doesn’t work anymore. It will still keep the IP-adresses resolved at the beginning, right? Because then it would make sense, that I saw some working torrents, even though the issue already appeared.