[dns-operations] co-operative cacheing

Simon Waters simonw at zynet.net
Thu May 8 12:00:48 UTC 2008


On Thursday 08 May 2008 12:02, Tony Finch wrote:
> On Wed, 7 May 2008, James R. Cutler wrote:
> > Third:  Do a statistical analysis of your server query-response
> > performance.
>
> Exactly why I was hoping that someone else had already done this :-)
> There are lots of good numbers in the literature on the effectiveness or
> otherwise of web cache clusters (distributed or not) but I couldn't find
> anything similar about the DNS other than single recursive resolver
> studies.

I suspect the results will always be specific to the site in question to be of 
much use elsewhere.

Basically how broken are the clients on that network, and how broken the 
authoritive servers for domains on interest are. 

Since some clients will send the same query to multiple recursive servers much 
more readily than others. Others have different behaviour in terms of when 
they switch between unresponsive resolvers. It is the 80:20 type rule, most 
of the DNS queries that propagate upward are broken, and it is the broken 
stuff that needs the work.

Possibly if it was broken down by client type (type and version of OS, site 
specific configurations, Applications in use - Squid, Proxy servers, 
firewalls etc), you might produce some sort of chattiness indices for 
different resolver libraries by number of recursive resolvers. But it is a 
lot of work, and unless folk will switch OS or versions to optimise their DNS 
performance, unlikely to be much help, especially when DNS provision for most 
sites is not a major performance issue.

There are other optimisations of recursive resolvers that give immediate 
benefits in performance, such as slaving zones that receive a lot of traffic, 
be they blacklists, or ".", or your own zones if you are an ISP.



More information about the dns-operations mailing list