slave server

Tue Jun 29 22:43:15 UTC 2010

On 6/29/2010 5:36 PM, Fred Zinsli wrote:
> Hi everyone
>
> Very new to bind (or dns for that matter).
>
> I am wanting to know if there is a way to setup a slave only server for my
> network.
>
> I would like it to simply act as a secondary server should the main server
> fail.
>    

Would these "main" and "secondary" servers be answering queries for 
end-user devices, so-called "stub resolvers"?

If so, then please understand that a stub resolver doesn't really care 
who is "main" and who is "secondary". All it really cares about is 
getting an answer to its query. A stub resolver is configured with a 
list of upstream resolvers to use, it tries the first one, and if that 
query fails, then it tries the next one in the list, and so on.

So, the important question to ask is: is it acceptable in your 
environment that, in the event of a your "main" server failing, that 
clients fail over to the "secondary" server in order to get DNS 
resolution? Bear in mind that each application has a timeout value for 
the lookups that it issues, and these timeout values may or may not be 
very short by default, and may or may not be configurable within the 
application. The stub resolver itself, may or may not have a way to 
configure the timeout/failover parameters.

The bottom line is: stub-resolver failover may potentially be 
*insufficient* to prevent application breakage in the case of a 
single-node failure. I don't know what applications you're running, so I 
can't tell whether this is an issue for you or not.

If regular stub-resolver failover is sufficient, then you can simply 
configure both servers into your stub resolvers (either statically, or 
by using something dynamic like DHCP), and you're set.

If it's insufficient, then you will have to resort to more exotic 
technologies like Anycast, clustering, local load-balancing or the like, 
so that queries to a particular IP address get 
redirected/intercepted/forwarded if the device associated with that IP 
address fails, or, alternatively, that some other device steps in to 
associate itself with that IP address in the case of failure (which it 
would detect through some sort of "heartbeat" or "keepalive" mechanism 
between the nodes).

> I would also like the slave server to automatically add any (all) new
> domain/s

Not possible using the DNS protocol alone. There are various 
non-protocol-based (e.g. programmed/scripted) techniques for 
managing/synchronizing nameserver configurations within whole 
communities of servers, and of course, this is a standard feature of any 
enterprise-level DNS product.

One simplistic approach (not that I'd necessarily recommend it, since we 
do things somewhat differently) is to periodically copy the named.conf 
over to the slave and then massage it to turn all of the "type master"s 
into "type slave"s, along with adding the appropriate "masters" 
clause(s). Every time the named.conf changes on the slave, then of 
course you'd need to bump the named process in order for the changes to 
become visible.

    and/or changes to any existing domain/s on the master.

Depends on what you mean by "changes". If you mean changes to the zone 
data, then these will be replicated from the master to the slave (that's 
pretty much encompassed in the respective definitions of "master" and 
"slave"). On the other hand, if you're referring to any kind of 
"metadata" changes, such as query/zone-transfer/dynamic-update 
permissions, tuning parameters, etc. then those are changes to the zone 
*configuration*, and thus fall under the same category as zone 
additions, as discussed above; there is nothing in the DNS protocol 
which allows for propagation of  those.

                                                                     - Kevin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20100629/d0f60e4e/attachment.html>