Add local DNS forwarder to Windows client

Yves Goergen yves.goergen at
Sun Nov 15 19:42:39 CET 2020

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

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.


More information about the WireGuard mailing list