After the update to 20.04 base, both machines updated can no longer connect to archive.neon.kde.org. Other computers on the network, and same machines before 20.04 update, connect fine.

I can get it to resolve by adding

Code: Select all

nameserver 8.8.4.4
nameserver 8.8.8.8


to /etc/resolv.conf

Does anyone have an idea why this is happening?

Note: the dns changes are not required on 18.04 base or on the other machines on my home network, so seems it is not my isp dns that is the issue here.

Well, I can add yet another machine with the same symptoms.

I am leaning towards some issue with the change to systemd-resolved, either something borked or it is pointing to an unavailable mirror, which is bypassed when I force a different DNS.

Still rather lost, so if anyone has even a hint of an idea to try and track this down, would be awesome to get it nailed and reported/fixed.

I have no idea what's going on with systemd-resolved either. It's failing to fetch/apply DNS from my DHCP router and all (however iirc, it succeeds in fetching/applying DNS from my phone's hotspot).

First I'd recommend checking where your /etc/resolv.conf is pointing to.
The basic setup is to have it point to either /run/systemd/resolve/resolv.conf OR /run/systemd/resolve/stub-resolv.conf.
The latter if you have DNSStubListener=yes in your systemd-resolved config (which is the default in our system, iirc), so the former if the opposite.

Then reboot your machine.

Afterwards reconnect to your network, then use "resolvectl status" to check which DNS server is being detected & used by systemd-resolved.

bobbywibowo wrote:I have no idea what's going on with systemd-resolved either. It's failing to fetch/apply DNS from my DHCP router and all (however iirc, it succeeds in fetching/applying DNS from my phone's hotspot).

First I'd recommend checking where your /etc/resolv.conf is pointing to.
The basic setup is to have it point to either /run/systemd/resolve/resolv.conf OR /run/systemd/resolve/stub-resolv.conf.
The latter if you have DNSStubListener=yes in your systemd-resolved config (which is the default in our system, iirc), so the former if the opposite.

Then reboot your machine.

Afterwards reconnect to your network, then use "resolvectl status" to check which DNS server is being detected & used by systemd-resolved.

I use a lot of DNS servers, I responsibly claim that none of the changes to the DNS server helped, the Neon server crashed
Yandex
OpenDNS
Cloudflare
Google Public DNS
Comodo Secure DNS
Quad9
Verisign DNS

Alrighty, so /etc/resolv.conf is pointed to /run/systemd/resolve/stub-resolv.conf, as is I guess the default as you mentioned.
resolvectl-status gives the output below:

Code: Select all

Global
       LLMNR setting: no                 
MulticastDNS setting: no                 
  DNSOverTLS setting: no                 
      DNSSEC setting: no                 
    DNSSEC supported: no                 
          DNSSEC NTA: 10.in-addr.arpa     
                      16.172.in-addr.arpa
                      168.192.in-addr.arpa
                      17.172.in-addr.arpa
                      18.172.in-addr.arpa
                      19.172.in-addr.arpa
                      20.172.in-addr.arpa
                      21.172.in-addr.arpa
                      22.172.in-addr.arpa
                      23.172.in-addr.arpa
                      24.172.in-addr.arpa
                      25.172.in-addr.arpa
                      26.172.in-addr.arpa
                      27.172.in-addr.arpa
                      28.172.in-addr.arpa
                      29.172.in-addr.arpa
                      30.172.in-addr.arpa
                      31.172.in-addr.arpa
                      corp               
                      d.f.ip6.arpa       
                      home               
                      internal           
                      intranet           
                      lan                 
                      local               
                      private             
                      test               

Link 2 (enp0s31f6)
      Current Scopes: DNS       
DefaultRoute setting: yes       
       LLMNR setting: yes       
MulticastDNS setting: no         
  DNSOverTLS setting: no         
      DNSSEC setting: no         
    DNSSEC supported: no         
  Current DNS Server: 192.168.1.1
         DNS Servers: 192.168.1.1
          DNS Domain: ~.         


enp0s31f6 is the link in question, I removed a few virtual bridge nics from the output, but otherwise this is the output.
I did not think to try if tethering would give a different result before, thank you for the hint! I did give this a try and yes, as with yourself I can resolve archive.neon.kde.org while tethering.

If it helps, my setup is fairly simple here:
D-Link DSL-2885A Router connects to the internet and shares throughout the house (we use modem/router combos here in aussieland, I have heard this is possibly different elsewhere? Incase it is confusing that we have only one device)

Computers themselves are on a combination of wired and wireless, in particular the 3 20.04 installs are my main PC, a 2-in-1 HP Laptop, and a VM for testing if it happened there aswell, which it did.
So it seems to, possibly, be some sort of hiccup with systemd-resolved and our particular systems/setups? Hopefully we can track down the cause, or at least a more permanent fix than overriding the dns in the stub every boot.

You can opt to make a new file named "fallback-dns.conf" (or any name, as long as it ends with .conf) at /etc/systemd/resolved.conf.d (if resolved.conf.d directory don't exist, just make one).
Fill it with the following:

Code: Select all

[Resolve]
FallbackDNS=1.1.1.1 1.0.0.1


You can use any DNS servers you want, just separate each one by a whitespace (it'll try one by one from the left, then settle with the first working one, afaik).
Anyway, it will just tell systemd-resolved to use those DNS if, and only if, it fails to get DNS servers from the network. It's a better alternative for the time being.

Restarting the service with "sudo systemctl restart systemd-resolved", then reconnecting to the network, should reflect the change immediately. If not, no harm in rebooting.

I have yet to make a breakthrough in looking for the root cause of the issue, unfortunately.

I'm just using a pretty basic standalone TP-LINK Wi-Fi router with DHCP server enabled to allow more-controlled local network (local IP assignments, among other things), which should be the very basic setup of home routers, so I don't think it's due to anything special in our setup (as in the network themselves; I do think there has to be a misconfiguration somewhere in our machines).

Alrighty, I gave this a try and, interestingly - it does not seem to have worked for me.
I grabbed the latest 20.04 based ISO for Neon (as of today) and spun up a new VM to see if it has the same trouble. As it turns out, it does not, so looking definitely like something malconfigured/broke in the update (assuming the change to systemd-resolved as we have been thinking).

I will take a look at the configuration/compare and see if I can find anything that is broken, or points to our problem.

If there is anything you can think of that you would like checked or need output of, or anything really that I can help with, I am happy to help wherever!

@Corodius,
Neon user edition plasma 5.19.4, ubuntu 20.04 file /run/systemd/resolve/stub-resolv.conf is empty.
In Manjar and Arch it does not even exist
@bobbywibowo,
I have an optical connection to the router in the house. I know well the previous clean installation of Neon 5.19.4 Ubuntu 18.04, the system required an upgrade. The upgrade was successfully done on Neon 5.19.4 Ubuntu 20.04. There were two updates after this and in both pkcon it reported that the IP address of the Neon server was not available. Only the third day after all these crashes and corrections, and any updates were made. I change the DNS servers where it is defined, change the DNS server, disconnect and then reconnect.

Code: Select all

/etc/resolv.conf Manjaro
# Generated by NetworkManager
nameserver 77.88.8.88
nameserver 77.88.8.2
nameserver 208.67.222.222
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 208.67.220.220
nameserver 77.88.8.87

Arch

Code: Select all

# Generated by NetworkManager
nameserver 77.88.8.88
nameserver 208.67.222.222
nameserver 208.67.220.220
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 77.88.8.2

Neon
resolv.conf is link to /run/systemd/resolve/stub-resolv.conf and file is empty?
What should I do to get normal files as you write? which command to type?