Fixing wg-quick's DNS= directive with a hatchet

Geo Kozey geokozey at
Fri Oct 27 00:52:41 CEST 2017

> From: Jason A. Donenfeld <Jason at>
> Sent: Fri Oct 27 00:19:27 CEST 2017
> To: Geo Kozey <geokozey at>
> Subject: Re: Fixing wg-quick's DNS= directive with a hatchet
> On Thu, Oct 26, 2017 at 11:53 PM, Geo Kozey <geokozey at> wrote:
> > No, with fixed resolv.conf pointing to local namserver only there would be no DNS resolution as your cache has to come from somewhere. I'm talking specifically about local nameserver without external connectivity but I think users may want to use their own static nameservers with dynamic one which they get from wg for whatever reason. Having to chose one over another as only possibility isn't best solution IMO.
> Usually people who do this usually point their cache toward the remote
> tunneled nameserver, via, say, dnsmasq's -S option. Some people do
> indeed enjoy multiple entries in their resolv.conf and rely on this
> generally buggy behavior, which means you could make an argument that
> I shouldn't be using openresolv's "-x" option, and maybe you'd have a
> case. But I don't care for nobs, and those powerusers probably don't
> want wg-quick anyway or can just use PostUp.
> In any case, this is a different issue from what this thread is trying
> to determine, so if you'd like to bikeshed -x vs -m and options and
> whatnot in openresolv, please do so on an entirely different thread
> with a different subject.
> ----------------------------------------
The thing is if "openresolv -x"  isn't best solution then this thread with your patch can go straight to /dev/null. You wrote yourself that you don't care about nobs and power users won't use it anyway so what's the point?. Especially as distro maintainers are against all of this. IMO "openresolv -x" is usable for preventing people who have no idea what they doing from shooting themselves in foot. Powerusers most of the time will choose full control over what is and what isn't in their resolv.conf.


More information about the WireGuard mailing list