mutual forwarders in ISC BIND

[Peter Andreev]

2011/12/28 Damien Fleuriot <ml at my.gd>:
>
>
> On 12/28/11 2:07 PM, Victor Sudakov wrote:
>> Damien Fleuriot wrote:
>>>
>>> If you're trying to build up a cache to improve performance and response
>>> time, here's your scenario:
>>>
>>> DNS C, forward to DNS A,B for all queries
>>> DNS D, forward to DNS B,A for all queries
>>>
>>> Your cache will start building up and only responses that are not cached
>>> will be taken from your NS A and B servers.
>>
>> Sorry, I fail to see how this is any better than two independent DNS
>> servers. Perhaps a variant like
>>
>> DNS C, forward to DNS A
>> DNS D, forward to DNS A
>>
>> would be close to the goal of cache consolidation.
>>
>
> DNS A suffers an outage ; you're fucked, to put it bluntly.

BIND can be configured to deal with such troubles.  But still Victor's
idea isn't very good. First of all because response time increasing in
case of using forwarders.

Victor, we researched this topic and learned that response time highly
depends on distance between user and resolver, while cache influence
on this value is lesser.
So I advice you to keep all as is.

>
>
>> Matthew Seaman wrote:
>>>
>>> If you want to consolidate caches then probably your best bet is to have
>>> fewer, but larger resolvers.  A pretty standard server class machine
>>> dedicated to recursive DNS should be easily capable of supporting many
>>> thousands of clients.
>>
>> You are certainly right.
>>
>>>
>>> DNS is not really a fruitful target for reducing traffic volume -- there
>>> really isn't that much of it compared to all other types in any case.
>>> It's also pretty critical to the perceived performance of your networks.
>>>  Complicating and slowing down the DNS lookup path just makes everything
>>> look slow.
>>
>> I just wanted the servers to benefit from each other's caches. That
>> could speed up the lookups.
>>
>>
>
> On a side note, have you considered unbound ?
>
> It may be better suited to your needs and scale.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"



--
--
AP


-- 
--
AP