Hi Andre, et al. > On Aug 11, 2021, at 1:36 AM, Andre Heider <a.hei...@gmail.com> wrote: > > I'm using 2.86test6 on OpenWrt, and I think I've found a bug. Detail's are > vague so far but ever since I've started DoT with stubby as upstream server, > dnsmasq every now and then gets into a mode where it stops responding to > request completely and just sits there using 100% cpu power on one core. > I haven't found a way yet to trigger that reliably, but it feels like > timing/parallel requests. > > Does that ring any bells?
Our project experienced a similar issue (pre-2021) when we used dnsmasq->stubby for DoT, at the time we were using dnsmasq 2.82 and getdns/stubby 1.5.2/0.2.6. The issue was upstream DNS would randomly "stall", it could be a couple days, a week or a month before the "stall" reoccured. The DoT provider also seemed to make a difference ... for example it stalled more often with Quad9 than with Cloudflare. Keeping all things equal, we tested using unbound 1.13.0 (now 1.13.1) configured only as a DoT forwarder (forward-zone:) replacing getdns/stubby and the random stalls no longer occurred. This dnsmasq->unbound(DoT) is now our production implementation for upstream DoT. Side notes: 1) Our project used libunbound previously, so building the extra unbound daemon added about the same amount of code as the removed getdns/stubby code. 2) As of unbound 1.13.0, its DoT features are on par with stubby, ex. stream reuse and tcp fast open. 3) Our default DNS is provided by dnsmasq, only upstream DoT users start the unbound daemon. 4) Additionally, getdns/stubby dropping autotools (in favor of cmake) was a thorn in my paw. I personally use dnsmasq->unbound(DoT) and no issues since dropping getdns/stubby at the end of 2020. Lonnie _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
