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

Todd Snyder todd at borked.ca
Wed May 9 13:10:50 UTC 2012


>
> 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/83922137/attachment.html>


More information about the dns-operations mailing list