On Mon, May 11, 2020 at 09:11:32PM -0500, Chris Adams wrote:
Once upon a time, Zbigniew Jędrzejewski-Szmek
> Yep. There's also /run/systemd/resolve/resolv.conf, where systemd-resolved
> always exposes a list (with the limitations described above).
I wasn't aware of that file... to me, that's a rather obscure location
(and I didn't find it mentioned anywhere in the change proposal). I
think having it (or at least having it symlinked to by something) in the
more "usual" location, /etc, would be better. Something like
/etc/resolv.conf.upstream? I don't know, I'm really bad at naming
The file is created dynamically at runtime, so symlinking from /etc has
the downside that you'd get a dangling symlink if systemd-resolved is not
running. The name would be "new" anyway, and we can document the name
under /run just as well as any name under /etc. So I don't think adding
a symlink in /etc/ is useful.
I added the following to the Change page:
And while I get that the multi-VPN thing is an important use case,
also wager it's a fairly small use case, so not super important to the
people that want to query "real" DNS servers (which I grant is also a
small use case, but I'm just saying it's definitely non-zero and worth
Right. Sadly dig doesn't seem to have an option to specify
path, and host also doesn't. I guess it would be a useful addition esp.
in case of dig.
Even better would be a standard location (and maybe even defaulting
to be symlinked to /etc/resolv.conf if systemd-resolved is not in use),
plus trying to get upstreams for common utilities like "dig" to learn
about the alternate (at least with an easy-to-use option).
If systemd-resolved is
not in use, then most likely you want something
else to manage that file, e.g. NetworkManager. In other words, if
systemd-resolved is not "on", then we want to fall back to what we do
currently, and we don't want systemd-resolved to touch that file at