ping: Temporary failure in name resolution

Posted May 10, 2021 5.6k views
Ubuntu 18.04


I have a problem with my Droplet, which I believe I caused myself and can’t get out of it. Basically I’m unable to ssh into the droplet (18.04, failed upgrade to 20.04), and can’t access outside internet from it. Below are the things I tried so far (apart from fully turning off and rebooting the droplet numerous times):

ssh into the server results in:
ssh: connect to host port 22: Connection timed out

From the droplet:

$ ping
ping: Temporary failure in name resolution

Contents of /etc/systemd/resolved.conf:

$ ufw status
ERROR: Couldn't determine iptables version
$ ifconfig -a
lists eth0 and lo, both running
$ cat /etc/network/interfaces
auto lo
iface lo inet loopback

source /etc/network/interfaces.d/*

auth eth0
iface eth0 inet static

… and probably bunch of other things which I will mention when I recall all of them… Also I don’t care about fully resurrecting the droplet, I need to make some data backup and destroy it. For that though I need outside access, besides the “Access console”.

What am I missing?


  • $ ls -la /etc/resolv.conf was a symlink to /run/systemd/resolve/stub-resolv.conf, which didn’t exist. Recreated the file with:

    options edns0

    $ service systemd-resolve status shown that the service is stopped.
    $ service systemd-resolve start activated it, but after another reboot still no luck…

  • So I unlinked /etc/resolv.conf from /run/systemd/resolve/stub-resolv.conf and linked it to:
    $ ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

    Contents of /etc/resolv.conf:

  • $ systemd-resolve --status, contents of eth0 section:

    Link 2 (eth0)
          Current Scopes: none
           LLMNR setting: yes
    MulticastDns setting: no
          DNSSEC setting: no
        DNSSEC supported: no
  • $ sudo netstat -tupln | grep 22
    tcp    0    0*    LISTEN 693/sshd
    tcp6   0    0    :::22         :::*         LISTEN 693/sshd

    $ service ssh status - runnning

  • Okay, SOME success. I can now SSH into the droplet after running (this allows all incoming SSH):
    sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
    sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

  • Show 1 more comments

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
1 answer

Hi @LukaszFormela,

First try making your resolv.conf be the following:

options edns0

If this doesn’t work, I’ll suggest contacting DigitalOcean’s support. I was going to ask you to check the contents of your /etc/netplan/50-cloud-init.yaml file and see if everything there looks properly configured however there might be some misconfiguration which you won’t be able to see so better to contact support.

You can reach them here:

Please do keep me in the loop though! I’m interested to see how this would be resolved.

  • Hi @KFSys,

    Appreciate your response! So I believe that resolv.conf got updated automatically after reboot and looks exactly like you posted.

    Contents of /etc/netplan/50-cloud-init-yaml:

        version: 2
                    macaddress: 76:e3:4e:20:18:3d
                    search: []
                set-name: eth0

    I may eventually have to reach out to support, however it’s probably me that made a boo-boo, so I’m trying to solve it on my own :)

    • Hi @LukaszFormela,

      The contents of the /etc/netplan/50-cloud-init-yaml do look correct as well. I mean as far as I can tell without having all the information it does look legit.

      Even so, the network issues are more often than not a bit harder to troubleshoot without having all the information about or knowing it a 100 % like - Gateway, Mac Address and stuff like that.

      Sadly, I don’t have anything else in mind that could’ve been the source of the issue.

      • Hi @KFSys,

        That’s fine, I truly appreciate your input anyway, I wouldn’t expect much response to the thread really :)

        So for future reference, I now can SSH into droplet, left a comment above with what I did.

        In the meantime I also reached out to the support.


        • Hi @LukaszFormela,

          I’m glad to hear you have some success on that front!

          Regarding your last comment about SSH and how you lost it once you rebooted your droplet. Make sure to save your Iptables prior to rebooting otherwise the rules won’t be there and you’ll have to re-add them.

          You can do so with iptables-save