up vote 3 down vote favorite

systemd-resolved is a daemon that, among other things, acts as a DNS server by listening IP address 127.0.0.53 on the local loopback interface.

I would like to let the daemon listen to another interface. My use-case is to expose it to docker containers, so that docker containers share the DNS caching provided by systemd-resolved. I know how to configure the host as a DNS server for docker containers, but at least by default, systemd-resolved rejects these DNS queries because they are not coming from the loopback interface, but from the docker bridge interface.

With dnsmasq (a tool similar to systemd-resolved), I did this by adding listen-address=172.17.0.1 to the configuration file. Unfortunately, I couldn't find a systemd-resolved equivalent.

Since systemd-resolved is the default at least on Ubuntu 18.04, I would like a solution that works in this configuration.

Is there a way to configure which interface systemd-resolved listens on?

share|improve this question
  • 1
    What is your use-case? I mean, why are you employing systemd-resolved as a stub resolver? There are any number of established, purpose-made alternatives, including but not limited to bind, dnsmasq, unbound, etc. Note that this is not a rant or mindless hate on the systemd suite. I'd just like to know what prompted you to pick this particular service. Is there any functionality the others don't offer? – Nubarke May 30 at 15:42
  • My use case is to have docker that "just works" on my machine and on typical people's machine (e.g. my students, as I'm a teacher). I didn't pick systemd-resolved: my distro (Ubuntu) picked it for me when I upgraded (to 18.04). I can uninstall systemd-resolved and re-install dnsmasq (which I had before), but that's a rather intrusive solution, and in particular not a solution I'd recommend lightly to anyone (for example, I tried installing dnsmasq without uninstalling systemd-resolved. My package manager happily accepted and then my machine went berserk eating 100% CPU for nothing ...). – Matthieu Moy May 31 at 8:04
  • 1
    Thanks for the reply. So I guess the question changes from "why did you pick systemd-resolved" to "why did the Ubuntu mantainers pick systemd-resolved". It seems clear that, at the very least, packages dnsmasq and systemd-resolved should have a breaks relationship. And again, why did the distro maintainers make that choice? Seems rather intrusive. – Nubarke Jun 1 at 8:49
up vote 5 down vote
+100

Resolved is not intended nor designed for your use-case, but to provide services in the local loopback, thus the listen address is hardcoded.

share|improve this answer

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.