DDNS Issues With Secondary/Slave Configurations

[Kevin Darcy]

Lokhandwala Akbar-E15102 wrote:
> Hello All :
>  
> I have a couple of questions related to DDNS and Primary/ Secondary
> Relationship of the DNS Server :
>  
>  
> 1. Is it possible to do a Zone transfer from a Slave Domain Name Server
> to a Primary Domain Name Server. If yes can you please tell me what
> statement will do that trick for me. 
>   
>  
> 2.  If I have a Master Slave configuration set up for my DNS Server with
> Dynamic DNS , if the Master DNS server goes down , can the Slave DNS
> Name Server perform Dyamic DNS ?  I have been seeing errors ( tail -f
> messages ) that it is not able to perform forward update and it fails.
> When I change the type to master from slave in the named.conf file , the
> forward and reverse mapping works for me. But now I have both the DNS
> servers as Master , in which case I cannot perform a zone transfer. How
> do I overcome  this problem. 
>   
You'd have to reconfigure the slave as a master in that case. With 
unmodified BIND, only the master can accept Dynamic Updates.
>  
> 3.  The goal is to have a Master/Slave configuration with DDNS working.
> Even if the Master fails then the Slave should take over and continue to
> perform DDNS for new devices/elements joining the network . When the
> Master comes back up , then the Slave should do a Zone Transfer  to the
> Master and then the  Master should again take the responsibility for
> DDNS. Is this configuration possible. 
>  
>   
Fail Over: reconfigure the slave as a master. If you have any 
exceptionally-stupid clients that don't do Dynamic Update properly and 
will just keep on banging on whatever nameserver happens to appear in 
the SOA.MNAME of the zone, even if other servers for the zone are 
available, then you might need to fiddle around with SOA.MNAME, together 
with pushing out the changes quickly to the slaves shortly thereafter, 
just to get their Dynamic Updates going to the right place.

Fail Forward: 1) disable Dynamic Updates on the "temporary master", 2) 
obtain the latest zone information from the "temporary master" (using 
command-line or scripted zone transfer, scp, rsync, FTP or whatever your 
favorite file-transfer mechanism happens to be), 3) bring up the regular 
master with the up-to-date zone data, 4) reconfigure the "temporary 
master" to be the slave again. Steps #1, #2, #3 should of course be 
performed as rapidly as possible, so as not to lose any Dynamic Updates 
that arrive in the interim. Step #4 should be performed shortly 
afterwards, otherwise the slave may start drifting out of sync with the 
master, but it's not usually quite as time-sensitive as the other steps, 
since it's not uncommon for a slave to be temporarily out of sync with 
the master even under normal circumstances. The exception, of course, 
would be if you had to fiddle with SOA.MNAME in the Fail Over procedure, 
in order to satisfy stupid clients. For those stupid clients, you'll 
have to do that all over again, as quickly as possible, when failing 
forward.

If this doesn't meet your requirements for Dynamic Update availability, 
you may need to look at commercial IP Management products, some of which 
have "multi-master" capability. But that's borderline off-topic for this 
list (even though some of those products are BIND-based).

                                                                         
                        - Kevin