I recently installed dnsmasq to act as DNS Server for my local network. dnsmasq listens on port 53 which is already in use by the local DNS stub listener from systemd-resolved.

Just stopping systemd-resolved and then restart it after dnsmasq is running solves this issue. But it returns after a reboot: systemd-resolved is started with preference and dnsmasq will not start because port 53 is already in use.

The first obvious question, I guess, is how do I best make systemd-resolved understand that it should not start the local DNS stub listener and thus keep port 53 for use by dnsmasq?

A more interesting question, however, is how the two services are generally meant to work together. Are they even meant to work side by side or is systemd-resolved just in the way if one's using dnsmasq?

  • 2
    Have you tried just disabling via sudo systemctl disable systemd-resolved? dnsmasq if properly configured should handle the domain resolution I think. – pbhj Jun 6 '17 at 17:57

As of systemd 232 (released in 2017) you can edit /etc/systemd/resolved.conf and add this line:

DNSStubListener=no

This will switch off binding to port 53.

The option is described in more details in the resolved.conf manpage.

You can find the systemd version your system is running with:

systemctl --version
  • Doing this turn of the internet connection – Ravinder Aug 29 at 11:35
  • 1
    @Ravinder: It will disable the systemd DNS server, yes. If your system is configured to use this server then it will look like the Internet connection stops working (because you turned it off). You will need to configure your system to use another DNS server instead. Typically people turn off binding on port 53 because they want to run their own DNS server there instead, so it's not a problem. – Malvineous Aug 30 at 5:59

You can disable systemd-resolved from loading at boot using sudo systemctl disable systemd-resolved.

If you want to run the two together, you can redirect the systemd-resolved to use the localhost as the primary nameserver. This will make sure that all queries are directed to dnsmasq for resolution before hitting the external DNS server. This can be done by adding the line nameserver 127.0.0.1 at the top of your /etc/resolv.conf file. This will also disable systemd's local caching.

You can read more on the Arch Linux wiki. I copied this from there and it covers it quite well.

After this, if you like, you can create a separate /etc/dnsmasq-resolv.conf file for the upstream nameservers and pass it using the -r or --resolv-file option, or add the upstream nameservers to the dnsmasq configuration file and use the -R or --no-resolv option. This way you only have the localhost in your /etc/resolv.conf and everything goes through dnsmasq.

  • 1
    I had to remove my previous comment as I can no longer confirm that this solved the issue. I did read the wiki before asking here, and I already had a resolv.conf file with the localhost nameserver at the top. This didn't help. I then followed your instructions to move out the external nameservers to a second file for dnsmasq. After the first reboot, dnsmasq loaded first so the problem didn't arise. At the second reboot, resolved loaded first so dnsmasq exited with the described error. I'm as far as before. – vic Aug 18 '16 at 9:57
  • 4
    In the dnsmasq unit, put a Before=systemd-resolved in the [Unit] section. That way, dnsmasq will always start first. – Munir Aug 18 '16 at 13:18

Judging from the systemd manpages it's not intended being able to manually disable the stub DNS server. Interestingly I only noticed the described problem after upgrading systemd from 230 to 231.

Disabling systemd-resolved was no option for me because I need it to handle received upstream DNS servers through DHCP.

My solution was making dnsmasq stop systemd-resolved before starting and starting it afterwards again.

I created a drop-in config in /etc/systemd/system/dnsmasq.service.d/resolved-fix.conf:

[Unit]
After=systemd-resolved.service

[Service]
ExecStartPre=/usr/bin/systemctl stop systemd-resolved.service
ExecStartPost=/usr/bin/systemctl start systemd-resolved.service

This appears to be a rather hackish solution but it works.

  • 1
    Hey actually this solution is pretty slick. It is persistent even after package updates because it keeps the original unit file. Nicely done. The following is stated under DNSStubListener in the resolved.conf manual: "Note that the DNS stub listener is turned off implicitly when its listening address and port are already in use." That is why this method works fine I think. – Jonathan Komar Apr 27 '17 at 14:06

There will be an option in systemd version 232 to disable the stub listener. See https://github.com/systemd/systemd/pull/4061.

I just enabled option "bind-interfaces" by removing '#' at the start of the line in /etc/dnsmasq.conf.

I was able to start dnsmasq again:

  • dnsmasq bind DNS port on all interfaces (including 127.0.0.1) port 53,
  • systemd-resolv keeps listening on 127.0.0.53:53

I was pointed to this solution by this discussion resolved: add an option to disable the stub resolver

I solved it this way:

Add or uncomment the following line in /etc/default/dnsmasq:

IGNORE_RESOLVCONF=yes

Create your own resolv file (/etc/resolv.personal) to define nameservers. You can use any nameserver here. I took two from https://www.opennic.org

nameserver 5.132.191.104
nameserver 103.236.162.119

In /etc/dnsmasq.conf add or uncomment the following line:

resolv-file=/etc/resolv.personal

Then restart dnsmasq and disable the default resolver: systemd-resolved.

sudo service dnsmasq restart

sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved

If you're using a default Ubuntu 18.04 setup, this may be caused by a conflict between systemd-resolved (the default DNS server) and dnsmasq. If you installed dnsmasq yourself deliberately because you explicitly wanted it, then one of the other answers to this question, explaining how to disable systemd-resolved, will probably be good for you. If you didn't explicitly install dnsmasq, then it is likely in place because you're using lxd. This might be because you actually use lxd to manage containers, but it's most likely to be because snaps use lxd to protect you when apps are installed. From my perspective, I want to keep dnsmasq (because lxd wants it) but I also want to keep systemd-resolved as the DNS server (because it's what the Ubuntu team chose and I trust them more than myself).

So, this seems to be an lxd problem at heart. If so, the way I fixed it, as per a lxd-users mailing list post, is this:

$ lxc network edit lxdbr0

This will edit your configuration in a terminal editor. It will look something like this:

config:
  ipv4.address: 10.216.134.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "true"
name: lxdbr0
type: bridge

Add three lines to it:

config:
  ipv4.address: 10.216.134.1/24
  ipv4.nat: "true"
  ipv6.address: none
  ipv6.nat: "true"
  raw.dnsmasq: |
    auth-zone=lxd
    dns-loop-detect
name: lxdbr0
type: bridge

and this should cause dnsmasq, which is being run by lxd, to detect DNS loops. This, at least for me, solved the problem and stopped systemd-resolved and dnsmasq using 100% CPU.

I'm not sure why both services are trying to use the same address. Maybe you can arrange them as in my case on Xubuntu 18.04.1, where their configuration is the following:

xy@zq:~$ sudo netstat -tulpn | grep 53
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN      13549/systemd-resol 
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      9632/dnsmasq 

To make systemd-resolved using my dnsmasq I just set:

#/etc/systemd/resolved.conf 
[Resolve]
DNS=127.0.0.1

In my dnsmasq config I set my external nameservers:

#/etc/dnsmasq.conf
nameserver x.x.x.x
nameserver y.y.y.y

After restarting everything:

# sudo systemctl restart systemd-resolved.service
# sudo systemctl restart dnsmasq.service

systemd-resolved will set the default DNS server to dnsmasq in:

#/etc/resolv.conf
nameserver 127.0.0.1

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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