1

After each reboot Ubuntu cannot resolve host by DNS and cannot open any page. I use to run these commands after each reboot to make everything work

rm /etc/resolv.conf 
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf
sudo resolvconf -u

How can I avoid that issue?

3
  • Could this possibly be related to this bug? digitalocean.com/community/questions/…
    – Ketzak
    Jan 31, 2018 at 23:42
  • hi, similar question ? > askubuntu.com/a/134137/397428
    – Yolateng0
    Jan 31, 2018 at 23:50
  • If you could add the info in the non-working resolv.conf to your question, that could be helpful. @Yolateng0, similar in symptom, but very different causes and broken states. It would seem he does have a resolv.conf, albeit a useless one, whereas the user in the other question errantly deleted config files.
    – Ketzak
    Feb 1, 2018 at 0:56

2 Answers 2

0

I see that you're already trying to use the solution described here: https://unix.stackexchange.com/questions/280264/no-dns-resolution-after-upgrade-from-ubuntu-14-04-to-16-04

While not ideal, a work-around would be to automatically run your commands on boot. This page includes some methods of doing that:

http://linuxtechlab.com/executing-commands-scripts-at-reboot/

Another possibility is that you're affected by the bug in the March 2017 update:

https://www.digitalocean.com/community/questions/how-to-fix-the-march-2017-ubuntu-dns-resolution-issues

Another very thorough answer appears here: 16.10 fail to resolve DNS

I don't know enough about your precise circumstances to advise a particular one of these to try first, but hopefully one of them will work for you.

Update: Based on the knowledge that it's failing when the server reboots with a non-standard VPN client up, it's reasonable to assume that this VPN client could be modifying resolv.conf and removing some of the default entries in an attempt to avoid DNS leakage. I would recommend then making sure that your VPN client is disconnected before shutdown, and possibly still automatically resetting the resolv.conf after boot.

Alternatively, you could try adding a legitimate nameserver of your choice, such as nameserver 8.8.8.8 to the file /etc/resolvconf/resolv.conf.d/head, which might help. I am not sure if this will affect functionality of your VPN or not, or cause DNS leaking, so use it cautiously. Source:
https://ubuntuforums.org/showthread.php?t=2352821&page=2

5
  • 1
    It happens only if Vpn connection was on, before the reboot. I'm using PulseSecure client Feb 1, 2018 at 0:15
  • Are you using NetworkManager?
    – Ketzak
    Feb 1, 2018 at 0:46
  • For VPN I use a separate client Feb 1, 2018 at 0:48
  • Hmm.. I'm not super familiar with that client or service, and can't seem to find any suitable resources on it. I would recommend trying the first approach; running the commands you're already using to fix it immediately after reboot. Additionally, knowing the contents of the broken resolv.conf after reboot could prove helpful.
    – Ketzak
    Feb 1, 2018 at 0:52
  • Not a solution, but could provide you some insight: unix.stackexchange.com/questions/273050/…
    – Ketzak
    Feb 1, 2018 at 1:01
0

It sounds like something (perhaps your PulseSecure client) is overwriting /etc/resolv.conf or /run/resolvconf/resolv.conf the latter by default should contain the following:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.1.1

the former as you know is supposed to be a symbolic link to the latter. You might check these files prior to reboot to insure they are unchanged. or better yet watch them for changes to determine when and why the modification occurs.

1
  • That's the suspicion I had as well, once he mentioned it.
    – Ketzak
    Feb 1, 2018 at 1:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .