[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