Virtual domian as NS ?

Kevin Darcy kcd at daimlerchrysler.com
Fri Dec 8 00:47:59 UTC 2000


It doesn't really matter which box is the master and which is the slave. To
the rest of the world, the data from one authoritative server is just as good
as from any other. In terms of *selecting* servers, however, sophisticated
nameserver implementations such as BIND will prefer *faster* nameservers over
slower ones. So if your smaller box answers more slowly, the load will tend to
gravitate to the larger one.

To answer your second question, more servers are generally better, but if that
connection is *really* slow, it may not make a lot of sense to run a
nameserver over it -- that will just slow down resolution for any other
nameserver that happens to query that nameserver first. It may be that you
have to decide between reliability and performance. (Although ultimately of
course, it's a 3-way tradeoff between reliability, performance and *cost*,
since you could always pay some ISP to run a slave for you on a box much
nearer to the Internet backbone).


- Kevin
Ridwan wrote:

> Okay..
> All replies reffer to one good solution to have another server.. :-)
>
> Another question, if I get another box with less power than the first box
> (slower cpu and less ram). Which you all suggest, having the master in the
> first box or in the second box?
> Assuming the second box will only provide name and a limitted anonymous ftp
> services. The first box will act as web server, ftp server and mail server
> for all of virtual host/domain.
>
> Is there any good reason for me to run the third (second slave) NS in my
> office which only have slow dedicated line connection with several static
> IPs?
>
> tia,
> Ridwan
>
> ----- Original Message -----
> From: "Joseph S D Yao" <jsdy at cospo.osis.gov>
> ...
> > What good does this do you?  If the one machine fails, you lose all
> > your peer name servers.
> >
> > Look up "listen-on".  Then get someone else, somewhere else in the
> > world, to peer with you on serving each other's names.






More information about the bind-users mailing list