Unable to run if systemd-resolved claims port 53

[tmerse]

Hi,
thank you for putting this together.

Running the make deploy part of the install instructions gave me an error that something is blocking port 53.

sudo lsof -Pnl +M -i4 | grep 53 lead to systemd-resolved.service occupying port 53.

I was able to fix the problem by adding the line DNSStubListener=no to /etc/systemd/resolved.conf followed by sudo systemctl restart systemd-resolved.service.

Maybe this could be added to a troubleshooting section, as I think this problem could be rather present these days.

[dstapp]

Hey, thanks for the feedback! Yes, I think this makes sense. In general it should be clear that this will not work if something is already using port 53, but as those systemd features slowly become the standard in many distributions, it might make sense to add it. Can you give more information about what DNSStubListener is for exactly?

[tmerse]

..but as those systemd features slowly become the standard in many distributions, it might make sense to add it

That was my train of thought.

Can you give more information about what DNSStubListener is for exactly?

To be honest, I am not really sure. I just googled and did some cross-reading around the subject. Maybe someone else can tell more about possible consequences and implications.

Taken from systemd-resolved.service:

Additionally, systemd-resolved provides a local DNS stub listener on IP address 127.0.0.53 on the local loopback interface. Programs issuing DNS requests directly, bypassing any local API may be directed to this stub, in order to connect them to systemd-resolved. Note however that it is strongly recommended that local programs use the glibc NSS or bus APIs instead (as described above), as various network resolution concepts (such as link-local addressing, or LLMNR Unicode domains) cannot be mapped to the unicast DNS protocol.

[dstapp]

@tmerse I added a brief note to the README.md mentioning possible implications and linked the manual you referenced. I'm not using anything systemd-based currently so I'm not able to investigate but if someone else has additional feedback, feel free to create a new issue. As this is basically solved now, I'm closing this issue. Thanks again for making this project better :-)

[ricardojlrufino]

Possible alternative:
hashicorp/consul#4155 (comment)

[muzo178]

If I enable DNSStubListener=no in /etc/systemd/resolved.conf, my machine cannot resolve any dns addresses.

When I dry dig I get a ;; reply from unexpected source: 127.0.0.1#53, expected 127.0.0.53#53

Any ideas?

[AaronHirsch]

@muzo178 I just ran into the same issue. Seems like dig always expects the reply to come from a fixed address. Instead of fighting with this issue, I told docker-ddns to bind to other, non-common ports (5353:53, 5353:53/udp). This way, you can keep DNSStubListener untouched and run both DNS resolvers in parallel.

You can then redirect incoming traffic from 53 to 5353 if you wish.

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 53 -j REDIRECT --to-port 5353
iptables -A PREROUTING -t nat -i eth0 -p udp --dport 53 -j REDIRECT --to-port 5353

This way, digging on the host itself should always use the default resolver whereas requests coming from the eth0 interface should use the containerised DNS resolver.

This did the trick.

[muzo178]

Thanks for the help @AaronHirsch.

This is another approach that also does the trick: https://medium.com/@niktrix/getting-rid-of-systemd-resolved-consuming-port-53-605f0234f32f