> On 2/12/2015, at 15:23, Roland Dobbins <[email protected]> wrote: > > On 2 Dec 2015, at 3:28, [email protected] wrote: > >> But simply replacing BIND with something else is *not* likely to solve >> your problem. > > Concur 100%. > > You may also wish to consider two layers of caching - e.g., an aggregate > cache in addition to caching on user-facing caches, along with dedicated > resolvers. See this .jpg diagram: > > <https://app.box.com/s/72bccbac1636714eb611>
I have tested similar topologies in anger and haven’t found that the benefit (which is fairly small) is worth it for the added complexity. I find that unbound with large cache sizes works very well - https://www.unbound.net/documentation/howto_optimise.html <https://www.unbound.net/documentation/howto_optimise.html> is a good primer. I collect stats with collectd and the unbound collectd python module from here: https://github.com/tarnfeld/collectd-unbound <https://github.com/tarnfeld/collectd-unbound> We get the stats out the end of our stats pipeline with Grafana, and have a detailed analytics dashboard that give us hints about what needs to be looked at. We chart queries per CPU%, recursion times, all sorts of good stuff. -- Nathan Ward _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
