[nSLUG] Looking for a DNS secondary partner

Jason Kenney jdkenney at gmail.com
Mon May 4 10:30:02 ADT 2009


There are good free measurement tools from Nominum:
http://www.nominum.com/services/measurement_tools.php

Writing your own script to test a server is actually pretty tricky...
If you just have a script calling dig in a loop over and over, that is
not close to being representative of what a real dns server does.  The
Nominum tools allow you to set lots of options regarding how many
outstanding unanswered queries should be allowed before sending a new
one, etc.

There are also two things really to consider regarding performance:
- performance of cached data
- performance of uncached data

Again the nominum tools provide a convenient test suite, which can be
tailored to test either of the two items above.

I would be skeptical to say the least of any results from a homegrown
script that does not throw multiple simultaneous queries at a server.

Moving on, yes old versions of bind had a lot of security problems,
but BIND9 was a complete rewrite starting from scratch.  I don't think
you should be considering their histories as one - if anything the
lessons learned from BIND8 hopefully helped fix design and
architectural issues for BIND9.

Yes, you can run bind in a jailed environment, however I believe there
are some or at least were issues related to privilege separation and
using multiple CPUs on some platforms.

Running tests for cached performance in a vmware instance on my single
cpu pentium M laptop I can get performance in the thousands of the
queries per second.

Your organization would need to be very large indeed before your
sustained traffic reaches thousands of queries per second.

DNS performance is just not an issue.  Flexibility of configuration
and features however, most certainly is.


Jason

On Mon, May 4, 2009 at 10:02 AM, Dan Peterson <dpiddy at gmail.com> wrote:
> On Sat, May 2, 2009 at 6:40 AM, Michael Crawford <mdcrawford at gmail.com> wrote:
>> For my own domains, for the next year or so I'm not at all concerned
>> about performance.  I just don't expect to get a lot of traffic.
>>
>> What I'm the most concerned about is making some kind of mistake in
>> the configuration or installation, so that either my service isn't
>> reliable, or my servers get 0wnz0r3d.
>>
>> This because I've never operated my own DNS server before.
>>
>> In the hopeful event that a year from now I get so many visitors that
>> performance *is* an issue, I expect to be experienced enough that I
>> can easily get it right.
>>
>> Given all that, which DNS software do you all think I ought to run?
>
> Here's my piece on this. :)
>
> I've been using djbdns since 2000. It rules. People have their
> problems with DJB, the license (which isn't valid anymore), this and
> that. But it really is the simplest suite to use once you understand
> how it works.
>
> As for its performance, I know it seemed to "lose" the benchmarks in
> the blog post but there are at least a couple possible reasons for
> that:
>
> * At least BIND will use all memory possible for cache data,
> dnscache's default is 1M. I doubt that was changed for the test.
> * dnscache's default logging is somewhat verbose; in a busy scenario
> such as a benchmark like that it could end up blocking dnscache.
>
> Also, it didn't even test tinydns which is probably more what you're
> concerned with. tinydns is the content serving part of djbdns while
> dnscache is the recursive resolver. The data tinydns serves is
> basically precompiled into a small static database file which usually
> ends up being cached in memory. You'll probably never worry about
> performance with it.
>
> I highly recommend you check out the pages at
> http://cr.yp.to/djbdns.html to get a feel for how things work. If you
> have any questions and/or decide to go the djbdns route I'd be happy
> to help; find me in #nslug on OFTC as danp or via this email address.
>
> -Dan
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/cgi-bin/mailman/listinfo/nslug
>



More information about the nSLUG mailing list