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