BIND9 dynamic configuration sharing from a master

/dev/rob0 rob0 at gmx.co.uk
Tue Jan 27 22:57:18 UTC 2004


[it's taking a long time to see my posts come back!]

In article <bv6hol$3tk$1 at sf1.isc.org>, I wrote:
> Is there any means within BIND itself to share configuration changes at
> a master nameserver among slaves? The site I set up last week wants to
> block a blacklist of domains in DNS. I've got that all rigged up on the
> master, using an $INCLUDE in named.conf:

Oops, sorry, that's just "include". I got confused with the zone file
syntax. Anyway I do have it working.

> I know I can rig this up manually quite easily, but I just wondered if
> [snip]
> I think I *will* use named to signal the slave that an update is needed.
> I'll make a "dnsupdateconf" A record pointing to the master's IP, and
> set a TXT record with a timestamp of the last update. The TXT record
> will be cached on disk at the slave and compared against the output of
> "host -t TXT dnsupdateconf" in a cron job. If the TXT value changes, the
> slave retrieves /etc/named.blacklist from the master and "rndc reload".

I did this, except the TXT record is on the name for the SOA/NS. No need
for a new "A" record.

Here's the script on the server which runs whenever the configuration is
changed:
#v+
#!/bin/sh
# new-blacklist.sh - run by the Webmin module when the blacklist is
#   changed, to signal slaves to update their configurations
# 2004/01/26 - /dev/rob0 <rob0 at gmx.co.uk>

# This will be used to tally up errors
ERRBASE=0

# the present number of seconds since 1970/01/01 00:00:00 GMT
NOW=`date +%s`

# the nameserver to update
DNS=put.your.NS.record.here.    # remember the trailing period. :)

# remove the existing TXT record for $DNS, replace it with $NOW
# NOTE: the blank lines are necessary for nsupdate!

nsupdate << EOF &> /dev/null
update delete $DNS TXT

update add $DNS 38400 TXT $NOW

EOF
# record exit value
NSUP=$?

# check it
NEW=`host -t TXT ns | cut -f2 -d\"`
# echo NOW\=$NOW NEW\=$NEW
if [ ! "$NOW" -eq "$NEW" ] ; then
  echo "nsupdate failed (code $NSUP): $NEW should be $NOW"
  # Add 65 to our exit code
  ERRBASE=$(($ERRBASE + 65))
fi

# implement the change
rndc reload
# Add rndc's exit code to ours
ERRBASE=$(($ERRBASE + $?))
# echo ERRBASE\=$ERRBASE
exit $ERRBASE
#v-

This one runs hourly on the slaves, although I'm thinking perhaps I
could do this with an also-notify directive?
#v+
#!/bin/sh
# confupdate.sh - dynamic updating of DNS blacklist on slave nameserver
# 2004/01/26 - /dev/rob0 <rob0 at gmx.co.uk>

cd /var/named
# Our master nameserver is called "ns" and we have the domain in the
# search in resolv.conf. Change the following to suit.
UPDATE=`host -t TXT ns ns | grep text | cut -f2 -d\"`
if [ -z "$UPDATE" ] ; then
  echo "unspecified error obtaining DNS record"
  exit 65
fi
PREVIOUS=`< confupdate`
# You should manually create /var/named/confupdate to avoid this error.
# "date +%s > /var/named/confupdate" will do the job.
if [ -z "$PREVIOUS" ] ; then
  echo "unspecified error with confupdate file"
  exit 66
fi
if [ "$UPDATE" -eq "$PREVIOUS" ] ; then
  echo "configuration is up-to-date"
  exit 0
fi

echo "current ns value $UPDATE"
echo "previous ns value $PREVIOUS"
echo -en "\tfetching new blacklist from master... "
# httpd is running on the master server "ns", and in the /files/ virtual
# directory we have a symlink to the actual file in /etc. If you're not
# running httpd, any other means of automated file transfer would do.
if wget -q http://ns/files/named.blacklist ; then
  echo " done."
else
  echo " FAILED."
  exit 67
fi

mv named.blacklist /etc || exit 68

rndc reload || exit 69
echo "Successfully updated DNS blacklist."

echo $UPDATE > confupdate || exit 70
exit 127
#v-

So what's the point of all this? I hope it helps someone if in fact this
is the best way to propagate configuration changes from a master to a
slave nameserver. If not I hope it annoys someone enough to inspire him
to tell me a better way. :)
-- 
  /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
  or put "not-spam" or "/dev/rob0" in Subject header to reply


More information about the bind-users mailing list