DNS failure - - network or configuration issue?

Hey friend,

Sorry to hear about the trouble this is giving you. I see that Javi replied to a ticket on this. I also had a second look at it, as well as one of our engineers. I just wanted to make sure that we were all on the same page, and we all came to the conclusion that the reply sent to the ticket represents the correct path to begin troubleshooting.

It’s at least good for us to make sure there are no platform issues causing such things, and to be extra certain of that.

Jarland

This isn’t much of a solution or answer. The purpose of this post is to document the situation after I had to nuke my droplet and start over.

For the better part of 2 weeks I had been going back and forth with tech support reps with DigitalOcean privately over email. We couldn’t figure it out.

To recap the issue, here are all the details.

When running apt, the original DNS issue is still present. See here: https://i.imgur.com/kHaFNHF.png

An escalations rep had me paint a more comprehensive picture of my networking stack. Here are the commands he suggested and their output:

$ cat /etc/netplan/50-cloud-init.yaml: https://i.imgur.com/jumdfze.png

$ ip addr: https://i.imgur.com/qLLXncr.png

$ ip route, uname -a, ls -l /lib/modules: https://imgur.com/HuG1EhN.png

$ cat /etc/udev/rules.d/70-persistent-net.rules: This file doesn’t exist. The only file found Inside /etc/udev/rules.d/ is a file named 99-digitalocean-automount.rules. The contents are 30 lines long. Here are two screenshots: Lines 1-19: https://i.imgur.com/5ABdgcn.png Lines 19-30: https://i.imgur.com/RqCiQJL.png

$ sudo iptables -nvL --line-numbers: I can’t take screenshots of this output because the output is some 180 lines long. If I had ssh access, this would be easy. But for now I am stuck with the web-based Droplet Console so the only way for me to convey information is with screenshots.

The Developer Support Escalations rep responded with:

All of that information looks fine as well, so again it’s a bit of a head-scratcher here. Can you try taking a snapshot of this Droplet and then creating a new Droplet from that snapshot - then get back to us if it has the same issues? I’ve added a bit of credit to your account to pay for this testing.

He also suggested that I take a snapshot. So with a new Droplet with this new snapshot, apt is still broken. See here: https://i.imgur.com/UvXxf21.png

I floated the idea of filing a bug report upstream. Another DO user encountered the same issue last year on 16.04: https://www.digitalocean.com/community/questions/temporary-failure-resolving-digitalocean-mirrors Unfortunately this user never received an answer. I found users with similar issues going as far back as 14.04.

I’ve resolved to nuke my Droplet and start over. Lucky for me my LAMP stack is easy to set up so it’s only a minor inconvenience.

I recall changing resolv.conf and playing with some other commands and cat’ing other configuration files. I don’t recall exactly what other changes I may or may not have made. I’ve sifted through my bash history and there are no timestamps so it’s hard for me to pinpoint exactly. Based on what I see, I can’t tell which other configurations I changed, if at all.

With my firewall turned off, pinging 8.8.8.8 seems to work. No packet loss. But pinging www.google.com yields: Temporary failure in name resolution. Another member of the Ubuntu community on FreeNode suggested I try: ip -4 route add default via 104.131.14.1 dev eth0. The resulting output is RTNETLINK answers: File exists. See here for the raw output of all of the above: https://i.imgur.com/cmlu7B9.png

Since pinging 8.8.8.8 works, what does that show or indicate from your perspective?

For what it’s worth, the only file present in /etc/netplan/ is 50-cloud-init.yaml. It’s contents can be found here: https://i.imgur.com/tfnzcTo.png