mirror of
https://github.com/mageddo/dns-proxy-server.git
synced 2026-04-25 09:25:56 +03:00
[GH-ISSUE #371] Timeout for a list of remote DNS servers #129
Labels
No labels
bug
confirmed
discussion
duplicate
enhancement
feature
feature-request
not-planned
pull-request
secondary-feature
stale
triage
waiting-feedback
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/dns-proxy-server-mageddo#129
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dmekhov on GitHub (Mar 17, 2023).
Original GitHub issue: https://github.com/mageddo/dns-proxy-server/issues/371
I have thhe list of dns servers in a remoteDnsServers array. First of them is my internal corporate DNS.
Sometimes it fails to respond within the required time and other external dns (e.g., 1.1.1.1) answered, so I got unexpected results.
It would be better to be able to prioritize the list of remote DNS servers or/and set a timeout for each server to avoid such issues. Can you please suggest a solution or configuration that can help me achieve this?
@mageddo commented on GitHub (Mar 18, 2023):
Hey @dmekhov ,
That's the currently behavior, I think the issue here is that DPS remote solver timeout was set to
300 ms, as 3.13.x it's10srespecting common timeout used by other DNS clients.Can you give a try at
3.13.1and check if your issue is fixed?@dmekhov commented on GitHub (Mar 19, 2023):
@mageddo thanks, I'll test it on weekdays.
@dmekhov commented on GitHub (Mar 21, 2023):
@mageddo
No, unfortunately I still have this problem (seems not so often).
Maybe I can enable some kind of debug mode for catch that (with targeting to some network or something else, to exclude extra logs)?
@dmekhov commented on GitHub (Mar 21, 2023):
last logs (with grep
rancher- example of errored page) on the issue momentthen if I push f5 button on page with error, no new logs (because of wrong browser cache)
logs after reset browser cache:
@mageddo commented on GitHub (Mar 21, 2023):
isn't the right address for rancher? Looking at these logs everything seems to be working great. Do you know what address it's supposed to be? Maybe you can do some tests with the problematic hostname trying to solving it using DPS then testing it directly on your local DNS.
@dmekhov commented on GitHub (Mar 21, 2023):
Yes, it is correct address.
10.0.69.21 - is stored in DPS config for this domain.
However, sometimes the browser starts use another "external" address and caches it. (maybe dps doesn't respond at the requested moment 0_o). I use DPS docker host IP (172.17.0.1) as my main dns server in the network manager (I use ubuntu as the host system).
I tried to dig some domains in loop script with 5 sec delay, but couldn't catch the error.
@dmekhov commented on GitHub (Mar 21, 2023):
hm, I'm just tried nslookup in the moment of broewser errorr and got this:
@dmekhov commented on GitHub (Mar 21, 2023):
But if I use nslookup directly to 172.17.0.1 - all is ok
@mageddo commented on GitHub (Mar 21, 2023):
Thanks this clue can help to find out the problem... So you are setting DPS as your default DNS in the NetworkManager, not in the /etc/resolv.conf directly.
Depending on the program your Linux is using to control the dns servers, systemd-resolved for example, the results can be very random because it will decide which DNS server to use based on its own decision.
Can you show the following files content so I can understand the resolution order?
What error you see at the browser?
Are you using which version?
@mageddo commented on GitHub (Mar 21, 2023):
That was the right or wrong ip? nslookup didn't used DPS dns in this case...
@mageddo commented on GitHub (Mar 21, 2023):
Can you provide the command you are using to start DPS?
@dmekhov commented on GitHub (Mar 21, 2023):
@mageddo, thanks for being with me! ;)
ERR_CONNECTION_CLOSED - when my browser tried to send request to wrong (public) ip adress (whitch drops by firewall)
so nslookup without specific dns - returns external (not expected, wrong) ip
I use Ubuntu 22.04.1 (5.19 kernel)
I use docker-compose without specific cmd attribute
@mageddo commented on GitHub (Mar 21, 2023):
Okay... So if you do specify 9.9.9.9 or 172.17.0.1 (DPS) at nslookup then
rancher.corp.intra.lanwill solve to the correct IP, right? The DNS server capable to solverancher.corp.intra.lanis9.9.9.9?My best bet is that the root cause is that DPS doesn't support recursion yet then resolvconf program is giving up and trying the next dns server, it isn't working well though.
I'm looking at recursion feature to understand how difficult it's to implement.
@mageddo commented on GitHub (Mar 22, 2023):
I did some reads and tests, #392 is really supposed to fix your issue, please read the issue , I've added some examples there, anyway
3.15.1-snapshotis out, can you give it a try and bring a feedback?@dmekhov commented on GitHub (Mar 22, 2023):
@mageddo thanks!
I've updated the app and will test it. At least the error message ("recursion not available") is gone for default requests.
@mageddo commented on GitHub (Mar 23, 2023):
Seems like it worked?
@dmekhov commented on GitHub (Mar 24, 2023):
@mageddo
Hmm, that's hard to say. (but yes, msg "recursion not available" is gone)
It looks like the reason is not only dps, but in combination with some other problem.
Perhaps something has changed in the chrome browser, or in my system, I'll try to test it on FF next week.
Anyway, with your latest fixes, it's a lot better, and I'm get this problem 1-2 times a day. (On the first dps v3 builds it was very often)
Yesterday I tried to roll back to v2, and got the same problem a couple of times.
And the fact that the dns record for the domain rancher.corp.intra.lan I have directly in the dps config (i.e. this is not a long response from an remote dns, but for some other reason chrome requested another dns, not dps).
I think you can close this issue, at least the result is not worse than in the v2 builds. Thanks ;)
If I have some new information I will post here or in new issue. ;)
@dmekhov commented on GitHub (Mar 28, 2023):
So it seems that everything is ok with ff.
Even if ff also have some short issues with resolving it doesn't cache wrong dns.
It's not very convenient for me to change main browser to ff, but for now I have to (at least for internal services).
@mageddo commented on GitHub (Mar 29, 2023):
Okay, maybe #386 might help you. I expect it to be released in the next weeks.
@dmekhov commented on GitHub (Mar 31, 2023):
@mageddo
I found that crome dns client now works in asynchronous mode, and it's configurable with a flag chrome://flags/#enable-async-dns (default: true in current versions).
So when I disable it - everything became fine.
Now I finaly resolved my problem
but still (about reason of this issue) it's can be for some performance issue - in async mode (when it is enabled) somehow external dns like 1.1.1.1/9.9.9.9/etc answered faster than dps and chrome use that answer
@mageddo commented on GitHub (Mar 31, 2023):
Thanks @dmekhov , I'll take a look
@mageddo commented on GitHub (Mar 31, 2023):
@dmekhov what chrome version are you using? I'm using
111.0.5563.146and can't see this option on Mac, I'll take a look at Linux.@dmekhov commented on GitHub (Mar 31, 2023):
My chrome version is
111.0.5563.146Try to search
dnson chrome://flags page? Maybe it have otther name on Mac?(Now it calls
Async DNS resolver, previously it wasBuilt-in Asynchronous DNSaccording to google)@mageddo commented on GitHub (Mar 31, 2023):
As Chrome feature makes DNS queries in parallel, if one of the available servers answer a NONERROR response then chrome will abort other queries and go on, DPS can't do much here as the issue is on the another Server , what you can do as workaround is:
/etc/systemd/resolved.confref1@dmekhov commented on GitHub (May 24, 2023):
Hi, I tried to use this way on new ubuntu instalation (23.04), and have some issues now
I set my DPS IP (172.17.0.1) in network manager and in /etc/systemd/resolved.conf
In DPS config my first DNS is DNS in VPN network, the second one is 1.1.1.1
So if I try to call any resource (ping google.com for example) but my VPN connection isn't active - DPS is waiting it and retturn timeout
Am I configured something wrong? (should I open new issue for that?)
@mageddo commented on GitHub (Jun 1, 2023):
@dmekhov I see, DPS doesn't have a remote DNS circuit breaker feature to automatically disable/re-enable remote servers when the come offline or online again.
I've opened https://github.com/mageddo/dns-proxy-server/issues/415 for that feature, for now you will have to manually disable the VPN remote server. I consider it's not too complex to implement.