DNS Redundancy After a Disaster

Holger Honert holger.honert at signal-iduna.org
Tue Jan 24 08:33:25 UTC 2006


Hi Martin,

maybe it's not the answer you are expecting but we have succesfully 
implement a failover for our master dns server (ns).
Therefore we modified a script written by Bob Flickinger (Cheap IP 
TakeOver) and used rsync for getting or pushing
zone data and named.conf to our failover server (ns1).

Here are the scripts:

#!/bin/bash
## Cheap IP Take Over Script running on ns1 ##
# taken from Rob Flickenger
# IP Take Over for DNS

# Variable specified for the Alias Interface

PRI="VIPA"
WATCH_IP="10.11.12.253"
PRI_IP="10.11.12.123"
MASK="255.255.255.0"
BCAST="10.12.112.255"

# General Variables

PAUSE=3
FAILED=0

PATH=/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/sbin/:/usr/sbin

while true; do
 if ! ping -c 1 -w 1 $WATCH_IP > /dev/null; then
   ((FAILED++))
 else
   if [ $FAILED -gt 2 ]; then
     ifconfig eth0:$PRI down
     # clear arp cache on routers
     /root/scripts/cl-arp.sh > /dev/null
     /etc/rc.d/named stop
     # Syncing data back to primary server
     rsync -auz -e "ssh -i /chroot/named/etc/cron/ns-rsync-key" 
/chroot/named/etc/namedb/secondary/db.* 
bind at ns:/chroot/named/etc/namedb/secondary
     rsync -auz -e "ssh -i /chroot/named/etc/cron/ns-rsync-key" 
/chroot/named/etc/namedb/primary/db.* 
bind at ns:/chroot/named/etc/namedb/primary
     rsync -auz -e "ssh -i /chroot/named/etc/cron/ns-rsync-key" 
/chroot/named/etc/named.conf bind at ns:/chroot/named/etc
   fi
   FAILED=0
 fi;

 if [ $FAILED -eq 2 ]; then
  ifconfig eth0:$PRI $PRI_IP netmask $MASK broadcast $BCAST
  # Loeschen des Arp-Eintrages
  /root/scripts/cl-arp.sh > /dev/null
  /etc/rc.d/named start
 fi
 sleep $PAUSE
done

The synchronization from pri. to failover server (because of dyn. DNS 
Zones) goes every 5 min:

#!/usr/bin/bash
### its AIX ####

# rsync mit -truz means time saving, recursive, update only if newer and 
z compressed!

# for secondary zones
rsync -auz -e "ssh -i /chroot/named/etc/cron/nshh-rsync-key" 
/chroot/named/etc/namedb/secondary/db.* 
bind at ns1:/chroot/named/etc/namedb/secondary

rsync -auz -e "ssh -i /chroot/named/etc/cron/nshh-rsync-key" 
/chroot/named/etc/namedb/primary/db.* 
bind at ns1:/chroot/named/etc/namedb/primary

# syncing reverse-zones
rsync -auz -e "ssh -i /chroot/named/etc/cron/nshh-rsync-key" 
/chroot/named/etc/namedb/primary/*.arpa 
bind at ns1:/chroot/named/etc/namedb/primary

# syncing named.conf
rsync -auz -e "ssh -i /chroot/named/etc/cron/nshh-rsync-key" 
/chroot/named/etc/named.conf bind at ns1:/chroot/named/etc

A recommended reading for the rsync feature is www.jdmz.net/ssh.

Due to this config dyn. DNS Zones may only differ for 5 min. and the 
loss of connectivity to the pri. ip-inmterface is not more than 3 
seconds (in worst case and is proved!).

Regards

Holger

Martin McCormick schrieb:
> 	In discussing various disaster scenarios, we have been thinking
> of what we would need to do if some mammoth event destroyed most of our
> infrastructure on our campus, rendering our local master and slave
> DNS's inoperable or inaccessible.
>
> 	One obvious solution is to install a slave in a nearby town
> which will quietly mirror all the updates to all our zones and then
> become a master if we need it to.
>
> 	One of the beautiful things about the DNS protocol is that one
> should have one or more slaves listed along with the master.  Other
> than not being able to dynamically update one's zones, how bad does
> service get if the master is dead and the only working DNS is an
> off-site slave?
>
> 	Do large companies do anything special to insure that if a
> master DNS fails, there will always be something at the IP address of
> the master?
>
> 	Our DNS's are running on FreeBSD and have a fabulous track
> record for robustness so I am fortunate that we don't get to see much
> in the way of failure modes, but we must 
> always plan for the worst and be able to give truthful answers to the
> other groups we serve.
>
> 	Thanks for any ideas, war stories, etc.
>
> Martin McCormick WB5AGZ  Stillwater, OK 
> OSU Information Technology Department Network Operations Group
>
>
>
>
>   




More information about the bind-users mailing list