Every now and then, I notice that the dns query takes upward of 1 second to resolve.
I notice this by comparing the query time of dig @8.8.8.8 www.google.com which shows about 40 ms, versus dig www.google.com which shows about 1.5 seconds (going via https-dns-proxy).
If I log into openWrt server and reboot https-dns-proxy with /etc/init..d/https-dns-proxy restart, this problem disappears immediately, and https-dns-proxy then resolves also in about 40 ms.
I checked the memory usage and CPU usage of https-dns-proxy, and it was normal (very low).
Any idea about what could be the issue?
System : OpenWrt 22.03.2 r19803-9a599fee93
https-dns-proxy : 2022-10-15-6
I only checked the overall time with dig.
Let me make sure I understand your suggestion.
My expectations (might be wrong) are that I would see
Message A going from the client to the router
Message B going from the router to the dns server
Message C arriving from the dns server to the router
Message D arriving from the router to the client
The 1.5 seconds or latency are either tB - tA (i.e. https-dns-proxy takes time to process incoming requests) or tD-tC (i.e. https-dns-proxy takes time to forward the answer to the client).
Are you using adblock/simple-adblock or any large address or server lists with dnsmasq (which may slow down dnsmasq vs querying google servers directly)?
Which DoH resolvers are you using with https-dns-proxy?
May your provider prioritize dns traffic and deprioritize https traffic?
For DNS resolvers, I've tried a bunch (the same issue always end up cropping up) : including Google's 8888, Cloudflare's 1111.
I am not aware that my provider prioritize dns traffic over https, but given that restarting https-dns-proxy immediately fixes the issue, I do not believe that is what is at stake here.
I'm also having this problem, and I was having it before I started using the adblock software. I never had such long delays when I was using it with stubby instead. Nor when I was using a recent version of unbound on opnsense.