[dns-operations] dns-operations at lists.dns-oarc.net

[Stephane Handfield]

Hello Todd,

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.

Thanks,

Stef

On Wed, May 9, 2012 at 9:10 AM, Todd Snyder <todd at borked.ca> wrote:

> 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.
>>
>>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Cheers,
>
> Todd.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20120509/aa945942/attachment.html>