mutual forwarders in ISC BIND

Peter Andreev andreev.peter at gmail.com
Thu Dec 29 09:36:12 UTC 2011


2011/12/29 Victor Sudakov <vas at mpeks.tomsk.su>:
> Peter Andreev wrote:
>> >> >> > 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.
>> >> >>
>> >> >> Be it so. Thank you.
>> >> >
>> >> > And the reason for the whole thread. One of the customers told me that
>> >> > 8.8.8.8 is faster than our own DNS servers which are located on the
>> >> > same 100 MBit/s LAN with them. I was shocked but it seems true, at
>> >> > least for the answers which are not yet cached.
>> >>
>> >> I don't know what software google uses on its resolvers, but I suppose
>> >> something with shared or synchronizing cache. May be they also make
>> >> preventive lookups on popular domains to fill this cache. And the
>> >> reason why 8.8.8.8 seems faster - it answered from cache while your
>> >> resolver made full lookup chain.
>> >
>> > Duh! That is why I started thinking about some cache synchronizing
>> > technique for my resolvers.
>>
>> Preventive lookups can be made via self-written scripts.
>
> Sure, after query log analysis.
>
>>
>> AFAIK there is no free open source implementations providing cache
>> synchronization between different resolvers.
>
> Unbound cannot do that, can it?

It has options "dump-cache" and "load-cache" for debugging purposes,
but I don't recommend using it in production.
May be "cache-min-ttl" and "cache-max-ttl" would be useful, but I
doubt what is better - get fast response or get right response.
>
> I am surprised. After all, squid siblings are quite common.
>
>
> --
> Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
> sip:sudakov at sibptus.tomsk.ru
> _______________________________________________
> 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


More information about the freebsd-questions mailing list