I see nameserver 10.139.1.1 and nameserver 10.139.1.2 in resolv.conf, but what happens to DNS when using VPN or Whonix? Please explain the mechanism within Qubes.
4 Likes
Perhaps @adrelanos should know the answer.
1 Like
The answer to this question requires a full explanation of how the DNS protocol actually works.
In the DNS world, you have two types of records:
- Authoritative
- “I own this DNS record, so everyone asks me for access to the records, and I can change it whenever I want. I also never have to ask anyone else, because I own it.”
- Non-authoritative
- “Well, I don’t own this DNS record, so I always have to ask someone else up the chain. If they don’t know, they’ll ask further up the chain, until we all get an answer”
DNS blockers like Pi-Hole or bind9 work by giving authoritative answers for any domain names on their blacklist. They basically say “Guess what? It turns out the domain name you asked for is actually…YOU! Don’t bother asking anyone else, because I own the record.”
This would never work if it was humans having this conversation, but to computers, they don’t question it at all 
Anyway, when you use a VPN to access a website, you aren’t actually the one submitting the web request. The VPN server is. So you can either use your own to figure out the IP address yourself, and then send the request using the IP address you determined on your own, either by having the DNS request spit out from your own computer, or the VPN server (most people would make the VPN server spit it out for them), or you can ask the VPN server to do it for you, trusting whatever DNS infrastructure it has.
This applies for both commercial VPN providers, and self-done VPNs like WireGuard. VPNs are basically just a relay, an encrypted proxy, a “you tell me, and I’ll tell him” guy, etc.
If you put DNS servers in between you and the VPN client, like, for example, on Qubes OS if you have a sys-vpn, then the standard DNS protocol will apply, with the internal DNS servers asking up the chain whether those servers know the IP address of a domain name. The difference is that the chain now goes through the VPN (and onwards past the VPN server, in some cases).
But if you run the VPN client in the same qube as the one initiating the request, then it should go straight through the VPN server, bypassing the chain.
Tor is a little different. Tor doesn’t actually have DNS per se. When trying to access the clearnet through Tor, the DNS server used is the one specified by the exit node.
For hidden onion services, Tor has a distributed hash table, which all of the nodes know half of. The other half is the onion address. When combined together, they become meaningful data, that, in a nutshell (I’m paraphrasing heavily), identifies where the introduction points are, and how to find the server and set up a rendezvous point to serve the hidden service.
In other words, “You talk to your guys, and I’ll talk to my guys, and we’ll get our guys to meet in the park by the benches. There will be a guy with a red hat sitting there. My guys will leave the website with this guy in a bag. Wait until we leave to go and retrieve it from the guy with the red hat.” (Again, paraphrasing, but you can think of Tor working pretty much like this).
If you want to get into all the nerdy details (which I definitely recommend 
), there are much more detailed explanations on the WireGuard and Tor Project websites.
Hope this helps 
2 Likes
3 Likes
Thank you, it was very clear and easy to understand.
1 Like