On Mon, 2020-07-27 at 09:20 -0400, Neal Gompa wrote: > 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). 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. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc _______________________________________________ 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
