16

I am running Arch Linux on a Raspberry Pi.

Suddenly:

  1. I am unable to ping to a website.
  2. I am unable to access a website from the browser.

I have two more computers (all running Arch Linux) connected to the Internet, where I can ping and use the Internet. Also, /etc/resolv.conf is identical on the other computers:

nameserver 10.230.252.252
nameserver 203.147.88.2
nameserver 8.8.8.8
search domain.name

I can use VNC. I can also ping to 8.8.8.8. When trying to access DuckDuckGo on Chromium I get:

This site can’t be reached
duckduckgo.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN

I have an active Internet connection. What's wrong?

11
  • Can you ping 10.230.252.252? Can you establish a network connection to it on port 53 (nc -z 10.230.252.252 53)? Same two questions for the other IP addresses.
    – DopeGhoti
    May 10, 2019 at 15:53
  • Yes, I can ping to 10.230.252.252 and the other two IP addresses . But there's a problem running netcat. I don't really have netcat installed - and I can't access the internet to install netcat.
    – S.Goswami
    May 10, 2019 at 15:57
  • My laptop is one the same network - from which I am posting this question. Which has the same resolv.conf file.
    – S.Goswami
    May 10, 2019 at 16:04
  • Do you have telnet? You can use that as an alternative to nc.
    – DopeGhoti
    May 10, 2019 at 16:10
  • 1
    Other network services can sometimes override what you have specified in resolv.conf. Check to see if any of these services are running: wiki.archlinux.org/index.php/… May 10, 2019 at 17:35

5 Answers 5

31

Although I've never had problem with my other x86_64 PC all running Arch Linux, this frequently happens till date with Arch Linux ARM when running NetworkManager.

The problem is like you are connected to wifi, but you can't ping or use the internet but you can access all the computers on the local network, and even use remote desktop sharing software.

There is a high chance that something went wrong while your ping or your browser tries to resolve the host. I can think of 3 solutions:

Solution 1

I believe this is a problem on the thousands of the Raspberry Pi systems running Archlinux ARM and using NetworkManger.

In my case /etc/resolv.conf was a broken symlink to ../run/systemd/resolve/stub-resolv.conf.

NetworkManager can't populate the symlink, and the /etc/resolv.conf is empty. We have to:

  1. Remove the broken symlink:
# rm /etc/resolv.conf
  1. Create an /etc/NetworkManager/conf.d/dns.conf file with the contents:
[main]
dns=none
main.systemd-resolved=false
  1. Restart NetworkManager:
sudo systemctl restart NetworkManager

This should fix the issue, if not follow Solution 2.


Solution 2

In case the above didn't fix the issue for you, you can temporarily populate /etc/resolv.conf by:

sudo systemctl restart systemd-resolved && sudo systemctl stop systemd-resolved

The reason this works is because probably something is messing up the /etc/resolv.conf file. The above command should overwrite the contents, but again, you should look at what causing the issue.


Solution 3

If you can't get your /etc/resolv.conf back, just create a new /etc/resolv.conf (delete if an empty old one or symbolic link exists) and paste the code:

search domain.name
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 1.0.0.1

Note, in the first line, you can also use your router's IP address, for example (nameserver 192.168.43.1 in my case) which will make other systems pingable on the same network. It's not a good idea to generate resolv like this, but I had a bad time with the NetworkManager's auto-generated resolv. Systemd-resolvd also generates wrong ones, even on my PC.

A bit weird, here I am using google's primary dns and cloudflare's primary dns, you can use 8.8.8.8 with 8.8.4.4 or 1.1.1.1 with 1.0.0.1.


Although that step works, but you may want to stop NetworkManager from overwriting the file whenever it restarts:

Add this entry to /etc/NetworkManager/NetworkManager.conf

[main]
dns=none
systemd-resolved=false

They worked for my installations on Raspberry Pi 3 model B. Hope this will work for you, too.

6
  • 4
    Thanks, disabling systemd-resolved fixed it for me. I had the same issue with the same setup: Fresh vanilla Raspberry Pi 3b running Arch Linux ARM. Maybe you should file a bug report. Seems like it doesn't work like it's supposed to.
    – Minding
    Jan 1, 2020 at 0:59
  • Yes, the bug exists till date and sometimes even restarting systemd-resolved works! And the problem occurs on ArchLinux ARM only. I have posted the issue in the forum archlinuxarm.org/forum/viewtopic.php?f=15&t=14188
    – S.Goswami
    Jan 1, 2020 at 7:01
  • 1
    F yeah! been banging my head about this issue. Solution 3 worked for me! Jun 30, 2020 at 4:02
  • 1
    Solution 3 works for me. My problem is: Server couldn't resolve the host of specific domains Jul 26, 2021 at 13:58
  • 1
    solution 1 with dns.conf saved me time. Thanks
    – DenisZ
    Nov 29, 2021 at 18:08
6

I've just had problem with same effects. Check if time is set properly. DNSSEC seems to be enabled by default and blocking requests due to "expired" certificates.

Some other problems related to this can be diagnosed with journalctl -u systemd-resolved -b -0.

1
  • Thank you for the suggestion. I kept my pi with the broken internet connection (DNS look up error?) and didn't fix it. But today I turned it on... The time is Ok indeed. And I don't know why it's working fine!!! It's super weird.
    – S.Goswami
    May 27, 2019 at 13:43
5

I had this issue on Raspberry Pi 4 running Arch Linux.

The symptoms were that there was no DNS, producing the ping error message.

I observed by calling date that the time was severely off, about two days in the past.

I made sure that time synchronisation was on with systemctl status systemd-timesyncd but noticed from the output of timedatectl timesync-status that the service didn't have an IP address for the NTP server (it said Server: Null).

Using jaku255's tip of checking journalctl -u systemd-resolved -b -0, I saw that time synchronisation didn't work because DNS was failing:

DNSSEC validation failed for question ntp.org IN DS: signature-expired

It's a bit of a deadlock: DNS doesn't work because the time is wrong and the time is wrong because DNS doesn't work.

Attempting to set the time manually, I issued

timedatectl set-time "2020-02-29 10:51:55"

but this produced an error:

Failed to set time: Automatic time synchronization is enabled

To fix this, I temporarily (hehe^^) disabled time synchronization with

timedatectl set-ntp 0

and called timedatectl set-time again, this time successfully.

Afterwards, I reactivated time synchronization with timedatectl set-ntp 1 and made sure using timedatectl timesync-status that synchronisation works now:

Server: 212.69.166.153 (0.arch.pool.ntp.org)

Also, ping and curl work fine now with DNS succeeding.

0
1

Wanted to add one more to Goswami's solution list.

I face the same problem of chicken-and-egg between DNSSEC and NTP on my tiny portable servers running Debian 10. Sometimes they stay unpowered for quite some time and literally lose sense of time, while world changes around them, so I could not just create a static hot-fix configuration(s). At the same time, they do have to get online on their own when powered, as I do not have physical access to them. I decided to break out of the loop through correcting time first and so far this method seem to be reliable enough.


Solution 4

Obtain list of reliable IP addresses of reliable and trustworthy NTP servers. Let's use this one, for instance: https://tf.nist.gov/tf-cgi/servers.cgi . Here are some samples from there:

time-a-g.nist.gov       129.6.15.28
time-b-g.nist.gov       129.6.15.29
time-c-g.nist.gov       129.6.15.30
...
time-a-wwv.nist.gov     132.163.97.1
time-b-wwv.nist.gov     132.163.97.2
time-c-wwv.nist.gov     132.163.97.3
time-d-wwv.nist.gov     132.163.97.4
...

Since I use chronyd for time sync, I simply added those IP addresses to its config: (NOTE: that also works for ntpd config, usually found at /etc/ntp.conf)

nano /etc/chrony/chrony.conf

added lines:

...
pool time.nist.gov
server 132.163.97.1
server 132.163.97.2
server 132.163.97.3
server 132.163.97.4
...

Now, chrony goes through all specified addresses until it is able to connect and obtain time. And from that point everything else starts working properly.

I have a script on my mainframe that periodically checks that all IPs on the list are active and notifies if any of them go offline, so I can update remote configs when necessary, while servers are online and not all NTP servers expired.

Probably, the best practice would be to have fall-back configs for both ends, DNS and NTP.

2
  • 1
    "the best practice would be to have fall-back configs" The problem with "fall-back" in many cases is that it is impossible to tell if it is a "legitimate" fall back like you describe or one happening because of an active attack. Apr 19, 2021 at 18:52
  • I completely, agree, pardon my phrasing. As always, here is a trade-off between usability (autonomous reliability) and security. In this particular case I meant best practice for best reliability. But every admin should evaluate this trade-off before committing to a certain fall-back setup.
    – Nik
    Apr 19, 2021 at 19:52
1

This issue still continues to happen on Arch Linux Arm and Raspberry Pi 4. I use systemd-networkd instead of NetworkManager so one of the solutions above does not apply. My NTP system time was also syncing properly. DNSSEC was disabled by default.

In my case, WAN hostnames were resolving but LAN hostnames were not and I was getting the same Name or service not known errors.

My solution was to use classic DNS instead of LLMNR by editing /etc/systemd/resolved.conf:

[Resolve]
...
LLMNR=no
...
ResolveUnicastSingleLabel=yes

Restart services to apply changes:

sudo systemctl restart systemd-networkd
sudo systemctl restart systemd-resolved

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.