ping displays "Name or service not known"

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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