starred/dns-proxy-server-mageddo
1
0
Fork 0
mirror of https://github.com/mageddo/dns-proxy-server.git synced 2026-04-25 17:35:54 +03:00
Code Issues 10 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #68] DNS Resolution is very slow for container names -- >10 seconds #28

New issue
Closed
opened 2026-02-26 04:33:49 +03:00 by kerem · 10 comments
kerem commented 2026-02-26 04:33:49 +03:00
Owner
Copy link

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

I'm testing out your DNS Proxy Server but it appears to be very slow for docker container hostname resolution. I can resolve Internet hostnames in an instant but container hostname resolution takes over 10 seconds before I start getting replies to my ping requests.

I'm on Ubuntu 16.04.4 LTS if that matters.

Let me know what I can provide to help track down the issue.

Originally created by @ak2766 on GitHub (May 12, 2018). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/68 I'm testing out your DNS Proxy Server but it appears to be very slow for docker container hostname resolution. I can resolve Internet hostnames in an instant but container hostname resolution takes over 10 seconds before I start getting replies to my ping requests. I'm on Ubuntu 16.04.4 LTS if that matters. Let me know what I can provide to help track down the issue.
kerem 2026-02-26 04:33:49 +03:00
  • closed this issue
  • added the
    bug
         label
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

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

@ak2766 Thanks for use DPS

You take 10 seconds in which scenario? by accessing the browser, by running a ping command, nslookup?

I never got any delay in DNS resolution from the browser or nslookup from terminal, but I notice some delay in ping command testing it right now, please confirm your test source, then we can investigate that.

Regards

<!-- gh-comment-id:388561999 --> @mageddo commented on GitHub (May 12, 2018): @ak2766 Thanks for use DPS You take 10 seconds in which scenario? by accessing the browser, by running a `ping` command, `nslookup`? I never got any delay in DNS resolution from the browser or nslookup from terminal, but I notice some delay in ping command testing it right now, please confirm your test source, then we can investigate that. Regards
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

@ak2766 commented on GitHub (May 13, 2018):

Hi Mageddo.

Yes, it happens when I'm sending pings (I did mention in the post above, maybe you missed it).

I've started the dns-proxy-server as follows:

docker run -h dns.mageddo --name dns-proxy-server -p 5380:5380 -v /var/run/docker.sock:/var/run/docker.sock -v /etc/resolv.conf:/etc/resolv.conf -d defreitas/dns-proxy-server

I then started a CentOS image with the hostname pingclient.example.com as follows:
docker run -it --name pingclient -h pingclient.example.com -d centos

I then created an image based on CentOS with bind-utils and net-tools:

cat Dockerfile 
from centos
run yum install -y bind-utils net-tools
cmd ["/bin/bash"]

Then started it:
docker run -it --name pinger -h pinger.example.com -d pinger

I then pinged pingclient from the pinger with the following results:

docker exec -i pinger ping -c4 pingclient.example.com
PING pingclient.example.com (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=2 ttl=64 time=0.062 ms
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=3 ttl=64 time=0.096 ms
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=4 ttl=64 time=0.102 ms

--- pingclient.example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 12044ms
rtt min/avg/max/mdev = 0.043/0.075/0.102/0.026 ms

As you can see, it took 12.044s to send 4 ping most of which was spent waiting for DNS to resolve the name.

If I ping an internet location - www.google.com.au - I get responses very quickly - only 3 seconds as indicated below:

docker exec -i pinger ping -c4 www.google.com.au
PING www.google.com.au (172.217.25.163) 56(84) bytes of data.
64 bytes from syd09s13-in-f163.1e100.net (172.217.25.163): icmp_seq=1 ttl=51 time=20.4 ms
64 bytes from syd09s13-in-f163.1e100.net (172.217.25.163): icmp_seq=2 ttl=51 time=20.8 ms
64 bytes from syd09s13-in-f163.1e100.net (172.217.25.163): icmp_seq=3 ttl=51 time=20.9 ms
64 bytes from syd09s13-in-f163.1e100.net (172.217.25.163): icmp_seq=4 ttl=51 time=21.6 ms

--- www.google.com.au ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 20.408/20.970/21.686/0.472 ms

So, Definitely something odd going on with container name resolution.

<!-- gh-comment-id:388595572 --> @ak2766 commented on GitHub (May 13, 2018): Hi Mageddo. Yes, it happens when I'm sending pings (I did mention in the post above, maybe you missed it). I've started the `dns-proxy-server` as follows: ``` docker run -h dns.mageddo --name dns-proxy-server -p 5380:5380 -v /var/run/docker.sock:/var/run/docker.sock -v /etc/resolv.conf:/etc/resolv.conf -d defreitas/dns-proxy-server ``` I then started a `CentOS` image with the hostname `pingclient.example.com` as follows: ```docker run -it --name pingclient -h pingclient.example.com -d centos``` I then created an image based on `CentOS` with `bind-utils` and `net-tools`: ``` cat Dockerfile from centos run yum install -y bind-utils net-tools cmd ["/bin/bash"] ``` Then started it: ```docker run -it --name pinger -h pinger.example.com -d pinger``` I then pinged `pingclient` from the `pinger` with the following results: ``` docker exec -i pinger ping -c4 pingclient.example.com PING pingclient.example.com (172.17.0.3) 56(84) bytes of data. 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=1 ttl=64 time=0.043 ms 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=2 ttl=64 time=0.062 ms 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=3 ttl=64 time=0.096 ms 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=4 ttl=64 time=0.102 ms --- pingclient.example.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 12044ms rtt min/avg/max/mdev = 0.043/0.075/0.102/0.026 ms ``` As you can see, it took 12.044s to send 4 ping most of which was spent waiting for DNS to resolve the name. If I ping an internet location - `www.google.com.au` - I get responses very quickly - only 3 seconds as indicated below: ``` docker exec -i pinger ping -c4 www.google.com.au PING www.google.com.au (172.217.25.163) 56(84) bytes of data. 64 bytes from syd09s13-in-f163.1e100.net (172.217.25.163): icmp_seq=1 ttl=51 time=20.4 ms 64 bytes from syd09s13-in-f163.1e100.net (172.217.25.163): icmp_seq=2 ttl=51 time=20.8 ms 64 bytes from syd09s13-in-f163.1e100.net (172.217.25.163): icmp_seq=3 ttl=51 time=20.9 ms 64 bytes from syd09s13-in-f163.1e100.net (172.217.25.163): icmp_seq=4 ttl=51 time=21.6 ms --- www.google.com.au ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3004ms rtt min/avg/max/mdev = 20.408/20.970/21.686/0.472 ms ``` So, Definitely something odd going on with container name resolution.
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

@ak2766 commented on GitHub (May 13, 2018):

Interestingly, dig returns results very quickly:

$ docker exec -i pinger dig pingclient.example.com

; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> pingclient.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12692
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;pingclient.example.com.		IN	A

;; ANSWER SECTION:
pingclient.example.com.	0	IN	A	172.17.0.3

;; Query time: 0 msec
;; SERVER: 172.17.0.2#53(172.17.0.2)
;; WHEN: Sun May 13 02:08:12 UTC 2018
;; MSG SIZE  rcvd: 78

Yet, pinging immediately after still results in a long wait before ping replies start coming back:

$ docker exec -i pinger ping -c4 pingclient.example.com
PING pingclient.example.com (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=1 ttl=64 time=0.044 ms
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=2 ttl=64 time=0.042 ms
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=3 ttl=64 time=0.052 ms
64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=4 ttl=64 time=0.082 ms

--- pingclient.example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 12043ms
rtt min/avg/max/mdev = 0.042/0.055/0.082/0.016 ms
<!-- gh-comment-id:388595903 --> @ak2766 commented on GitHub (May 13, 2018): Interestingly, `dig` returns results very quickly: ``` $ docker exec -i pinger dig pingclient.example.com ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> pingclient.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12692 ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;pingclient.example.com. IN A ;; ANSWER SECTION: pingclient.example.com. 0 IN A 172.17.0.3 ;; Query time: 0 msec ;; SERVER: 172.17.0.2#53(172.17.0.2) ;; WHEN: Sun May 13 02:08:12 UTC 2018 ;; MSG SIZE rcvd: 78 ``` Yet, pinging immediately after still results in a long wait before ping replies start coming back: ``` $ docker exec -i pinger ping -c4 pingclient.example.com PING pingclient.example.com (172.17.0.3) 56(84) bytes of data. 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=1 ttl=64 time=0.044 ms 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=2 ttl=64 time=0.042 ms 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=3 ttl=64 time=0.052 ms 64 bytes from 172.17.0.3 (172.17.0.3): icmp_seq=4 ttl=64 time=0.082 ms --- pingclient.example.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 12043ms rtt min/avg/max/mdev = 0.042/0.055/0.082/0.016 ms ```
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

@ak2766 commented on GitHub (May 13, 2018):

For completeness sake, when I ping the IP Address, response is immediate:

docker exec -i pinger ping -c4 172.17.0.3
PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data.
64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.058 ms
64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.064 ms
64 bytes from 172.17.0.3: icmp_seq=3 ttl=64 time=0.127 ms
64 bytes from 172.17.0.3: icmp_seq=4 ttl=64 time=0.109 ms

--- 172.17.0.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3065ms
rtt min/avg/max/mdev = 0.058/0.089/0.127/0.030 ms
<!-- gh-comment-id:388597491 --> @ak2766 commented on GitHub (May 13, 2018): For completeness sake, when I ping the IP Address, response is immediate: ``` docker exec -i pinger ping -c4 172.17.0.3 PING 172.17.0.3 (172.17.0.3) 56(84) bytes of data. 64 bytes from 172.17.0.3: icmp_seq=1 ttl=64 time=0.058 ms 64 bytes from 172.17.0.3: icmp_seq=2 ttl=64 time=0.064 ms 64 bytes from 172.17.0.3: icmp_seq=3 ttl=64 time=0.127 ms 64 bytes from 172.17.0.3: icmp_seq=4 ttl=64 time=0.109 ms --- 172.17.0.3 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3065ms rtt min/avg/max/mdev = 0.058/0.089/0.127/0.030 ms ```
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

@ak2766 commented on GitHub (May 13, 2018):

FYI: I've just repeated the experiment with a user defined network and ping is now super responsive:

I created a user defined network as below:
docker network create dockernet

I then added --network dockernet option as I started the containers above.

This site was instrumental in my experimentation:
User Defined Bridges

Cheers,
ak.

<!-- gh-comment-id:388626620 --> @ak2766 commented on GitHub (May 13, 2018): FYI: I've just repeated the experiment with a user defined network and ping is now super responsive: I created a user defined network as below: `docker network create dockernet` I then added `--network dockernet` option as I started the containers above. This site was instrumental in my experimentation: [User Defined Bridges](https://docs.docker.com/network/bridge/#differences-between-user-defined-bridges-and-the-default-bridge) Cheers, ak.
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

@ak2766 commented on GitHub (May 15, 2018):

Update:

It appears that the fast response is not always guaranteed. Sometimes super fast other times I get that same ~10 second delay before I get my responses.

<!-- gh-comment-id:389328617 --> @ak2766 commented on GitHub (May 15, 2018): Update: It appears that the fast response is not always guaranteed. Sometimes super fast other times I get that same ~10 second delay before I get my responses.
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

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

@ak2766 I think I got it.

Basically when you ping a hostname it will do a second question to DNS server asking for reverse DNS lookup eg. 2.0.18.172.in-addr.arpa., as it doesn't exists, remote server returns an error code, DPS code was with a bug that returns nothing when it receives an error code from remote server then ping timeouts after 10s and keep going.

I will pre-release version 2.5.1 and keep testing.

Thank you very much for your contribution.

<!-- gh-comment-id:389393426 --> @mageddo commented on GitHub (May 16, 2018): @ak2766 I think I got it. Basically when you ping a hostname it will do a second question to DNS server asking for reverse DNS lookup eg. `2.0.18.172.in-addr.arpa.`, as it doesn't exists, remote server returns an error code, DPS code was with a bug that returns nothing when it receives an error code from remote server then ping timeouts after 10s and keep going. I will pre-release version **2.5.1** and keep testing. Thank you very much for your contribution.
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

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

PR

<!-- gh-comment-id:389394311 --> @mageddo commented on GitHub (May 16, 2018): [PR](https://github.com/mageddo/dns-proxy-server/pull/69)
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

@ak2766 commented on GitHub (May 19, 2018):

Thank you very much for your contribution.

Thank you much more for creating a tool that makes my life really easy while getting to know Docker.

<!-- gh-comment-id:390366556 --> @ak2766 commented on GitHub (May 19, 2018): > Thank you very much for your contribution. Thank you much more for creating a tool that makes my life really easy while getting to know Docker.
kerem commented 2026-02-26 04:33:50 +03:00
Author
Owner
Copy link

@ak2766 commented on GitHub (May 19, 2018):

I've been running this peridically (stopping and starting all containers prior to testing):

for u in {1..1000}; do ping -f -c 100 pingclient.example.com 2>&1 | egrep transmitted; done

I haven't seen a number > 2ms.

Solid fix muchly appreciated.

<!-- gh-comment-id:390368693 --> @ak2766 commented on GitHub (May 19, 2018): I've been running this peridically (stopping and starting all containers prior to testing): `for u in {1..1000}; do ping -f -c 100 pingclient.example.com 2>&1 | egrep transmitted; done` I haven't seen a number > 2ms. Solid fix muchly appreciated.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
gh-pages
develop
feat/138_2
feat/629
feat/594
5.9.0
5.9.0-snapshot
5.8.4
5.8.4-snapshot
5.8.3-snapshot
5.8.2-snapshot
5.8.1-snapshot
5.8.0-snapshot
5.7.0-snapshot
5.6.2-snapshot
5.6.1-snapshot
5.6.0-snapshot
5.5.1-snapshot
5.5.0-snapshot
5.4.0-snapshot
5.3.0-snapshot
5.2.0-snapshot
5.1.3-snapshot
5.1.2-snapshot
5.1.0-snapshot
5.0.5-snapshot
5.0.3-snapshot
5.0.2-snapshot
5.0.1-snapshot
5.0.0-snapshot
4.3.0-snapshot
4.2.0-snapshot
4.0.0
4.0.0-snapshot
3.32.7
3.32.7-snapshot
3.32.6
3.32.6-snapshot
3.32.5-snapshot
3.32.4
3.32.4-snapshot
3.32.3
3.32.3-snapshot
3.32.2-snapshot
3.32.1-snapshot
3.32.0-snapshot
3.31.1-snapshot
3.31.0-snapshot
3.30.5-snapshot
3.30.4
3.30.4-snapshot
3.30.3-snapshot
3.30.2-snapshot
3.30.1
3.30.1-snapshot
3.30.0-snapshot
3.29.0-snapshot
3.27.0
3.27.0-snapshot
3.26.0-snapshot
3.25.14
3.25.14-snapshot
3.25.13-snapshot
3.25.12-snapshot
3.25.11
3.25.11-snapshot
3.25.10
3.25.10-snapshot
3.25.9-snapshot
3.25.8-snapshot
3.25.7-snapshot
3.25.6-snapshot
3.25.4-snapshot
3.25.3-snapshot
3.25.2-snapshot
3.25.1-snapshot
3.25.0-snapshot
3.24.2
3.24.2-snapshot
3.24.1
3.24.1-snapshot
3.24.0-snapshot
3.23.0-snapshot
3.22.2-snapshot
3.22.3-snapshot
3.22.1-snapshot
3.21.3-snapshot
3.22.0-snapshot
3.21.2-snapshot
3.21.1-snapshot
3.20.0-snapshot
3.21.0-snapshot
3.19.7-snapshot
3.19.6-snapshot
3.19.5-snapshot
3.19.4-snapshot
3.19.3-snapshot
3.19.2-snapshot
3.19.1
3.19.1-snapshot
3.19.0
3.18.5-snapshot
3.18.4-snapshot
3.18.3-snapshot
3.18.2
3.18.2-snapshot
3.18.1-snapshot
3.18.0-snapshot
3.17.3-snapshot
3.17.2-snapshot
3.17.1-snapshot
3.17.0-snapshot
3.16.3-snapshot
3.16.2-snapshot
3.16.1-snapshot
3.16.0-snapshot
3.15.13-snapshot
3.15.12-snapshot
3.15.11-snapshot
3.15.10-snapshot
3.15.9-snapshot
3.15.8-snapshot
3.15.7-snapshot
3.15.6-snapshot
3.15.5-snapshot
3.15.4-snapshot
3.15.3-snapshot
3.15.2-snapshot
3.15.1-snapshot
3.15.0-snapshot
3.14.5
3.14.4
3.14.3
3.14.3-snapshot
3.14.2-snapshot
3.14.1-snapshot
3.14.0-snapshot
3.13.1
3.13.1-snapshot
3.13.0-snapshot
3.12.1
3.12.0
3.11.0
3.10.2-snapshot
3.10.3-snapshot
3.10.4-snapshot
3.10.5-snapshot
3.10.1-snapshot
3.9.2
3.9.1
3.9.0
3.8.1-last-version-with-quarkus
3.8.1
3.8.0
3.7.0
3.6.0
3.5.3
3.5.2
3.5.0
3.4.0-beta
3.3.0-beta
3.2.5-beta
3.2.4-beta
3.2.3-beta
3.2.2-beta
3.2.1-beta
3.2.0-beta
3.1.7-beta
3.1.6-beta
3.1.5-beta
3.1.4-beta
3.1.3-beta
3.1.2-beta
b-jre-8
3.1.1-beta
3.1.0-beta
3.0.4-beta
3.0.3-beta
3.0.2-beta
3.0.1-beta
v2-golang
2.19.5
2.19.4
2.19.3
2.19.2
2.19.1
2.19.0
2.18.7
2.18.6
2.18.5
2.18.4
2.18.3
2.18.2
2.18.1
2.18.0
2.17.4
2.17.3
2.17.2
2.17.1
2.17.0
2.16.0
2.15.0
2.14.6
2.14.5
2.14.4
2.14.2
2.14.1
2.14.0
2.13.2
2.13.1
2.13.0
2.12.0
2.11.0
2.10.4
2.10.3
2.10.2
2.10.1
2.10.0
2.9.1
2.9.0
2.8.0
2.7.0
2.6.1
2.6.0
2.5.4
2.5.3
2.5.2
2.5.1
2.5.0
2.4.1
2.4.0
2.3.3
2.2.3
2.2.2
2.2.1
2.2.0
2.1.8
2.1.7
2.1.6
2.1.5
2.1.2
2.1.1
2.1.0
2.0.21
2.0.20
2.0.19
2.0.18
2.0.17
2.0.16
2.0.9
2.0.5
2.0.4
v1-nodejs
1.8.1
1.8.0
1.7.7
1.7.6
1.7.5
1.7.4
1.7.3
1.7.2
1.7.1
1.7.0
1.6.9
1.6.8
1.6.7
1.6.6
1.6.5
1.6.4
1.6.3
1.6.2
1.6.1
1.6.0
1.5.0
1.4.0
1.3.5
1.3.4
1.3.3
1.3.2
1.3.1
1.3.0
peteris-version
1.1.4-peteris-version
1.2.0
1.1.3
1.1.2
1.1.1
1.1.0
1.0.1
1.0.0
Labels
Clear labels   
bug

   
confirmed

   
discussion

   
duplicate

   
enhancement

   
feature

   
feature-request

   
not-planned

   
pull-request

Mirrored from GitHub Pull Request

  
secondary-feature

   
stale

   
triage

   
waiting-feedback
No labels
bug
confirmed
discussion
duplicate
enhancement
feature
feature-request
not-planned
pull-request
secondary-feature
stale
triage
waiting-feedback
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#28
No description provided.