If I run my own DNS on 2 servers. One for the primary and one for the secondary. On both servers I also have a bunch of web hosting accounts. What is the average number of zone records you can have on one server?

2. Once I reach that limit, do I have to start a whole new ns.AnotherDomain.com ?

Thanks for your help.

The maximum amount of domains is basically limited by the amount of file descriptors your OS can handle, whereas the average number varies depending on the amount of RAM, CPU horsepower, etc.

What are the specs on those servers?

The specs on my server is:

primary
Red Hat 7.1
1 GB of ram
650 mhz

the seconary has
red hat
512 MB
650 mhz

Just looking for an estimate, I know it can really vary and remember both of these servers also have hosting accounts

Thanks again

I'd say that each of those should be able to handle several thousands of zone records without breaking a sweat.

However, I'm assuming that the load on the machines isn't terribly high... if they're constantly overloaded, you'll definitely experience some troubles.

OK. Thanks again.

Originally posted by lewney
The maximum amount of domains is basically limited by the amount of file descriptors your OS can handle, whereas the average number varies depending on the amount of RAM, CPU horsepower, etc.

What are the specs on those servers?

Please don't make things up.

The number of available file descriptors is unrelated to the number of zones a name server can answer AA for.

Also, advanced name servers like tinydns do not rely on the amount of ram in a server to serve large zones.

-davidu

Originally posted by lewney
The maximum amount of domains is basically limited by the amount of file descriptors your OS can handle, whereas the average number varies depending on the amount of RAM, CPU horsepower, etc.

Thats a new one :confused:

No. of zones your DNS can serve is not related to the amount of file descriptors ur OS can handle.

Heh. Right. So the DNS daemon doesn't fopen() any zone files or TCP sockets for transfers, therefore it's not dependant on the FSD limit?

Originally posted by DavidU


Please don't make things up.

The number of available file descriptors is unrelated to the number of zones a name server can answer AA for.

Also, advanced name servers like tinydns do not rely on the amount of ram in a server to serve large zones.

-davidu

Oh, I see. It doesn't need RAM to cache data, and yet it doesn't need to open files on disk to get that data (and therefore it's not affected by FS limits). Does it magically create values and serve them?

Originally posted by lewney
Oh, I see. It doesn't need RAM to cache data, and yet it doesn't need to open files on disk to get that data (and therefore it's not affected by FS limits). Does it magically create values and serve them?
Have you ever used tinydns? From what you're saying, it appears as through you're attempting to compare the way BIND works with the way tinydns works. If that's the case, you're sadly mistaken.

tinydns uses cdb, which improves performance over BIND in more ways than one. tinydns doesn't load much into memory and uses one file to access information (the cdb file).

http://cr.yp.to/cdb.html

http://cr.yp.to/djbdns.html

Heh, I've not used djb's DNS suite (outside of tinkering for a few hours). Point taken.

The original poster did not specify, however, which DNS daemon he was running. I simply assumed that it was BIND, thus my previous comments.

Originally posted by lewney
Heh, I've not used djb's DNS suite (outside of tinkering for a few hours). Point taken.

The original poster did not specify, however, which DNS daemon he was running. I simply assumed that it was BIND, thus my previous comments.

Which would still be wrong (and I assume, pulled out of thin air).

Even BIND reads the zone files on startup, opening and closing them, then loading them into memory. Changes via dynamic dns updates and IXFR/AXFR are kept in binary change files and kept in memory. (from what I remember reading, I don't run buggy software so I can't say from experience)

Either way, file descriptors are the least of one's worries when running bind. In fact, There are very few situations on a server where running out of open FD's could become an issue.

-davidu

I've seen a server that ran out of FD's -- it wasn't only running BIND, but Apache, ProFTPD, Exim and a slew of other services (qpopd, etc), just like the orig. poster said.

file descriptors are in no way related to the number of zones bind can serve.

If you ran out of FDs on server running apache, the probable reason would be you have lots of virtualhost blocks with access_log, error_log etc defined for each virtualhost which would eat up all ur FDs.