-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Upstreams with Internal Hostname Supplied in /etc/hosts Stopped Working on v0.107.31 #5902
Comments
Hello and thanks for the thorough report. This is most likely because in v0.107.30 we've fixed a long-standing issue where the bootstrap IP addresses weren't used to resolve the hosts in |
Thanks for the quick reply. The extra_hosts directive adds the hostname and IP address combo into the container's /etc/hosts file, so I am kinda sceptical if the information will be available to the Docker host. I did try resolving the private DNS server hostnames name using the AGH container's internal DNS (on 127.0.0.11), but too bad it is not resolvable as well. By any chance AGH will allow resolving of upstream DNS server hostnames using the bootstrap DNS, plus the entries in the /etc/hosts file on the container? That would resolve the problem. Thanks. |
Hi, it seems like you are having a similar problem to what i had. I hope this helps. |
Hi @webocalypse, thanks for your reply. This is because only 1 of the 2 upstream DNS nodes are created in the same Docker Compose stack, where the other node is on a separate Docker host altogether. That was the reason that I have added additional hosts entry via the extra_hosts directive. So at any one time, AGH is only able to resolve the private upstream DNS hostname if the particular node is created in the same Docker Compose stack. As of now, I am thinking the best bet to resolve this is to allow resolution of upstream DNS hostnames from both the /etc/hosts file and the bootstrap DNS. Thanks :) |
It does seem logical that the |
Merge in DNS/adguard-home from 5902-bootstrap-hosts to master Updates #5902. Squashed commit of the following: commit fcc65d3 Merge: 0c336af 1fd6cf1 Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Fri Jun 30 12:29:06 2023 +0300 Merge branch 'master' into 5902-bootstrap-hosts commit 0c336af Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Thu Jun 29 15:40:28 2023 +0300 all: imp & simplify commit 45aae90 Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Wed Jun 28 20:24:43 2023 +0300 all: imp code, docs commit e3dbb5b Merge: a33a8e9 2069edd Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Wed Jun 28 18:27:36 2023 +0300 Merge branch 'master' into 5902-bootstrap-hosts commit a33a8e9 Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Wed Jun 28 13:27:11 2023 +0300 aghos: add type check commit 781a3a2 Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Wed Jun 28 13:09:37 2023 +0300 all: log changes commit 4575368 Merge: 636c440 cf7c12c Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Wed Jun 28 13:08:11 2023 +0300 Merge branch 'master' into 5902-bootstrap-hosts commit 636c440 Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Wed Jun 28 13:06:32 2023 +0300 all: imp tests commit 0eff7a7 Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Mon Jun 26 18:40:22 2023 +0300 dnsforward: imp code commit 7489a30 Author: Eugene Burkov <E.Burkov@AdGuard.COM> Date: Mon Jun 26 17:04:10 2023 +0300 all: resolve upstreams with hosts
@siaush, this should be fixed as of v0.107.33. Can you please check? |
Thanks for the update @ainar-g, I am now running v0.107.33 on both of my Docker hosts. They needed a little modification to work as they were in v0.107.29 - which is to add the AGH container's internal DNS server (127.0.0.11) to the bootstrap DNS list. This is probably because currently I do not include the IP address of the upstream DNS container if they are on the same Compose stack as AGH, in the extra_hosts directive. Only the upstream DNS that are located on the different Compose stack and host are included. Other than that, it is working as it was in v0.107.29 now. Thank you very much :) |
Make AdGuard Home query via dnslow.me-blocky again, broken since AdGuard Home v0.107.30, until now. Reference: - AdguardTeam/AdGuardHome#5902
Prerequisites
I have checked the Wiki and Discussions and found no answer
I have searched other issues and found no duplicates
I want to report a bug and not ask a question
Operating system type
Linux, Other (please mention the version in the description)
CPU architecture
AMD64
Installation
Docker
Setup
On one machine
AdGuard Home version
v0.107.31 and edge
Description
What did you do?
Upgraded AGH from v0.107.29 to v0.107.31, and internal upstream DNS servers specified as internal hostnames in the AGH Upstream DNS servers list stopped working.
I have 2 AGH nodes running on 2 separate Docker hosts, and their settings are synchronised with Adguardhome-Sync.
I also have 2 internal DNS servers nodes, running on 2 Docker hosts, one each on the same Docker host as each of the AGH containers.
My Upstream DNS servers are specified as such in both of the AGH nodes:
The actual IP addresses of
private-upstream-1
andprivate-upstream-2
are specified in thedocker-compose.yml
file for each of the AGH nodes, using theextra_hosts
directive.The reason I did not specify the upstream IP addresses directly in the AGH Upstream DNS is, both of the upstream DNS have different IP address when accessed from different AGH nodes that are hosted on different Docker host.
An example of the
extra_hosts
directive in thedocker-compose.yml
file are:AGH Node 1:
AGH Node 2:
Expected result
Internal upstream DNS specified with internal hostnames should still be reachable from AGH.
This works up until v0.107.29, and stops working on v0.107.31 as well as the edge version.
Actual result
Additional information
Both
private-upstream-1
andprivate-upstream-2
are reachable byping
andnslookup
resolves successfully to the IP addresses specified indocker-compose.yml
from inside the AGH containers.Replacing
private-upstream-1
andprivate-upstream-2
with their actual IP addresses in the Upstream DNS Servers configuration works as well, but not feasible as the settings are synchronised across nodes, and not all IP addresses are accessible from both nodes.Rolling back the containers to v0.107.29 and the issue above goes away.
Thanks!
The text was updated successfully, but these errors were encountered: