Some domains don't resolve.

Barry Margolin barmar at
Sat Jun 7 14:53:23 UTC 2008

In article <g2dhd2$1mb8$1 at>,
 Sten Carlsen <ccc2716 at> wrote:

> The question as I read it, is if a very small amount of users will 
> benefit most from using the cached lookups of a large number of users 
> (the whole ISP population) or from having their own independent resolver.
> I have that situation here, I first used forward but later switched to 
> just resolving. My feeling (I have no statistics) is clearly in favour 
> of NOT forwarding. I don't see any speed penalty in real life but got 
> rid of some mysterious issues that happened while forwarding and the 
> speed seems to be higher.

I'm not saying that I recommend forwarding.  I don't, because it adds an 
extra layer of dependency, and the benefit is probably not worth it.

I was just refuting the guy who said that the theory that you get better 
cache hits is a myth.

> Barry Margolin wrote:
> > In article <g2aeee$1bb9$1 at>, Kevin Darcy <kcd at> 
> > wrote:
> >
> >   
> >> Barry Margolin wrote:
> >>     
> >>> But if your ISP has 100,000 users of the same caching server, it will be 
> >>> cached if any of 1,000 users have accessed it recently.  For any one of 
> >>> them, there's only a 0.1% chance that their lookup will be the one that 
> >>> has to wait for fetching from the source.
> >>>   
> >>>       
> >> And if you have 100,000 users using the same caching server, it's likely 
> >> to experience big spikes of activity (e.g. several thousands of queries, 
> >> within the course of less than a second), during which time some users 
> >> will experience some extra delay in getting their queries resolved.
> >>     
> >
> > Certainly if the nameserver is not engineered to handle the load it's a 
> > bad idea to use it as a forwarder.  That's a completely different issue 
> > than whether it's useful to share caches via a forwarding hierarchy.
> >
> >

Barry Margolin, barmar at
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***

More information about the bind-users mailing list