Laptop Resets DNS Lookup Server to Nothing, Preventing Access to the Internet

Software PureOS
1

Would appreciate some help/suggestions as to how I can fix the below problem to reliably get online again.

Suddenly one day when I was just doing my thing, my computer froze and I had to shut down. When I started it up again, I couldn’t access any websites.

After some time diagnosing, I found out that the issue was the device was not resolving domains. I found the file where the list of DNS servers get written to when using DHCP at /etc/resolv.conf, where it had the following in it:

'# Generated by Network Manager
nameserver ::1

What even is that? I set it to Google’s 8.8.8.8 DNS server, however I’ve noticed that every time my computer resumes from sleep, restarts, or I change Wi-Fi routers, it gets rewritten to ::1 again. I don’t know how to get the Network Manager to stop it from doing this, but right now I need to edit the file multiple times a day to connect to the internet.

I’ve tried things like editing /etc/dhcp/dhclient.conf to precede, or supersede with 8.8.8.8, but this doesn’t seem to help, and obviously won’t work when a network doesn’t allow this DNS server. The only thing that really had changed on my computer was I had applied the regular updates. I tried uninstalling my VPN in case that was the cause, but the problem still persists, and there wasn’t a problem with the VPN before.

1 Like
2

That is localhost but for IPv6 i.e. the equivalent of IPv4’s 127.0.0.1

There is nothing wrong with pointing your DNS at localhost provided that
a) if you are going to point it at localhost IPv6 then better make sure that IPv6 is working
b) more importantly, you must of course be running a DNS server locally

That’s all by way of an aside to answer that question.

You haven’t provided much info to go on.

What hardware?

WiFi? Ethernet? Both?

Is the interface / Are the interfaces configured to use DHCP? static IP address? something else? If not static IP address, what IP address are you getting?

Have you enabled IPv4? IPv6? Both?

Are the interfaces configured to get DNS via DHCP? static configuration? something else?

I don’t know whether that’s really the right file. A thousand years ago that was the right file and it would be statically configured by the system administrator. These days I think that file is only an output - and if it doesn’t contain the right thing then that is only a symptom of a problem elsewhere (and likewise editing that file is not fixing the underlying problem, so it will get overwritten).

Most people would consider that to be privacy fail. Were you previously using that as your DNS server? Or just trying it now for testing? Whose DNS server are you intending to use? previously using?

3

Thanks for your reply, and the additional background on IPv6, DNS, & sysadmin stuff! :grinning:

Hardware: Librem 14v1
This occurs with both the Wi-Fi & Ethernet interface

I haven’t manually changed any of the default configuration that PureOS shipped wiith. For IPv4 this is set to Automatic (DHCP) by default on all networks, and IPv6 to Automatic. Both have DNS set to automatic. I’m not doing anything fancy like static IP or custom DNS servers. I imagine with the home routers I’m connecting to, these should all typically be a IPv4.

For the IP address, this configured correctly and gives me a 192.168.x.x IPv4 address depending on the router’s preferences. In GNOME settings, it does list the correct DNS servers from the router like 192.168.x.1, though I guess somehow it is not reaching /etc/resolv.conf.

Currently connecting to Google’s just as a troubleshooting measure, don’t want that to be a permanent fixture. It’s clear that something else related to the Network Manager is writing to /etc/resolv.conf, though if I knew that would likely help solve the issue.

I checked in /etc/NetworkManager/NetworkManager.conf, and it has the following, which doesn’t look unusual.
[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

4

So the router is handing itself out as the DNS server (which is fine in the right circumstances)?

You probably want to check the output from: resolvectl status
to see what DNS servers are available to the computer and which DNS server is being used by it at the current time. I think this would be more definitive than /etc/resolv.conf

On my system /etc/resolv.conf is a symbolic link (into /run/...) and those target files are all generated dynamically. The point is that each interface contributes one or more DNS servers and as each interface comes up and down the total list of DNS servers changes dynamically (both because of the interface coming up and down and because often the DNS servers for an interface are obtained dynamically via DHCP). That isn’t really compatible with the old static way of configuring an actual file, not a symbolic link, as /etc/resolv.conf

So you should confirm whether /etc/resolv.conf is an actual file or a symbolic link. And, yeah, if the file (either way) says “Generated file. Do not edit.”, that’s probably good advice. :slight_smile: You need to fix the underlying problem.

So my system is using the systemd-resolved service for DNS handling. If yours is too then you might want to check output from: systemctl status systemd-resolved

A lot of software won’t even use /etc/resolv.conf to determine how to resolve hostnames but some legacy software might and that’s why the file still exists.

5

I did notice when poking around that compared to another Debian based device, there weren’t some equivalent files under /run/... Anyways, I checked the status with:
systemctl status systemd-resolved

Which indicated it was disabled &inactive/dead:
systemd-resolved.service -Network Name Resolution
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
Active: inactive (dead)
etc…

To fix this I enabled and started the service:
sudo systemctl enable systemd-resolved.service
sudo systemctl start systemd-resolved.service

Which got it back running as it likely should be:
Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
Active: active (running) since ...
etc…

I linked the two files with:
sudo ln -sf /run/sysemd/resolve/stub-resolv.conf /etc/resolv.conf

I confirmed that these two now mirror each other, however nameserver 127.0.0.53 isn’t working to resolve DNS queries to allow the browser to connect, which suggests something else is wrong.

Additionally, on my other Debian-based device, it doesn’t seem to have these symbolically linked. /run/sysemd/resolve/stub-resolv.conf has nameserver 127.0.0.53 listed, but `/etc/resolv.conf has the nameservers assigned from the router via NetworkManager.

After running
sudo systemctl restart systemd-resolved.service
resolvedctl status

I get:
Global
Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub

Which should be set to foreign instead of stub to get from the router. I also have below that:

Link2 (eno0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link4 (lxcbr0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link5 (ipv6leakintrf0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
DNS Servers: ::1
DNS Domain: ~.

Link 10 (wls6)
Current Scopes: LLMNR/IPv4 LLMNR/IPv6
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

No sign of wlan0 or eth0, which I would’ve expected somewhere in there…

6

OK, that’s progress. So that’s the stub resolver. The system maintains a list of the actual DNS servers to use and clients can ask the stub resolver and the stub resolver will ask an actual DNS server.

Did you reboot?

Are you sure? Mine shows, under Global, resolv.conf mode: stub

7

Networkmanger should pull the DNS server from the access point to which you are connected and append it into resolv.conf as

nameserver 0.0.0.0

Where 0.0.0.0 is the ip address of the DNS server that was retrieved from the access point.

A dirty way to fix it without figuring out why that isn’t happening is to manually set the nameserver and set the resolv.conf file to be immutable by adding the +i bit to the file.

$ sudo chattr +i /etc/resolv.conf

A better solution may be to just check in settings, open the WiFi settings for your access point or the ethernet interface settings and check if the DNS is set to be obtained automatically from the router.

If you run dnscrypt-proxy on your laptop then manually configuring the resolv.conf file to have 127.0.0.1 as the nameserver and setting the immutable bit works to prevent networkmanager from changing it when the network status changes.

The network interface names have changed with udev, eth0 and wlan0 were from old naming conventions.

https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/#:~:text=The%20classic%20naming%20scheme%20for,are%20probed%20by%20the%20drivers.&text=In%20a%20way%20this%20naming,%2F*%2Fby-path%2F%20symlinks.

This has been this way a pretty long time now.

With the new naming convention eno0 is probably your ethernet (RJ45) port and wls6 is your WiFi.

You can add

net.ifnames=0

To your kernel command line to revert to the old naming convention (eth0, wlan0, etc.)

8

Thank you both for your suggestions and help. I tried various things without success for my particular problem, and ended up giving up, re-flashing, and reinstalling programs one-by-one to figure out what was causing the issue in the first place. In hindsight, it makes sense, but I can see why I struggled to figure it out.

The VPN program I use has a kill-switch, and even though I never toggled it, there appears to be a bug in that particular program itself which it automatically went into a weird mode where it thought it was both on and off, so it didn’t connect with or without the VPN being on. Problem was fixed by enabling then disabling the kill-switch, and filing a bug report with the VPN provider.

3 Likes
9

Thanks for the info and solution, Magician. I was running into the same problem and probably the same frustrations you experienced. Flipping the kill-switch for my VPN worked like a charm.

1 Like