Https-dns-proxy slow

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

Have you verified if the delay is on the resolver or on the proxy? (with timestamps on tcpdump for example)

1 Like

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

  1. Message A going from the client to the router
  2. Message B going from the router to the dns server
  3. Message C arriving from the dns server to the router
  4. 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).

Is that what you have in mind?

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?

1 Like

Yes, so the tC-tB is normal?

Yes, the tC-tB was normal.

Yes, I am using adblock with a fairly long list.

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'd bet it's a dnsmasq issue. There was a thread back in the day documenting resolution time penalties for different dnsmasq ad blocking options.

Have you tried increasing verbosity in DoH service to see what's happening?

1 Like

Ok, thanks. I haven't tried to increase the verbosity. Which option specifically do you have in mind to do so?