I'm using a local BIND9 server to host some local dns records. When trying to dig for a local domain name I can't find it if I don't explicitly tell dig to use my local BIND9 server.

user@heimdal:~$ dig +short heimdal.lan.se
user@heimdal:~$ dig +short @ heimdal.lan.se

Ubuntu 17.04 and systemd-resolved are used. This is the content of my /etc/resolved

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.


And the output from systemd-resolve --status

         DNS Servers:
          DNSSEC NTA: 10.in-addr.arpa

The DNS Servers section does seem to have rightfully configured as the main DNS server (my local BIND9 instance). I can't understand why it's not used ... ?

  • I remember something along the lines of how systemd uses Google DNS as a fallback...
    – William
    Feb 17, 2018 at 16:18
  • What is systemd-resolve heimdal.lan.se telling?
    – Bigon
    Feb 19, 2018 at 19:47

5 Answers 5


So, changing my wired eth0 interface to be managed solved this issue for me.

Changing ifupdown to managed=true in /etc/NetworkManager/NetworkManager.conf


Then restart NetworkManager

sudo systemctl restart NetworkManager

After this it works flawlessly..

This was not 100%. I also applied theses changes to try and kill resolver

sudo service resolvconf disable-updates
sudo update-rc.d resolvconf disable
sudo service resolvconf stop

Big thanks to this blog post regarding the subject: https://ohthehugemanatee.org/blog/2018/01/25/my-war-on-systemd-resolved/ (if unavailable use https://github.com/ohthehugemanatee/ohthehugemanatee.org/blob/main/content/blog/source/2018-01-25-my-war-on-systemd-resolved.markdown)

Lets pray this works.. This whole systemd-resolve business is just so ugly.

  • Late comment but systemd-networkd related another thing would be to check if the eth0 or enX device has a *.network file in ` /lib/systemd/network/` see info systemd-networkd and info systemd.network and info resolved.conf
    – jmunsch
    Aug 26, 2018 at 4:46
  • Just a simple restart of the NetworkManager service solved the issue that DNS update on my Wifi interface didn't reflect. I feared that I might have to restart but this worked.
    – pavi2410
    Sep 6, 2023 at 11:51

My guess is that your systemd-resolved service is configured correctly, but it never gets to see the request. The .local domain is treated specially by systems running mDNS. avahi-daemon, which provides mDNS/DNS-SD services (aka "Bonjour" on Apple products) can be configured to take precedence over DNS during name resolution; it appears that Ubuntu does this.

There are a few options that you could choose from:

  1. Rename your .local domain to something different (possibly .internal or .lan). This may be the easiest to do in practice because you just have to change a couple of things on your DNS server, and it works best with Avahi. I would recommend this method.

  2. Alter your /etc/nsswitch.conf file by putting the dns entry in front of the mdns entries.

  3. Alter Avahi's configuration to change the mDNS domain from .local to something else by editing /etc/avahi/avahi-daemon.conf and changing (or adding) domain-name=.something (located in the [server] section). You'll need to do this on every computer that uses mDNS so they still work together.

  • I'm sorry to say that I obfuscated the real domain here. It's not a .local domain. The top domain is actually .se. I will however follow up on your lead and check the content of nsswitch. Sorry for any confusion
    – Civing
    Feb 19, 2018 at 19:11
  • Thanks for this answer - could you point me in the right direction for how to "rename my .local domain"? Is there a command or interface for that? Oct 8, 2020 at 19:59
  • Simply right! Thanks a lot. I had the same problem on MacOS with .local domains so I switched to .lan. But now I tried to use automountfs with hostnames and had no clue that here (without a domain ending) the exact same problem occures. Change my mountpoint to server.lan and everything is running fine !
    – Michael P
    Aug 2, 2021 at 11:29

Seems this would be better as a comment, but not enough reputation....

Civing's self-answer was most along the lines of what I wanted.

I also had to add dns=none to the [main] section of /etc/NetworkManager/NetworkManager.conf, so it looks like this:


I have just updated to xubuntu 18.04, from 14.04, and I have a LAN that's older than that, with many little adjustments accrued over the years. So I want my DNS to do what I want (yes, I have purchased many copies of Cricket Lius's book over the years, starting with the second edition).

As an aside, I had previously been adding the DNS resolving information I want to see to the file /etc/resolvconf/resolv.conf.d/head.

In a nutshell, once I had a working /etc/resolv.conf, as root:

cat /etc/resolv.conf >> /etc/resolvconf/resolv.conf.d/head

But now, I just edit /etc/resolv.conf directly, and it stays put. Visitors to my LAN, who are using systemd/resolvconf, are SOOL. They do not exist.

Reading man 8 resolvconf helped. A lot. I did not follow the instructions for putting things where the ifup program could find them. Mostly because there's a whole superstructure in the GUI that was already being ignored by whatever was done during the upgrade. That seems to be a bigger issue (WTF, Ubuntu?).

So this is fugly, and there is still the issue that what I had (long ago) entered into the network control panel GUI was not being obeyed by the newly-upgraded system, but that's a totally different question, once I figure out how to ask it.


For me, running a recently installed 18.04, I made the first change cited by @Civing:


then, noticing that /etc/resolv.conf was always pointing stub-resolv.conf and that a reasonable resolv.conf with the proper LAN DNS server was being generated, changed the symlink:

/etc/resolv.conf -> /run/systemd/resolve/resolv.conf

and then local all hostnames resolved via ping.

It remains to be seen how long this keeps working.

When I initially installed, wireless network setup failed, and I can't help but wonder if the installation left /etc/resolv.conf in this initial state.

So, one suggestion is to look at what resolved is generating; you may have a working basis already.


I was using Ubuntu 18, and I'm more used to debian and centOS. Cue confusion.

resolve.conf said it's using systemd-resolved ok...

systemd shows global and per-link settings ok...

research shows that may mean it's using netplan

So, open up /etc/netplan/01-network-manager-all.yaml, and it says...renderer: NetworkManager

Turns out NetworkManager is in the gui, and a way to enable per-link settings. But...you can install nmcli and configure this sucker on the command line....

I hope this helped someone.

  • It would maybe help a lot more if you could elaborate if renderer: NetworkManager is what it should be or if not what it should be changed to ;) Jul 19, 2021 at 10:32
  • 1
    You could change it to networkd. But instead, I used nmcli to modify the settings of NetworkManager. My goal was not to change the system setup but find where dns settings could be changed.
    – Dan
    Jul 20, 2021 at 15:16
  • Ah okay, thank you for your reply! Jul 20, 2021 at 15:22

You must log in to answer this question.

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