question about caching of lame servers

[Kevin Darcy]

Klaus Darilion wrote:
> 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 
>>> help.
>>>
>>> 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 
> again.
>
>   
>> Perhaps the interim solution is to tune openser's lookup timeout-retry 
>> parameters.
>>     
>
> 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.
>   
I think you're setting yourself for a very fragile and fickle lookup 
subsystem, since we're talking primarily about an unreliable protocol 
(UDP) being used over long-distance networks with varying latencies. 
Packet delays and drops are commonplace.

But go ahead with your experiments/modifications and let us know how it 
works out.

                                                                         
                  - Kevin