question about caching of lame servers
Kevin Darcy
kcd at daimlerchrysler.com
Wed Oct 18 02:44:53 UTC 2006
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
More information about the bind-users
mailing list