On Mon, 2020-07-27 at 09:20 -0400, Neal Gompa wrote:
On Mon, Jul 27, 2020 at 9:07 AM Simo Sorce simo@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@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.
Simo.