[GH-ISSUE #164] HOSTNAMES env not fully respected #68

New issue

Closed

opened 2026-02-26 04:33:57 +03:00 by kerem · 1 comment

kerem commented

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

Owner

Originally created by @lupujo on GitHub (Oct 10, 2019).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/164

What is Happening

When using the HOSTNAMES env, those are properly resolved by the docker host (when using in /etc/resolv.conf the dns docker IP address) but not by the docker containers (when using in /etc/resolv.conf the 127.0.0.11 IP address)

What is expected

Resolving should be the same from outside and from inside the docker container.

Steps to Reproduce

Set HOSTNAMES for a docker container.
Try to resolve from docker host - works.
Try to resolve from any docker container - does not work.

Originally created by @lupujo on GitHub (Oct 10, 2019). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/164 ### What is Happening When using the HOSTNAMES env, those are properly resolved by the docker host (when using in /etc/resolv.conf the dns docker IP address) but not by the docker containers (when using in /etc/resolv.conf the 127.0.0.11 IP address) ### What is expected Resolving should be the same from outside and from inside the docker container. ### Steps to Reproduce 1. Set HOSTNAMES for a docker container. 2. Try to resolve from docker host - works. 3. Try to resolve from any docker container - does not work.

kerem closed this issue

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

kerem commented

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

Author

Owner

@mageddo commented on GitHub (Nov 3, 2019):

Hello @lupujo, thanks for the report.

I couldn't reproduce your issue, I think it really depends how you're starting DPS and your containers, can you please provide a full example?

Starting DPS

docker run --rm --hostname dns.mageddo \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /etc/resolv.conf:/etc/resolv.conf \
defreitas/dns-proxy-server

Starting my testing container

docker run -e HOSTNAMES=nginx1.intranet --rm --name nginx-1 nginx

Starting and testing HOSTNAMES hosts from another container

docker run --name linux-1 --rm -it alpine sh -c 'apk add --update curl iputils bind-tools; sh'
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
....
/ # nslookup nginx1.intranet
Server:		172.17.0.2
Address:	172.17.0.2#53

Non-authoritative answer:
Name:	nginx1.intranet
Address: 172.17.0.3
Name:	nginx1.intranet
Address: 172.17.0.3

DPS version: 2.18.0

Best regards

@mageddo commented on GitHub (Nov 3, 2019): Hello @lupujo, thanks for the report. I couldn't reproduce your issue, I think it really depends how you're starting DPS and your containers, can you please provide a full example? Starting DPS ```bash docker run --rm --hostname dns.mageddo \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /etc/resolv.conf:/etc/resolv.conf \ defreitas/dns-proxy-server ``` Starting my testing container ```bash docker run -e HOSTNAMES=nginx1.intranet --rm --name nginx-1 nginx ``` Starting and testing `HOSTNAMES` hosts from another container ``` docker run --name linux-1 --rm -it alpine sh -c 'apk add --update curl iputils bind-tools; sh' fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz .... / # nslookup nginx1.intranet Server: 172.17.0.2 Address: 172.17.0.2#53 Non-authoritative answer: Name: nginx1.intranet Address: 172.17.0.3 Name: nginx1.intranet Address: 172.17.0.3 ``` DPS version: 2.18.0 Best regards

kerem referenced this issue

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

[PR #69] [MERGED] Bugfix/68 #253