1

After upgrading Debian11/KDE to Debian12, restarting and running sudo apt-get upgrade it shows errors like Could not resolve ftp.XX.debian.org. These also show when running sudo apt-get update. I then tried to open websites in the Firefox-esr browser and it can't open any (it shows the "Hmm. We're having trouble finding that site." error). I can't ping any sites either, it shows "Name or service not known". So it has problems resolving domain names with DNS.


Details and what I tried:

I tried sudo mv /etc/resolv.conf /etc/backup.resolv.conf. DNS still works on a Debian11 machine and it worked before upgrading to Debian12. The nftables firewall rules are the same as before. The time was off by minutes again but I corrected it so it shouldn't be off by more than seconds. At the end of upgrading at 99% I tried to open the browser when it asked me to replace a certain config file, this caused a black screen (once during updating the screen could not get woken up too) and logged me out so I had to finish upgrading with sudo dpkg --configure -a which seemed to have worked. Maybe I need to check if the upgrading worked.

Right now I can't use the Internet on that machine while NetworkManager displays it's properly connected and my router page also shows the device as connected.

  • grep ^hosts /etc/nsswitch.conf shows hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines

  • /etc/resolv.conf contains #Generated by NetworkManager nameserver: 1.1.1.1 (I already tried adding nameserver 1.0.0.1 beneath it which didn't help)

  • nmcli c show <connection name> | grep -i dns shows the below for the Internet connection (not the VPN connection). On the Debian11 machine where DNS still works those values are different: it does not have connection.dns-over-tls. I think dns-over-tls likely has to do with the problem. It's also configured in the router that is used by multiple machines of which only the Debian12 machine can't reach websites. I use IPv4-only for good reasons and a VPN.

connection.mdns:                        -1 (default)
connection.dns-over-tls:                -1 (default)
ipv4.dns:                               1.1.1.1
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.ignore-auto-dns:                   yes
ipv6.dns:                               --
ipv6.dns-search:                        --
ipv6.dns-options:                       --
ipv6.dns-priority:                      0
ipv6.ignore-auto-dns:                   no
IP4.DNS[1]:                             1.1.1.1

Why is that and how to solve this problem?

11
  • What servers does your /etc/resolv.conf actually reference? Jun 13, 2023 at 16:35
  • Why would you ever consider sudo mv /etc/resolv.conf /etc/backup.resolv.conf? I suggest you put it back. Carefully Jun 13, 2023 at 16:47
  • In it there's just the nameserver that I configured that worked before and still works on another machine (D11). @roaima Didn't expect that would help, I only tried that after nobody replied and it was the only thing I found (here)
    – mYnDstrEAm
    Jun 13, 2023 at 17:14
  • 1
    Start from /etc/nsswitch.conf. If your system was already configured to use systemd-resolved as the primary resolver or the upgrade caused it to be reconfigured so, then /etc/resolv.conf may now be meaningless. You might also want to run resolvectl status.
    – telcoM
    Jun 14, 2023 at 10:20
  • 1
    Please add the output of grep ^hosts /etc/nsswitch.conf and the contents of /etc/resolv.conf (if there is one at the moment). to your initial question. Also nmcli c show <connection name> | grep -i dns, replacing <connection name> with the name of your active NetworkManager connection (see nmcli c output - look for connection(s) listed in green to identify active connections).
    – telcoM
    Jun 14, 2023 at 12:15

2 Answers 2

1

The connection.dns-over-tls setting is new to Debian 12. As far as I understand, the value "default" (-1) has a meaning that depends on which resolver library you're using. I don't think the classic libc resolver (hosts: keyword dns) has any DNS-over-TLS functionality, so with your current settings, the "default" setting (or even any setting!) would mean "no". But you could change it with:

nmcli c modify <connection name> connection.dns-over-tls <new setting>

The possible settings would be "default", "no", "opportunistic", and "yes". I think they would only take effect when using systemd-resolved or some other resolver library with DoT support.

So you have hardcoded DNS server 1.1.1.1 in the NetworkManager settings, and tried to add 1.0.0.1 by directly editing /etc/resolv.conf. But have you tested if you can even reach those DNS servers?

If you don't have nslookup or dig installed yet, the most basic test using only libc-bin tools (which really ought to be present as that package is marked essential) would be:

getent hosts 1.1.1.1             # reverse lookup
getent hosts one.one.one.one     # one.one.one.one is the DNS name of 1.1.1.1

If you have traceroute installed, a good test for DNS-over-TLS that might even locate the problem for you would be:

traceroute -T -p 853 -n 1.1.1.1

For regular non-TLS DNS queries, you might test:

traceroute -T -p 53 -n 1.1.1.1

I know you said NetworkManager says it's properly connected, but is that really true?

If you run ip addr show, you will see the actual low-level state of each network interface. It should show <BROADCAST,MULTICAST,UP,LOWER_UP> and ... state UP ... for the network interface you're currently using.

If there is just UP but no LOWER_UP within the angle brackets, it means the interface is configured (wants to work) but has no link or has some other problem that prevents it from actually working (can't). In that case, check the dmesg output, as there might be an error message indicating that you're missing a NIC firmware file, or something like that.

4
  • modifying to yes or no didn't change anything. (Do I need to set that to yes or does it suffice if I configure that in my router?) I don't have systemd-resolved installed (nslookup & dig neither). The getent commands work but there's no output for both of these commands. Now I'm thinking I probably need to add a nftables firewall rule to allow port 853. Is that the case and if so how should that look like? I tried rules like this and it didn't work: udp sport 853 ct state established,new accept (like the domain rules; don't know if also a name for this port).state UP&LU set
    – mYnDstrEAm
    Jun 14, 2023 at 21:27
  • 1
    I don't have Debian 12 yet, but I believe connection.dns-over-tls will only take effect if you are using a resolver that can actually do DoT, e.g. systemd-resolved. So until you can install that, you will be using classic non-DoT DNS queries. The symptoms suggest you cannot reach the DNS server's port 53 for some reason.
    – telcoM
    Jun 15, 2023 at 0:04
  • I couldn't edit the comment - I replaced udp with tcp in the nftables firewall rule. When I run (I have to use sudo) sudo traceroute -T -p 53 -n 1.1.1.1 I get send: Operation not permitted. Let me know when you have another idea what to try to reach DNS servers.
    – mYnDstrEAm
    Jun 15, 2023 at 8:24
  • Now I found this with journalctl | tail -n 100 but I don't know why it wasn't there earlier: write to TUN/TAP : Invalid argument from nm-openvpn which could be cause of this. However, the VPN connection displays as established/working and I don't know what to change in the networkmanager config for it. Edit: this was the solution, I'll add it as answer to make it easier to find. Your answer could help many to debug problems though, thanks! (And I don't know why this error wasn't in journalctl earlier.)
    – mYnDstrEAm
    Jun 15, 2023 at 8:42
0

With journalctl | tail -n 100 I found this error (which didn't show at first):
nm-openvpn: write to TUN/TAP : Invalid argument (fd=-1,code=22)

To solve this problem (in KDE) right click the tray icon of NetworkManager (if you have imported your VPN config to it or set the VPN up in there)
->Configure Network Connections...->Your VPN->VPN (openvpn)->Advanced->General->check "Use compression" and select LZO in the box on the right (I haven't tried other compression methods)->Ok and Apply->Disconnect, reconnect and test it.

I still don't know why this problem occurred and it seems like DNS-over-TLS doesn't yet work. Please comment if you know about either.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .