BIND9 dynamic configuration sharing from a master
/dev/rob0
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:
$INCLUDE "/etc/named.blacklist";
and a simple null zone file which sets SOA, NS and A records to the
master, and then sets a similar "*" A record.
I know I can rig this up manually quite easily, but I just wondered if
there was a means to dynamically update a slave's configuration within
BIND's own capabilities.
#v+
if \\! grep "$FEATURE" "$BIND_FEATURES" ; then
echo "$FEATURE" >> "$BIND_WISHLIST"
fi # to say it in sh ... :)
#v-
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".
Has anyone else done something like this? Comments appreciated.
--
/dev/rob0 - preferred_email=i$((28*28+28))@softhome.net
or put "not-spam" or "/dev/rob0" in Subject header to reply
/dev/rob0
In article <bv6hol$3tk$1...@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 <ro...@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 <ro...@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. :)
Barry Finkel
>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:
> $INCLUDE "/etc/named.blacklist";
>and a simple null zone file which sets SOA, NS and A records to the
>master, and then sets a similar "*" A record.
>
>I know I can rig this up manually quite easily, but I just wondered if
>there was a means to dynamically update a slave's configuration within
>BIND's own capabilities.
>
>#v+
> if \\! grep "$FEATURE" "$BIND_FEATURES" ; then
> echo "$FEATURE" >> "$BIND_WISHLIST"
> fi # to say it in sh ... :)
>#v-
>
>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".
>
>Has anyone else done something like this? Comments appreciated.
There is no way in BIND nor in the DNS protocol for a master to send
configuration updates to a slave. And I am not sure that I would
want a master to update a slave's configuration. It would require
some security checking.
> the slave retrieves /etc/named.blacklist from the master
There is no way in BIND to do this. This could be done via an
non-DNS FTP.
----------------------------------------------------------------------
Barry S. Finkel
Computing and Instrumentation Solutions Division
Argonne National Laboratory Phone: +1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 222, Room D209 Internet: BSFi...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
Kevin Darcy
>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:
> $INCLUDE "/etc/named.blacklist";
>and a simple null zone file which sets SOA, NS and A records to the
>master, and then sets a similar "*" A record.
>
>I know I can rig this up manually quite easily, but I just wondered if
>there was a means to dynamically update a slave's configuration within
>BIND's own capabilities.
>
Nope. I've submitted an "autoslaving" patch, but it basically sank
without a trace.
One alternative method is to have a special zone, slaved by the entire
community of slaves, containing no leaf records except one TXT or PTR
record (_nota_bene_, PTR records can benefit from label compression)
naming each zone that should be slaved. Every time you add/delete a zone
to/from the master, add/delete the corresponding record to/from that
zone too. All of the slaves then have a cron job to check the "special"
zone and if it has changed, add and/or delete zones from their configs.
If one hosted the "special" zone on a separate nameserver instance, then
one could theoretically even use "views" to give out different lists to
different communities of slaves (one probably wouldn't want to do this
on the main master instance, since then one would have to repeat all of
those zone definitions in each view).
>#v+
> if \\! grep "$FEATURE" "$BIND_FEATURES" ; then
> echo "$FEATURE" >> "$BIND_WISHLIST"
> fi # to say it in sh ... :)
>#v-
>
>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".
>
>Has anyone else done something like this? Comments appreciated.
>
OK, that's kind of like the "special zone" method, except that you're
grabbing a whole include-file from the master instead of configuring
individual zones, and for change notification, you're periodically
grabbing a single DNS record instead of slaving a whole "special" zone.
One variation of the "special zone" method that comes closer to what you
are doing is for the cron script to issue IXFRs (requires a
suitably-modern version of "dig") instead of waiting for the zone
transfers to occur "naturally". One of the beauties of the "special
zone" method is that it doesn't require any non-DNS transfer mechanisms
or the establishment of trust relationships for same. So it works well
across trust boundaries (e.g. firewalls) and/or multiple levels of slaves.
- Kevin
Barry Finkel
>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:
> $INCLUDE "/etc/named.blacklist";
>and a simple null zone file which sets SOA, NS and A records to the
>master, and then sets a similar "*" A record.
>
>I know I can rig this up manually quite easily, but I just wondered if
>there was a means to dynamically update a slave's configuration within
>BIND's own capabilities.
>
>#v+
> if \\! grep "$FEATURE" "$BIND_FEATURES" ; then
> echo "$FEATURE" >> "$BIND_WISHLIST"
> fi # to say it in sh ... :)
>#v-
>
>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".
>
>Has anyone else done something like this? Comments appreciated.
There is no way in BIND nor in the DNS protocol for a master to send
configuration updates to a slave. And I am not sure that I would
want a master to update a slave's configuration. It would require
some security checking.
> the slave retrieves /etc/named.blacklist from the master
There is no way in BIND to do this. This could be done via an
/dev/rob0
>>I know I can rig this up manually quite easily, but I just wondered if
>>there was a means to dynamically update a slave's configuration within
>>BIND's own capabilities.
>>
> Nope. I've submitted an "autoslaving" patch, but it basically sank
> without a trace.
>
> One alternative method is to have a special zone, slaved by the entire
> community of slaves, containing no leaf records except one TXT or PTR
> record (_nota_bene_, PTR records can benefit from label compression)
> naming each zone that should be slaved. Every time you add/delete a zone
> to/from the master, add/delete the corresponding record to/from that
> zone too. All of the slaves then have a cron job to check the "special"
So there seems to be no getting around the cron job.
>>Has anyone else done something like this? Comments appreciated.
>>
> OK, that's kind of like the "special zone" method, except that you're
Yes it is, it seems very similar. It's working well. I expanded it, even
broadened the purpose, by now sharing a modular ACL file and a list of
slaved domains in addition to the "blacklist" thing that started it. I
can't do major configuration changes this way, but it does what we're
likely to need most often.
> transfers to occur "naturally". One of the beauties of the "special
> zone" method is that it doesn't require any non-DNS transfer mechanisms
> or the establishment of trust relationships for same. So it works well
> across trust boundaries (e.g. firewalls) and/or multiple levels of slaves.
Yes. It's too bad that the "also-notify" feature can't trigger an action
external to BIND, but like I said, this is easily worked around. Thanks
Kevin and Barry for your comments.