Re: dns_timeout and dns_retransmit_interval in ms

On 03/14/2011 05:08 PM, Amos Jeffries wrote:
> 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!").

The cases I am worried about are problematic DNS outside of the cache
administrator control or just slow/lossy links to selected DNS servers.

>>
>> 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.

I think we should be conservative with these defaults. Clearly, 2
minutes is too much and 5 seconds is too optimistic. Your call, but
perhaps 30 seconds would still work?

> 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.

Storing individual response records, including their TTLs, sounds good
to me.

Thank you,

Alex.
Received on Tue Mar 15 2011 - 00:06:09 MDT