59

I've recently upgraded to 17.10. When I try to browse to a website, or ping a domain it fails saying the site cannot be resolved.

network-admin shows the contents of /etc/resolv.conf to be nameserver: 127.0.0.53

If I change that to 8.8.8.8 or 208.67.222.222 then everything works. Until I reboot.

Upon reboot or resume, the nameserver is reset to 127.0.0.53.

How do I permanently set the nameserver to something that works?


For systemd fans, if I run systemd-resolve --status I get

Link 3 (wlo1)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

If I follow the advice at this question - DNS keeps resetting after reboot. Ubuntu 17.10 - DNS still fails to resolve.

  • 2
    systemctl stop systemd-resolved and systemctl mask systemd-resolved should do the trick :) – Shayan Aug 22 '19 at 19:13

10 Answers 10

39

You can install a package resolvconf, which will modify the way /etc/resolv.conf is built up at system boot.

sudo apt install resolvconf

You can then create or modify a file /etc/resolvconf/resolv.conf.d/tail. If you put in this file a line nameserver 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.

Although my answer addresses the question in a proper way, indeed a warning should be added that, if you want/need to do this, probably something else is wrong. This was already stated by @intelfx at the time, 127.0.0.53 should work by itself.

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. Installing resolvconf solved it, because it takes over resolv.conf, restoring it with correct rights. Changing systemd-resolve settings is no solution in this case, since the bug is in ppp. But an alternative, maybe simpler solution is sudo 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:

#!/bin/sh
if [[ "$1"="ppp0" && "$2"="vpn-down" ]]; then  
    /bin/chmod a+r /etc/resolv.conf
fi

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.

| improve this answer | |
  • 4
    This works - thank you! Do you know if there's any way to get 127.0.0.53 to work by itself? – Terence Eden Mar 8 '18 at 12:27
  • 1
    I am fairly new to this matter. Just have been trying to get rid of dns problems when switching vpn on/off over the last weeks. You could try sudo dpkg-reconfigure resolvconf. I tried this lately, cleared the tail file, and at first this seems to work. – oscar1919 Mar 8 '18 at 13:31
  • @TerenceEden if you are looking to make 127.0.0.53 to work by itself (as it should), take a look at my answer: askubuntu.com/a/1083843/281191 – intelfx Mar 5 '19 at 14:57
  • 2
    I'll have to show my ignorance here, but what happened to the practice of using the DNS server handed out by the DHCP server on your network?? My firewall (OPNsense) is set up to do that, and I'd really like to have my Ubuntu boxen use the DNS that I choose. Maybe that's what is happening here, but wtf is 127.0.0.53... loopback w/ DNS port # as part of IP addr?! :) – Seamus Jun 8 at 23:42
  • @Seamus nothing happened to that practice. It is widely considered useful to use DNS stub resolvers and cache DNS responses wherever possible. Your provider will have their own DNS servers that point to root DNS servers and cache their responses, then your router (if you use something sane like OpenWrt) will run dnsmasq that points to the ISP's DNS servers and cache their responses, and finally your Linux system will also run a caching DNS resolver that points to the router and caches its responses. 127.0.0.53 is the address of that caching DNS resolver. – intelfx Jul 26 at 22:47
27

The correct solution would be to fix systemd-resolved instead of trying to cure migraine with a guillotine.

It is a nice tool, really, if used properly.

Judging by your systemd-resolve --status output...

Link 3 (wlo1)
      Current Scopes: LLMNR/IPv4 LLMNR/IPv6
       LLMNR setting: yes
MulticastDNS setting: no
      DNSSEC setting: no
    DNSSEC supported: no

...your network manager tool does not communicate per-interface DNS configuration to systemd-resolved.

Recent versions of NetworkManager will detect if /etc/resolv.conf is a symlink to a resolved-generated file (/run/systemd/resolve/*.conf or /usr/lib/systemd/resolv.conf) and if that's the case, communicate with resolved directly.

Alternatively, recent versions of systemd-resolved try to be compatible with the historical resolvconf interface by installing a resolvconf binary that does the right thing.

While either of these two solutions would be preferred, if you are looking for a quick and dirty fix, you can just configure systemd-resolved to use your DNS servers globally:

$ cat /etc/systemd/resolved.conf
<...>
[Resolve]
DNS=8.8.8.8 8.8.4.4
<...>

Then restart systemd-resolved.service or reboot.

| improve this answer | |
  • At least for me this answer doesnt work, using ubuntu 18.04, after change the "DNS" entry it keep usint the 127.0.0.53 – André M. Faria Jan 30 '19 at 19:03
  • 3
    @AndréM.Faria learn how resolved works. 127.0.0.53 is the address of the local caching stub resolver. It forwards DNS requests to whatever upstream DNS servers you specify. – intelfx Jan 31 '19 at 2:53
  • Sometimes you know something and just ignore it, yes you right. – André M. Faria Jan 31 '19 at 11:46
  • 3
    Also good to note here, is that by default systemd-resolved caches DNS responses. While this may be useful sometimes, it can cause problems in some situations. Uncomment the cache=yes line in the config file in the answer and set it to no. – Quentin Skousen Feb 13 '19 at 17:32
  • 1
    what actually causes /etc/resolve.conf (or really, /run/resolvconf/resolv.conf, which the former points to) to be updated? would be nice to know for testing, without a presumed reboot being required. all i can say is that restarting systemd-resolved.service did not seem to do the trick – bbarker Mar 4 '19 at 19:22
10

working within the systemd paradigm add a DNS to a link / device

using ubuntu 17.10+ add a *.network file:

sudo nano /lib/systemd/network/100-somecustom.network:

100-somecustom.network ( 100 can be any number for priority, and it requires the .network file extension ):

[Match]
Name=wlo1 # the device name here

[Network] # add multiple DNS 
DNS=8.8.8.8
DNS=208.67.222.222

Then restart:

sudo service systemd-networkd restart

Also look into:

netplan apply

Then check:

systemd-resolve --status wlo1

From info page info systemd.network :

In addition to /etc/systemd/network, drop-in ".d" directories can be placed in /lib/systemd/network or /run/systemd/network directories. Drop-in files in /etc take precedence over those in /run which in turn take precedence over those in /lib. Drop-in files under any of these directories take precedence over the main netdev file wherever located. (Of course, since /run is temporary and /usr/lib is for vendors, it is unlikely drop-ins should be used in either of those places.)

Another approach disable the DNSStubListener for usage with dnsmasq:

sudo nano /etc/systemd/resolved.conf:

#
DNSStubListener=false

related:

| improve this answer | |
  • Strange is that you stated that the DNSStubListener=false, but the actual commented configuration is DNSStubListener=yes, usually the inverse of the "yes" value is "no" and not "false" who in case of "false" was usually be "true". – André M. Faria Jan 30 '19 at 19:16
  • Your answer to create a file with extension .network didnt worked. – André M. Faria Jan 30 '19 at 19:19
9

I use Lubuntu & Kubuntu 18.04. I was able to overcome the DNS problem in 2 steps:

First step: Install unbound and set it to replace systemd-resolved as Grégoire C shows here.

sudo systemctl disable systemd-resolved
sudo systemctl stop systemd-resolved
sudo systemctl enable unbound-resolvconf
sudo systemctl enable unbound

reboot

Open as root the file /etc/NetworkManager/NetworkManager.conf

(sudo leafpad /etc/NetworkManager/NetworkManager.conf in Lubuntu 18.04 or in Kubuntu 18.04 SUDO_EDITOR=kate sudoedit /etc/NetworkManager/NetworkManager.conf)

and below [main] put this line:

dns=unbound

reboot again

Second step: If after the reboot the problem is still not solved, as it was in my case, start the file manager as root, go to /etc, delete resolv.conf and create a new resolv.conf. Leave it empty and reboot the OS. In my case after this reboot the problem disappeared.

In Kubuntu 18.04 you can't start Dolphin as root, so you can first go to /etc and open the terminal from there, then type sudo su and press Enter to use it as root and then delete resolv.conf with the command rm resolv.conf. Then you can create a new empty file on your desktop, name it resolv.conf and open a terminal from there. Use the sudo su command to enter the root mode for the terminal and then copy the new resolv.conf from your desktop to /etc with the command cp resolv.conf /etc.

I have to add that I did not try to do the second step before installing unbound, so the next time I will do so, just to see if it will be enough or not.

| improve this answer | |
  • Why not just edit it as root and delete the contents? – Ballie Aug 8 '18 at 10:09
  • @Ballie I have tried this at first, but it did not help. Also the original resolv.conf from /etc was shown as some kind of a shortcut, which is not normal, I think. This is why I decided to delete it and recreate it by creating a new empty file and naming it resolv.conf. And it worked. By this reason I wrote above that the next time I have to reinstall the OS, I will try to do this first, without doing the "first step" - to see if it would be enough. But the original resolv.conf in /etc needs to be removed and recreated anyway - about this I am sure. – user186598 Aug 9 '18 at 20:35
  • 1
    I have just disabled systemd-resolved.service and removed the link of resolv.conf and created one manually, and it worked! – André M. Faria Jan 30 '19 at 19:32
2

This is how I change my dns record on the interface configuration.

$ vi /etc/netplan/50-cloud-init.yaml

Change name server addresses, previously it was .4 then I changed it to .3:

...
            nameservers:
                addresses:
                - 192.168.1.3
...

Save the configuration and then apply the configuration:

$ sudo netplan apply

After that restart the resolvectl service.

$ sudo systemctl restart systemd-resolved.service

For notes: I did reboot the server and changes that I made still intact. I use resolvctl dns command to verify the dns record.

| improve this answer | |
  • This is actually the correct answer. I'm surprised it's not the accepted one. – Toumal Apr 9 '19 at 15:17
1

Maybe a bit late, but I ran into this problem. I do have to admit that I have been manually configuring my network settings via cli before and not via the inbuilt networkmanager. I run ubuntu 18.04.

So after I disabled and then re-enabled systemd.resolved.service, this erratic behaviour of randomly losing my DNS configuration was solved for me.

systemctl disable systemd.resolved.service
reboot

after reboot:

systemctl enable systemd.resolved.service
reboot

I am a relatively fresh Linux user so there must be someone that can explain the hows and why's of why this would have worked for me, but it seemed worth to mention if it can help others.

| improve this answer | |
  • Sry to disappoint, but there must be something you did in-between that actually fixed the problem. The operations you are suggesting here can only leave the system as it was. – tishma Sep 7 '19 at 14:50
  • To my surprise, this solution which I originally saw here, actually removed 127.0.0.53 from my /etc/resolv.conf. But it was just temporary. After a reboot the issue reappeared. – Omid Jun 23 at 5:02
0

Had some issues with NordVPN so decided to add to this.

Findings:
NordVPN sets /run/systemd/resolve/resolv.conf DNS settings when connecting.
NordVPN removes all DNS settings from /run/systemd/resolve/resolv.conf when disconnecting.
This causes DNS server to no longer work (since there isn't one set).

The system needs a reboot to set it back to anything at all. A standard restart of the service (sudo systemctl restart systemd-resolved.service) does not work.

The solution to work around this:

sudo apt install resolvconf

Head over to /etc/resolvconf/resolv.conf.d/

cd /etc/resolvconf/resolv.conf.d/
sudo nano tail

Add nameservers

nameserver 1.1.1.1
nameserver 1.0.0.1

Check following places for nameservers that could have been set:

/run/resolvconf/interface/original.resolvconf
/run/resolvconf/interface/systemd-resolved
/etc/resolvconf/resolv.conf.d/tail
/etc/resolvconf/resolv.conf.d/head
/etc/systemd/resolved.conf
/run/systemd/resolve/resolv.conf
/run/systemd/resolve/stub-resolv.conf

Test which DNS servers are being used with:

nslookup google.com

Server:         1.1.1.1
Address:        1.1.1.1#53
| improve this answer | |
0

I'm using Ubuntu 18.04 LTS. I don't know how my OS came into this problem in a sudden while my DNS had been working well for months. Here is my solution:

Install resolvconf

$ sudo apt install resolvconf

Find the source of /etc/resolv.conf.

$ ls -al /etc/resolv.conf shows that /etc/resolv.conf is a symbolic link of /run/resolvconf/resolv.conf

And I found that: This file /run/resolvconf/resolv.conf is composed of:

/etc/resolvconf/resolv.conf.d/head
/run/resolvconf/interface/systemd-resolved
/etc/resolvconf/resolv.conf.d/tail

$ cat /run/resolvconf/interface/systemd-resolved shows nameserver 127.0.0.53, which would be reset after reboot.

Add DNS

It seems that nameserver <my DNS> needs to be in front of nameserver 127.0.0.53 so that it could work.

So I add nameserver <my DNS> at the end of /etc/resolvconf/resolv.conf.d/head.

Update resolvconf

$ sudo resolvconf -u

| improve this answer | |
-1

When using dhcp name resolution works as expected in Ubuntu. The problems begin when you want to go static. cat /etc/resolv.conf will show that yor dns is 127.0.0.53 and not the ones you have in /etc/netplan/.yaml file. To fix this you need to remove the /etc/resolve.conf link and create a new one pointing to /run/resolve/resolve.conf

| improve this answer | |
  • Please, edit your answer and fix some formatting... – ThunderBird Oct 10 '18 at 9:24
-2

This required some playing around with. After I updated the setting, I rebooted. Use:

ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

/etc/systemd/resolved.conf
DNS=8.8.8.8
Cache=no

System resolved failed
systemctl stop systemd-resolved
systemctl disable systemd-resolved

When Comment out the "request" for

# domain-name, domain-name-servers, domain-search, host-name,

Add this line to your /etc/dhcp/dhclient.conf:

 supersede domain-name "cwillenterprise.com";

Edit config file and add entry. Additional will not replace.

Add entries to /etc/resolvconf/resolv.conf.d/tail

nameserver 8.8.8.8
search "cwillenterprise.com"

Run to implement changes

resolvconf -u
| improve this answer | |
  • 1
    Welcome to Ask Ubuntu! Please edit your answer to use code formatting for the code that should be entered in files or terminal. Do not prepend # to “comments” to the code – it means header in Markdown. Please always check the preview of your post before sending it. – Melebius Mar 5 '19 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.