(In reply to Jan Vlug from comment #8) > Yesterday, I had host name resolution shortly working after fiddling with > nsswitch.conf IIRC. Did you read the warning telling you not to edit it at that top of that file? If you modified it outside authselect, you'll want to regenerate it to get back to a consistent state: # authselect apply-changes --force Otherwise future authselect operations will fail. The hosts like in /etc/nsswitch should look like this: hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns If you want to change it, you need to edit /etc/authselect/user-nsswitch.conf. Never edit /etc/nsswitch.conf directly. (In reply to Jan Vlug from comment #8) > Just now I changed the line back to: > hosts: files dns myhostname This is legacy mode. nss-dns will read /etc/resolv.conf instead of talking directly to systemd-resolved. There's no good reason to do that, so I recommend switching back to our defaults. > # systemctl restart NetworkManager > Connected the VPN again via the GUI (first time I got an error, second time > was successful) > # resolvectl dns > Global: 192.168.253.4 192.168.253.5 84.116.46.21 84.116.46.20 > Link 2 (enp35s0): 84.116.46.21 84.116.46.20 > Link 3 (virbr0): > Link 4 (virbr0-nic): > Link 5 (virbr1): > Link 6 (virbr1-nic): > # resolvectl domain > Global: > Link 2 (enp35s0): ~. > Link 3 (virbr0): > Link 4 (virbr0-nic): > Link 5 (virbr1): > Link 6 (virbr1-nic): > But the dns does not work for VPN internal hosts. I'm confused. You have no VPN interfaces here. Is your VPN enabled? Why is there no tun interface? You have only one DNS domain -- the global domain ~. -- so all your DNS should go to 84.116.46.21 or 84.116.46.20. Those are public addresses, so no surprise that you're unable to use public DNS servers to resolve internal names. Likely as not, your case is a separate problem from Benedikt's. Since you've been doing some custom configuration, I'm not convinced there's a software bug here. (In reply to Benedikt Gollatz from comment #9) > I don't remember changing the /etc/resolv.conf symlink; my guess is that the > symlink remains unchanged when upgrading from an earlier version of Fedora. > The internal nameservers get added to the top, so that shouldn't be the > issue. Well... it's not the issue, but it also doesn't make sense. You really want /etc/resolv.conf to only list systemd-resolved itself, 127.0.0.53. Otherwise you're going to have inconsistent behavior. Applications that read /etc/resolv.conf directly will ignore your DNS settings configured by NetworkManager and systemd-resolved. I suspect this is a NetworkManager packaging bug. I suspect the NetworkManager package previously symlinked /etc/resolv.conf to /var/run/NetworkManager/resolv.conf. We probably need a scriptlet somewhere to clean this up, probably in the NetworkManager package, or perhaps in the systemd package. So while I do think we have a Fedora bug here, that also doesn't explain what's going wrong for you. > When connecting to the VPN, resolvectl domain says the following, > irrespective of the /etc/resolv.conf symlink. > > Global: > Link 2 (wlp58s0): ~. > Link 3 (virbr0): > Link 4 (virbr0-nic): > Link 5 (tun0): This is a problem. ~. means all your DNS is sent to the DNS server corresponding to wlp58s0. What you want to see would be either this (Example 1): Global: Link 2 (wlp58s0): Link 3 (virbr0): Link 4 (virbr0-nic): Link 5 (tun0): ~. which means "all DNS should go to the VPN," or perhaps this (Example 2): Global: Link 2 (wlp58s0): ~. Link 3 (virbr0): Link 4 (virbr0-nic): Link 5 (tun0): example.com which means "example.com DNS goes to the VPN, all other DNS goes to interface DNS." Example 1 corresponds to NetworkManager's default settings (good for public VPN services), and Example 2 corresponds to checking the checkbox "Use this connection only for resources on its own network" in NetworkManager settings (good for corporate VPNs). I guess you want to match Example 2, because you mention you're having trouble resolving internal names, so I guess it's a corporate VPN. What I don't understand is how you wound up in such a weird state. If /etc/resolv.conf points to /var/run/NetworkManager/resolv.conf, then NetworkManager doesn't realize systemd-resolved is running at all, and won't attempt to use split DNS, so this trouble is expected. But if /etc/resolv.conf points to the stub resolver, NetworkManager should configure systemd-resolved to match one of my two examples, yet that has not happened in your case. I don't know why. > If I use /var/run/NetworkManager/resolv.conf, resolvectl dns says this: > > Global: > Link 2 (wlp58s0): > Link 3 (virbr0): > Link 4 (virbr0-nic): > Link 5 (tun0): This isn't good. Ideally your VPN servers would be listed under Link 5 (tun0) rather than Global. Forget about this case: let's not bother with /var/run/NetworkManager/resolv.conf. > However, if i use the stub resolver, the VPN nameservers do not show up at > all: > > Global: > Link 2 (wlp58s0): > Link 3 (virbr0): > Link 4 (virbr0-nic): > Link 6 (tun0): This is a little better, in that your VPN nameservers are no longer listed in the wrong place. But they're not listed in the right place either. That is strange. You can try to manually fix it. Let's say you want DNS for your internal corporate domain, example.com, to be resolved over VPN, and everything else to be resolved by your ISP, then you could try (untested): $ sudo nmcli connection modify tun0 ipv4.dns-search ~example.com ipv4.dns 1.2.3.4 Of course, replace example.com with your internal domain, and 1.2.3.4 with the desired internal DNS server. But while manually fixing it is fine, I wish I knew how it got so messed up in the first place! Because so long as /etc/resolv.conf is symlinked to systemd-resolved, NetworkManager should take care of all this for you.