mirror of
https://github.com/mageddo/dns-proxy-server.git
synced 2026-04-25 09:25:56 +03:00
[GH-ISSUE #424] Standalone setup doesn't resolve Docker hosts, after switching from Docker and older version #147
Labels
No labels
bug
confirmed
discussion
duplicate
enhancement
feature
feature-request
not-planned
pull-request
secondary-feature
stale
triage
waiting-feedback
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/dns-proxy-server-mageddo#147
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @SimJoSt on GitHub (Jul 29, 2023).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/424
Continuation from https://github.com/mageddo/dns-proxy-server/issues/251#issuecomment-1653813515
What is Happening / What is expected
host nextcloud.dockerAdditional information
I also tried to install it as a Linux service following the instructions: https://github.com/mageddo/dns-proxy-server/blob/master/docs/content/2-features/installing-as-service/_index.en.md?plain=1#L23
Checking the
--help, I also tried-service=normalinstead of-service=dockerfrom the docs. None of the registered a service.Is there anything obvious I might have missed, switching from Docker to binary?
This problem can be moved to a new issue, I just wanted to document the results here, as I have not been able to get it running to test, if the original issue has been resolved.
Specs
@SimJoSt commented on GitHub (Sep 23, 2023):
@mageddo if you need any additional debugging information, I am happy to provide it. I'm just lost on my own.
@mageddo commented on GitHub (Jul 22, 2024):
Hey @SimJoSt, I tried to reproduce your scenario but wasn't able to get the issue, all worked just fine, some reprodution steps were missing, they can be the cause of the issue, below the steps I assumed you followed.
Be aware that to solve docker containers from they host name, you need to set
"registerContainerNames": truein both versions.I also noticed that one line is missing at your logs and present on the mine at the standalone version, maybe did you have suppress it?
Env
Creating a docker container to be solved
Running the docker version 2.19.0
The config file, same as the default just changed the
"registerContainerNames": trueflagRunning the container and set as the default host DNS server
Solving
Testing the Standalone Version 3.15.13-snapshot
Using the same config file, just changed to the port to 5355
Running DPS
Solving
@github-actions[bot] commented on GitHub (Aug 7, 2024):
This issue is stale because it has been waiting-feedback for 15 days with no activity.
@github-actions[bot] commented on GitHub (Aug 15, 2024):
This issue was closed because it has been inactive for 7 days since being marked as stale, you can reopen it at any time.
@SimJoSt commented on GitHub (Sep 13, 2024):
Thank you @mageddo, I finally got around to overhauling the config and testing a bit more.
As the docs currently recommend using Docker over the standalone version, I decided to stick with it.
I upgraded from
image: ghcr.io/thisisqasim/dns-proxy-server:3.16.1-snapshotto thisdocker-compose.yml:The config is:
Even though there is no port exposed for the container, DNS resolution works fine. Why? Beats me :)
The test shows that port 53 is used, even though it was not opened:
I also added a volume to access the systemd
resolved.conffile:But the following error was not fixable, even when restarting the service:
Sticking to the
resolve.confmethod, the container boots up fine:I stuck with the maximum version of 3.17.2, as all later versions would either through errors or would not advance past this point of booting up.
Version 3.16.1 through 3.17.2 mostly worked without issue and the log would extend like this, resolving the docker container hostnames:
I'm not sure what specifically changed after that, that prevents it from resolving docker host with higher versions.
@SimJoSt commented on GitHub (Dec 17, 2024):
@mageddo can you gauge if the issues I am describing fit the original issue or are a seperate one?
@mageddo commented on GitHub (Dec 17, 2024):
Hey @SimJoSt , are having success using DPS at the latest version despite the warning or what issue are you getting? Can you share the logs?
I suppose your
/etc/systemd/resolved.confis pointing to DPS container IP.Yep, that's just a warning telling you will need to restart systemd-resolved by yourself at the first time you use DPS because systemd-resolved need to be restarted when the config file is changed and DPS inside the container can´t do that.
When using
/etc/resolv.confyou won't need to restart systemd-resolved, people say is better to use systemd-resolved anyway.