Best way to handle multiple retries from BIND?

[Petr Špaček]

On 26. 06. 23 3:05, Fred Morris wrote:
> I have an authoritative server which performs a resource intensive 
> operation to determine an answer; sometimes it takes long enough that 
> BIND asks again (and again!). Firing off multiple attempts to determine 
> the answer just digs the hole deeper.

As others said, deduplicate on the auth side. At least it will not dig 
the hole deeper.

> What's the best approach, assuming the same client asks repeatedly:
> 
>   * Discard later queries, answer the first one?
>   * Discard earlier queries, answer the last one?
>   * Send same the response (when we get it) in response to all queries
>     (I don't like this one)?
> 
> And does anyone know can the recommended mitigation be presumed to be 
> the best option regardless of the recursive server (BIND, Unbound, etc.)?

Well, if you insist ... you can respond with TC=1 when your internal 
timeout fires off (which obviously must be shorter than client's 
timeout), but this is going to be pretty tough race. Knot Resolver used 
to retransmit after 200 ms or so.

Or do TC=1 all the time and answer only over TCP. That usually has more 
leeway in terms of timeouts, but I doubt you can reliably prolong it 
over 1 sec. At that mark it starts to smell like slow lorris attack and 
the client might close the connection.

-- 
Petr Špaček