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... Feb 17 '18 at 16:18
  • What is systemd-resolve heimdal.lan.se telling?
    – Bigon
    Feb 19 '18 at 19:47

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/

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 '18 at 4:46

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 '18 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 '20 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 '21 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 '21 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 '21 at 15:16
  • Ah okay, thank you for your reply! Jul 20 '21 at 15:22

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.