Default BIND query timeouts

Shawn Zhou shawnzhou00 at yahoo.com
Tue May 20 00:00:53 UTC 2014



What about non-recursive queries?

In particular case, our test queries are non-recursive and we expect the name server should have answers. We are sending test host with very high query rate so BIND may be too busy to respond to all the queries.


On Monday, May 19, 2014 4:25 PM, Kevin Darcy <kcd at chrysler.com> wrote:
 

>
>
>If a client sends a recursive query to the BIND instance, and that instance needs to fetch the answer from one or more other upstream sources, then my understanding is that the "resolver-query-timeout" global option (see the BIND docs) controls the timeout for each one of those upstream transactions. Default value is 10 seconds.
>
>Does that answer your question?
>
>                                                               
          - Kevin
>
>On 5/19/2014 6:15 PM, Shawn Zhou wrote:
>
>
>>
>>I  am looking at some scripts that use IO::Socket::INET and IO::Select for testing BIND.
>>
>>
>>UDP sockets are created use use IO::Socket::INET and sockets are polled via IO::Select at 6-second interval.
>>
>>
>>     my  $sock = IO::Socket::INET->new(
>>            PeerHost => $server,
>>            PeerPort => $port,
>>            Proto    => $protocol,
>>            Blocking => 0,
>>
>>
>>
>>I'd like to know what the timeout is for the queries.
>>
>>
>>Thanks,
>>Shawn
>>
>>
>>
>>_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users at lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
>
>
>_______________________________________________
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
>bind-users mailing list
>bind-users at lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140519/b623c482/attachment.html>


More information about the bind-users mailing list