On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce <simo@xxxxxxxxxx> 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@xxxxxxxxxxxxx> 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! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
