Development discussion of WireGuard
 help / color / mirror / Atom feed
* Add local DNS forwarder to Windows client
@ 2020-11-03 10:31 Yves Goergen
  2020-11-10  8:14 ` Tomcsanyi, Domonkos
  0 siblings, 1 reply; 13+ messages in thread
From: Yves Goergen @ 2020-11-03 10:31 UTC (permalink / raw)
  To: wireguard

Hello,

I've already used WireGuard to connect to private networks and it's
quite easy once you figure out how to set it up. (Most tutorials are
outdated and haven't been updated, new ones haven't been written.) One
thing that's really missing however is DNS support. All I can do now
is connect to IP addresses. Names are not resolvable on the other
side. If I add the "DNS" directive to my client configuration, it
replaces the local DNS resolver and *all* lookups go to that server
instead. This isn't working either because I'm on two local networks
and each has its own local DNS server that can only resolve its own
local names (and forward the rest to the internet).

Specifying both networks' DNS servers also fails because when
resolving a name, one of them is chosen at random (and the other one
isn't regarded) and then you won't be able to resolve some of the
names some of the time. This is also very frustrating. And it wouldn't
scale to multiple active tunnels.

The solution I've read about is to set up a local DNS forwarder that
can be configured so that it uses multiple servers and queries each of
them and returns only a positive response. This way it could query
both local LAN DNS servers and for local names, only one of them would
resolve the name. This is a bit complicated to do if you're not
permanently connected to a VPN, or if you move from one local DHCP
network to another (like with a laptop). And it requires additional
software, setup and configuration, and probably intensive maintenance
and care. All of this makes WireGuard a pretty ugly alternative to
OpenVPN where all of this already works. Despite all the disadvantages
of OpenVPN.

I'm asking if it's possible to integrate such a local DNS forwarder
into the Windows client application. I imagine it would start up
automatically once the first tunnel is activated. And it would replace
the local system's DNS server setting for as long as it's active (like
the tunnel-configured DNS server already does). And it would query the
original locally configured DNS server and all configured DNS servers
for the active tunnels. It would then be able to resolve local names
and tunnel-remote names without any additional work on the user end.
The user wouldn't have to perform many complex tasks upon activating
or deactivating a tunnel. This would make WireGuard be as simple and
productive as I believe it was intended to be (but isn't yet).

This probably stops working as soon as other VPN software is used in
parallel, but the current "DNS" setting has the same limitation, it's
better than nothing and most of the time, you only run a single VPN
software.

Please let me know what you think of it.

-Yves

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-03 10:31 Add local DNS forwarder to Windows client Yves Goergen
@ 2020-11-10  8:14 ` Tomcsanyi, Domonkos
  2020-11-10  8:44   ` Der PCFreak
       [not found]   ` <CADJb3qTGhm8a=aAA8_6ZgEHHFyBZyOch_GRBkC1p4yym28fN-Q@mail.gmail.com>
  0 siblings, 2 replies; 13+ messages in thread
From: Tomcsanyi, Domonkos @ 2020-11-10  8:14 UTC (permalink / raw)
  To: Yves Goergen; +Cc: wireguard

Hello Yves,

I am by no means a person with authority to make such a decision, but your usecase seems to be so specific I would not imagine it would make sense to blow up the size and complexity of the Windows wg with a local DNS forwarder.
I think it is way better if people just install a local DNS resolver/forwarder on their own. There a ton of choices available, from simply python scripts to large scale servers. You could easily configure any of these to distinguish which DNS server to ask based on the TLD portion of your local domain or whatever other distinguisher you have.
Then the only thing you need to do is tell your system (either via wg or by other means) to use the local resolver and the case is solved :).
Also I am pretty sure one of the main philosophies behind wg is to be the same as much as possible on all platforms. Adding a DNS resolver would again mean a lot of complications when compared to e.g. the Linux version, since most Linux distributions already feature some kind of a local resolver by default.

Cheers,
Domi


> 09.11.2020 dátummal, 23:46 időpontban Yves Goergen <yves.goergen@gmail.com> írta:
> 
> Hello,
> 
> I've already used WireGuard to connect to private networks and it's
> quite easy once you figure out how to set it up. (Most tutorials are
> outdated and haven't been updated, new ones haven't been written.) One
> thing that's really missing however is DNS support. All I can do now
> is connect to IP addresses. Names are not resolvable on the other
> side. If I add the "DNS" directive to my client configuration, it
> replaces the local DNS resolver and *all* lookups go to that server
> instead. This isn't working either because I'm on two local networks
> and each has its own local DNS server that can only resolve its own
> local names (and forward the rest to the internet).
> 
> Specifying both networks' DNS servers also fails because when
> resolving a name, one of them is chosen at random (and the other one
> isn't regarded) and then you won't be able to resolve some of the
> names some of the time. This is also very frustrating. And it wouldn't
> scale to multiple active tunnels.
> 
> The solution I've read about is to set up a local DNS forwarder that
> can be configured so that it uses multiple servers and queries each of
> them and returns only a positive response. This way it could query
> both local LAN DNS servers and for local names, only one of them would
> resolve the name. This is a bit complicated to do if you're not
> permanently connected to a VPN, or if you move from one local DHCP
> network to another (like with a laptop). And it requires additional
> software, setup and configuration, and probably intensive maintenance
> and care. All of this makes WireGuard a pretty ugly alternative to
> OpenVPN where all of this already works. Despite all the disadvantages
> of OpenVPN.
> 
> I'm asking if it's possible to integrate such a local DNS forwarder
> into the Windows client application. I imagine it would start up
> automatically once the first tunnel is activated. And it would replace
> the local system's DNS server setting for as long as it's active (like
> the tunnel-configured DNS server already does). And it would query the
> original locally configured DNS server and all configured DNS servers
> for the active tunnels. It would then be able to resolve local names
> and tunnel-remote names without any additional work on the user end.
> The user wouldn't have to perform many complex tasks upon activating
> or deactivating a tunnel. This would make WireGuard be as simple and
> productive as I believe it was intended to be (but isn't yet).
> 
> This probably stops working as soon as other VPN software is used in
> parallel, but the current "DNS" setting has the same limitation, it's
> better than nothing and most of the time, you only run a single VPN
> software.
> 
> Please let me know what you think of it.
> 
> -Yves

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-10  8:14 ` Tomcsanyi, Domonkos
@ 2020-11-10  8:44   ` Der PCFreak
  2020-11-10 15:38     ` Yves Goergen
       [not found]   ` <CADJb3qTGhm8a=aAA8_6ZgEHHFyBZyOch_GRBkC1p4yym28fN-Q@mail.gmail.com>
  1 sibling, 1 reply; 13+ messages in thread
From: Der PCFreak @ 2020-11-10  8:44 UTC (permalink / raw)
  To: wireguard

Hi,

concerning local DNS forwarder.

I am in an environment where I need to resolve public DNS names to local 
IPs for specific hosts and additionally public DNS for the rest.
In Windows XP it was possible to just stop the DNS cache service and set 
2 DNS servers and everything worked.
Newer versions of Windows starting with Windows 7 do only connect to the 
second DNS if connecting (not querying) the first fails.
So if your first DNS is up but has no reply for your query, Windows will 
just add that fqdn to the negative cache and no longer
query the DNS for a specific time or until you delete the cache with 
ipconfig /flushdns.

All of the above can be fixed using a local DNS forwarder.

I use DeadWood on my machine for years now. 
https://maradns.samiam.org/deadwood/doc/FAQ.html

I just point my DNS to 127.0.0.1 (which is the deadwood service) and 
configure Deadwood a little bit. It basically let's me
exactly specify which hosts to resolve how and can have something 
similiar to a HOSTS entry, too.

As Domi wrote I would encourage you to tryout a local DNS resolver, too.

Regards

Peter

On 10.11.2020 09:14, Tomcsanyi, Domonkos wrote:
> Hello Yves,
>
> I am by no means a person with authority to make such a decision, but your usecase seems to be so specific I would not imagine it would make sense to blow up the size and complexity of the Windows wg with a local DNS forwarder.
> I think it is way better if people just install a local DNS resolver/forwarder on their own. There a ton of choices available, from simply python scripts to large scale servers. You could easily configure any of these to distinguish which DNS server to ask based on the TLD portion of your local domain or whatever other distinguisher you have.
> Then the only thing you need to do is tell your system (either via wg or by other means) to use the local resolver and the case is solved :).
> Also I am pretty sure one of the main philosophies behind wg is to be the same as much as possible on all platforms. Adding a DNS resolver would again mean a lot of complications when compared to e.g. the Linux version, since most Linux distributions already feature some kind of a local resolver by default.
>
> Cheers,
> Domi
>
>
>> 09.11.2020 dátummal, 23:46 időpontban Yves Goergen <yves.goergen@gmail.com> írta:
>>
>> Hello,
>>
>> I've already used WireGuard to connect to private networks and it's
>> quite easy once you figure out how to set it up. (Most tutorials are
>> outdated and haven't been updated, new ones haven't been written.) One
>> thing that's really missing however is DNS support. All I can do now
>> is connect to IP addresses. Names are not resolvable on the other
>> side. If I add the "DNS" directive to my client configuration, it
>> replaces the local DNS resolver and *all* lookups go to that server
>> instead. This isn't working either because I'm on two local networks
>> and each has its own local DNS server that can only resolve its own
>> local names (and forward the rest to the internet).
>>
>> Specifying both networks' DNS servers also fails because when
>> resolving a name, one of them is chosen at random (and the other one
>> isn't regarded) and then you won't be able to resolve some of the
>> names some of the time. This is also very frustrating. And it wouldn't
>> scale to multiple active tunnels.
>>
>> The solution I've read about is to set up a local DNS forwarder that
>> can be configured so that it uses multiple servers and queries each of
>> them and returns only a positive response. This way it could query
>> both local LAN DNS servers and for local names, only one of them would
>> resolve the name. This is a bit complicated to do if you're not
>> permanently connected to a VPN, or if you move from one local DHCP
>> network to another (like with a laptop). And it requires additional
>> software, setup and configuration, and probably intensive maintenance
>> and care. All of this makes WireGuard a pretty ugly alternative to
>> OpenVPN where all of this already works. Despite all the disadvantages
>> of OpenVPN.
>>
>> I'm asking if it's possible to integrate such a local DNS forwarder
>> into the Windows client application. I imagine it would start up
>> automatically once the first tunnel is activated. And it would replace
>> the local system's DNS server setting for as long as it's active (like
>> the tunnel-configured DNS server already does). And it would query the
>> original locally configured DNS server and all configured DNS servers
>> for the active tunnels. It would then be able to resolve local names
>> and tunnel-remote names without any additional work on the user end.
>> The user wouldn't have to perform many complex tasks upon activating
>> or deactivating a tunnel. This would make WireGuard be as simple and
>> productive as I believe it was intended to be (but isn't yet).
>>
>> This probably stops working as soon as other VPN software is used in
>> parallel, but the current "DNS" setting has the same limitation, it's
>> better than nothing and most of the time, you only run a single VPN
>> software.
>>
>> Please let me know what you think of it.
>>
>> -Yves

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Fwd: Add local DNS forwarder to Windows client
       [not found]   ` <CADJb3qTGhm8a=aAA8_6ZgEHHFyBZyOch_GRBkC1p4yym28fN-Q@mail.gmail.com>
@ 2020-11-10 10:47     ` Yves Goergen
  2020-11-10 22:24     ` Tomcsanyi, Domonkos
  1 sibling, 0 replies; 13+ messages in thread
From: Yves Goergen @ 2020-11-10 10:47 UTC (permalink / raw)
  To: wireguard

Oops, Google Mail cannot reply to all including the mailing list? Why
can't we have a normal web forum here?


---------- Forwarded message ---------
Von: Yves Goergen <yves.goergen@gmail.com>
Date: Di., 10. Nov. 2020 um 11:45 Uhr
Subject: Re: Add local DNS forwarder to Windows client
To: Tomcsanyi, Domonkos <domi@tomcsanyi.net>


Hello Domi,

It's not quite that simple. I'll have to find a DNS proxy that does
what is required to make this scenario work. There is no
hostname/domain pattern because all hosts on a LAN have no dot in
them, just names alone. And nobody knows what names are valid in a
certain network, so all have to be tried. Only one of them should
resolve for a local name. All of them might resolve for global names.
If all are equal, that's fine. If not, we have a problem anyway.

But which DNS servers to query depends on what VPN connections are
active. Only the WG client knows that because it's managing the
connections/tunnels. A separate DNS proxy would need to query the WG
state and also know what DNS servers can be found in each tunnel. This
would best be configured in the tunnel configuration. Anything else
makes it complicated and error-prone.

I really can't imagine why DNS resolution should be very specific.
Nobody uses DNS in local networks? Do you access all your LAN machines
by their IP address? If not, why would you want to do it over a VPN?
This is basically what you're suggesting.

Imagine you have tunnels to two separate local networks active. How
would you set things up, on Windows or Linux, to resolve local host
names from both remote LANs as well as the internet in your default
browser? Internet names should prefer the local DNS resolver, not go
through any potentially slow VPN.

-Yves

Am Di., 10. Nov. 2020 um 09:14 Uhr schrieb Tomcsanyi, Domonkos
<domi@tomcsanyi.net>:
>
> Hello Yves,
>
> I am by no means a person with authority to make such a decision, but your usecase seems to be so specific I would not imagine it would make sense to blow up the size and complexity of the Windows wg with a local DNS forwarder.
> I think it is way better if people just install a local DNS resolver/forwarder on their own. There a ton of choices available, from simply python scripts to large scale servers. You could easily configure any of these to distinguish which DNS server to ask based on the TLD portion of your local domain or whatever other distinguisher you have.
> Then the only thing you need to do is tell your system (either via wg or by other means) to use the local resolver and the case is solved :).
> Also I am pretty sure one of the main philosophies behind wg is to be the same as much as possible on all platforms. Adding a DNS resolver would again mean a lot of complications when compared to e.g. the Linux version, since most Linux distributions already feature some kind of a local resolver by default.
>
> Cheers,
> Domi
>
>
> > 09.11.2020 dátummal, 23:46 időpontban Yves Goergen <yves.goergen@gmail.com> írta:
> >
> > Hello,
> >
> > I've already used WireGuard to connect to private networks and it's
> > quite easy once you figure out how to set it up. (Most tutorials are
> > outdated and haven't been updated, new ones haven't been written.) One
> > thing that's really missing however is DNS support. All I can do now
> > is connect to IP addresses. Names are not resolvable on the other
> > side. If I add the "DNS" directive to my client configuration, it
> > replaces the local DNS resolver and *all* lookups go to that server
> > instead. This isn't working either because I'm on two local networks
> > and each has its own local DNS server that can only resolve its own
> > local names (and forward the rest to the internet).
> >
> > Specifying both networks' DNS servers also fails because when
> > resolving a name, one of them is chosen at random (and the other one
> > isn't regarded) and then you won't be able to resolve some of the
> > names some of the time. This is also very frustrating. And it wouldn't
> > scale to multiple active tunnels.
> >
> > The solution I've read about is to set up a local DNS forwarder that
> > can be configured so that it uses multiple servers and queries each of
> > them and returns only a positive response. This way it could query
> > both local LAN DNS servers and for local names, only one of them would
> > resolve the name. This is a bit complicated to do if you're not
> > permanently connected to a VPN, or if you move from one local DHCP
> > network to another (like with a laptop). And it requires additional
> > software, setup and configuration, and probably intensive maintenance
> > and care. All of this makes WireGuard a pretty ugly alternative to
> > OpenVPN where all of this already works. Despite all the disadvantages
> > of OpenVPN.
> >
> > I'm asking if it's possible to integrate such a local DNS forwarder
> > into the Windows client application. I imagine it would start up
> > automatically once the first tunnel is activated. And it would replace
> > the local system's DNS server setting for as long as it's active (like
> > the tunnel-configured DNS server already does). And it would query the
> > original locally configured DNS server and all configured DNS servers
> > for the active tunnels. It would then be able to resolve local names
> > and tunnel-remote names without any additional work on the user end.
> > The user wouldn't have to perform many complex tasks upon activating
> > or deactivating a tunnel. This would make WireGuard be as simple and
> > productive as I believe it was intended to be (but isn't yet).
> >
> > This probably stops working as soon as other VPN software is used in
> > parallel, but the current "DNS" setting has the same limitation, it's
> > better than nothing and most of the time, you only run a single VPN
> > software.
> >
> > Please let me know what you think of it.
> >
> > -Yves

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-10  8:44   ` Der PCFreak
@ 2020-11-10 15:38     ` Yves Goergen
  2020-11-10 16:04       ` Matthias Urlichs
                         ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: Yves Goergen @ 2020-11-10 15:38 UTC (permalink / raw)
  To: Der PCFreak; +Cc: wireguard

I just read through the 'upstream_servers' section of the Deadwood DNS
resolver. And it doesn't seem to do what I need. I'll have to specify
a fixed DNS server for a fixed name suffix. This is not possible on
LANs where there are no suffixes, as I already described. Setting
multiple upstreams for the same '.' suffix again results in a lookup
in one of them, not both.

This is not a solution to my problem. And I still refuse to believe
that my problem is exotic. Every home LAN has this.

Am Di., 10. Nov. 2020 um 14:06 Uhr schrieb Der PCFreak
<mailinglists@pcfreak.de>:
>
> Hi,
>
> concerning local DNS forwarder.
>
> I am in an environment where I need to resolve public DNS names to local
> IPs for specific hosts and additionally public DNS for the rest.
> In Windows XP it was possible to just stop the DNS cache service and set
> 2 DNS servers and everything worked.
> Newer versions of Windows starting with Windows 7 do only connect to the
> second DNS if connecting (not querying) the first fails.
> So if your first DNS is up but has no reply for your query, Windows will
> just add that fqdn to the negative cache and no longer
> query the DNS for a specific time or until you delete the cache with
> ipconfig /flushdns.
>
> All of the above can be fixed using a local DNS forwarder.
>
> I use DeadWood on my machine for years now.
> https://maradns.samiam.org/deadwood/doc/FAQ.html
>
> I just point my DNS to 127.0.0.1 (which is the deadwood service) and
> configure Deadwood a little bit. It basically let's me
> exactly specify which hosts to resolve how and can have something
> similiar to a HOSTS entry, too.
>
> As Domi wrote I would encourage you to tryout a local DNS resolver, too.
>
> Regards
>
> Peter
>
> On 10.11.2020 09:14, Tomcsanyi, Domonkos wrote:
> > Hello Yves,
> >
> > I am by no means a person with authority to make such a decision, but your usecase seems to be so specific I would not imagine it would make sense to blow up the size and complexity of the Windows wg with a local DNS forwarder.
> > I think it is way better if people just install a local DNS resolver/forwarder on their own. There a ton of choices available, from simply python scripts to large scale servers. You could easily configure any of these to distinguish which DNS server to ask based on the TLD portion of your local domain or whatever other distinguisher you have.
> > Then the only thing you need to do is tell your system (either via wg or by other means) to use the local resolver and the case is solved :).
> > Also I am pretty sure one of the main philosophies behind wg is to be the same as much as possible on all platforms. Adding a DNS resolver would again mean a lot of complications when compared to e.g. the Linux version, since most Linux distributions already feature some kind of a local resolver by default.
> >
> > Cheers,
> > Domi
> >
> >
> >> 09.11.2020 dátummal, 23:46 időpontban Yves Goergen <yves.goergen@gmail.com> írta:
> >>
> >> Hello,
> >>
> >> I've already used WireGuard to connect to private networks and it's
> >> quite easy once you figure out how to set it up. (Most tutorials are
> >> outdated and haven't been updated, new ones haven't been written.) One
> >> thing that's really missing however is DNS support. All I can do now
> >> is connect to IP addresses. Names are not resolvable on the other
> >> side. If I add the "DNS" directive to my client configuration, it
> >> replaces the local DNS resolver and *all* lookups go to that server
> >> instead. This isn't working either because I'm on two local networks
> >> and each has its own local DNS server that can only resolve its own
> >> local names (and forward the rest to the internet).
> >>
> >> Specifying both networks' DNS servers also fails because when
> >> resolving a name, one of them is chosen at random (and the other one
> >> isn't regarded) and then you won't be able to resolve some of the
> >> names some of the time. This is also very frustrating. And it wouldn't
> >> scale to multiple active tunnels.
> >>
> >> The solution I've read about is to set up a local DNS forwarder that
> >> can be configured so that it uses multiple servers and queries each of
> >> them and returns only a positive response. This way it could query
> >> both local LAN DNS servers and for local names, only one of them would
> >> resolve the name. This is a bit complicated to do if you're not
> >> permanently connected to a VPN, or if you move from one local DHCP
> >> network to another (like with a laptop). And it requires additional
> >> software, setup and configuration, and probably intensive maintenance
> >> and care. All of this makes WireGuard a pretty ugly alternative to
> >> OpenVPN where all of this already works. Despite all the disadvantages
> >> of OpenVPN.
> >>
> >> I'm asking if it's possible to integrate such a local DNS forwarder
> >> into the Windows client application. I imagine it would start up
> >> automatically once the first tunnel is activated. And it would replace
> >> the local system's DNS server setting for as long as it's active (like
> >> the tunnel-configured DNS server already does). And it would query the
> >> original locally configured DNS server and all configured DNS servers
> >> for the active tunnels. It would then be able to resolve local names
> >> and tunnel-remote names without any additional work on the user end.
> >> The user wouldn't have to perform many complex tasks upon activating
> >> or deactivating a tunnel. This would make WireGuard be as simple and
> >> productive as I believe it was intended to be (but isn't yet).
> >>
> >> This probably stops working as soon as other VPN software is used in
> >> parallel, but the current "DNS" setting has the same limitation, it's
> >> better than nothing and most of the time, you only run a single VPN
> >> software.
> >>
> >> Please let me know what you think of it.
> >>
> >> -Yves

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-10 15:38     ` Yves Goergen
@ 2020-11-10 16:04       ` Matthias Urlichs
  2020-11-10 18:08       ` Lech Perczak
  2020-11-11  7:36       ` Der PCFreak
  2 siblings, 0 replies; 13+ messages in thread
From: Matthias Urlichs @ 2020-11-10 16:04 UTC (permalink / raw)
  To: wireguard


[-- Attachment #1.1.1: Type: text/plain, Size: 854 bytes --]

On 10.11.20 16:38, Yves Goergen wrote:
> This is not a solution to my problem. And I still refuse to believe
> that my problem is exotic. Every home LAN has this.

Which "every" home LAN has two resolvers, none of them being 
authoritative? Mine certainly doesn't.

 >  So if your first DNS is up but has no reply for your query,

Define "no reply". There's more than one kind of non-reply here. If the 
no-reply you're talking about is actually a "doesn't exist" reply, then 
Windows is perfectly correct not to ask anybody else for a second 
opinion. The net is flooded with stupid (if not to say "terminally 
brain-dead") DNS queries as it is, ask any DNS provider; no need to add 
even more of these.

Please elucidate why you can't use a fixed prefix like ".home" or ".lan" 
for these. Cf. RFC 2606.

-- 
-- Matthias Urlichs


[-- Attachment #1.1.2: OpenPGP_0x72CF8E5E25B4C293_and_old_rev.asc --]
[-- Type: application/pgp-keys, Size: 48415 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-10 15:38     ` Yves Goergen
  2020-11-10 16:04       ` Matthias Urlichs
@ 2020-11-10 18:08       ` Lech Perczak
  2020-11-15 18:42         ` Yves Goergen
  2020-11-11  7:36       ` Der PCFreak
  2 siblings, 1 reply; 13+ messages in thread
From: Lech Perczak @ 2020-11-10 18:08 UTC (permalink / raw)
  To: wireguard

Hi,

Thing is, most home LANs have dedicated gateways doing this. Running a 
Windows PC as a home router  is exotic.
It might be easier for you to pick up a cheap router which runs OpenWrt 
and set up it as gateway running Wireguard and local DNS resolver 
(dnsmasq) too.
And even there, local DNS resolution is not done by Wireguard, but by 
dnsmasq, and DNS forwarding is simply not in scope of any VPN 
implementation.

Kind regards,
Lech

W dniu 2020-11-10 o 16:38, Yves Goergen pisze:
> I just read through the 'upstream_servers' section of the Deadwood DNS
> resolver. And it doesn't seem to do what I need. I'll have to specify
> a fixed DNS server for a fixed name suffix. This is not possible on
> LANs where there are no suffixes, as I already described. Setting
> multiple upstreams for the same '.' suffix again results in a lookup
> in one of them, not both.
>
> This is not a solution to my problem. And I still refuse to believe
> that my problem is exotic. Every home LAN has this.
>
> Am Di., 10. Nov. 2020 um 14:06 Uhr schrieb Der PCFreak
> <mailinglists@pcfreak.de>:
>> Hi,
>>
>> concerning local DNS forwarder.
>>
>> I am in an environment where I need to resolve public DNS names to local
>> IPs for specific hosts and additionally public DNS for the rest.
>> In Windows XP it was possible to just stop the DNS cache service and set
>> 2 DNS servers and everything worked.
>> Newer versions of Windows starting with Windows 7 do only connect to the
>> second DNS if connecting (not querying) the first fails.
>> So if your first DNS is up but has no reply for your query, Windows will
>> just add that fqdn to the negative cache and no longer
>> query the DNS for a specific time or until you delete the cache with
>> ipconfig /flushdns.
>>
>> All of the above can be fixed using a local DNS forwarder.
>>
>> I use DeadWood on my machine for years now.
>> https://maradns.samiam.org/deadwood/doc/FAQ.html
>>
>> I just point my DNS to 127.0.0.1 (which is the deadwood service) and
>> configure Deadwood a little bit. It basically let's me
>> exactly specify which hosts to resolve how and can have something
>> similiar to a HOSTS entry, too.
>>
>> As Domi wrote I would encourage you to tryout a local DNS resolver, too.
>>
>> Regards
>>
>> Peter
>>
>> On 10.11.2020 09:14, Tomcsanyi, Domonkos wrote:
>>> Hello Yves,
>>>
>>> I am by no means a person with authority to make such a decision, but your usecase seems to be so specific I would not imagine it would make sense to blow up the size and complexity of the Windows wg with a local DNS forwarder.
>>> I think it is way better if people just install a local DNS resolver/forwarder on their own. There a ton of choices available, from simply python scripts to large scale servers. You could easily configure any of these to distinguish which DNS server to ask based on the TLD portion of your local domain or whatever other distinguisher you have.
>>> Then the only thing you need to do is tell your system (either via wg or by other means) to use the local resolver and the case is solved :).
>>> Also I am pretty sure one of the main philosophies behind wg is to be the same as much as possible on all platforms. Adding a DNS resolver would again mean a lot of complications when compared to e.g. the Linux version, since most Linux distributions already feature some kind of a local resolver by default.
>>>
>>> Cheers,
>>> Domi
>>>
>>>
>>>> 09.11.2020 dátummal, 23:46 időpontban Yves Goergen <yves.goergen@gmail.com> írta:
>>>>
>>>> Hello,
>>>>
>>>> I've already used WireGuard to connect to private networks and it's
>>>> quite easy once you figure out how to set it up. (Most tutorials are
>>>> outdated and haven't been updated, new ones haven't been written.) One
>>>> thing that's really missing however is DNS support. All I can do now
>>>> is connect to IP addresses. Names are not resolvable on the other
>>>> side. If I add the "DNS" directive to my client configuration, it
>>>> replaces the local DNS resolver and *all* lookups go to that server
>>>> instead. This isn't working either because I'm on two local networks
>>>> and each has its own local DNS server that can only resolve its own
>>>> local names (and forward the rest to the internet).
>>>>
>>>> Specifying both networks' DNS servers also fails because when
>>>> resolving a name, one of them is chosen at random (and the other one
>>>> isn't regarded) and then you won't be able to resolve some of the
>>>> names some of the time. This is also very frustrating. And it wouldn't
>>>> scale to multiple active tunnels.
>>>>
>>>> The solution I've read about is to set up a local DNS forwarder that
>>>> can be configured so that it uses multiple servers and queries each of
>>>> them and returns only a positive response. This way it could query
>>>> both local LAN DNS servers and for local names, only one of them would
>>>> resolve the name. This is a bit complicated to do if you're not
>>>> permanently connected to a VPN, or if you move from one local DHCP
>>>> network to another (like with a laptop). And it requires additional
>>>> software, setup and configuration, and probably intensive maintenance
>>>> and care. All of this makes WireGuard a pretty ugly alternative to
>>>> OpenVPN where all of this already works. Despite all the disadvantages
>>>> of OpenVPN.
>>>>
>>>> I'm asking if it's possible to integrate such a local DNS forwarder
>>>> into the Windows client application. I imagine it would start up
>>>> automatically once the first tunnel is activated. And it would replace
>>>> the local system's DNS server setting for as long as it's active (like
>>>> the tunnel-configured DNS server already does). And it would query the
>>>> original locally configured DNS server and all configured DNS servers
>>>> for the active tunnels. It would then be able to resolve local names
>>>> and tunnel-remote names without any additional work on the user end.
>>>> The user wouldn't have to perform many complex tasks upon activating
>>>> or deactivating a tunnel. This would make WireGuard be as simple and
>>>> productive as I believe it was intended to be (but isn't yet).
>>>>
>>>> This probably stops working as soon as other VPN software is used in
>>>> parallel, but the current "DNS" setting has the same limitation, it's
>>>> better than nothing and most of the time, you only run a single VPN
>>>> software.
>>>>
>>>> Please let me know what you think of it.
>>>>
>>>> -Yves


-- 
Pozdrawiam,
Lech Perczak
lech.perczak@gmail.com
Mobile: +48 694 309 185


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
       [not found]   ` <CADJb3qTGhm8a=aAA8_6ZgEHHFyBZyOch_GRBkC1p4yym28fN-Q@mail.gmail.com>
  2020-11-10 10:47     ` Fwd: " Yves Goergen
@ 2020-11-10 22:24     ` Tomcsanyi, Domonkos
  1 sibling, 0 replies; 13+ messages in thread
From: Tomcsanyi, Domonkos @ 2020-11-10 22:24 UTC (permalink / raw)
  To: Yves Goergen; +Cc: wireguard

Hello Yves,

Thanks for your reply. Let me answer each point inline:


> It's not quite that simple. I'll have to find a DNS proxy that does
> what is required to make this scenario work. There is no
> hostname/domain pattern because all hosts on a LAN have no dot in
> them, just names alone. And nobody knows what names are valid in a
> certain network, so all have to be tried.

Sorry to be the critical guy here, but this is not really a well built network. It introduces unnecessary traffic by running queries everywhere and also using hostnames without a tld. However, this is just a sidenote, so again apologies.

> Only one of them should
> resolve for a local name. All of them might resolve for global names.
> If all are equal, that's fine. If not, we have a problem anyway.
> 
> But which DNS servers to query depends on what VPN connections are
> active. Only the WG client knows that because it's managing the
> connections/tunnels. A separate DNS proxy would need to query the WG
> state and also know what DNS servers can be found in each tunnel. This
> would best be configured in the tunnel configuration. Anything else
> makes it complicated and error-prone.

Okay, I could understand this fully. Hence I am proposing using a DNS server setting per tunnel. You could point to multiple localhost addresses different tunnels (e.g. Tunnel1 DNS 127.0.0.1, Tunnel2 DNS 127.0.0.2) and configure your forwarder accordingly.

> I really can't imagine why DNS resolution should be very specific.
> Nobody uses DNS in local networks?

We are, certainly. However we use it the way it was designed, with TLDs like .local or similar making it less like your setup which just feels like a blown up NetBIOS.

> Do you access all your LAN machines
> by their IP address? If not, why would you want to do it over a VPN?
> This is basically what you're suggesting.

I must mention that besides regular DNS there are a ton of ways to deal with this both on Linux and Windows. Examples include adding hosts with static IPs to your hosts file, or if you just want to SSH to them using a custom SSH client config with Host/Alias settings could do the job as well. Naturally these are inferior to a well set up DNS server, however they are robust and doing their job fine in many scenarios.

> Imagine you have tunnels to two separate local networks active. How
> would you set things up, on Windows or Linux, to resolve local host
> names from both remote LANs as well as the internet in your default
> browser? Internet names should prefer the local DNS resolver, not go
> through any potentially slow VPN.

Here is my proposal: if you have those tunnels running simultenously you must specify two upstream servers in your local DNS forwarder as well as defining a regular Internet DNS, e.g. 8.8.8.8 or whatever. Then you need to specify that if the domain to be looked up contains a dot then query the Internet DNS, otherwise query both local upstreams.
In case you have only one active tunnel at a time it becomes easier in a way that you could dynamically switch between two configs in sync with changing tunnels as described above.
From the top of my head I cannot name a suitable software for this, but it should be possible to configure this in most resolvers I think.
Me personally as a Python developer would naturally create a quick script in case nothing off the shelf works, since it is not a very complex problem imho.

Cheers,
Domi

> 
> -Yves
> 
>> Am Di., 10. Nov. 2020 um 09:14 Uhr schrieb Tomcsanyi, Domonkos
>> <domi@tomcsanyi.net>:
>> 
>> Hello Yves,
>> 
>> I am by no means a person with authority to make such a decision, but your usecase seems to be so specific I would not imagine it would make sense to blow up the size and complexity of the Windows wg with a local DNS forwarder.
>> I think it is way better if people just install a local DNS resolver/forwarder on their own. There a ton of choices available, from simply python scripts to large scale servers. You could easily configure any of these to distinguish which DNS server to ask based on the TLD portion of your local domain or whatever other distinguisher you have.
>> Then the only thing you need to do is tell your system (either via wg or by other means) to use the local resolver and the case is solved :).
>> Also I am pretty sure one of the main philosophies behind wg is to be the same as much as possible on all platforms. Adding a DNS resolver would again mean a lot of complications when compared to e.g. the Linux version, since most Linux distributions already feature some kind of a local resolver by default.
>> 
>> Cheers,
>> Domi
>> 
>> 
>>> 09.11.2020 dátummal, 23:46 időpontban Yves Goergen <yves.goergen@gmail.com> írta:
>>> 
>>> Hello,
>>> 
>>> I've already used WireGuard to connect to private networks and it's
>>> quite easy once you figure out how to set it up. (Most tutorials are
>>> outdated and haven't been updated, new ones haven't been written.) One
>>> thing that's really missing however is DNS support. All I can do now
>>> is connect to IP addresses. Names are not resolvable on the other
>>> side. If I add the "DNS" directive to my client configuration, it
>>> replaces the local DNS resolver and *all* lookups go to that server
>>> instead. This isn't working either because I'm on two local networks
>>> and each has its own local DNS server that can only resolve its own
>>> local names (and forward the rest to the internet).
>>> 
>>> Specifying both networks' DNS servers also fails because when
>>> resolving a name, one of them is chosen at random (and the other one
>>> isn't regarded) and then you won't be able to resolve some of the
>>> names some of the time. This is also very frustrating. And it wouldn't
>>> scale to multiple active tunnels.
>>> 
>>> The solution I've read about is to set up a local DNS forwarder that
>>> can be configured so that it uses multiple servers and queries each of
>>> them and returns only a positive response. This way it could query
>>> both local LAN DNS servers and for local names, only one of them would
>>> resolve the name. This is a bit complicated to do if you're not
>>> permanently connected to a VPN, or if you move from one local DHCP
>>> network to another (like with a laptop). And it requires additional
>>> software, setup and configuration, and probably intensive maintenance
>>> and care. All of this makes WireGuard a pretty ugly alternative to
>>> OpenVPN where all of this already works. Despite all the disadvantages
>>> of OpenVPN.
>>> 
>>> I'm asking if it's possible to integrate such a local DNS forwarder
>>> into the Windows client application. I imagine it would start up
>>> automatically once the first tunnel is activated. And it would replace
>>> the local system's DNS server setting for as long as it's active (like
>>> the tunnel-configured DNS server already does). And it would query the
>>> original locally configured DNS server and all configured DNS servers
>>> for the active tunnels. It would then be able to resolve local names
>>> and tunnel-remote names without any additional work on the user end.
>>> The user wouldn't have to perform many complex tasks upon activating
>>> or deactivating a tunnel. This would make WireGuard be as simple and
>>> productive as I believe it was intended to be (but isn't yet).
>>> 
>>> This probably stops working as soon as other VPN software is used in
>>> parallel, but the current "DNS" setting has the same limitation, it's
>>> better than nothing and most of the time, you only run a single VPN
>>> software.
>>> 
>>> Please let me know what you think of it.
>>> 
>>> -Yves

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-10 15:38     ` Yves Goergen
  2020-11-10 16:04       ` Matthias Urlichs
  2020-11-10 18:08       ` Lech Perczak
@ 2020-11-11  7:36       ` Der PCFreak
  2 siblings, 0 replies; 13+ messages in thread
From: Der PCFreak @ 2020-11-11  7:36 UTC (permalink / raw)
  To: wireguard

Hi,

you are wrong!

For example, my dwood3rc.txt (only partially) file looks like this:

upstream_servers = 
{}                                                         # Initialize 
dictionary variable
upstream_servers["internal."]="192.168.178.1, 192.168.178.2, 
192.168.178.3"   # local DNS servers for all fqdns.internal
upstream_servers["."]="9.9.9.9, 
8.8.8.8"                                      # for others Quad Nine, 
Google, WITRON Firewall
root_servers = {}
# manual entries (similar to /etc/hosts)
# pointing to specific DNS servers for specific hostnames to resolve
root_servers["host1.separate.domain."]="10.11.12.13"           # resolve 
host1.separate.domain via DNS 10.11.12.13
bind_address="0.0.0.0"
# The IPs allowed to connect and use the cache
recursive_acl = "127.0.0.1/16, 192.168.178.0/24"

filter_rfc1918 = 0
reject_mx = 0
# please make sure you have 1 empty line at the end of the configuration 
file

So you can exactly do what you told is not possible. Make sure you don't 
forget the dots "." at the end of the names!

- resolve specific hosts via specifix DNS
- resolve specific subdomain via specific DNS
- resolve all others (.) via upstream server e.g. google DNS

So what else you need?

Regards

Peter


On 10.11.2020 16:38, Yves Goergen wrote:
> I just read through the 'upstream_servers' section of the Deadwood DNS
> resolver. And it doesn't seem to do what I need. I'll have to specify
> a fixed DNS server for a fixed name suffix. This is not possible on
> LANs where there are no suffixes, as I already described. Setting
> multiple upstreams for the same '.' suffix again results in a lookup
> in one of them, not both.
>
> This is not a solution to my problem. And I still refuse to believe
> that my problem is exotic. Every home LAN has this.
>
> Am Di., 10. Nov. 2020 um 14:06 Uhr schrieb Der PCFreak
> <mailinglists@pcfreak.de>:
>> Hi,
>>
>> concerning local DNS forwarder.
>>
>> I am in an environment where I need to resolve public DNS names to local
>> IPs for specific hosts and additionally public DNS for the rest.
>> In Windows XP it was possible to just stop the DNS cache service and set
>> 2 DNS servers and everything worked.
>> Newer versions of Windows starting with Windows 7 do only connect to the
>> second DNS if connecting (not querying) the first fails.
>> So if your first DNS is up but has no reply for your query, Windows will
>> just add that fqdn to the negative cache and no longer
>> query the DNS for a specific time or until you delete the cache with
>> ipconfig /flushdns.
>>
>> All of the above can be fixed using a local DNS forwarder.
>>
>> I use DeadWood on my machine for years now.
>> https://maradns.samiam.org/deadwood/doc/FAQ.html
>>
>> I just point my DNS to 127.0.0.1 (which is the deadwood service) and
>> configure Deadwood a little bit. It basically let's me
>> exactly specify which hosts to resolve how and can have something
>> similiar to a HOSTS entry, too.
>>
>> As Domi wrote I would encourage you to tryout a local DNS resolver, too.
>>
>> Regards
>>
>> Peter
>>
>> On 10.11.2020 09:14, Tomcsanyi, Domonkos wrote:
>>> Hello Yves,
>>>
>>> I am by no means a person with authority to make such a decision, but your usecase seems to be so specific I would not imagine it would make sense to blow up the size and complexity of the Windows wg with a local DNS forwarder.
>>> I think it is way better if people just install a local DNS resolver/forwarder on their own. There a ton of choices available, from simply python scripts to large scale servers. You could easily configure any of these to distinguish which DNS server to ask based on the TLD portion of your local domain or whatever other distinguisher you have.
>>> Then the only thing you need to do is tell your system (either via wg or by other means) to use the local resolver and the case is solved :).
>>> Also I am pretty sure one of the main philosophies behind wg is to be the same as much as possible on all platforms. Adding a DNS resolver would again mean a lot of complications when compared to e.g. the Linux version, since most Linux distributions already feature some kind of a local resolver by default.
>>>
>>> Cheers,
>>> Domi
>>>
>>>
>>>> 09.11.2020 dátummal, 23:46 időpontban Yves Goergen <yves.goergen@gmail.com> írta:
>>>>
>>>> Hello,
>>>>
>>>> I've already used WireGuard to connect to private networks and it's
>>>> quite easy once you figure out how to set it up. (Most tutorials are
>>>> outdated and haven't been updated, new ones haven't been written.) One
>>>> thing that's really missing however is DNS support. All I can do now
>>>> is connect to IP addresses. Names are not resolvable on the other
>>>> side. If I add the "DNS" directive to my client configuration, it
>>>> replaces the local DNS resolver and *all* lookups go to that server
>>>> instead. This isn't working either because I'm on two local networks
>>>> and each has its own local DNS server that can only resolve its own
>>>> local names (and forward the rest to the internet).
>>>>
>>>> Specifying both networks' DNS servers also fails because when
>>>> resolving a name, one of them is chosen at random (and the other one
>>>> isn't regarded) and then you won't be able to resolve some of the
>>>> names some of the time. This is also very frustrating. And it wouldn't
>>>> scale to multiple active tunnels.
>>>>
>>>> The solution I've read about is to set up a local DNS forwarder that
>>>> can be configured so that it uses multiple servers and queries each of
>>>> them and returns only a positive response. This way it could query
>>>> both local LAN DNS servers and for local names, only one of them would
>>>> resolve the name. This is a bit complicated to do if you're not
>>>> permanently connected to a VPN, or if you move from one local DHCP
>>>> network to another (like with a laptop). And it requires additional
>>>> software, setup and configuration, and probably intensive maintenance
>>>> and care. All of this makes WireGuard a pretty ugly alternative to
>>>> OpenVPN where all of this already works. Despite all the disadvantages
>>>> of OpenVPN.
>>>>
>>>> I'm asking if it's possible to integrate such a local DNS forwarder
>>>> into the Windows client application. I imagine it would start up
>>>> automatically once the first tunnel is activated. And it would replace
>>>> the local system's DNS server setting for as long as it's active (like
>>>> the tunnel-configured DNS server already does). And it would query the
>>>> original locally configured DNS server and all configured DNS servers
>>>> for the active tunnels. It would then be able to resolve local names
>>>> and tunnel-remote names without any additional work on the user end.
>>>> The user wouldn't have to perform many complex tasks upon activating
>>>> or deactivating a tunnel. This would make WireGuard be as simple and
>>>> productive as I believe it was intended to be (but isn't yet).
>>>>
>>>> This probably stops working as soon as other VPN software is used in
>>>> parallel, but the current "DNS" setting has the same limitation, it's
>>>> better than nothing and most of the time, you only run a single VPN
>>>> software.
>>>>
>>>> Please let me know what you think of it.
>>>>
>>>> -Yves

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-10 18:08       ` Lech Perczak
@ 2020-11-15 18:42         ` Yves Goergen
  2020-11-15 21:10           ` Matthias Urlichs
  2020-11-15 21:43           ` "Tomcsányi, Domonkos"
  0 siblings, 2 replies; 13+ messages in thread
From: Yves Goergen @ 2020-11-15 18:42 UTC (permalink / raw)
  To: Lech Perczak; +Cc: wireguard

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-15 18:42         ` Yves Goergen
@ 2020-11-15 21:10           ` Matthias Urlichs
  2020-11-15 21:43           ` "Tomcsányi, Domonkos"
  1 sibling, 0 replies; 13+ messages in thread
From: Matthias Urlichs @ 2020-11-15 21:10 UTC (permalink / raw)
  To: wireguard


[-- Attachment #1.1.1: Type: text/plain, Size: 920 bytes --]

On 15.11.20 19:42, Yves Goergen wrote:
> This reality includes host names like "pc1" and "pc2" in one LAN and
> "pc3" and "pc4" in the other LAN.

So you need a DNS proxy that knows about stripping .one.lan and .two.lan 
suffixes from your host names before forwarding the request to the 
requisite DNS server. Or one that asks both and merges the replies. None 
of this is in any way difficult to code, or indeed specific to Wireguard.

Also, why would you want to reconfigure your DNS proxy whenever the 
tunnel state changes? The proxy either gets an answer or it doesn't (or 
it gets a ICMP Unreachable back). If not, the tunnel is down, either 
because the other end is temporarily unreachable or because you tore 
down the tunnel. No reconfiguration required, simply react to timeouts 
and ICMPs / EHOSTUNREACH (or whatever the Windows equivalent is) as 
appropriate.

-- 
-- Matthias Urlichs


[-- Attachment #1.1.2: OpenPGP_0x72CF8E5E25B4C293_and_old_rev.asc --]
[-- Type: application/pgp-keys, Size: 48415 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
  2020-11-15 18:42         ` Yves Goergen
  2020-11-15 21:10           ` Matthias Urlichs
@ 2020-11-15 21:43           ` "Tomcsányi, Domonkos"
  1 sibling, 0 replies; 13+ messages in thread
From: "Tomcsányi, Domonkos" @ 2020-11-15 21:43 UTC (permalink / raw)
  To: Yves Goergen; +Cc: Lech Perczak, wireguard

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@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


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Add local DNS forwarder to Windows client
@ 2020-11-11 11:31 Stefan Puch
  0 siblings, 0 replies; 13+ messages in thread
From: Stefan Puch @ 2020-11-11 11:31 UTC (permalink / raw)
  To: wireguard

Hi Yves,

i can reassure you, the problem is not exotic. I had exact the same question in
mind when thinking whether I should move from OpenVPN to Wireguard (I'd like to).

For all people working in home office therse days where they're using some kind
of SOHO router (e.g. Speedport, Fritz!Box, what ever) I like to "push" them the
companies DNS server for the time they are connected without forcing them to
install additional software / python sript, modifying hosts file with static
IPs. Although OpenVPN has many disadvantages, the way it is possible to just
push a search list or name server is very comfortable.

My experiences with tutorial are exactly the same as yours and I (as a non
expert) would like to ask whats the intended solution on windows systems to
include a companies remote DNS server for the (limited) time period connected to
a VPN by leaving the local DNS (mostly handled by the SOHO routers) untouched?

Maybe I missed something, but adding the "DNS" directive to the client
configuration has exactly the behavior Yves elaborated on and so far I didn't
find an alternative solution.

Kind regards
Stefan

> Hello,
>
> I've already used WireGuard to connect to private networks and it's
> quite easy once you figure out how to set it up. (Most tutorials are
> outdated and haven't been updated, new ones haven't been written.) One
> thing that's really missing however is DNS support. All I can do now
> is connect to IP addresses. Names are not resolvable on the other
> side. If I add the "DNS" directive to my client configuration, it
> replaces the local DNS resolver and *all* lookups go to that server
> instead. This isn't working either because I'm on two local networks
> and each has its own local DNS server that can only resolve its own
> local names (and forward the rest to the internet).
>
> Specifying both networks' DNS servers also fails because when
> resolving a name, one of them is chosen at random (and the other one
> isn't regarded) and then you won't be able to resolve some of the
> names some of the time. This is also very frustrating. And it wouldn't
> scale to multiple active tunnels.
>
> The solution I've read about is to set up a local DNS forwarder that
> can be configured so that it uses multiple servers and queries each of
> them and returns only a positive response. This way it could query
> both local LAN DNS servers and for local names, only one of them would
> resolve the name. This is a bit complicated to do if you're not
> permanently connected to a VPN, or if you move from one local DHCP
> network to another (like with a laptop). And it requires additional
> software, setup and configuration, and probably intensive maintenance
> and care. All of this makes WireGuard a pretty ugly alternative to
> OpenVPN where all of this already works. Despite all the disadvantages
> of OpenVPN.
>
> I'm asking if it's possible to integrate such a local DNS forwarder
> into the Windows client application. I imagine it would start up
> automatically once the first tunnel is activated. And it would replace
> the local system's DNS server setting for as long as it's active (like
> the tunnel-configured DNS server already does). And it would query the
> original locally configured DNS server and all configured DNS servers
> for the active tunnels. It would then be able to resolve local names
> and tunnel-remote names without any additional work on the user end.
> The user wouldn't have to perform many complex tasks upon activating
> or deactivating a tunnel. This would make WireGuard be as simple and
> productive as I believe it was intended to be (but isn't yet).
>
> This probably stops working as soon as other VPN software is used in
> parallel, but the current "DNS" setting has the same limitation, it's
> better than nothing and most of the time, you only run a single VPN
> software.
>
> Please let me know what you think of it.
>
> -Yves


^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2020-11-15 21:43 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-03 10:31 Add local DNS forwarder to Windows client Yves Goergen
2020-11-10  8:14 ` Tomcsanyi, Domonkos
2020-11-10  8:44   ` Der PCFreak
2020-11-10 15:38     ` Yves Goergen
2020-11-10 16:04       ` Matthias Urlichs
2020-11-10 18:08       ` Lech Perczak
2020-11-15 18:42         ` Yves Goergen
2020-11-15 21:10           ` Matthias Urlichs
2020-11-15 21:43           ` "Tomcsányi, Domonkos"
2020-11-11  7:36       ` Der PCFreak
     [not found]   ` <CADJb3qTGhm8a=aAA8_6ZgEHHFyBZyOch_GRBkC1p4yym28fN-Q@mail.gmail.com>
2020-11-10 10:47     ` Fwd: " Yves Goergen
2020-11-10 22:24     ` Tomcsanyi, Domonkos
2020-11-11 11:31 Stefan Puch

Development discussion of WireGuard

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/wireguard

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 wireguard wireguard/ http://inbox.vuxu.org/wireguard \
		wireguard@lists.zx2c4.com
	public-inbox-index wireguard

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git