[GH-ISSUE #251] Running dns-proxy-server makes docker image builds fail, with cannot resolve host errors #104

Closed
opened 2026-02-26 04:34:03 +03:00 by kerem · 16 comments
Owner

Originally created by @SimJoSt on GitHub (Dec 2, 2022).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/251

What is Happening

  • Building docker images with the need to resolve external dependencies throws "cannot resolve host" errors.

What is expected

Docker image builds are not affected.
Either they resolve normally or through dns-proxy-server

Steps to Reproduce

  1. Have a dns-proxy-server running
  2. Start a Docker image build with the need to resolve external dependencies

Specs:

  • OS: Debian 10 Buster
  • Docker Version: 20.10.21
  • DPS Version: 2.19.0
Originally created by @SimJoSt on GitHub (Dec 2, 2022). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/251 ### What is Happening * Building docker images with the need to resolve external dependencies throws "cannot resolve host" errors. ### What is expected Docker image builds are not affected. Either they resolve normally or through dns-proxy-server ### Steps to Reproduce 1. Have a dns-proxy-server running 2. Start a Docker image build with the need to resolve external dependencies **Specs:** - OS: Debian 10 Buster - Docker Version: 20.10.21 - DPS Version: 2.19.0
kerem closed this issue 2026-02-26 04:34:03 +03:00
Author
Owner

@zxzharmlesszxz commented on GitHub (Feb 15, 2023):

UP!

<!-- gh-comment-id:1431340153 --> @zxzharmlesszxz commented on GitHub (Feb 15, 2023): UP!
Author
Owner

@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.

<!-- gh-comment-id:1441196639 --> @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.
Author
Owner

@mageddo commented on GitHub (Feb 23, 2023):

@zxzharmlesszxz @SimJoSt

<!-- gh-comment-id:1441197045 --> @mageddo commented on GitHub (Feb 23, 2023): @zxzharmlesszxz @SimJoSt
Author
Owner

@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

<!-- gh-comment-id:1441234335 --> @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
Author
Owner

@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.

<!-- gh-comment-id:1441501538 --> @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.
Author
Owner

@zxzharmlesszxz commented on GitHub (Feb 24, 2023):

It is possible if you run dns-proxy container at the different network than other containers, example:

  • run dns-proxy at dns network
  • run test container at the test network
    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:
  • DNS-proxy at the different network
  • build process running at the default network
    Build process doesn't have access to dns-proxy to resolve names
<!-- gh-comment-id:1442793183 --> @zxzharmlesszxz commented on GitHub (Feb 24, 2023): It is possible if you run dns-proxy container at the different network than other containers, example: - run dns-proxy at dns network - run test container at the test network 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: - DNS-proxy at the different network - build process running at the default network Build process doesn't have access to dns-proxy to resolve names
Author
Owner

@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

version: '3'
services:
  dps:
    image: defreitas/dns-proxy-server:2.19.0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/resolv.conf:/etc/resolv.conf
    hostname: dns.mageddo
    networks:
      dns:
  nginx:
    image: nginx:1.22
    hostname: nginx.app
    networks:
      test:

networks:
  dns:
  test:

curl -I nginx.app
HTTP/1.1 200 OK
Server: nginx/1.22.1
<!-- gh-comment-id:1445113689 --> @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 ```yml version: '3' services: dps: image: defreitas/dns-proxy-server:2.19.0 volumes: - /var/run/docker.sock:/var/run/docker.sock - /etc/resolv.conf:/etc/resolv.conf hostname: dns.mageddo networks: dns: nginx: image: nginx:1.22 hostname: nginx.app networks: test: networks: dns: test: ``` ```bash curl -I nginx.app HTTP/1.1 200 OK Server: nginx/1.22.1 ```
Author
Owner

@mageddo commented on GitHub (Feb 25, 2023):

Created a section at the docs to add more details about that.

<!-- gh-comment-id:1445120047 --> @mageddo commented on GitHub (Feb 25, 2023): Created a [section][1] at the docs to add more details about that. [1]: http://mageddo.github.io/dns-proxy-server/latest/en/2-features/docker-different-networks-solving/
Author
Owner

@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

<!-- gh-comment-id:1445177883 --> @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
Author
Owner

@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

<!-- gh-comment-id:1445182207 --> @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
Author
Owner

@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

<!-- gh-comment-id:1447510112 --> @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
Author
Owner

@mageddo commented on GitHub (Mar 2, 2023):

Please re-open it if have any updates

<!-- gh-comment-id:1452115767 --> @mageddo commented on GitHub (Mar 2, 2023): Please re-open it if have any updates
Author
Owner

@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.conf file and changed the necessary entries. However, I could not resolve the docker hostnames like nextcloud.docker anymore. 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=normal instead of -service=docker from 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.

<!-- gh-comment-id:1653336050 --> @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.conf` file and changed the necessary entries. However, I could not resolve the docker hostnames like `nextcloud.docker` anymore. 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=normal` instead of `-service=docker` from 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.
Author
Owner

@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

<!-- gh-comment-id:1653813515 --> @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
Author
Owner

@mageddo commented on GitHub (Jul 27, 2023):

@SimJoSt

<!-- gh-comment-id:1653813821 --> @mageddo commented on GitHub (Jul 27, 2023): @SimJoSt
Author
Owner

@SimJoSt commented on GitHub (Jul 29, 2023):

@mageddo I have done so: https://github.com/mageddo/dns-proxy-server/issues/424

<!-- gh-comment-id:1656700001 --> @SimJoSt commented on GitHub (Jul 29, 2023): @mageddo I have done so: https://github.com/mageddo/dns-proxy-server/issues/424
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/dns-proxy-server-mageddo#104
No description provided.