Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Yves Goergen <yves.goergen@gmail.com>
To: Der PCFreak <mailinglists@pcfreak.de>
Cc: wireguard@lists.zx2c4.com
Subject: Re: Add local DNS forwarder to Windows client
Date: Tue, 10 Nov 2020 16:38:28 +0100	[thread overview]
Message-ID: <CADJb3qRapO=3-fuyeS6iC8EnM34TxTxpZBr1uyVhhTmfjgOmwA@mail.gmail.com> (raw)
In-Reply-To: <d62f54e7-cb5f-7baf-9320-19903b7c5d51@pcfreak.de>

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

  reply	other threads:[~2020-11-10 15:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-03 10:31 Yves Goergen
2020-11-10  8:14 ` Tomcsanyi, Domonkos
2020-11-10  8:44   ` Der PCFreak
2020-11-10 15:38     ` Yves Goergen [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADJb3qRapO=3-fuyeS6iC8EnM34TxTxpZBr1uyVhhTmfjgOmwA@mail.gmail.com' \
    --to=yves.goergen@gmail.com \
    --cc=mailinglists@pcfreak.de \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).