Question

ping: google.com: Temporary failure in name resolution

Hello,

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 167.172.205.93 port 22: Connection timed out

From the droplet:

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

Contents of /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDns=8.8.4.4
$ 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
  address 167.172.205.93
  netmask 255.255.240.0
  gateway 167.172.192.1
  dns-nameservers 8.8.4.4

… 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?

Thanks, Lukasz

Subscribe
Share

Support asked me to use the following commands to be able to resolve DNS correctly:

iptables -A INPUT -p udp --sport 53 -j ACCEPT
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT

However it didn’t help. Moreover I rebooted the droplet and somehow lost SSH access again, none of previous rules I used work any more… I think I’m ready to simply bin it.

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 and sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

$ sudo netstat -tupln | grep 22
tcp    0    0    0.0.0.0:22    0.0.0.0.*    LISTEN 693/sshd
tcp6   0    0    :::22         :::*         LISTEN 693/sshd

$ service ssh status - runnning

$ 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

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:

nameserver 1.1.1.1
nameserver 8.8.8.8

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

nameserver 8.8.8.8
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…


Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

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.

Hi @LukaszFormela,

First try making your resolv.conf be the following:

nameserver 127.0.0.53
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:

https://www.digitalocean.com/support/

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