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 #256] DNS slow for container names when not connected to the internet #103

New issue

Closed

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

kerem commented

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

Owner

Originally created by @addshore on GitHub (Jan 12, 2023).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/256

Downstream ticket is https://phabricator.wikimedia.org/T326735

What is Happening

This issue occurs while trying to resolve names that are not configured in the dns-proxy-server

When connected to the internet all appears to happen as normal, the resolution falls back to a public dns server like 8.8.8.8, and fails quickly

dps_1                                  | 2023/01/11 15:33:53.883025 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=af63dcc644 status=bad-code, name=mysql., rcode=3, err=status=invalid-answer-name, name=mysql., rcode=3
dps_1                                  | 2023/01/11 15:33:53.883053 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=af63dcc644 status=complete, name=mysql., res=3

When not connected to the internet however the resolution still falls back to a public dns server, but that is not accessible and takes many seconds to timeout

dps_1                                  | 2023/01/11 15:34:10.499217 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=708a0ff26e status=no-answer, question=mysql., server=8.8.8.8, err=%!s(MISSING)
dps_1                                  | 2023/01/11 15:34:10.499271 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=708a0ff26e status=complete, name=mysql., res=-1
dps_1                                  | 2023/01/11 15:34:10.499365 ERROR f=dns.go:59 pkg=main m=handleQuestion uuid=708a0ff26e status=complete, question={Name:mysql. Qtype:1 Qclass:1}, answers=[]
dps_1                                  | Not solver for the question mysql.

What is expected

I would expect one of the following:

names such as mysql would never make their way to the public DNS server as part of their resolution
timeouts for any public DNS lookups would happen much quicker

Steps to Reproduce

Currently using the defreitas/dns-proxy-server:2.19.0 docker image

I can try to create a minimal reproduction if desired, but I'm not sure this repo is that active right now?

Originally created by @addshore on GitHub (Jan 12, 2023). Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/256 Downstream ticket is https://phabricator.wikimedia.org/T326735 ### What is Happening This issue occurs while trying to resolve names that are not configured in the dns-proxy-server When connected to the internet all appears to happen as normal, the resolution falls back to a public dns server like 8.8.8.8, and fails quickly ``` dps_1 | 2023/01/11 15:33:53.883025 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=af63dcc644 status=bad-code, name=mysql., rcode=3, err=status=invalid-answer-name, name=mysql., rcode=3 dps_1 | 2023/01/11 15:33:53.883053 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=af63dcc644 status=complete, name=mysql., res=3 ``` When not connected to the internet however the resolution still falls back to a public dns server, but that is not accessible and takes many seconds to timeout ``` dps_1 | 2023/01/11 15:34:10.499217 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=708a0ff26e status=no-answer, question=mysql., server=8.8.8.8, err=%!s(MISSING) dps_1 | 2023/01/11 15:34:10.499271 INFO f=remote.go:64 pkg=github.com/mageddo/dns-proxy-server/proxy.remoteDnsSolver m=Solve uuid=708a0ff26e status=complete, name=mysql., res=-1 dps_1 | 2023/01/11 15:34:10.499365 ERROR f=dns.go:59 pkg=main m=handleQuestion uuid=708a0ff26e status=complete, question={Name:mysql. Qtype:1 Qclass:1}, answers=[] dps_1 | Not solver for the question mysql. ``` ### What is expected I would expect one of the following: - names such as `mysql` would never make their way to the public DNS server as part of their resolution - timeouts for any public DNS lookups would happen much quicker ### Steps to Reproduce Currently using the `defreitas/dns-proxy-server:2.19.0` docker image I can try to create a minimal reproduction if desired, but I'm not sure this repo is that active right now?

kerem

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

closed this issue
added the
bug

waiting-feedback

confirmed
labels

kerem commented

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

Author

Owner

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

Hey @addshore , thanks for your report

names such as mysql would never make their way to the public DNS server as part of their resolution

It makes sense, but we are not going to add such rules to DPS for now.

timeouts for any public DNS lookups would happen much quicker

I agree, had issues like this in the past, expected it to be finally solved already, I will try to reproduce the issue and give you a feedback.

DPS 3 is alive, in beta version though, it maybe fix that issue, maybe you can find a different one, give it a try and give a feedback if possible.

Thanks in advance

@mageddo commented on GitHub (Feb 23, 2023): Hey @addshore , thanks for your report > names such as mysql would never make their way to the public DNS server as part of their resolution It makes sense, but we are not going to add such rules to DPS for now. > timeouts for any public DNS lookups would happen much quicker I agree, had issues like this in the past, expected it to be finally solved already, I will try to reproduce the issue and give you a feedback. [DPS 3 is alive](https://github.com/mageddo/dns-proxy-server/releases), in beta version though, it maybe fix that issue, maybe you can find a different one, give it a try and give a feedback if possible. Thanks in advance

kerem commented

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

Author

Owner

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

Okay, I confirmed the bug on 2.19.0 (evidence below), please give a try in DPS version 3.1.4-beta+ it must be fixed

time dig mysql -p 5354 @127.0.0.1

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> mysql -p 5354 @127.0.0.1
;; global options: +cmd
;; connection timed out; no servers could be reached


real	0m15.054s
user	0m0.027s
sys	0m0.005s

log.txt

@mageddo commented on GitHub (Feb 23, 2023): Okay, I confirmed the bug on `2.19.0` (evidence below), please give a try in DPS version `3.1.4-beta+` it must be fixed ``` time dig mysql -p 5354 @127.0.0.1 ; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> mysql -p 5354 @127.0.0.1 ;; global options: +cmd ;; connection timed out; no servers could be reached real 0m15.054s user 0m0.027s sys 0m0.005s ``` [log.txt](https://github.com/mageddo/dns-proxy-server/files/10809925/log.txt)

kerem commented

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

Author

Owner

@addshore commented on GitHub (Feb 24, 2023):

I tried giving it a try, but filled https://github.com/mageddo/dns-proxy-server/issues/309 for a failing end to end test on my application.
If I can get the tests to be green then I can give the offline behaviour a try!

@addshore commented on GitHub (Feb 24, 2023): I tried giving it a try, but filled https://github.com/mageddo/dns-proxy-server/issues/309 for a failing end to end test on my application. If I can get the tests to be green then I can give the offline behaviour a try!

kerem commented

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

Author

Owner

@addshore commented on GitHub (Mar 1, 2023):

I can confirm this is working in 3.5.2
DNS resolution for my usecase now doesn't hang on these timeouts

@addshore commented on GitHub (Mar 1, 2023): I can confirm this is working in 3.5.2 DNS resolution for my usecase now doesn't hang on these timeouts