I experienced similar problems, for example with adding an extra USB wifi dongle.
First I disabled dnsmasq in networkmanager as described above and I stopped dnsmasq (service dnsmasq stop)
I noticed that when resolving broke during my VPN connecting, the routing table looks slightly different (output of route command).
The name of the Gateway is DD-WRT in the case it does not work and simply 'gateway' when it does work.
The output of this did not change:
nmcli device show wlp1s0 | grep IP4.DNS
It kept showing my router IP.
A workaround to get it to work for a while is to restart systemd-resolvd:
sudo service systemd-resolved restart
Since dnsmasq is out of the equation, it is either systemd-resolvd that is the cause of the issue, or anything changing the routing table.
So this is the only difference I see:
ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default gateway 0.0.0.0 UG 601 0 0
which works.
And this when it does NOT work:
ubuntu@ubuntu-Lenovo-Yoga-2-11:~$ route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default DD-WRT 0.0.0.0 UG 601 0 0 wlp1s0
And the same name difference on the VPN line :
vpn-dns.name gateway 255.255.255.255 UGH 0 0 0 wlp1s0
Who knows what may influence the routing table?
It would be great if we can identify this so a bug report can be filed.
I am getting seriously sick and tired of pursuing all these bugs, but I would like to get them fixed so future users and us will be happy :).
[update]
It seems stopping systemd-resolved may fix this and not negatively impact other stuff. You can try that and let it know if it does break stuff.
I saw when running systemd-resolvd in debug when it broke:
Removing scope on link wlp1s0, protocol llmnr, family AF_INET
Removing scope on link wlp1s0, protocol llmnr, family AF_INET6
Removing scope on link *, protocol dns, family *
To disable:
sudo systemctl disable systemd-resolved.service
I updated the Ubuntu report with suggestions.
[/update]
Add: Note: the bug report :
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624317
has a patch for 17.04 for some issues.
Please check the bug report and if possible test the patch. Thank you!
[update]
Please check the above mentioned bug report, the issue seems to be resolved for 17.10 and with a simple command DNS leakage can be disabled too.
[/update]
I am reproducing section "1.11.2. Configure /etc/resolv.conf file" from my answer Part-I Preinstallation: How to install Oracle 18c (Enterprise Edition) on Ubuntu 18.04?
To display what network interfaces are available in the system, issue the following command:
$ ip link show
Figure-39: The WiFi network adapter wlp5s0 is active, up and running.
Network configuration file /etc/netplan/.yaml
should be checked for configuration details. To display the contents of the file, issue the following command:
$ cat /etc/netplan/01-network-manager-all.yaml
Figure-40: Network Manager file 01-network-manager-all.yaml is not configured yet.
Find out whether /etc/resolv.conf
is a static file or symlink
by the following command:
$ ls -l /etc/resolv.conf
Figure-41: File /etc/resolv.conf is a symlink pointing to stub file 'stub-resolv.conf'.
In fact, @igor, the symlink what you removed from other post was really the link to stub file stub-resolv.conf
.
After severed the symlink between /etc/resolv.conf
and stub-resolv.conf
which carried the nameserver 127.0.0.53
, /etc/resolv.conf
was left alone and it was you who made /etc/resolv.conf
as a static file!
The fact is, @Igor, you were not really offered any solution by that act of severance.
Now, display contents of /etc/resolv.conf
by the command:
$ cat /etc/resolv.conf
Figure-42: The contents of symlink '/etc/resolv.conf' having 127.0.0.53 as nameserver.
The dns shown by /etc/resolv.conf
, is 127.0.0.53
but not the default nameserver configured for dhcp
.
Issue the following command to find out the default dns server:
$ systemd-resolve --status wlp5s0
Figure-43: The default DNS server for WiFi network adapter is 192.168.43.1.
Display contents of /run/systemd/resolve/resolv.conf
, by the command:
$ cat /run/systemd/resolve/resolv.conf
Figure-44: The contents of '/run/systemd/resolve/resolv.conf' indicating default nameserver.
From figure-44, you can observe that /run/systemd/resolve/resolv.conf
is the one which really is carrying the default name server 192.168.43.1
.
Issue the following command to change the symlink /etc/resolv.conf
to point default dns server 192.168.43.1
instead of 127.0.0.53
.
$ sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
$ ls -l /etc/resolv.conf
Figure-45: File /etc/resolv.conf is a symlink pointing to default nameserver.
After setting up sysmlink as shown in figure-45, you must make sure that your Wi-Fi is connected, up and running, by issuing the following command:
$ nmcli device
Figure-45-a: Wi-Fi network interface adapter 'wlp5s0' is connected, up and running.
Conclusion:
Under the circumstances, the symlink is the not only best answer you got but also a decent and acceptable solution.
Best Answer
You can install a package resolvconf, which will modify the way
/etc/resolv.conf
is built up at system boot.You can then create or modify a file
/etc/resolvconf/resolv.conf.d/tail
. If you put in this file a linenameserver 8.8.8.8
, this line will be added at the end of/run/resolvconf/resolv.conf
at boot./etc/resolv.conf
will now be a symbolic link to this file.Post Scriptum:
Almost two years after posting my answer I came across https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/1778946 which explains exactly why merely installing
resolvconf
solved a dns problem I had at the time. I feel I have to share this here.According that bug report, after a pptp VPN goes down,
resolv.conf
is restored with the wrong access rights.ping ubuntu.com
does not work,sudo ping ubuntu.com
does. Installingresolvconf
solved it, because it takes overresolv.conf
, restoring it with correct rights. Changingsystemd-resolve
settings is no solution in this case, since the bug is inppp
. But an alternative, maybe simpler solution issudo chmod a+r /etc/resolv.conf
after VPN down. And this can be automated by putting an executable script in /etc/NetworkManager/dispatcher.d with contents:In all cases the contents of
resolv.conf
do not change. And, yes, I know pptp must be avoided because of security issues, but at the time I thought of it as a good excercise for an ubuntu newbie. I imagined it would work out of the box. Little did I know that it would give me a headache, as diagnosed so well by @intelfx.