On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce <simo(a)redhat.com> wrote:
On Sun, 2020-07-26 at 21:06 -0500, Michael Catanzaro wrote:
> On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr
> <johnmh(a)splentity.com> wrote:
> > Please do not disable reading from /etc/resolv.conf. If you do so,
> > please
> > limit that to the Spins that it won't affect people on, such as
> > Workstation,
> > if you believe people there don't set their own DNS servers.
>
> Except:
>
> * /etc/resolv.conf is broken by design, as you would know if you read
> the section on split DNS that you just quoted
> * There's no value in reading from /etc/resolv.conf unless you have
> written something custom to it
> * /etc/resolv.conf is managed by NetworkManager in Fedora, so you
> cannot safely write to it anyway in our default configuration
>
> Fact is that unless you have done custom work to allow manual
> modifications to /etc/resolv.conf, you're not going to notice this
> change at all. And if you have, then surely you'll be able to figure
> out the very, very simple steps to get back to the original behavior.
> In fact, it should actually be *easier* than before to get traditional
> behavior. Remove the symlink. Create your own /etc/resolv.conf. Hey
> presto! systemd will read it....
Sorry Michael,
but there are truckloads of programs that read resolv.conf directly, if
all this change is doing is moving the file elsewhere but providing the
same data in it, fine. If it is removing the pointers to DNS servers
this change is absolutely not something you can do covertly in an
update, it *will* be seen, but normal users will have a hard time
figuring out what broke in the first place, let alone figure out how to
resolve it (pun intended :).
Moreover if glibc is changed to use a different resolver then why
change resolv.conf away? Only non-glibc querying programs would use it,
and they intentionally do so anyway. Case in point one of the core
components of the identity system in Fedora (SSSD) MUST be able to
query directly DNS in scenarios were it is joined to an AD or IPA
domain. Because it queries for stuff like SRV and TXT records
concurrently (we use an async library) and needs to see those fields,
as well as receive multiple IP addresses in order to set up fallbacks.
Please do not break DNS this way, if you really want to force
everything through a single system resolver (I think that is a worthy
goal) then it needs to be a thing that speaks DNS on UDP port 53 on
127.0.0.X and that address needs to be in resolv.conf as the nameserver
address.
Any other "solution" will just break a bunch of stuff unnecessarily.
That *is* what will happen. In this scenario, systemd-resolved creates
a file in /run that is populated with the required information for
applications to request name resolution from resolved through the
standard DNS protocol. The /etc/resolv.conf file becomes a symlink to
the file in /run so that the file in /etc is stable and regenerating
the file in /run won't cause issues for package management. This
system has been in use *already* for a while now in other
distributions (see Debian and resolvconf(8), which systemd-resolved
replaced in Ubuntu).
The only thing this mechanism breaks is applications trying to *write*
to the resolv.conf file, because systemd-resolved will just blow away
those changes right after. If you want to modify DNS settings, you
need to configure systemd-resolved itself, either through
NetworkManager (as we will recommend) or directly through
systemd-resolved's configuration interface (if not using NetworkManager).
--
真実はいつも一つ!/ Always, there's only one truth!