Unfortunately, there is an issue using QUAD9 as DoH-upstream for https-dns-proxy. Official reports filed already. Many errors, although recovered, make DNS resolution slow. Better to use different provider.
Has got nothing to do with OpenWrt. BTW, most likely it depends on your location. Just ran 1000 requests to 9.9.9.9 and 2620:fe::9 and see not a single failure.
Do not do any assumptions, please. This is not helpful, but only spreading “fake news”. Because when you read other posts of mine here, you will see, that this issue is even confirmed by another member.
Reason of issue unknown yet; might be regional, correct. But might be an openwrt issue. When it does not affect you, you just are the lucky one.
It is about quad9 DOH and I can confirm the problem.
Other DOH providers (cloudlfare, google) do not exhibit the problem.
Don't take it personally, I just don't observe it. You can search my previous history and realize that I use Quad9 (and Google DNS at work) in my daily personal life (because of properly disabled EDNS Client Subnet). Just like with your previous post the root cause may reside in geography.
P.S. Is Quad9's DoT affected for you too?
I do not take it personally. However, there are quite a few possible explanations, why you do not observe it, besides geography. I.e. different router hardware, causing timing effects. Or slower/faster ISP, which might also cause timing effects. Or your testing environment. Which MIGHT only serialize requests, and NOT to generate parallel queries. A systematic approach simply starts with “Lets check, what might be the difference then”. Anyway, even in case it is a geographic (ISP) issue, I think, it is worth to know, that this possibility exists. And not just to wonder about high latency, when using quads DoH. There might be other users, who also like quads privacy (?). Opposed to using cloudflare or google. Sorry, I am not interested in DoT.
Plus 1 but I have been trying Quad 9 set in my main browser for the last couple of weeks and the latency and non-connection has been appalling. Counted more than 10 seconds to connect on more than one occasion. Persevering but not sure for how long…….
I have it set also in the router along with Cloudflare to avoid ISP but that seemed to generally default to Cloudflare presumably because so much quicker (based on comments in previous threads).
Quad9 has very slow IPv6 replies (~200-250 ms, at least at my location), the rest is within 30-40 ms.
As I wrote, the issue I mentioned is recovered, usually. And only indicated by high latency, therefor. Like you have, too. Details regarding possible Errors from Quad can be found in https-dns-proxy.log. Do you have a LINUX or Windows client, you used with your browser ? Which browser ?
This is, how fake news are born. This is, what I wrote:
chrome on win10/11 client, by default, uses https or plain tcp for dns.
And I only mentioned a RFC, which states, that DNS both has to service UDP and TCP queries.
False:
False:
False:
... and then I just realized that you have no idea that DNS over TCP and DoH are two different things. DNS can employ TCP for long replies. It has been like that for more than 20 years. DoH works over TCP. DoQ works over Quic (UDP)... but it is not supported by Chrome. You can't get encrypted secure DNS over UDP in Chrome. Stop making things up. Use OS resolver and that's it. You can set up DNSCrypt on your router and get UDP + secirity (if you so like it). But very resolvers support it. "Fake news, fake news", - it became too easy to explain own stupidity by saying this phrase.
Obviously, a serious, academic discussion is not possible, as you only do claims, without any reference. For example, regarding DNS via TCP in Chrome/Windows (Your first wrong FALSE claim), which is a not very new feature, you can start here: https://lists.dns-oarc.net/pipermail/dns-operations/2023-March/021979.html However, this fruitless discussion among the two of us is of no concern here, as there are other posters confirming the heading of my post.
DNS over TCP is not related to DoH (the one you're trying to optimize). These are two totally different things. Normally DNS operates over UDP port 53 via OS resolver. TCP was added later for the purpose I mentioned earlier. This is a NORMAL mode of operation for most applications including Chrome (tcpdump was attached to prove it). In-application resolving is a new thing. It works over HTTP/2 which is indeed TCP. In can't operate over UDP. DNS over encrypted UDP called DNSCrypt, DNS over Quic (which is UDP too) called DoQ. Both DNSCrypt and DoQ are not supported in Chrome, for that you use proxy on your router. If you use proxy you just disable DoH on your Chrome. Yes, it requires user intervention. In case of Firefox and Apple you block canary domains I mentioned earlier (no intervention is required on user devices). This signals to browsers to disable DoH and use regular DNS over UDP port 53 via OS resolver.
Are you on drugs or what? Produce tcpdump packet capture to prove me wrong.
Update: Quads suppport acked the reported errors, when using https-dns-proxy with them, and has 2 explanations:
a Minor number of errors because https-dns-proxy sometimes trying to use http1.1 for comms with quad. Which is not supported any more with quad9.
b Many other errors MIGHT be caused by proxy or curl, causing “framing errors”.
First one not a real bug, but a switch “no-http11” for proxy appreciated.
Second one under further investigation.
After updating the package to very last version of https-dns-proxy, situation improved. Still many errors, but recovery, within 100ms. New version of package in SNAPSHOT actually, soon to be backported. Now, to be called “good enough” to use QUAD9 as DoH-resolver for https-dns-proxy, in case you trade slower name resolution, compared with goggle or cloudflare, for higher privacy.
Just switch over to DNSCrypt (supports UDP) or DoT if you need Quad9 and can't bear errors.