Promoting slave to master DNS server with dynamic updates

John Miller johnmill at brandeis.edu
Thu Sep 11 15:02:53 UTC 2014


Hi Eric,

Depends on how long you can live without dynamic updates, and how many
dynamic updates it's acceptable to lose in the event of a master failure.
Journal files are synced every 15 minutes, so in the event of a master
failure (in a single-master situation), you've lost at most 15 minutes'
worth of updates.  Stand up a new master (with config management software,
doable in a few minutes), and you're good to go.

But why have just a single master?  If you're worried about the primary
going down, just have a warm standby ready to go.  To keep zone data in
sync, you could use shared storage, a replicated database (BIND does
support a database backend), or perhaps some sort of also-notify
configuration.  To do the failover itself, you could use something like
Pacemaker/Corosync, ucarp, or similar.  Just pass a VIP back/forth between
the two -- your NS records would only use the VIP.

The big issue I see with converting a slave to a master is that you'd have
to change all of your zone definitions, change your named.conf, and do so
under time pressure.  Then, when the master came back online, you'd have to
change your zone definitions again.  With config management software, not
that hard to do, but servers are cheap these days -- easier just to create
a failover pair (or group) for your master, then stand up as many slaves
(doing update forwarding) as you need.  If you purchase a DNS appliance
(Infoblox, SolidServer, Bluecat, etc.), this is how they handle things.

Separate issue: you might think about trying out RHEL 6 -- it's using a
much newer version of BIND which has some updated tools (particularly rndc
freeze/thaw, HTTP stats interface).

John

On Thu, Sep 11, 2014 at 4:48 AM, <Eric.BERTHIAUME.external at banque-france.fr>
wrote:

> Hello DNS gurus,
>
>
>
> New on the list, I’ve been tasked by my manager to revamp our dns
> infrastructure.  I think this list is the best place to get answers.
>
>
>
> Bind 9.3.6-16 running on RHEL5.7
>
>
>
> Right now everything run’s on manually editing zone files but we have
> recently integrated vmware orchestrator (automatic deployment of linux
> vm’s) in the mix and that complicates things for automated processes.  Add
> Autosys to this and you have one big messy DNS infrastructure and of course
> no team wants to change their work flows (classic).
>
>
>
> So I’ve written a basic script that would allow everyone (admin’s, vmware,
> autosys) to use dynamic updates with nsupdate for all tasks.  Everything
> works dandy but a simple question remains:
>
>
>
> If the primary goes down for whatever reason, how can we quickly continue
> to update our DNS records on the secondary?  What are the options?
>
>
>
> -          Classic slave/master change manually editing the named.conf?
> What happens to everything in the jnl file on the master if it crashes
> before the dump and zone transfer?  Lost?
>
> -          Nsupdate special ninja trick?  Read something about updating
> the SOA through dynamic update but didn’t fully understand that process.
>
> -          Pray that we get the primary up?
>
>
>
> The last option would normally be the logical choice but like I said our
> DNS infrastructure is a mess and those autosys process control DNS records
> for their “failover” feature (yeah I know) so we need a
> super-lightning-fast switch if we do not want production to stop.
>
>
>
> Of course the best solution would be something automatic but I haven’t
> seen anything anywhere.  If it’s manual so be it maybe I would be able to
> write a script that could be used by support and minimize human errors.
>
> I’m already at least pushing for a more recent bind version and of course
> if a special feature exist (maybe I’ve missed it) that provides an easier
> solution that would be a super argument to push for something with more
> features.
>
>
>
> Thanks in advance.
>
>
>
> Eric
>
>
>
> **************************************************************
> Ce courrier électronique, y compris les pièces jointes, est à l'attention
> exclusive des destinataires désignés et revêt un caractère confidentiel.
> Si vous recevez ce courrier électronique par erreur, merci d'en informer
> sans délai l'expéditeur et de supprimer son contenu et ses pièces jointes.
>
> Le contenu de ce courrier électronique ne pourrait engager la
> responsabilité de la Banque de France que s'il a été émis par une personne
> dûment habilitée agissant dans le strict cadre des fonctions auxquelles
> elle est employée et à des fins non étrangères à ses attributions.
>
> L'expéditeur de ce courrier électronique ne peut pas garantir la sécurité
> de l'acheminement par voie électronique et ne saurait dès lors encourir une
> quelconque responsabilité en cas d'altération de son contenu.
>
> **************************************************************
>
> This e-mail, attachments included, is intended solely for the addressees
> and should be considered as confidential.
> Should you receive this message by error, please notify the sender
> immediately and destroy this e-mail and its attachments.
>
> Banque de France cannot be considered as liable for the content of this
> message unless the sender has been duly authorized and has acted strictly
> in the course of his/her tasks as an employee.
>
> The sender of this e-mail cannot ensure the security of its electronic
> transmission and consequently will not be liable should its content be
> altered.
> **************************************************************
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>



-- 
John Miller
Systems Engineer
Brandeis University
johnmill at brandeis.edu
(781) 736-4619
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140911/aed0d723/attachment.html>


More information about the bind-users mailing list