starred/dns-proxy-server-mageddo

Fork 0

mirror of https://github.com/mageddo/dns-proxy-server.git synced 2026-04-26 01:45:59 +03:00

[GH-ISSUE #70] DNS resolution from inside of container #30

New issue

Closed

opened 2026-02-26 04:33:49 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 04:33:49 +03:00

Owner

Originally created by @ps1x on GitHub (May 17, 2018).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/70

Whenever i start dns-proxy-server with command provided, dns resolution from inside of other containers stops immediately. What can i do here?

UPD: repeating same in clean virtualbox machine i can not reproduce it, however new problem raises:
i can not resolve container A hostname from inside of container B

UPD2: adding this line to /etc/default/docker and restarting docker service changed things, now i am able to resolve docker hostnames, but not external (internet) hostnames like google.
DOCKER_OPTS="--dns 172.2.0.10 --dns 8.8.8.8
Where 172.2.0.10 is ip of image with dns-proxy-server.

Originally created by @ps1x on GitHub (May 17, 2018). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/70 Whenever i start dns-proxy-server with command provided, dns resolution from inside of other containers stops immediately. What can i do here? UPD: repeating same in clean virtualbox machine i can not reproduce it, however new problem raises: i can not resolve container A hostname from inside of container B UPD2: adding this line to /etc/default/docker and restarting docker service changed things, now i am able to resolve docker hostnames, but not external (internet) hostnames like google. `DOCKER_OPTS="--dns 172.2.0.10 --dns 8.8.8.8` Where 172.2.0.10 is ip of image with dns-proxy-server.

kerem closed this issue

2026-02-26 04:33:49 +03:00

kerem commented

2026-02-26 04:33:50 +03:00

Author

Owner

@mageddo commented on GitHub (May 17, 2018):

@ps1x

Whenever i start dns-proxy-server with command provided, dns resolution from inside of other containers stops immediately

Containers that are already running or new containers?

are you using docker-compose to start your containers?
Can you provide full log after simulate the issue?

Regards

@mageddo commented on GitHub (May 17, 2018): @ps1x > Whenever i start dns-proxy-server with command provided, dns resolution from inside of other containers stops immediately Containers that are already running or new containers? * are you using docker-compose to start your containers? * Can you provide full log after simulate the issue? Regards

kerem commented

2026-02-26 04:33:50 +03:00

Author

Owner

@ps1x commented on GitHub (May 17, 2018):

Yes, i'm using docker-compose for dns-proxy-server and for my projects. Docker-compose file for dns-proxy-server:

version: '3.1'

services:
  dns-resolver:
    image: defreitas/dns-proxy-server
    restart: always
    ports:
      - 5380
    volumes:
      - /opt/dns-proxy-server/conf:/app/conf
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/resolv.conf:/etc/resolv.conf

networks:
  shared:
    driver: bridge
    ipam:
      config:
        - subnet: 172.2.0.0/16

First i'm attached to running container and within bash i try to ping google.com (ends with dns timeout) then hostname which was defined in environment variable of another container "test.lol" which succeed. Then i'm exiting container and doing same commands from host machine. Both works.

log.txt

@ps1x commented on GitHub (May 17, 2018): Yes, i'm using docker-compose for dns-proxy-server and for my projects. Docker-compose file for dns-proxy-server: ``` version: '3.1' services: dns-resolver: image: defreitas/dns-proxy-server restart: always ports: - 5380 volumes: - /opt/dns-proxy-server/conf:/app/conf - /var/run/docker.sock:/var/run/docker.sock - /etc/resolv.conf:/etc/resolv.conf networks: shared: driver: bridge ipam: config: - subnet: 172.2.0.0/16 ``` First i'm attached to running container and within bash i try to ping google.com (ends with dns timeout) then hostname which was defined in environment variable of another container "test.lol" which succeed. Then i'm exiting container and doing same commands from host machine. Both works. [log.txt](https://github.com/mageddo/dns-proxy-server/files/2013395/log.txt)

kerem commented

2026-02-26 04:33:50 +03:00

Author

Owner

@mageddo commented on GitHub (May 18, 2018):

Actually DPS has a limitation aside docker: DPS must be started before all containers, containers that starts before won't use DPS as default DNS

version: '3.1'

services:
  dns-resolver:
    image: defreitas/dns-proxy-server:2.5.1
    restart: always
    ports:
      - 5380
    hostname: dns.mageddo.intranet
    container_name: dns-resolver
    volumes:
      - /opt/dns-proxy-server/conf:/app/conf
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/resolv.conf:/etc/resolv.conf
    networks:
      - shared

  linux-1:
    image: alpine:3.7
    command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null'
    container_name: linux-1
    networks:
      - shared

networks:
  shared:
    driver: bridge
    ipam:
      config:
        - subnet: 172.2.0.0/16

Simulating the issue

$ docker-compose up linux-1
$ docker-compose up dns-resolver

$ docker exec -it linux-1 ping dns.mageddo.intranet
ping: unknown host dns.mageddo.intranet
$ docker exec -it linux-1 ping google.com
PING google.com (172.217.29.174) 56(84) bytes of data.
64 bytes from gru10s02-in-f14.1e100.net (172.217.29.174): icmp_seq=1 ttl=48 time=13.1 ms

Starting DPS first don't have any issues

$ docker-compose up dns-resolver
$ docker-compose up linux-1

$ docker exec -it linux-1 ping dns.mageddo.intranet
PING dns.mageddo.intranet (172.2.0.2) 56(84) bytes of data.
64 bytes from dns-resolver.tmp_shared (172.2.0.2): icmp_seq=1 ttl=64 time=0.089 ms
$ docker exec -it linux-1 ping google.com
PING google.com (172.217.29.206) 56(84) bytes of data.
64 bytes from gru10s03-in-f206.1e100.net (172.217.29.206): icmp_seq=1 ttl=48 time=12.2 ms

Workaround
A possible workaround is to all containers mount /etc/resolv.conf as readyonly as soon as DPS starts then DNS resolution will start to work

version: '3.1'

services:
  dns-resolver:
    image: defreitas/dns-proxy-server:2.5.1
    restart: always
    ports:
      - 5380
    hostname: dns.mageddo.intranet
    container_name: dns-resolver
    volumes:
      - /opt/dns-proxy-server/conf:/app/conf
      - /var/run/docker.sock:/var/run/docker.sock
      - /etc/resolv.conf:/etc/resolv.conf
    networks:
      - shared

  linux-1:
    image: alpine:3.7
    command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null'
    container_name: linux-1
    restart: unless-stopped
    volumes:
      - /etc/resolv.conf:/etc/resolv.conf:ro
    networks:
      - shared

networks:
  shared:
    driver: bridge
    ipam:
      config:
        - subnet: 172.2.0.0/16

$ docker-compose up linux-1
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.7/main: temporary error (try again later)

$ docker-compose up dns-resolver

$ docker exec linux-1 ping google.com
PING google.com (172.217.30.78): 56 data bytes
64 bytes from 172.217.30.78: seq=0 ttl=50 time=10.658 ms

docker exec linux-1 ping dns.mageddo.intranet
PING dns.mageddo.intranet (172.2.0.3) 56(84) bytes of data.
64 bytes from 172-2-0-3.lightspeed.dybhfl.sbcglobal.net (172.2.0.3): icmp_seq=1 ttl=64 time=0.193 ms

My /etc/default/docker is the default

# Docker Upstart and SysVinit configuration file

#
# THIS FILE DOES NOT APPLY TO SYSTEMD
#
#   Please see the documentation for "systemd drop-ins":
#   https://docs.docker.com/engine/admin/systemd/
#

# Customize location of Docker binary (especially for development testing).
#DOCKERD="/usr/local/bin/dockerd"

# Use DOCKER_OPTS to modify the daemon startup options.
#DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4"

# If you need Docker to use an HTTP proxy, it can also be specified here.
#export http_proxy="http://127.0.0.1:3128/"

# This is also a handy place to tweak where Docker's temporary files go.
#export DOCKER_TMPDIR="/mnt/bigdrive/docker-tmp"

@mageddo commented on GitHub (May 18, 2018): Actually DPS has a limitation aside docker: DPS must be started before all containers, containers that starts before won't use DPS as default DNS ```yaml version: '3.1' services: dns-resolver: image: defreitas/dns-proxy-server:2.5.1 restart: always ports: - 5380 hostname: dns.mageddo.intranet container_name: dns-resolver volumes: - /opt/dns-proxy-server/conf:/app/conf - /var/run/docker.sock:/var/run/docker.sock - /etc/resolv.conf:/etc/resolv.conf networks: - shared linux-1: image: alpine:3.7 command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null' container_name: linux-1 networks: - shared networks: shared: driver: bridge ipam: config: - subnet: 172.2.0.0/16 ``` Simulating the issue ```bash $ docker-compose up linux-1 $ docker-compose up dns-resolver $ docker exec -it linux-1 ping dns.mageddo.intranet ping: unknown host dns.mageddo.intranet $ docker exec -it linux-1 ping google.com PING google.com (172.217.29.174) 56(84) bytes of data. 64 bytes from gru10s02-in-f14.1e100.net (172.217.29.174): icmp_seq=1 ttl=48 time=13.1 ms ``` Starting DPS first don't have any issues ```bash $ docker-compose up dns-resolver $ docker-compose up linux-1 $ docker exec -it linux-1 ping dns.mageddo.intranet PING dns.mageddo.intranet (172.2.0.2) 56(84) bytes of data. 64 bytes from dns-resolver.tmp_shared (172.2.0.2): icmp_seq=1 ttl=64 time=0.089 ms $ docker exec -it linux-1 ping google.com PING google.com (172.217.29.206) 56(84) bytes of data. 64 bytes from gru10s03-in-f206.1e100.net (172.217.29.206): icmp_seq=1 ttl=48 time=12.2 ms ``` **Workaround** A possible workaround is to all containers mount `/etc/resolv.conf` as readyonly as soon as DPS starts then DNS resolution will start to work ```yaml version: '3.1' services: dns-resolver: image: defreitas/dns-proxy-server:2.5.1 restart: always ports: - 5380 hostname: dns.mageddo.intranet container_name: dns-resolver volumes: - /opt/dns-proxy-server/conf:/app/conf - /var/run/docker.sock:/var/run/docker.sock - /etc/resolv.conf:/etc/resolv.conf networks: - shared linux-1: image: alpine:3.7 command: sh -c 'apk add --update curl iputils bind-tools && tail -f /dev/null' container_name: linux-1 restart: unless-stopped volumes: - /etc/resolv.conf:/etc/resolv.conf:ro networks: - shared networks: shared: driver: bridge ipam: config: - subnet: 172.2.0.0/16 ``` ```bash $ docker-compose up linux-1 fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz ERROR: http://dl-cdn.alpinelinux.org/alpine/v3.7/main: temporary error (try again later) $ docker-compose up dns-resolver $ docker exec linux-1 ping google.com PING google.com (172.217.30.78): 56 data bytes 64 bytes from 172.217.30.78: seq=0 ttl=50 time=10.658 ms docker exec linux-1 ping dns.mageddo.intranet PING dns.mageddo.intranet (172.2.0.3) 56(84) bytes of data. 64 bytes from 172-2-0-3.lightspeed.dybhfl.sbcglobal.net (172.2.0.3): icmp_seq=1 ttl=64 time=0.193 ms ``` My /etc/default/docker is the default ``` # Docker Upstart and SysVinit configuration file # # THIS FILE DOES NOT APPLY TO SYSTEMD # # Please see the documentation for "systemd drop-ins": # https://docs.docker.com/engine/admin/systemd/ # # Customize location of Docker binary (especially for development testing). #DOCKERD="/usr/local/bin/dockerd" # Use DOCKER_OPTS to modify the daemon startup options. #DOCKER_OPTS="--dns 8.8.8.8 --dns 8.8.4.4" # If you need Docker to use an HTTP proxy, it can also be specified here. #export http_proxy="http://127.0.0.1:3128/" # This is also a handy place to tweak where Docker's temporary files go. #export DOCKER_TMPDIR="/mnt/bigdrive/docker-tmp" ```

kerem commented

2026-02-26 04:33:50 +03:00

Author

Owner

@ps1x commented on GitHub (May 18, 2018):

Thanks for quick answer!

@ps1x commented on GitHub (May 18, 2018): Thanks for quick answer!

kerem commented

2026-02-26 04:33:50 +03:00

Author

Owner

@mageddo commented on GitHub (May 18, 2018):