I have a problem with one of my Ubuntu 18.04 servers.

After a recent power cut, I can no longer connect to it from outside the network.

I'm currently SSHing to it through another server in my network (which does have internet access).

ping google.com
ping: google.com: Temporary failure in name resolution

 ping -c4
PING ( 56(84) bytes of data.

--- ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3050ms

cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.


Pinging my router ( works, but is actually quite slow, and intermittantly hangs:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=7 ttl=64 time=1.81 ms
64 bytes from icmp_seq=8 ttl=64 time=1.67 ms
64 bytes from icmp_seq=9 ttl=64 time=1.85 ms
64 bytes from icmp_seq=10 ttl=64 time=3.80 ms

And also, sometimes (maybe one in every 10 attempts) a ping to google.com returns the following:

ping google.com
PING google.com ( 56(84) bytes of data.
64 bytes from lhr48s09-in-f14.1e100.net ( icmp_seq=1 ttl=55 time=24.6 ms
64 bytes from lhr48s09-in-f14.1e100.net ( icmp_seq=2 ttl=55 time=19.2 ms
64 bytes from lhr48s09-in-f14.1e100.net ( icmp_seq=3 ttl=55 time=14.8 ms
64 bytes from lhr48s09-in-f14.1e100.net ( icmp_seq=4 ttl=55 time=25.7 ms
64 bytes from lhr48s09-in-f14.1e100.net ( icmp_seq=5 ttl=55 time=57.0 ms
64 bytes from lhr48s09-in-f14.1e100.net ( icmp_seq=6 ttl=55 time=21.9 ms
64 bytes from lhr48s09-in-f14.1e100.net ( icmp_seq=7 ttl=55 time=16.6 ms

I've disabled resolvd:

 systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-resolved.service(8)

And, following some advice from another forum, added an entry to /etc/NetworkManager/conf.d/no-systemd-resolved.conf to ensure Network manager is ignoring resolvd.

The last time the system rebooted (about 3 weeks ago), it recovered with no network related problems at all. There have been no updates to the server in that time.

If I take a look a look at the configuration of another Linux machine on the network (in this case, a Rasberry Pi,) I can see it's successfully using resolvd:

pi@colin:~ $ cat /etc/resolv.conf
# Generated by resolvconf
nameserver fd51:42f8:caae:d92e::1

I have tried adding nameserver to the resolv.conf of the problematic server but this makes no difference.


Strangely, I can ping external DNS servers, albeit very slowly. For example:

PING ( 56(84) bytes of data.
64 bytes from icmp_seq=7 ttl=58 time=15.1 ms
64 bytes from icmp_seq=98 ttl=58 time=18.2 ms
64 bytes from icmp_seq=99 ttl=58 time=15.6 ms
64 bytes from icmp_seq=100 ttl=58 time=12.4 ms
64 bytes from icmp_seq=101 ttl=58 time=9.09 ms
64 bytes from icmp_seq=102 ttl=58 time=22.3 ms
<approx 40 second pause>
64 bytes from icmp_seq=103 ttl=58 time=16.5 ms
64 bytes from icmp_seq=104 ttl=58 time=24.9 ms
64 bytes from icmp_seq=105 ttl=58 time=12.3 ms
64 bytes from icmp_seq=144 ttl=58 time=13.9 ms
64 bytes from icmp_seq=145 ttl=58 time=28.4 ms
<approx 10 second pause>
64 bytes from icmp_seq=146 ttl=58 time=8.77 ms
64 bytes from icmp_seq=147 ttl=58 time=9.13 ms
64 bytes from icmp_seq=148 ttl=58 time=22.3 ms
64 bytes from icmp_seq=149 ttl=58 time=25.4 ms
<approx 20 second pause>
64 bytes from icmp_seq=190 ttl=58 time=9.26 ms
64 bytes from icmp_seq=191 ttl=58 time=15.9 ms
64 bytes from icmp_seq=192 ttl=58 time=12.7 ms
64 bytes from icmp_seq=235 ttl=58 time=14.8 ms
64 bytes from icmp_seq=236 ttl=58 time=19.7 ms

There seems to be no consistency to the ping response times.

  • In your resolv.conf, make sure is listed as a nameserver, before and that ipv6 address you mentioned. In that case, can you reproduce those slow responses/dns resolution inconsistencies? If not, it sounds like the DNS server on is somehow responsible. – SYN Oct 18 '19 at 14:42

I ended up bouncing the router and that sorted the issue. Not something I could do remotely. Very strange problem and a hard reboot of a router seemed unnecessary but unavoidable at that point.

|improve this answer|||||

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.