Best way to handle multiple retries from BIND?

Petr Menšík pemensik at redhat.com
Mon Jun 26 07:46:14 UTC 2023


I would suggest doing what forwarders do, joining multiple queries into 
single upstream request. When the answer arrives, send replies to all 
requestors of this common transaction. If you cannot fix your server to 
handle the response right away and have pre-computed answers, as is 
common for authoritative servers.

It is expected authoritative server does not have to do anything serious 
per client. What is that resource intensive operation we are talking 
about? Do you sign on the fly? Can you explain a bigger picture? Maybe 
there is a design of the service, which could be improved instead. 
Attempt to suppress a retry when the server does not answer quickly 
enough is not correct way of solving it IMO.

Regards,
Petr

On 6/26/23 03: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.
>
> 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.)?
>
> Thanks in advance...
>
> --
>
> Fred Morris
>
>
>
-- 
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230626/fd8d16a1/attachment.htm>


More information about the bind-users mailing list