This is a discussion on Re: question about caching of lame servers - DNS ; Kevin Darcy wrote: > Klaus Darilion wrote: >> Hi Tatuya! >> >> Thanks for your answers. >> >> JINMEI Tatuya / 神明達哉 wrote: >> >>>> Further, I not only want to cache lame name servers, but also name >>>> servers ...
Kevin Darcy wrote:
> Klaus Darilion wrote:
>> Hi Tatuya!
>> Thanks for your answers.
>> JINMEI Tatuya / 神明達哉 wrote:
>>>> Further, I not only want to cache lame name servers, but also name
>>>> servers which are down. Is this possible?
>>> Not exactly, but the fact that a server is down is cached as
>>> a penalized RTT, which makes that server less preferred in subsequent
>>> server selection.
>> Penalized RTT works fine if at least one authoritative name server is
>> working, but if all authoritative name servers are down, then this is no
>> Maybe I should describe the cause of my question. I am using openser as
>> SIP proxy. openser is multi threaded (fixed number of threads) and uses
>> libresolv for domain resolving. Thus, if openser resolves a domain with
>> broken name servers (either by network problems or by intention (DoS
>> attack)), openser's thread is busy until a timeout happens.
>> This can be easily used to make a DoS attack. Probably the best solution
>> would be to use asynchronous DNS in openser, but this will not be
>> implemented soon.
>> Do you know a solution to solve this problem in the recursive name server?
> What's the difference between a "down" nameserver and one that's simply
> taking a long time to respond, from a resolver's point of view? In
> practice, not a whole lot.
There is no difference - I want to cache both failures and respond
immediately with SERVFAIL instead of waiting for timeout over and over
> Perhaps the interim solution is to tune openser's lookup timeout-retry
That gives faster timeouts - but I want to get rid of timeouts
completely - of course the first lookup will time out, but the name
servers should be marked as down for some time and sequential lookups
should be avoided.
> - Kevin