Thoughts on a large-scale DNS server...

Adam Jacob Muller adam at oxeo.com
Tue Jun 28 15:08:42 GMT 2005


I annotated your message below, basically explaining our similar setup.

On Jun 28, 2005, at 10:42 AM, John Von Essen wrote:

> I have been tasked with setting up a large-scale dns server  
> environment
> (One ISP is taking over another ISP) and would greatly appreciate any
> thouhts or experiences that could help me out.
>
> In the end we will probably be doing authoritative DNS for 11,000  
> domains,
> and another 200 or so in-arpa address ranges for reverse resolution.

we have ~ 10k domains right now, and much less than 200 ptr's

>
> The plan is to have 3 core machines. One is the master, and gets  
> its zone
> files created from local cvs exports. The other two are slaves, and do
> zone transfers from the master. The Public will actually only talk to
> these two slave DNS servers (NS1 and NS2). The machines themselves  
> will be
> Single 3Ghz Xeon, 1Gb Memory, and 70Gb RAID 1 U320 SCSI. For every
> machine, we will have a standby machine waiting and ready.

sounds like a very conservative setup, and for DNS that's good. if at  
all possible I
would suggest that you move at least one of those servers to a  
totally seperate network.
This is important, if your network is unreachable for say, 20 minutes  
for any reason, anyone who queries
your dns in that time and caches the result will be unable to connect  
until that invalid entry clears from their cache.

As slashdot tells us, some providers ignore your set records,
http://ask.slashdot.org/article.pl? 
sid=05/04/18/198259&tid=95&tid=128&tid=4
so this is a very prudent step as i'm sure providers also tweak the  
retry times since a failed lookups are
more likely to be repeated and consume more resources than successful  
ones.


>
> The first question is, do I have enough CPU/Memory. Keep in mind these
> machines will nothing but DNS.

Yes

>
> Are there any performace issues with using regular filesystem  
> directory
> zone file storage. For example, we will have a very large  
> named.conf file
> with some 11,000 zone entries (I have never worked with a named.conf
> file that big before). Those entries will just reference the local
> filesystem, file "s/a/adam.com"; and so on.
>
> The next big question is BIND8 or BIND9. I would like to take  
> advantage of
> threading in BIND9, but saw a previous post that BIND9 can have  
> difficulty
> working with BIND8 servers which were incorrectly setup, whereas  
> BIND8 can
> allow for a certain level of "external" incompetence.

the real question is, do you want to use bind at all?
We currently use djbdns to manage everything, i personally find it to  
be much more tolerant of errors than any version of bind.
http://cr.yp.to/djbdns.html


>
> And finally, Linux or FreeBSD, and if FreeBSD, 4 or 5.

FreeBSD

>
> Current staff (besides me) whats to run Debian Linux, but BIND9  
> pthreads
> dont work in Linux, do they work in FreeBSD? I want to use FreeBSD  
> just
> because it better overall with regards to TCP/IP.

Debian is a good, stable linux distro, my personal favorite in fact.  
(though gentoo is also nice).
Linux is more reliable out of the box, FreeBSD can and is more  
reliable if you know how to work it.

>
> The only performance numbers we got from the other ISP, is that  
> existing
> dns servers use about a constanst 400 kbps (bits) of bandwidth.

The bandwidth, the needed server specs are a combination of two  
things. First, the number of domains you have and 2nd the TTL on  
those domains.
We currently use a TTL of 12 hours. This serves us well. If you halve  
the TTL to say, 6 hours, expect to double the number of DNS queries.  
If you double the TTL to 24 hours, expect to halve the number of DNS  
queries.

>
> Thanks in advance
> John
> _______________________________________________
> freebsd-isp at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-isp
> To unsubscribe, send any mail to "freebsd-isp-unsubscribe at freebsd.org"
>



More information about the freebsd-isp mailing list