Hello Todd,<br><br>It's exactly the X times of the average qps rates I'm looking for, on our side, we try to do a capacity planning for recursive/caching DNS which are accessible only by our clients, no firewall on the path, only acl's at the edge for protecting the cache DNS of the internet but we're using a mix of LoadBalancers and anycast, which make the LB's a possible choke point. At that point, we define the following rule,  take the estimated QPS we'll have to support at the end of the year and put in place enought hardware to support that qps rate by 10x ... but 10x is only a number everybody here seem to be confortable with.<br>
<br>Thanks,<br><br>Stef<br><br><div class="gmail_quote">On Wed, May 9, 2012 at 9:10 AM, Todd Snyder <span dir="ltr"><<a href="mailto:todd@borked.ca" target="_blank">todd@borked.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><font size="3" color="#333333" face="arial, sans-serif"><div>I want to know what rules you follow in terms of capacity planning for your DNS. I am mainly interested in the best planning practice for caching  DNS. Definitly our rules need to reflect a lots of our own reality, in term of agility of deployment, risks, etc. But I'm really interested to know if exists any rule of thumb which mostly apply to any situations.</div>


<div><br></div></font></blockquote><div><br></div></div><div>I've just finished a capacity exercise, and followed through with new hardware.  We decided that in our business (a service provider, kind of), our externally facing authoritative servers *must* be able to handle 100x our normal production query rate.  It *should* be able to handle 300x production query rate.  We ended up with a service that, due to our topology and desire for redundancy, can handle 700-800 times our normal query load.  We also have a plan in place to double that within minutes should it be required.</div>

<div><br></div><div>This is all in place in case anyone ever decides to DOS our DNS service - we want to make sure that we have the most capacity available, striking a balance with cost and operational efficiency.  Without DNS, our services and customers are off the air, so it was deemed to be worth the resource outlay to protect that service.  It may not be as important to others.</div>

<div><br></div><div>Something to note is that DNS packets are small, and plentiful.  Those attributes make firewalls go *kaboom*.  If you're looking at how to build a DNS service, don't look at just the DNS server capacity, but the firewall (and other network pieces) you (may) put in front of it.  We removed the firewalls for just this reason.  It's great that you can build a DNS server that can handle X qps, but when your firewall fails at (X/10)qps, you're in trouble.</div>

<div><br></div><div>I don't know if this helps, I don't even know if those numbers make sense to other operators.  It's very difficult to get people to talk about this stuff in real, operational terms.</div><div>

<br></div><div>Cheers,</div><div><br></div><div>Todd.</div></div>
</blockquote></div><br>