You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using AdGuard Home on Docker with the userland-proxy (e.g. when running AdGuardHome with Docker Swarm in host mode) on a system with resolved creates an issue with ports already used by resolved's DNSStub:
resolved will bind the DNSStub to 127.0.0.53:53 (although only if no other service binds to the port beforehand)
docker-proxy will later try to bind to *:53 which creates a conflict with resolved
Consequently, the AdGuardHome container will not start properly.
Proposed Solution
The most straightforward solution is to disable the DNSStub via a setting in resolved.conf, (See resolved.conf(5)) by setting DNSStubListener=no in /etc/systemd/resolved.conf. This way, resolved will not listen on port 53 anymore and AdGuardHome can listen on port 53 on the host interfaces.
I would suggest to update the documentation in the Wiki accordingly to make users aware of this potential (although very particular) problem when using AdGuardHome on a system with resolved in host mode.
Alternatives Considered
There are a number of "alternatives" which might be considered but create substantial issues of their own:
Disable systemd-resolved: local DNS resolution might suffer (not work at all)
Don't use host mode for the AdGuardHome container: In this case, AdGuard can't see the originating IP which makes the query log less useful in case of problems.
Bind the docker-proxy only to 0.0.0.0:53 and not to *:53: it could well be that the userland-proxy in docker or the underlying Go code has an error here, however fixing that could be quite tedious. The process is started with 0.0.0.0:53 but then binds to *:53 nevertheless. On the other hand, resolved explicitly creates the DNSStub to allow other services binding to 0.0.0.0:53 (See here for a lengthy discussion).
The text was updated successfully, but these errors were encountered:
Problem Description
Using AdGuard Home on Docker with the userland-proxy (e.g. when running AdGuardHome with Docker Swarm in
host
mode) on a system withresolved
creates an issue with ports already used byresolved
's DNSStub:resolved
will bind the DNSStub to127.0.0.53:53
(although only if no other service binds to the port beforehand)docker-proxy
will later try to bind to*:53
which creates a conflict withresolved
Consequently, the AdGuardHome container will not start properly.
Proposed Solution
The most straightforward solution is to disable the
DNSStub
via a setting inresolved.conf
, (Seeresolved.conf(5)
) by settingDNSStubListener=no
in/etc/systemd/resolved.conf
. This way,resolved
will not listen on port 53 anymore and AdGuardHome can listen on port53
on the host interfaces.I would suggest to update the documentation in the Wiki accordingly to make users aware of this potential (although very particular) problem when using AdGuardHome on a system with
resolved
inhost
mode.Alternatives Considered
There are a number of "alternatives" which might be considered but create substantial issues of their own:
systemd-resolved
: local DNS resolution might suffer (not work at all)host
mode for the AdGuardHome container: In this case, AdGuard can't see the originating IP which makes the query log less useful in case of problems.0.0.0.0:53
and not to*:53
: it could well be that the userland-proxy in docker or the underlyingGo
code has an error here, however fixing that could be quite tedious. The process is started with0.0.0.0:53
but then binds to*:53
nevertheless. On the other hand,resolved
explicitly creates the DNSStub to allow other services binding to0.0.0.0:53
(See here for a lengthy discussion).The text was updated successfully, but these errors were encountered: