On Monday, July 27, 2020 6:43:23 AM MST Simo Sorce wrote:
On Mon, 2020-07-27 at 09:20 -0400, Neal Gompa wrote:
> 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).
Thanks, I guess I misunderstood because of alarmist tones.
This will work just fine, writing to resolv.conf is indeed something
advanced, and a user that can set that up will likely know how to fix
it as well.
Please note that the issue with this isn't replacing resolv.conf with a
symlink to a file in the same format that provides a local DNS server. The
issue is ignoring users' configuration and effectively doing this upon
upgrade:
rm -f /etc/resolv.conf
then putting a symlink there.
There's no reason for this. systemd-resolved has what's called "mode 1",
where
it reads from /etc/resolv.conf and everything continues to work just as you'd
expect.
--
John M. Harris, Jr.