Re: dns_timeout and dns_retransmit_interval in ms

 On Mon, 14 Mar 2011 10:35:13 -0600, Alex Rousskov wrote:
> On 03/12/2011 07:43 PM, Amos Jeffries wrote:
>>
>> I will also propose a related change. Reducing the dns_timeout to 5
>> seconds default.
>
> While it is difficult for most of us to imagine a user who would wait
> 2
> minutes for a page to start loading, I assume it does happen in
> poor-connectivity environments. We could argue that admins serving
> users
> in those environments should tune their timeouts accordingly, of
> course,
> but they may be dealing with a mixture of poorly- (e.g., "foreign")
> and
> well-connected (e.g., "local") DNS servers.

 I'm hoping/confident this will point those people at their DNS
 problems. So far they just get connection failed ("but ping is
 working!").

>
> Are there any DNS defaults/guidelines that we can rely on here?

 RFCs just state "reasonable". bind seems to be the benchmark with a
 dynamic retry using 5 seconds which expands to 45 on failures. The other
 software easily found use between 5 and 15 seconds.

 I suppose 5 sec was optimistic. I have spent much time looking at 0.00*
 second DNS response times.
 20 seconds would still work.

>
>> The existing state of several 2 minute dns_timeout expecting to be
>> finished within a 1 minute connect_timeout is leading to connection
>> problems on some systems where IPv6 times out but IPv4 is perfectly
>> usable.
>
> This would be fixed if we send IPv4 and IPv6 queries simultaneously,
> right?

 A single 2 minutes is still the longer timeout even if we have to wait
 for both to complete in parallel.

 Off the topic and out into wild ideas territory ....

  One devious optimisation I have been considering is altering the
 ipcache/fqdn data structure from a list of IPs to a list of result sets.
 Then we can lookup each RR type independently in parallel (even
 honouring independent TTLs!) and insert/update the relevant results
 asynchronously as they arrive. Any given ipcache caller can be given the
 fastest available results and later lookups can get the slow results as
 well once those hit the cache.

 I'm looking for someone to do the code for this is anyone is
 interested.

 Amos
Received on Mon Mar 14 2011 - 23:09:03 MDT