(Support question) DNS name resolution fails after the latest update (2023-04-23)

Software PureOS
1

Hi,

I have a Librem v14 and PureOS on top. I have noticed that DNS name resolution does not work after the most recent updates (yersterday/today).

Figuring out the Current State of the System

I don’t know how to query PureOS version, but …

root@machine:/# uname -a
Linux move 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux

GNOME Version: 3.38.5

and …

root@machine:/# lsb_release -a
No LSB modules are available.
Distributor ID:PureOS
Description:	PureOS
Release:	10.0
Codename:	byzantium

Network Manager is at 1.30.6

Content of /etc/resolv.conf

Network Manager generates resolv.conf like this:

# Generated by NetworkManager
nameserver ::1

I don’t know if this helps. It looks like a useless skeleton (referring to a loopback device).

I just know that, when I replaced this nameserver with Google’s 8.8.8.8 internet started working again.

2

I can’t comment on any actual changes to PureOS that may be relevant but there is nothing useless about using the loopback interface (in your example via IPv6) for DNS resolution. In fact that would be the normal situation on many of my computers.

Unfortunately DNS resolution has become rather complicated, compared with the good old days when /etc/resolv.conf was “it”.

If you mean that you edited /etc/resolv.conf then that can be badness if that file is generated automatically i.e. your change can get wiped out, and your fix would only be temporary (but at least temporarily useful e.g. for downloading further updates if something has been broken here).

3

Clearly, there is some sort of DNS-like service that’s locally taking over DNS requests. Otherwise, changing resolv.conf to point to another DNS server wouldn’t have worked.

It’s probably this service that fails.

4

Yep, would normally be a stub resolver - but the actual DNS servers (to which the stub resolver will relay) will be determined dynamically based on what interfaces are up and statically based on additional configuration.

If you want to troubleshoot this then your first step would be to find out what process, if any, is listening for UDP packets on port 53 on ::1 (or if not on that IPv6 address, on any other local IP address).

5

I can confirm that there was, it seems, a bug. In the past few days, autogenerated resolv.conf points to an IPv4 local address, not ::1 .

Who fixed it, why and exactly when is unknown :slight_smile: .