ping displays "Name or service not known"

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

2. Create an /etc/NetworkManager/conf.d/dns.conf file with the contents:

[main]
dns=none
main.systemd-resolved=false

3. 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.

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.

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.