This is a discussion on Re: DDNS Issues With Secondary/Slave Configurations - DNS ; 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 ...
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
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).