I understand about NetworkManager. I just think systemd is driving it.
I installed Fedora 36 Mate. Whatever it does by default is what I am doing. Until recently, I never touched it. Now, I am having a DNS issue and wanted to manually set which server is used. Used to be, you just set it in resolv.conf. That doesn’t work anymore. If you check the net you get “try this”, “try that”. I tried it all. The only thing that works was the awful hack I described above.
Manually setting the DNS server should be trivial. It has become a nightmare.
NetworkManager comes with a gui configuration program where you can set the DNF server among other things. Since dns is now handled by systemd-resolved, the content of /etc/resolv.conf has become irrelevant in most cases.
So, you configure the DNS in NetworkManager, and NetworkManager will do whatever it takes to pass on this information to systemd-resolved.
Yep, Villy has it right. Go into NetworkManager’s configuration tool (depending on where that lives in your desktop environment), find the connection that needs to be changed (wired, wifi, VPN, etc.), and disable ‘auto’ DNS replacing it with your desired address.
NetworkManager will then feed that information into the other places it is required when the connection is activated. Trying to manipulate that data at a lower level will lead to frustration since it is part of the ‘managed’ network connection.
The bad guy creating the /etc/resolv.conf link is revealed by
“rpm -q --scripts systemd-resolved”, so upon systemd-resolved update the link is recreated. If you really want or need the classical /etc/resolv.conf, the recipe is there: stop and disable systemd-resolved. But since systemd-resolved is more flexible and integrates with NetworkManager, better to configure and use it!
Yes, it creates the link. No it does not do so upon an upgrade if /etc/resolv.conf already exists.
Thus a manually created file at that location does not get removed with system updates.
I agree that manual changes should be put into the NetworkManager configuration tool as previously suggested. However, manually creating a file at /etc/resolv.conf and replacing the link there is actually a valid way of managing dns. The drawback is that any dns config done using the configuration tool is not seen by the system once the link has been replaced.
Agree, now in F37 I can reinstall systemd-resolved without loosing the manually created symlink. Only initial installation of systemd-resolved creates link now. (Two lines of code added above the comment block.)
Sorry for the wrong information.
According to “resolvectl status” the “resolv.conf mode” switches to foreign and the DNS parameter is taken from resolv.conf.
Unfortunately (or maybe fortunately depending upon your viewpoint) once a user has created that file to replace the symlink it effectively relegates systemd-resolved to an ineffective and unused status.
As far I understood, programs can do DNS lookup themselves or call library functions. In order to have consistent behaviour between the two, either /etc/resolv.conf should be a symbolic link and systemd-resolved active, or a classical /etc/resolv.conf file with systemd-resolved inactive/deactivated.
and NO. Nothing with systemd writes to /etc/resolv.conf. At startup the data is placed under /run/systemd/resolve/. That is why I said systemd-resolved becomes ineffective. Any information it retrieves and places in the /run/systemd/resolve/ tree related to dns is negated by having a user created file at /etc/resolv.conf instead of the symlink.
The dns related info returned by dhcp is still stored as intended but the user created file no longer directs the system to that since /etc/resolv.conf is now a file and not a link.
Network related info from dhcp still is managed by NetworkManager and systemd-resolved as intended. Only the DNS info is overridden (or rather no longer accessed).
Access with other programs that have been updated to directly access the systemd-resolve files and functions but do not directly access /etc/resolv.conf may exhibit a hybrid effect as shown by @hmmsjan above, but pure dns lookups for name service (such as browsers) use (in order) /etc/hosts, /etc/resolv.conf, then to the dns nameservers identified there. If /etc/resolv.conf does not point to the local systemd-resolved service then it never gets used for normal name service.
• Alternatively, /etc/resolv.conf may be managed by other packages, in
which case systemd-resolved will read it for DNS configuration data.
In this mode of operation systemd-resolved is consumer rather than
provider of this configuration file.
Also, /etc/nsswitch directs normal name lookups to systemd-resolved via the “resolve” entry. Some programs may bypass the nsswitch facility and access the dns server directly as directed by /etc/resolv.conf. So for these programs systemd-resolved would not be used.
Sorry, It’s still not clear for me.
In firefox, http://router.home gives me the router configuration page. This page is not known to 18.104.22.168 and can only be resolved by systemd-resolved.
Even a name-only lookup to a Windows PC works, which should be LLMNR.
As soon I stop systemd-resolved, the “router.home” is no longer known, but internet lookup works and originates from 22.214.171.124.
Is it not the other way around: if systemd-resolved is running, /etc/resolv.conf is not used for normal lookups, except, as @vekruse mentions , systemd-resolved uses it as consumer to define the DNS parameter.
Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
Current DNS Server: 126.96.36.199
DNS Servers: 188.8.131.52
Link 2 (wls1)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.2.254
DNS Servers: 192.168.2.254 fe80::b2ac:d2ff:fe57:410e%32655
DNS Domain: home