[Dnsmasq-discuss] Client retries broken in 2.84

Simon Kelley simon at thekelleys.org.uk
Sat Mar 13 00:35:55 UTC 2021


On 11/03/2021 11:19, Petr Menšík wrote:
> Hi Simon and Nicholas,
> 
> I think dnsmasq relying on driving retries by clients is not great
> design. When clients starts bombarding dnsmasq with requests, dnsmasq
> will in turn bombard upstream server(s) too. It seems unnecessary to me.
> And even wrong.
> 
> I think dnsmasq should drive retries itself, periodically checking
> existing frec, comparing last sent request timestamp. Every few
> miliseconds try sending a new packet, let's say each 200 ms. After no
> reply for long enough, it should send SERVFAIL reply to all clients
> requested that query.

The current state of affairs is driven mainly by history. Dnsmasq
doesn't do retries because it doesn't store enough information to do
retries. The original design, which is still at the core of things, is
that each in flight query needed only a fixed size entry in a table
(struct frec) which has things like the original source of the query.
Crucially, it doesn't include the actual query, so dnsmasq can't retry
it. This was in the days when routers didn't have 16MB of RAM and
dnsmasq was a small-footprint alternative to BIND. Of course, once you
start doing stuff like DNSSEC validation, the memory footprint starts to
grow and it's difficult to justify such a design, expecialy as these
days routers _do_ have 16MB. 2004 is not 2021. Petr has suggested
keeping the query rather than a cryptographic hash of it, which is
needed for modern security needs, and it's certainly arguable that that
makes more sense these days. My observation is that this is not a minor
change: it would be an opportunity to tidy up a lot of nasty legacy
code, but we're talking dnsmasq 3.x, not a small tweak.


Simon.



More information about the Dnsmasq-discuss mailing list