starred/dns-proxy-server-mageddo

Fork 0

mirror of https://github.com/mageddo/dns-proxy-server.git synced 2026-04-25 09:25:56 +03:00

[GH-ISSUE #347] Running in a container with DPS_NETWORK feature not working as expected #124

New issue

Closed

opened 2026-02-26 04:34:07 +03:00 by kerem · 8 comments

kerem commented

2026-02-26 04:34:07 +03:00

Owner

Originally created by @Sajito on GitHub (Mar 8, 2023).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/347

Really cool to see this project being actively developed again.

What is Happening

I'm running the dns server in a docker container and want to use the DPS_NETWORK feature. This is my docker-compose.yml.

version: '3.6'

services:
  dns:
    image: defreitas/dns-proxy-server:3.8.1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc:/host/etc
    environment:
      MG_RESOLVCONF: /host/etc/resolv.conf
      MG_DPS_NETWORK: true
      MG_DPS_NETWORK_AUTO_CONNECT: true

When the container is started, the dns server is started listening on the container ip address and the container localhost ip address. Then the server connects it's own container to the dps network. Finally it writes the ip address from the dps network to the resolv.conf.
But because the server is not listening on the dps interface, the dns is not reachable. Have a look at this screenshot. If i'd use the initial ip address as dns server, then everything would be fine.

What is expected

Simply said, I'd only expect the automatic configuration to work. I can think of multiple ways to solve this.

Bind the tcp and udp server to 0.0.0.0 instead of specific interfaces
Start the tcp and udp server after attaching the container to the dps network
Write the initial network ip address into the resolv.conf

Specs

OS: EndeavourOS

Docker Version:

Client:
Version:           23.0.1
API version:       1.42
Go version:        go1.20
Git commit:        a5ee5b1dfc
Built:             Sat Feb 11 13:58:04 2023
OS/Arch:           linux/amd64
Context:           default

Server:
Engine:
  Version:          23.0.1
  API version:      1.42 (minimum version 1.12)
  Go version:       go1.20
  Git commit:       bc3805a0a0
  Built:            Sat Feb 11 13:58:04 2023
  OS/Arch:          linux/amd64
  Experimental:     false
containerd:
  Version:          v1.6.19
  GitCommit:        1e1ea6e986c6c86565bc33d52e34b81b3e2bc71f.m
runc:
  Version:          1.1.4
  GitCommit:        
docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

DPS Version: Running /app/dns-proxy-server --version results in an error (Unmatched argument at index 0: '/app/dns-proxy-server'), but I've specified version 3.8.1 in my docker-compose.yml
The log is pretty short and visible in the screenshot. Hope that's enough.

Originally created by @Sajito on GitHub (Mar 8, 2023). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/347 Really cool to see this project being actively developed again. ### What is Happening I'm running the dns server in a docker container and want to use the DPS_NETWORK feature. This is my `docker-compose.yml`. ```yaml version: '3.6' services: dns: image: defreitas/dns-proxy-server:3.8.1 volumes: - /var/run/docker.sock:/var/run/docker.sock - /etc:/host/etc environment: MG_RESOLVCONF: /host/etc/resolv.conf MG_DPS_NETWORK: true MG_DPS_NETWORK_AUTO_CONNECT: true ``` When the container is started, the dns server is started listening on the container ip address and the container localhost ip address. Then the server connects it's own container to the dps network. Finally it writes the ip address from the dps network to the resolv.conf. But because the server is not listening on the dps interface, the dns is not reachable. Have a look at this screenshot. If i'd use the initial ip address as dns server, then everything would be fine. ![grafik](https://user-images.githubusercontent.com/6151929/223832541-539f1b21-b1b0-4313-9b1f-8ffbd4139578.png) ### What is expected Simply said, I'd only expect the automatic configuration to work. I can think of multiple ways to solve this. - Bind the tcp and udp server to 0.0.0.0 instead of specific interfaces - Start the tcp and udp server *after* attaching the container to the dps network - Write the initial network ip address into the resolv.conf ### Specs - OS: EndeavourOS - Docker Version: ``` Client: Version: 23.0.1 API version: 1.42 Go version: go1.20 Git commit: a5ee5b1dfc Built: Sat Feb 11 13:58:04 2023 OS/Arch: linux/amd64 Context: default Server: Engine: Version: 23.0.1 API version: 1.42 (minimum version 1.12) Go version: go1.20 Git commit: bc3805a0a0 Built: Sat Feb 11 13:58:04 2023 OS/Arch: linux/amd64 Experimental: false containerd: Version: v1.6.19 GitCommit: 1e1ea6e986c6c86565bc33d52e34b81b3e2bc71f.m runc: Version: 1.1.4 GitCommit: docker-init: Version: 0.19.0 GitCommit: de40ad0 ``` - DPS Version: Running `/app/dns-proxy-server --version` results in an error (`Unmatched argument at index 0: '/app/dns-proxy-server'`), but I've specified version 3.8.1 in my docker-compose.yml - The log is pretty short and visible in the screenshot. Hope that's enough.

kerem

2026-02-26 04:34:07 +03:00

closed this issue
added the
bug

waiting-feedback

triage
labels

kerem commented

2026-02-26 04:34:08 +03:00

Author

Owner

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

Hey, thanks, you are are helping a lot here.

DPS Version: Running /app/dns-proxy-server --version results in an error (Unmatched argument at index 0: '/app/dns-proxy-server'), but I've specified version 3.8.1 in my docker-compose.yml

Yep the command to retrieve the version on docker image changed, I'm updating the docs right now

$ docker run --rm  defreitas/dns-proxy-server --version

@mageddo commented on GitHub (Mar 12, 2023): Hey, thanks, you are are helping a lot here. > DPS Version: Running /app/dns-proxy-server --version results in an error (Unmatched argument at index 0: '/app/dns-proxy-server'), but I've specified version 3.8.1 in my docker-compose.yml Yep the command to retrieve the version on docker image changed, I'm updating the docs right now ``` $ docker run --rm defreitas/dns-proxy-server --version ```

kerem commented

2026-02-26 04:34:08 +03:00

Author

Owner

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

DPS is designed to prefer DPS network in all senses when it's available, it works great, I think the root cause here is DPS find 172.157.5.0, 0 is not a valid IP address, will take a look to find out what is hapenning.

@mageddo commented on GitHub (Mar 12, 2023): DPS is designed to prefer DPS network in all senses when it's available, it works great, I think the root cause here is DPS find `172.157.5`**.0**, 0 is not a valid IP address, will take a look to find out what is hapenning.

kerem commented

2026-02-26 04:34:08 +03:00

Author

Owner

@Sajito commented on GitHub (Mar 12, 2023):

When I first saw the IP address ending on .0 I thought the same, but everything worked fine using the IP address. I can use the IP address for anything, even the API of the GUI.
I searched a bit and found this thread on serverfault (https://serverfault.com/questions/10985/is-x-y-z-0-a-valid-ip-address).
Having an IP address ending on .0 seems to be perfectly fine, depending on the subnet. The created dps network is a 172.157.0.0/16 subnet. So from my understanding the IP address 172.157.5.0 should be perfectly fine, as it is for most software involved.

I'm not sure, because I didn't really debug it, but I think the problem is not the IP address. I think the problem here is that the dns server is started before the dps network is created and the container attached.
If I create the dps network manually and attach the container to that network by myself, then the server will start listening on the 172.157.5.0 address. Unfortunately if I do that, then it'll again write a wrong ip address in the resolv.conf file.

Would there be any problems, if the udp and tcp servers were started listening on all interfaces (0.0.0.0), instead of only on specific, detected ip addresses?

@Sajito commented on GitHub (Mar 12, 2023): When I first saw the IP address ending on `.0` I thought the same, but everything worked fine using the IP address. I can use the IP address for anything, even the API of the GUI. I searched a bit and found this thread on serverfault (https://serverfault.com/questions/10985/is-x-y-z-0-a-valid-ip-address). Having an IP address ending on `.0` seems to be perfectly fine, depending on the subnet. The created `dps` network is a `172.157.0.0/16` subnet. So from my understanding the IP address `172.157.5.0` should be perfectly fine, as it is for most software involved. I'm not sure, because I didn't really debug it, but I think the problem is not the IP address. I think the problem here is that the dns server is started before the dps network is created and the container attached. If I create the dps network manually and attach the container to that network by myself, then the server will start listening on the `172.157.5.0` address. Unfortunately if I do that, then it'll again write a wrong ip address in the resolv.conf file. Would there be any problems, if the udp and tcp servers were started listening on all interfaces (0.0.0.0), instead of only on specific, detected ip addresses?

kerem commented

2026-02-26 04:34:08 +03:00

Author

Owner

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

I'm not sure, because I didn't really debug it, but I think the problem is not the IP address. I think the problem here is that the dns server is started before the ~~dps network is created and~~ the container attached.

I think this must be the issue...

Would there be any problems, if the udp and tcp servers were started listening on all interfaces (0.0.0.0), instead of only on specific, detected ip addresses?

Containers won't be able to solve each other because docker won't be able to use this address as a valid DNS server, the container solving will only work at the host.

Despite on this, some feature to choose which interface to use for the OS configuration can be elaborated in the future

@mageddo commented on GitHub (Mar 12, 2023): > I'm not sure, because I didn't really debug it, but I think the problem is not the IP address. I think the problem here is that the dns server is started before the ~~dps network is created and~~ the container attached. I think this must be the issue... > Would there be any problems, if the udp and tcp servers were started listening on all interfaces (0.0.0.0), instead of only on specific, detected ip addresses? Containers won't be able to solve each other because docker won't be able to use this address as a valid DNS server, the container solving will only work at the host. Despite on this, some feature to choose which interface to use for the OS configuration can be elaborated in the future

kerem commented

2026-02-26 04:34:08 +03:00

Author

Owner

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

For now, you can disable defaultDns and set 127.0.0.1 or something like at your /etc/systemd/resolved.conf then run service systemd-resolved restart and run DPS as a docker service.

See configuring systemd-resolved

@mageddo commented on GitHub (Mar 12, 2023): For now, you can disable [defaultDns][1] and set 127.0.0.1 or something like at your `/etc/systemd/resolved.conf` then run `service systemd-resolved restart` and run DPS as a docker service. See [configuring systemd-resolved][2] [1]: http://mageddo.github.io/dns-proxy-server/latest/en/2-features/auto-configuration-as-default-dns/ [2]: https://unix.stackexchange.com/a/588778/117844

kerem commented

2026-02-26 04:34:08 +03:00

Author

Owner

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

Just letting you know MG_RESOLVCONF: /host/etc/resolv.conf is not necessary anymore, see https://github.com/mageddo/dns-proxy-server/pull/323

@mageddo commented on GitHub (Mar 12, 2023): Just letting you know `MG_RESOLVCONF: /host/etc/resolv.conf` is not necessary anymore, see https://github.com/mageddo/dns-proxy-server/pull/323

kerem commented

2026-02-26 04:34:08 +03:00

Author

Owner

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

just relesed 2.12.1, can you give it try @Sajito ?

@mageddo commented on GitHub (Mar 17, 2023): just relesed 2.12.1, can you give it try @Sajito ?

kerem commented

2026-02-26 04:34:08 +03:00

Author

Owner

@Sajito commented on GitHub (Mar 17, 2023):