0

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?

mYnDstrEAm
  • 4,008
  • 13
  • 49
  • 108
  • What servers does your /etc/resolv.conf actually reference? – u1686_grawity Jun 13 '23 at 16:35
  • Why would you ever consider `sudo mv /etc/resolv.conf /etc/backup.resolv.conf`? I suggest you put it back. Carefully – roaima Jun 13 '23 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](https://askubuntu.com/a/142342)) – mYnDstrEAm Jun 13 '23 at 17:14
  • Have you tried `ping ftp.XX.debian.org` for testing your internet connection? – Nepumuk Jun 13 '23 at 20:06
  • Sure, I tried pinging websites and Debian repos and it doesn't work: `Name or service not known`. I have the nftables firewall and the same firewall rules as on another D11 machine where resolving domain names still works. At the end of upgrading I tried to open the browser when it asked me to replace a certain config file, this caused a black and logged me out so I had to finish upgrading with `sudo dpkg --configure -a` which seemed to have worked. Maybe there's a command to identify the problem. – mYnDstrEAm Jun 13 '23 at 20:16
  • Correcting the time (which again was off by many minutes, I asked about this earlier) like suggested [here](https://unix.stackexchange.com/a/570382/233262) also didn't help and I can't find anything that seems very relevant with journalctl. – mYnDstrEAm Jun 13 '23 at 20:54
  • "_I only tried that after nobody replied_" - you only asked your question six hours ago. Some people may not have even woken up yet – roaima Jun 13 '23 at 21:13
  • I wonder if it has anything to do with the spate of "I have no ipv4" issues some people are having recently – Jaromanda X Jun 13 '23 at 23:49
  • 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 '23 at 10:20
  • @telcoM nsswitch.conf looks normal, is there sth I should put in there for testing? `resolvectl` command is not found. Maybe D12 has some problems with DNSsec which worked before, maybe the time needs to be more accurate; I haven't configured anything weird for DNS so it should be mostly be the default. – mYnDstrEAm Jun 14 '23 at 11:45
  • 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 | grep -i dns`, replacing `` 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 '23 at 12:15

2 Answers2

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.

telcoM
  • 87,318
  • 3
  • 112
  • 232
  • `modify`ing 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 '23 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 '23 at 00: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 '23 at 08: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](https://github.com/kylemanna/docker-openvpn/issues/551). 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 '23 at 08: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.

mYnDstrEAm
  • 4,008
  • 13
  • 49
  • 108