I am not understanding why my pc wasn't able to resolve names until I manually deleted a stale nmcli device entry.
Description/steps:
ubuntu 22.04 desktop, which uses network-manager and systemd-resolved. I had a vpn installed, with "block connectivity outside of VPN" enabled. Was having connectivity issues (specifically failure to resolve any names i believe). I disabled the "killswitch" in the VPN app, and uninstalled the VPN, and rebooted.
I was able to ping multiple ip's (including my intended dns server address 1.1.1.1, and a current IP of google.com) But nslookup could not resolve any hostnames. I could successfully dig @1.1.1.1 google.com as well.
My limited understand suggested that if i had:
- a valid interface
ip addrwith an IP on the expected subnet - a valid default
ip routeto an IP on that subnet, - and dns server of
1.1.1.1inNetwork Manager- as shown on the NM gui -
/etc/resolve.confpoints to a server on localhost,systemd-resolvd - but note i see no
1.1.1.1text anywhere in/etc/systemd/before or after the fix
- as shown on the NM gui -
then this (dns) "should be working". Not so, obviously.
After some poking, i found a stale device in nmcli d, of type dummy and state connected which by it's name must have been created by the (now uninstalled) VPN app. In case it is significant, this entry was 2nd, below the correct/expected connected wifi device.
deleting this nmcli device caused dns (nslookup, and programs such as browser), to resume working(resolving). Specifically, from a fresh reboot I did nslookup ... (failed to resolve), then nmcli connection delete ..., then nslookup ... works. No other changes / logout / etc.
Question:
Where should I have known to look to understand that this stale nmcli connection was the issue / what other components are involved here? I might assume my problem is in lack of systemd-resolved knowledge, but where's the link to the erroneous nmcli d entry, and where is systemd-resolved configured by NM to use 1.1.1.1?
