Date: Wed, 28 Dec 2011 14:36:15 +0100 From: Damien Fleuriot <ml@my.gd> To: freebsd-questions@freebsd.org Subject: Re: mutual forwarders in ISC BIND Message-ID: <4EFB1B4F.2090504@my.gd> In-Reply-To: <20111228130734.GA23763@admin.sibptus.tomsk.ru> References: <20111228075422.GA18064@admin.sibptus.tomsk.ru> <4EFAE80D.9040900@my.gd> <20111228130734.GA23763@admin.sibptus.tomsk.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EFB1B4F.2090504>