mirror of
https://github.com/mageddo/dns-proxy-server.git
synced 2026-04-25 09:25:56 +03:00
[GH-ISSUE #251] Running dns-proxy-server makes docker image builds fail, with cannot resolve host errors #104
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#104
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 (Dec 2, 2022).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/251
What is Happening
What is expected
Docker image builds are not affected.
Either they resolve normally or through dns-proxy-server
Steps to Reproduce
Specs:
@zxzharmlesszxz commented on GitHub (Feb 15, 2023):
UP!
@mageddo commented on GitHub (Feb 23, 2023):
Hey, I wasn't able to reproduce this behavior, What I noticed is that docker caches the DNS server address, so if you start DPS, restart docker, then restart DPS again and it get a new docker container IP then you can get an issue, because docker cached the previous DPS IP and will try to solve names from an IP that is not DPS server anymore. I think there's no much DPS can do in this case.
Can you please confirm if your usecase is something like that or give more details on the steps to reproduce it?
If your usecase is the mentioned, then you can lead with this by fixing a IP address to the DPS container by using
docker run --ip ....Thanks in advance.
@mageddo commented on GitHub (Feb 23, 2023):
@zxzharmlesszxz @SimJoSt
@mageddo commented on GitHub (Feb 23, 2023):
I've noticed that this can be related to this one https://github.com/mageddo/dns-proxy-server/issues/248, if DPS use systemd-resolved instead of the resolv.conf file this issue may disappear
@SimJoSt commented on GitHub (Feb 23, 2023):
We don't restart the containers that much on their own, so I don't think thus would be it. Of course it could be possible.
I'll check that out on the next maintenance.
It will take a few days at least to confirm this is fixes the issue.
@zxzharmlesszxz commented on GitHub (Feb 24, 2023):
It is possible if you run dns-proxy container at the different network than other containers, example:
What's happened?
DNS not resolved!
Example 2:
When your dns-proxy container is running at different than default network,
run build container command, what happens:
Build process doesn't have access to dns-proxy to resolve names
@mageddo commented on GitHub (Feb 25, 2023):
Hey @zxzharmlesszxz , it would be easier to understand the scenario with a minimal reproducible example, focusing on your first example, I tried the below but still works
@mageddo commented on GitHub (Feb 25, 2023):
Created a section at the docs to add more details about that.
@zxzharmlesszxz commented on GitHub (Feb 25, 2023):
It's really working, but can you to try build other docker image with models and npm install when this docker-compose containers will working.
At this situation - dns resolves will be failed
@mageddo commented on GitHub (Feb 25, 2023):
@zxzharmlesszxz Maybe your failing use case is related to this thread? #244 If yes we can migrate this discussion to there
@mageddo commented on GitHub (Feb 28, 2023):
The issue #244 was considered fixed, can you test version 3.5.0 and check if your issue persists? If not we can close this one
@mageddo commented on GitHub (Mar 2, 2023):
Please re-open it if have any updates
@SimJoSt commented on GitHub (Jul 27, 2023):
@mageddo thanks for the debugging, fixing, development and engagement 🙏
I finally got around to checking all the comments, resources and new releases.
As recommended, I got the binary (https://github.com/mageddo/dns-proxy-server/releases/tag/3.15.13-snapshot) instead of the Docker version. After shutting down the Docker version, confirming that it removed its entries from
/etc/resolve.conf, I started it with commands mentioned here: https://mageddo.github.io/dns-proxy-server/3.8/en/1-getting-started/running-it/linux/I could verify it used the
/etc/systemd/resolved.conffile and changed the necessary entries. However, I could not resolve the docker hostnames likenextcloud.dockeranymore. Switching back to the preexisting, not-updated Docker version, resolved the issue.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.
@mageddo commented on GitHub (Jul 27, 2023):
So you are getting issues with to solve docker containers when running the new version, right? Yep, I agree, please open a new issue describing the reproducing steps
@mageddo commented on GitHub (Jul 27, 2023):
@SimJoSt
@SimJoSt commented on GitHub (Jul 29, 2023):
@mageddo I have done so: https://github.com/mageddo/dns-proxy-server/issues/424