If you wanted to, you could post your /etc/resolv.conf and /etc/systemd/resolved.conf here. I don’t know if there might be a configuration directory option for systemd-resolved, so keep an eye out for a potential directory like /etc/systemd/resolved.d that might have the configs instead.
- 0 Posts
- 7 Comments
Joined 2 years ago
Cake day: July 1st, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Did you ever come back to this and figure it out? My curiosity is killing me :)
Agreed, though I don’t think they disabled systemd-resolved, because it still works using 127.0.0.53 when they’re connected to the VPN. So the daemon must be running, unless Mullvad itself has a DNS forwarder using the same loopback. I suspect they either hard coded some upstream DNS server for Mullvad, because Mullvad might not have supported systemd-resolved yet. Or maybe they set a permission on the configs, and something changed with the user context of Mullvad processes.
Interesting that it works when the VPN is connected, though. I also believe that systemd-resolved is installed on just about any system using systemd, but often isn’t enabled, without problem. Enabling it would generally involve a resolv.conf symlink and a config, so maybe that config was hijacked by Mullvad (or OP configuring Mullvad), and there’s no upstream DNS server available when the VPN isn’t connected.
I missed that it’s Linux Mint in the original post, and it looks like Mint has started using systemd-resolved. The Arch wiki might be useful to OP on how things are configured:
Ok, so something setup 127.0.0.53 as your DNS server, and isn’t removing it correctly. I think it’s safe to say it’s Mullvad, since it works using that DNS server IP when connected. Is that IP in your resolv.conf, or is resolv.conf maybe a stub, and you’re using systemd-resolved?
Ok, so does the VPN bring it’s own DNS? Some VPNs do, so it may explain why everything suddenly works fine when you connect.
When not connected to VPN, are you able to dig or nslookup internet names? Local names? A server timeout will be very different from an nxdomain or an empty SOA, in the response.
Are you able to telnet to a public web server on TCP/443?
One thought I’m having is, maybe at some point you set a static IP on your wifi interface, but screwed up the subnetting.
Have you ever messed with network manager or systemd-resolved internal settings, maybe trying to setup multicast DNS or caching?
Ok, so the resolv.conf is being used to put systemd-resolved in the forwarding path, with it listening on 127.0.0.53. That’s how Mint does things, so don’t touch that file.
Your resolved.conf has no DNS servers or fallback DNS servers configured, so it should just use the DNS servers handed out by DHCP. Either your DHCP servers isn’t handing out a DNS server (unlikely, since other machines work), NetworkManager was configured to not use DHCP DNS servers, or you’re hitting some bug causing the same. I suspect you may have configured NetworkManager for this, maybe it was overriding the VPN DNS. Or maybe you accidentally set the NetworkManager DNS backend to dnsmasq, when it should be systemd-resolved in Mint.
You could try uncommenting that FallbackDNS line and adding a couple space separated DNS servers, maybe your router IP. Mine looks like this:
#DNS= FallbackDNS=1.1.1.1 1.0.0.1 #Domains=
That will hopefully allow VPN DNS to work when it’s connected, and fall back to other DNS servers when not. If not, we could try taking a look at NetworkManager configs. It’s been a bit, I use systemd-networkd now, but I could spin up a VM.