I use wg-quick to setup a tunnel to my home LAN from various wireless
(WiFi) networks that I don't control. My /etc/wireguard/wg0.conf
contains the line:

DNS = yy.yy.yy.yy

where yy.yy.yy.yy is a DNS server on my LAN.

With a typical WiFi network, when I initially connect to it,
/etc/resolv.conf becomes populated with something like the following:

nameserver xx.xx.xx.xx
search nnn.nnn.nnn

When I then do 'wg-quick' up, resolv.conf ends up like this:

nameserver yy.yy.yy.yy
nameserver xx.xx.xx.xx
search nnn.nnn.nnn

So DNS queries will generally go through my designated DNS server, which
is good, but if something goes wrong with my server, queries will leak
out to the DNS server supplied by the WiFi network, which is not good.
Similarly, queries for addresses like 'example.com.nnn.nnn.nnn'
sometimes end up going out into the DNS system, which is also not good.

I would think that the correct behavior would be for wg-quick to *replace*
the existing contents of resolv.conf, rather than just *prepending* the
specified DNS server. I understand that as per the man page, I can
presumably get this behavior by using the PostUp and PostDown keys, but
I think the default should be changed, or at least that users should be
warned of the leak potential in the documentation.

I just have setup wireguard-tools together with openresolv and it behaves
exactly as you like it: it replaces completely the DNS servers in resolv.conf.

For you this behavior is the desired one, for me not ;). Because I am losing my
local DNS configuration poiting to my local hosts.

Anyway I think we see, that there is no general behavior that suits all users...

Cheers,
Mathias

Hi Celejar, Mathias,
look like you may want to consider cutting out the middleman and asserting
control of resolv.conf directly. The state of resolv.conf managment on
Linux is unfortunately a huge mess. Me personally I've lost confidence and
patience in the current crop of common tools
(resolvconf/openresolv/systemd-resolved) and so I feel it's worth it for my
purposes.

Here's two approaches I've used to bypass them with caveats and
workarounds:

1) Hand edit /etc/resolv.conf plus chattr +i

This works very well in my testing, none of the managment tools try to lift
the "i" (immutable) fs attribute so the contents stay the way you want them
and any rogue tool just fails to replace/write-to resolv.conf.

One nasty caveat is the current dhclient-script that fails to cleanup the
resolv.conf.tmpXXX file it uses to atomically replace resolv.conf. This can
cause serious blowup in /etc and ENOSPC problems (ask me how I know ;). I
dealt with this by installing a dhclient-enter-hook like so:

    $ cat /etc/dhcp/dhclient-enter-hooks.d/disable-resolv-conf
    #!/bin/sh
    # NOP out function updating resolv.conf as our upstreams like to force DNS
    # related dhcp options on us despite not asking for them. Woohoo.
    make_resolv_conf() :

Ofc. other tools may fail in similarly hilarious ways, but at least they
wont break DNS ;)

2) Install a symlink to your config at /etc/resolv.conf

AFAICT most mangmagment tools seem to back off when resolv.conf is a
symlink to a location they don't recognize (I've only really tested with
systemd-resolved). This works ok, but the main problem is apparmor (which
only affects some programs). /etc/apparmor.d/abstractions/nameservice has
an explicit list of files programs may read and this doesn't really
allocate any namespace for local system additions:

    @{etc_ro}/resolv.conf r,
    # On systems where /etc/resolv.conf is managed programmatically, it is
    # a symlink to @{run}/(whatever program is managing it)/resolv.conf.
    @{run}/{resolvconf,NetworkManager,systemd/resolve,connman,netconfig}/resolv.conf r,
    @{etc_ro}/resolvconf/run/resolv.conf  r,
    @{run}/systemd/resolve/stub-resolv.conf r,
    /mnt/wsl/resolv.conf r,

This can be fixed by installing a drop-in such as

    $ cat /etc/apparmor.d/abstractions/nameservice.d/local-resolv-conf
      abi <abi/3.0>,

    @{etc_ro}/resolv.conf.local.* r,

3) apt-get purge-with-a-vengeance resolvconf openresolv systemd-resolveconf && apt-pinning

I've had the problem that the offending DNS managment tools get installed
through recommends even though I don't intend for them to be used, I
haven't worked this out yet but I think it'd be reasonably easy to write an
apt preferences snippet to prevent them being installed in all cases.

A final note: I use ifupdown for my network interface managment needs:
ethernet, wifi, vpn (on/off switch) etc. This way I can easily integrate
hooks to configure the DNS on a per-network basis, but if you use something
like NetworkManage as-is this approach means you have to have one static
config you're happy with -- well you can always just copy/symlink
per-network templates into place manually but that seems a hassle.

Let me know your use cases though maybe I can figure something out even for
that case.