Skip to content

Reenable systemd-resolved stub resolver #4079

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: dev
Choose a base branch
from
Draft

Conversation

agners
Copy link
Member

@agners agners commented May 27, 2025

Enable the systemd-resolved stub resolver and make it available on the hassio host network interface (172.30.32.1). This allows to use systemd-resolved directly from all containers.

Note that this makes /etc/resolv.conf point to the stub resolver running at 127.0.0.53 by default. This stub resolver isn't reachable from within containers. However, Docker does regnize this situation [1] and falls back to the alternate path at /run/systemd/resolve/resolv.conf, which is what /etc/resolv.conf is today. So this should not affect the initial /etc/resolv.conf in containers in practise.

This will however bind to port 53 and affect add-on potentially attempt to use that port. Add-ons should not bind to 127.0.0.53 or the hassio host network (172.30.32.1).

[1] https://github.com/moby/moby/blob/v28.0.4/libnetwork/internal/resolvconf/resolvconf_path.go#L51C32-L51C45

Enable the systemd-resolved stub resolver and make it available on the
hassio host network interface (172.30.32.1). This allows to use
systemd-resolved directly from all containers.

Note that this makes /etc/resolv.conf point to the stub resolver running
at 127.0.0.53 by default. This stub resolver isn't reachable from within
containers. However, Docker does regnize this situation [1] and falls back
to the alternate path at /run/systemd/resolve/resolv.conf, which is what
/etc/resolv.conf is today. So this should not affect the initial
/etc/resolv.conf in containers in practise.

This will however bind to port 53 and affect add-on potentially attempt
to use that port. Add-ons should not bind to 127.0.0.53 or the hassio
host network (172.30.32.1).

[1] https://github.com/moby/moby/blob/v28.0.4/libnetwork/internal/resolvconf/resolvconf_path.go#L51C32-L51C45
@agners
Copy link
Member Author

agners commented May 27, 2025

As mentioned in 3aa7b21, some add-ons bind to port 53 UDP as well as TCP:

There are Add-Ons which try to bind port 53 on all interfaces including
127.0.0.53. Disable the stub resolver to make them continue working. We
don't need the resolver currently anyway.

In a quick test, specifically Adguard explicitly tries to bind to 172.30.32.1, which fails with this change:

2025/05/27 14:54:31.336442 [info] dnsproxy: creating udp server socket addr=172.30.32.1:53
2025/05/27 14:54:31.336458 [info] dnsproxy: listening to udp addr=172.30.32.1:53
2025/05/27 14:54:31.336465 [info] dnsproxy: creating udp server socket addr=127.0.0.1:53
2025/05/27 14:54:31.336477 [info] dnsproxy: listening to udp addr=127.0.0.1:53
2025/05/27 14:54:31.336483 [info] dnsproxy: creating udp server socket addr=[::1]:53
2025/05/27 14:54:31.336494 [info] dnsproxy: listening to udp addr=[::1]:53
...
2025/05/27 14:54:31.336740 [info] dnsproxy: creating tcp server socket addr=172.30.32.1:53
2025/05/27 14:54:31.336769 [info] dnsproxy: warning: binding attempt=1 err="listen tcp 172.30.32.1:53: bind: address already in use"

This got introduced a while back in hassio-addons/addon-adguard-home#168.

Furthermore the dnsmasq add-on tries to claim tcp port 53 too, which fails:

Can't start addon_core_dnsmasq: 500 Server Error for http+docker://localhost/v1.48/containers/9ed8c7922e5eeb1bbabdd228218b39ded02ec92c437fe42367b35211bce73112/start: Internal Server Error ("failed to set up container networking: driver failed programming external connectivity on endpoint addon_core_dnsmasq (241702f3d55491dcd8e7f9e398a6887aebaec43f11cd643b2a4c5bdd0c57ba14): failed to bind host port for 0.0.0.0:53:172.30.33.0:53/tcp: address already in use")

For UDP ports it seems that binding twice works, at least the dnsmasq add-on can be started with UDP port 53 enabled only. It does seem that dnsmasq then takes precedence though 😰 (nslookup homeassistant.local. 172.30.32.1 fails as seemingly dnsmasq processes the request instead of systemd-resolved.

@agners agners added the pinned Prevents from getting marked as stale label Jul 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed pinned Prevents from getting marked as stale
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant