[GH-ISSUE #244] Breaks DNS resolution within containers

kerem commented

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

Owner

Originally created by @hydrargyrum on GitHub (Jun 24, 2022).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/244

What is Happening

Without DPS:

% docker run --rm -it alpine nslookup docker.io
[…]

Non-authoritative answer:
Name:   docker.io
Address: 34.206.129.162
Name:   docker.io
Address: 54.145.113.149
[…]
% docker run --rm -it alpine getent hosts docker.io
54.145.113.149    docker.io  docker.io
[…]
% docker run --rm -it debian getent hosts docker.io
52.87.84.72     docker.io
[…]

While DPS is running (wait a few seconds):

% docker run --rm -it alpine nslookup docker.io
nslookup: bad address '172.24.0.2 # dps-entry'
% time docker run --rm -it alpine getent hosts docker.io || echo failed with $?
docker run --rm -it alpine getent hosts docker.io  0,03s user 0,02s system 0% cpu 10,803 total
failed with 2
% time docker run --rm -it debian getent hosts docker.io || echo failed with $?
docker run --rm -it debian getent hosts docker.io  0,02s user 0,03s system 0% cpu 40,797 total
failed with 2

As soon as I quit DPS, containers can resolve hosts again.

What is expected

DNS resolution should work fine in containers regardless of DPS being run.

Steps to Reproduce

I'm using this docker-compose.yml to run DPS:

version: '3'
services:
  dns:
    image: defreitas/dns-proxy-server
    hostname: dns.mageddo
    environment:
      - MG_REGISTER_CONTAINER_NAMES=1
      - MG_RESOLVCONF=/host/etc/resolv.conf
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      #- /etc/resolv.conf:/etc/resolv.conf
      # this is because some app on host will periodically overwrite resolve.conf
      - /etc:/host/etc

Then, docker run --rm -it alpine nslookup docker.io should expose the problem

Specs:

OS: Debian stable
Docker Version: 20.10.5+dfsg1
DPS Version: 2.19.0

Originally created by @hydrargyrum on GitHub (Jun 24, 2022). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/244 ### What is Happening Without DPS: ``` % docker run --rm -it alpine nslookup docker.io […] Non-authoritative answer: Name: docker.io Address: 34.206.129.162 Name: docker.io Address: 54.145.113.149 […] % docker run --rm -it alpine getent hosts docker.io 54.145.113.149 docker.io docker.io […] % docker run --rm -it debian getent hosts docker.io 52.87.84.72 docker.io […] ``` While DPS is running (wait a few seconds): ``` % docker run --rm -it alpine nslookup docker.io nslookup: bad address '172.24.0.2 # dps-entry' % time docker run --rm -it alpine getent hosts docker.io || echo failed with $? docker run --rm -it alpine getent hosts docker.io 0,03s user 0,02s system 0% cpu 10,803 total failed with 2 % time docker run --rm -it debian getent hosts docker.io || echo failed with $? docker run --rm -it debian getent hosts docker.io 0,02s user 0,03s system 0% cpu 40,797 total failed with 2 ``` As soon as I quit DPS, containers can resolve hosts again. ### What is expected DNS resolution should work fine in containers regardless of DPS being run. ### Steps to Reproduce - I'm using this `docker-compose.yml` to run DPS: ```yml version: '3' services: dns: image: defreitas/dns-proxy-server hostname: dns.mageddo environment: - MG_REGISTER_CONTAINER_NAMES=1 - MG_RESOLVCONF=/host/etc/resolv.conf volumes: - /var/run/docker.sock:/var/run/docker.sock #- /etc/resolv.conf:/etc/resolv.conf # this is because some app on host will periodically overwrite resolve.conf - /etc:/host/etc ``` - Then, `docker run --rm -it alpine nslookup docker.io` should expose the problem **Specs:** - OS: Debian stable - Docker Version: `20.10.5+dfsg1` - DPS Version: `2.19.0`

kerem

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

closed this issue
added the
confirmed
label

kerem commented

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

Author

Owner

@sh3bang commented on GitHub (Oct 6, 2022):

I've found the problem .... we should start DNS Proxy within the same Network as any Service that wants to reach the DNS Proxy ;-)

Create a new Network:
docker network create foobar

Start DPS within the Network:

docker run \
--rm \
--network=foobar \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /etc/resolv.conf:/etc/resolv.conf \
defreitas/dns-proxy-server

Test within the Nework:
docker run--rm --network=foobar -it alpine nslookup docker.io

Result:

Server:		127.0.0.11
Address:	127.0.0.11:53

Non-authoritative answer:
Name:	docker.io
Address: 18.210.197.188
Name:	docker.io
Address: 3.228.146.75
Name:	docker.io
Address: 18.206.20.10

Non-authoritative answer:

@sh3bang commented on GitHub (Oct 6, 2022): I've found the problem .... we should start DNS Proxy within the same Network as any Service that wants to reach the DNS Proxy ;-) Create a new Network: `docker network create foobar` Start DPS within the Network: ``` docker run \ --rm \ --network=foobar \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc/resolv.conf:/etc/resolv.conf \ defreitas/dns-proxy-server ``` Test within the Nework: `docker run--rm --network=foobar -it alpine nslookup docker.io` Result: ``` Server: 127.0.0.11 Address: 127.0.0.11:53 Non-authoritative answer: Name: docker.io Address: 18.210.197.188 Name: docker.io Address: 3.228.146.75 Name: docker.io Address: 18.206.20.10 Non-authoritative answer: ```

kerem commented

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

Author

Owner

@71walceli commented on GitHub (Feb 6, 2023):

Well, the last one is a workaround that requires every container to connect to a shared Docker network, which requires invoking containers with given net or declare the external in docker-compose of all my services. I don't really want to make this container be accessible by others, just using it for the convenience of typing hostnames in my browser and having it automatically resolve, not for any other containers to talk to each other.

This is my config for this container, as suggested by the docs:

version: "3"
services:
  docker-containers-dns:
    container_name: docker-containers-dns
    hostname: docker-containers-dns
    image: defreitas/dns-proxy-server
    ports:
      - "53:53"
    #  - 8000:5000/tcp
    #network_mode: host
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/resolv.conf:/etc/resolv.conf

The annoying part is:

$ cat /etc/resolv.conf
# nameserver 1.1.1.1 # dps-comment
# nameserver 8.8.8.8 # dps-comment
nameserver 172.18.0.2 # dps-entry

But I have port 53 published in my config, with which I expect the last entry to point to localhost:53, passing the DNS queries to actual localhost, then, by extension, every other container should be able to connect, right?

That might still break docker isolation, even allowing for leacage of other container records. Then I tried setting it to run with host network mode, like this:

version: "3"
services:
  docker-containers-dns:
    container_name: docker-containers-dns
    hostname: docker-containers-dns
    image: defreitas/dns-proxy-server
    #ports: connented out as it's actually incompatible with host networking.
    #  - "53:53"
    #  - 8000:5000/tcp
    network_mode: host
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/resolv.conf:/etc/resolv.conf

With that, I get the following resolv.conf:

$ cat /etc/resolv.conf
# nameserver 1.1.1.1 # dps-comment
# nameserver 8.8.8.8 # dps-comment
nameserver  # dps-entry

This lets normal DNS work fine, but then mageddo doesn't do its magic, i.e. I can't just resolve any docker container anymore, though Internet access is all good.

Another side effect is:

$ nslookup anything
nslookup: parse of /etc/resolv.conf failed

Then DNS might actually be broken... I'm still stuck! What now?

@71walceli commented on GitHub (Feb 6, 2023): Well, the last one is a workaround that requires every container to connect to a shared Docker network, which requires invoking containers with given net or declare the external in docker-compose of all my services. I don't really want to make this container be accessible by others, just using it for the convenience of typing hostnames in my browser and having it automatically resolve, not for any other containers to talk to each other. This is my config for this container, as suggested by the docs: ``` version: "3" services: docker-containers-dns: container_name: docker-containers-dns hostname: docker-containers-dns image: defreitas/dns-proxy-server ports: - "53:53" # - 8000:5000/tcp #network_mode: host restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock - /etc/resolv.conf:/etc/resolv.conf ``` The annoying part is: ``` $ cat /etc/resolv.conf # nameserver 1.1.1.1 # dps-comment # nameserver 8.8.8.8 # dps-comment nameserver 172.18.0.2 # dps-entry ``` But I have port 53 published in my config, with which I expect the last entry to point to localhost:53, passing the DNS queries to actual localhost, then, by extension, every other container should be able to connect, right? That might still break docker isolation, even allowing for leacage of other container records. Then I tried setting it to run with host network mode, like this: ``` version: "3" services: docker-containers-dns: container_name: docker-containers-dns hostname: docker-containers-dns image: defreitas/dns-proxy-server #ports: connented out as it's actually incompatible with host networking. # - "53:53" # - 8000:5000/tcp network_mode: host restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock - /etc/resolv.conf:/etc/resolv.conf ``` With that, I get the following resolv.conf: ``` $ cat /etc/resolv.conf # nameserver 1.1.1.1 # dps-comment # nameserver 8.8.8.8 # dps-comment nameserver # dps-entry ``` This lets normal DNS work fine, but then mageddo doesn't do its magic, i.e. I can't just resolve any docker container anymore, though Internet access is all good. Another side effect is: ``` $ nslookup anything nslookup: parse of /etc/resolv.conf failed ``` Then DNS might actually be broken... I'm still stuck! What now?

kerem commented

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

Author

Owner

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

Update: deleted that comment as it won't contribute to the discussion

@mageddo commented on GitHub (Feb 25, 2023): **Update**: deleted that comment as it won't contribute to the discussion

kerem commented

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

Author

Owner

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

docker run --rm -it alpine sleep 0.5 && nslookup google.com

After the &&, it runs on the host, not in the container. The shell parses it into 2 commands:

docker run --rm -it alpine sleep 0.5
nslookup google.com

@hydrargyrum commented on GitHub (Feb 25, 2023): > `docker run --rm -it alpine sleep 0.5 && nslookup google.com` After the `&&`, it runs on the host, not in the container. The shell parses it into 2 commands: - `docker run --rm -it alpine sleep 0.5` - `nslookup google.com`

kerem commented

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

Author

Owner

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

@71walceli as you are exposing port 53, it would be better to not volume /etc/resolv.conf and you manually configure it to nameserver 127.0.0.1, actually DPS won't understand that 127.0.0.1 would be a better option on that case, maybe someday?

@mageddo commented on GitHub (Feb 25, 2023): @71walceli as you are exposing port 53, it would be better to not volume `/etc/resolv.conf` and you manually configure it to nameserver `127.0.0.1`, actually DPS won't understand that 127.0.0.1 would be a better option on that case, maybe someday?

kerem commented

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

Author

Owner

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

docker run --rm -it alpine sleep 0.5 && nslookup google.com

After the &&, it runs on the host, not in the container. The shell parses it into 2 commands:

docker run --rm -it alpine sleep 0.5

nslookup google.com

wow, my mistake, so hold on.

@mageddo commented on GitHub (Feb 25, 2023): > > `docker run --rm -it alpine sleep 0.5 && nslookup google.com` > > After the `&&`, it runs on the host, not in the container. The shell parses it into 2 commands: > > * `docker run --rm -it alpine sleep 0.5` > * `nslookup google.com` wow, my mistake, so hold on.

kerem commented

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

Author

Owner

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

Because of docker network isolation, docker-compose up containers runs at one subnet and docker run.. runs containers at other, that's why the containers can't talk with each other and also can't talk with DPS container.

Scenarios where you won't get the issue

Running dps and other containers within the same docker-compose file
Running dps and other containers using docker run ...
As @sh3bang said, run all containers in a same network could fix the issue but it's no the best choice in the case where what you want is the containers accessing DPS as the default DNS, not all containers accessing each other. DPS provides a feature to make all containers containers automatically connect to the same network if you want to.

As @71walceli said, run dps on host mode or something like that should fix the issue but didn't though, I think that's because the poor DPS integration with system-resolved as pointed in https://github.com/mageddo/dns-proxy-server/issues/248 , so I will try to do integration with system-resolved using the right way and see what happens.

Can any of you confirm if you are using system-resolved? Probably yes...

@mageddo commented on GitHub (Feb 25, 2023): Because of docker network isolation, `docker-compose up` containers runs at one subnet and `docker run..` runs containers at other, that's why the containers can't talk with each other and also can't talk with DPS container. Scenarios where you won't get the issue * Running dps and other containers within the same docker-compose file * Running dps and other containers using `docker run ...` * As @sh3bang said, run all containers in a same network could fix the issue but it's no the best choice in the case where what you want is the containers accessing DPS as the default DNS, not all containers accessing each other. DPS [provides a feature][1] to make all containers containers automatically connect to the same network if you want to. As @71walceli said, run dps on host mode or something like that should fix the issue but didn't though, I think that's because the poor DPS integration with `system-resolved` as pointed in https://github.com/mageddo/dns-proxy-server/issues/248 , so I will try to do integration with `system-resolved` using the right way and see what happens. Can any of you confirm if you are using `system-resolved`? Probably yes... [1]: http://mageddo.github.io/dns-proxy-server/latest/en/2-features/dps-network-resolution/

kerem commented

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

Author

Owner

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

By using systemd-resolved instead of overwrite /etc/resolv.conf seems to solve all my issues, so try the following:

docker-compose.yml

version: '2'
services:
  dns:
    image: defreitas/dns-proxy-server:3.2.5-beta
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    network_mode: host

Then try some queries

$ docker run --rm -it alpine nslookup docker.io
docker run --rm -it alpine nslookup docker.io
Server:		172.157.5.1
Address:	172.157.5.1:53

Non-authoritative answer:
Name:	docker.io
Address: 18.206.20.10

Or even

client.yml

version: '2'
services:
  dns-client:
    image: alpine
    command: nslookup host.docker

$ docker-compose -f client.yml up
[+] Running 1/0
 ⠿ Container ex3-dns-1  Created                                                                                                                                                                                                0.0s
Attaching to ex3-dns-1
ex3-dns-1  | Server:            127.0.0.11
ex3-dns-1  | Address:   127.0.0.11:53
ex3-dns-1  | 
ex3-dns-1  | Non-authoritative answer:
ex3-dns-1  | Name:      host.docker
ex3-dns-1  | Address: 172.157.5.1

👋 But first, you need to configure systemd-resolved:

How to configure systemd-resolved:

=> 1 Start a DPS container by using the previous yaml I provided

=> 2 Choose one of the following IPs which will be logged at the server.dns.UDPServerPool m=start ... line

dns-proxy-server-backend-1  | 18:13:38.475 t=           main INF 1 roxyserver.server.dns.UDPServerPool m=start:35 {} Starting UDP server, addresses=/192.168.48.1:53, /172.157.5.1:53, /172.17.0.1:53, /192.168.0.128:53, /127.0.0.1:53

=> 3 Put the chosed IP at the resolved conf file

$ cat /etc/systemd/resolved.conf | grep -E '^DNS='
DNS=172.157.5.1

=> 4 Restarts systemd-resolved

$ sudo service systemd-resolved restart

You can check cat /run/systemd/resolve/resolv.conf to see how the servers are configured, DPS IP must be in the first line.

Done.

Additional information:

If you configure DPS docker service with restart: unless-stopped you will only need to run this process once, DPS will start after every reboot and the IP won't change as the host machine IP is being used.

You can also run DPS without host network mode, like this:

version: '2'
services:
  dns:
    image: defreitas/dns-proxy-server:3.2.5-beta
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - "192.168.0.128:53:53/udp" # this is real network interface local IP, it also can be any docker network IP at host machine
      - "192.168.0.128:53:53/tcp"
      - "127.0.0.1:53:53/udp" # It will work on host machine but in this case systemd-resolved wont use that server for the containers, will use another, the internet will work but they won't be able so to solve other containers, for example.

I will write a feature (#248) to automatically configure systemd-resolved when available at the OS but it will only possible when DPS is not running in a container because systemd-resolved restart is required on the host and I can't do that inside a container.

Wow, I've learned a lot here, can you try it out and give me some feedback please?

Best regards.

@mageddo commented on GitHub (Feb 25, 2023): By using systemd-resolved instead of overwrite `/etc/resolv.conf` seems to solve all my issues, so try the following: docker-compose.yml ```yml version: '2' services: dns: image: defreitas/dns-proxy-server:3.2.5-beta volumes: - /var/run/docker.sock:/var/run/docker.sock network_mode: host ``` Then try some queries ``` $ docker run --rm -it alpine nslookup docker.io docker run --rm -it alpine nslookup docker.io Server: 172.157.5.1 Address: 172.157.5.1:53 Non-authoritative answer: Name: docker.io Address: 18.206.20.10 ``` Or even client.yml ```yaml version: '2' services: dns-client: image: alpine command: nslookup host.docker ``` ```bash $ docker-compose -f client.yml up [+] Running 1/0 ⠿ Container ex3-dns-1 Created 0.0s Attaching to ex3-dns-1 ex3-dns-1 | Server: 127.0.0.11 ex3-dns-1 | Address: 127.0.0.11:53 ex3-dns-1 | ex3-dns-1 | Non-authoritative answer: ex3-dns-1 | Name: host.docker ex3-dns-1 | Address: 172.157.5.1 ``` :wave: But first, you need to configure systemd-resolved: **How to configure systemd-resolved:** => 1 Start a DPS container by using the previous yaml I provided => 2 Choose one of the following IPs which will be logged at the `server.dns.UDPServerPool m=start ... ` line ```bash dns-proxy-server-backend-1 | 18:13:38.475 t= main INF 1 roxyserver.server.dns.UDPServerPool m=start:35 {} Starting UDP server, addresses=/192.168.48.1:53, /172.157.5.1:53, /172.17.0.1:53, /192.168.0.128:53, /127.0.0.1:53 ``` => 3 Put the chosed IP at the resolved conf file ```bash $ cat /etc/systemd/resolved.conf | grep -E '^DNS=' DNS=172.157.5.1 ``` => 4 Restarts systemd-resolved ```bash $ sudo service systemd-resolved restart ``` You can check `cat /run/systemd/resolve/resolv.conf ` to see how the servers are configured, DPS IP must be in the first line. Done. **Additional information:** If you configure DPS docker service with `restart: unless-stopped` you will only need to run this process once, DPS will start after every reboot and the IP won't change as the host machine IP is being used. You can also run DPS without host network mode, like this: ```yaml version: '2' services: dns: image: defreitas/dns-proxy-server:3.2.5-beta volumes: - /var/run/docker.sock:/var/run/docker.sock ports: - "192.168.0.128:53:53/udp" # this is real network interface local IP, it also can be any docker network IP at host machine - "192.168.0.128:53:53/tcp" - "127.0.0.1:53:53/udp" # It will work on host machine but in this case systemd-resolved wont use that server for the containers, will use another, the internet will work but they won't be able so to solve other containers, for example. ``` I will write a feature (#248) to automatically configure `systemd-resolved` when available at the OS but it will only possible when DPS is not running in a container because `systemd-resolved` restart is required on the host and I can't do that inside a container. Wow, I've learned a lot here, can you try it out and give me some feedback please? Best regards.

kerem commented

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

Author

Owner

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

Also will update the running it docs to mention that after the pull request

@mageddo commented on GitHub (Feb 25, 2023): Also will update the running it docs to mention that after the pull request

kerem commented

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

Author

Owner

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

The feature is alive at DPS 3.4, please check it out and give me a feedback if possible. See #321 for some instructions of how to use it, I will update the docs later.

I'm using the following command:

$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
-v /etc/systemd/:/host/etc/systemd --network host \
defreitas/dns-proxy-server:3.4.0-beta

@mageddo commented on GitHub (Feb 26, 2023): The feature is alive at DPS 3.4, please check it out and give me a feedback if possible. See #321 for some instructions of how to use it, I will update the docs later. I'm using the following command: ```bash $ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc/systemd/:/host/etc/systemd --network host \ defreitas/dns-proxy-server:3.4.0-beta ```

kerem commented

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

Author

Owner

@71walceli commented on GitHub (Feb 26, 2023):

Anyway, I resorted to startng it up with following docker-compose.yml. though I'm looking towatd trying @mageddo's proposed workaround.

version: "3"
services:
  mageddo-dns:
    container_name: mageddo-dns
    hostname: mageddo-dns
    image: defreitas/dns-proxy-server
    ports:
      - 53:53/tcp
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./Config/:/app/conf

To set it up only for my host OS, I needed to get its IP by issuing command docker inspect mageddo-dns:

[
    {
        # ...
        "NetworkSettings": {
            # ...
            "Networks": {
                "mageddo_default": {
                    # ...
                    "IPAddress": "172.18.0.2",
                    # ...
                }
            }
        }
    }
]

# ... is other datails about the container, of which there are a lot. One only needs to get the container IP by looking for NetworkSettings > Networks > mageddo_default > IPAddress. If you ran mageddo using docker run ..., it would be NetworkSettings > Networks > bridge > IPAddress.

Then I edited /etc/resolvconf/resolv.conf.d/head and added it's IP, leaving it like this:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 172.18.0.2   # mageddo-dns

So i made /etc/resolv.conf be updated to:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 172.18.0.2   # mageddo-dns
nameserver 1.1.1.1
nameserver 8.8.8.8

This is the way I'm running for now. I thik this still isn't good enough, since Docker containers can't really connect to mageddo, so they might stall for several seconds, but haven't really tested or measured it. Of course, Google and Cloudfrare mane servers come next. Putthng 8.8.8.8 and 1.1.1.1 before mageddo-dns works OK for the Web, but anytime I query any internal domain, an NXDOMAIN error is raised, which causes Linux's resolvconf to stop there, never actually reaching 172.18.0.2

@71walceli commented on GitHub (Feb 26, 2023): Anyway, I resorted to startng it up with following `docker-compose.yml`. though I'm looking towatd trying @mageddo's proposed workaround. ```yml version: "3" services: mageddo-dns: container_name: mageddo-dns hostname: mageddo-dns image: defreitas/dns-proxy-server ports: - 53:53/tcp restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock - ./Config/:/app/conf ``` To set it up only for my host OS, I needed to get its IP by issuing command `docker inspect mageddo-dns`: ```js [ { # ... "NetworkSettings": { # ... "Networks": { "mageddo_default": { # ... "IPAddress": "172.18.0.2", # ... } } } } ] ``` `# ...` is other datails about the container, of which there are a lot. One only needs to get the container IP by looking for `NetworkSettings > Networks > mageddo_default > IPAddress`. If you ran mageddo using `docker run ...`, it would be `NetworkSettings > Networks > bridge > IPAddress`. Then I edited `/etc/resolvconf/resolv.conf.d/head` and added it's IP, leaving it like this: ``` # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 172.18.0.2 # mageddo-dns ``` So i made `/etc/resolv.conf` be updated to: ``` # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 172.18.0.2 # mageddo-dns nameserver 1.1.1.1 nameserver 8.8.8.8 ``` This is the way I'm running for now. I thik this still isn't good enough, since Docker containers can't really connect to mageddo, so they might stall for several seconds, but haven't really tested or measured it. Of course, Google and Cloudfrare mane servers come next. Putthng `8.8.8.8` and `1.1.1.1` before mageddo-dns works OK for the Web, but anytime I query any internal domain, an `NXDOMAIN` error is raised, which causes Linux's resolvconf to stop there, never actually reaching `172.18.0.2`

kerem commented

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

Author

Owner

@71walceli commented on GitHub (Feb 26, 2023):

The feature is alive at DPS 3.4, please check it out and give me a feedback if possible. See #321 for some instructions of how to use it, I will update the docs later.

I'm using the following command:
$ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \
-v /etc/systemd/:/host/etc/systemd --network host \
defreitas/dns-proxy-server:3.4.0-beta

Would you mind explaining how I might help by editing the docs?

@71walceli commented on GitHub (Feb 26, 2023): > The feature is alive at DPS 3.4, please check it out and give me a feedback if possible. See #321 for some instructions of how to use it, I will update the docs later. > > I'm using the following command: > > ```shell > $ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock \ > -v /etc/systemd/:/host/etc/systemd --network host \ > defreitas/dns-proxy-server:3.4.0-beta > ``` Would you mind explaining how I might help by editing the docs?

kerem commented

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

Author

Owner

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

Would you mind explaining how I might help by editing the docs?

You just need to edit the *.md at docs dir, this table needs to be updated for example,

@mageddo commented on GitHub (Feb 26, 2023): > Would you mind explaining how I might help by editing the docs? You just need to edit the *.md at docs dir, [this table needs][1] to be updated for example, [1]: http://mageddo.github.io/dns-proxy-server/latest/en/3-configuration/#environment-variable-configuration

kerem commented

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

Author

Owner

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

Give a try at version 3.4 @71walceli and run DPS as I showed, you probably won't need to manually configure IPs, also all features must work.

I'm not updating docker latest tag as DPS 3 is still in beta, I would say it's more stable than 2.x already, a final release should come shortly.

@mageddo commented on GitHub (Feb 26, 2023): Give a try at version 3.4 @71walceli and run DPS as I showed, you probably won't need to manually configure IPs, also all features must work. I'm not updating docker latest tag as DPS 3 is still in beta, I would say it's more stable than 2.x already, a final release should come shortly.

kerem commented

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

Author

Owner

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

The docs were updated, I'm considering this issue as fixed, if you have any update please re-open it

@mageddo commented on GitHub (Feb 28, 2023): The [docs were updated][1], I'm considering this issue as fixed, if you have any update please re-open it [1]: http://mageddo.github.io/dns-proxy-server/latest/en/1-getting-started/running-it/

kerem referenced this issue

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

[PR #99] [MERGED] #87 Fixing binaries were generated for wrong arch #270

Rows
Columns

[GH-ISSUE #244] Breaks DNS resolution within containers #99

What is Happening

What is expected

Steps to Reproduce