Hi Celejar, Mathias, On Thu, Oct 12, 2023 at 03:36:12PM +0200, Mathias Behrle wrote: > On Sun, 12 Jun 2022 17:13:29 -0400 Celejar <[email protected]> wrote: > > I would think that the correct behavior would be for wg-quick to *replace* > > the existing contents of resolv.conf, rather than just *prepending* > > For you this behavior is the desired one, for me not ;). Because I am losing > my > local DNS configuration poiting to my local hosts.
Since you both seem to have a sense of what you want your DNS config to
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.
--Daniel
signature.asc
Description: PGP signature
