Add local DNS forwarder to Windows client

["Tomcsányi, Domonkos"]

Hi Yves,

I'm still thinking you should not integrate your DNS so strong with Wireguard. What is the exact issue of setting the DNS parameter of each tunnel to localhost and running your own resolver/forwarder locally?
A quick google search shows a ton of options for such software. I really don't want this to feel like an advertisment, but e.g. MaraDNS (with Lua plugin(s) to customize things) or Technitium DNS seems to be a good start.
Once you have your DNS resolver set up correctly just use Wireguard to automatically point your machine to the local resolver if a tunnel is up and that's it.

Am I not seeing something obvious here?

Cheers,
Domi

> 2020. nov. 15. dátummal, 19:42 időpontban Yves Goergen <yves.goergen at gmail.com> írta:
> 
> I still cannot see how the suggested measures solve the root problem.
> 
> I, too, think of FritzBox or Speedport or EasyBox when I think of a
> home LAN. These DSL routers are also often used in small offices. So
> for this part, small offices and private home networks use the same
> technology. Larger companies surely have more money to spend. The
> mentioned router models probably make up half of all internet users in
> Germany. Other models (like TP-Link) don't include a DNS server for
> DHCP'd local hosts and are almost unusable for home LANs. If you use a
> router of that kind you have problems before thinking of VPN.
> 
> None of these networks offer a DNS suffix. And if they do (FritzBox),
> it's fixed to ".local". Everywhere. I tried to change it but it's not
> possible, confirmed by AVM support. Now you may want to call LANs
> managed by a FritzBox unprofessional. And to a certain point I can
> follow you. But unprofessional or not, it's the reality that a whole
> lot of people live in. Now and for the foreseeable future. I wouldn't
> want to spend extra work to set up a different custom-made router in
> all of my networks just so that the limited WireGuard capabilities
> solve my problems. Using OpenVPN is a lot easier then.
> 
> This reality includes host names like "pc1" and "pc2" in one LAN and
> "pc3" and "pc4" in the other LAN. If I'm in one of these LANs and want
> to connect to the other, I need name resolution with both routers to
> be able to use names in the LAN I'm currently in and at the same time
> names in the LAN I'm connected to. No single existing DNS server could
> ever do that because the two routers don't know each other.
> 
> I haven't mentioned public names yet. In this simple scenario, both
> routers could resolve internet names, but the local router is
> preferred because it's faster.
> 
> As far as I understand things, I need this specific solution, and it's
> almost impossible to built that without tight integration with a
> WireGuard client:
> 
> * A local DNS proxy on the tunnel client end
> * that registers itself as the new default DNS server for as long as a
> tunnel is active
> * and forwards all DNS queries to *all* of the connected tunnels' DNS
> (if specified) and also the previous system's DNS server
> * and responds with the first positive answer that comes in.
> * This proxy adapts to all active tunnels and
> * stops and unregisters when the last tunnel is closed.
> 
> None of the suggested solutions provide these features. All of them
> assume that I have host names with a distinguishable name suffix (not
> the case, not changeable) and that I can reconfigure DNS proxy
> configuration upon activating and deactivating a tunnel (not
> practical).
> 
> While I understand that WireGuard (the tunnel tech) is intended to be
> simple, I consider this feature necessary on a higher level for normal
> network operation. Make things as simple as possible, but no simpler!
> And in this case, it's just a client GUI that already provides several
> comfort features outside of the core tunnel scope. A DNS proxy would
> well fit in this.
> 
> And yes, this causes more network traffic than necessary in an ideal
> world. But I'm looking for a solution in the existing world, and it's
> only DNS packets, no OS image downloads. Make it correct, and fast; in
> that order.
> 
> -Yves