unknown option 'allow-update'
David Botham
DBotham at OptimusSolutions.com
Wed May 4 15:52:04 UTC 2005
bind-users-bounce at isc.org wrote on 05/04/2005 04:44:12 AM:
> Hello.
> I'm running bind 9.2.4-1 on Debian Sarge (frozen!).
>
> I currently have a primary name server and a secondary name server.
> The plan is to add a third shortly. Every zone on the primary needs to
> be pushed to the slaves when a zone is updated. This works, but it's
> not secure.
>
> Before I look at TSIG for doing this "properly" I'd like to get
> ip-restricted updates working.
> When using allow-update in the options part of the config, I get the
> following error:
> named[2108]: /etc/bind/named.conf.options:45: unknown option
'allow-update=
> '
>
> I'm guessing this is because it must be specified on a per-zone basis,
> but this doesn't feel right. If I wanted to restrict updates across
> all zones, but enable them on an individual zone, I'd expect to have
> allow-update { none; } in options, and then allow-update { somewhere;
> } in each zone.
Correct. allow-update is specified on a zone by zone basis. The
allow-update statement articulates those hosts that are allowed to perform
dynamic updates to the zone. It does not articulate who can perform a
zone transfer of the zone, which, is what secondaries/slave do when they
what to get the most recent copy of the zone from the master.
You can specify a global option of allow-transfer to articulate who can
perform the zone transfers. Either IP address ACL's or TSIG can be
specified. See section 4 of the ARM for a brief explaination of how to
use TSIG for this purpose. It is pretty straight forward.
>
> Is it possible to use allow-update globally without adding the
> statemet on a per-zone basis?
No. The allow-update statement does not have a global context. I would
not expect this behavior to change. After all, do you really want to
globally set dynamic DNS updates on every zone that the name server hosts?
I think the answer to that question is no.
I think you are looking for allow-transfer instead.
However, if you really do want to set dynamic updates globally, use a perl
script to generate your name.conf config file zone statements and add an
allow-update sub-statement to each zone statement. You can alter the code
below for this purpose:
#!/usr/bin/perl
#Get the IP of the Master for these zones...
# David Botham
print "Enter a description for this segment: ";
$discription = <STDIN>;
chomp $discription;
print "Enter the IP address of the Master name server for these zones: ";
$MASTER = <STDIN>;
chomp $MASTER;
print "Enter the sub-directory for these zones: ";
$DIRECTORY = <STDIN>;
chomp $DIRECTORY;
#Open the file containing the zone names, one per line...
print "Enter the name of the file containing zone list: ";
$DLIST = <STDIN>;
chomp $DLIST;
open(INFILE, "$DLIST");
print "Enter the name of the Zone DB File: ";
$ZONEDB = <STDIN>;
chomp $ZONEDB;
#Open the output files, one for the Master named.conf and one for the
Slave named.conf
open(SLAVE, ">$DLIST.slave.txt");
open(MASTER, ">$DLIST.master.txt");
print MASTER "//\n// $discription\n//\n";
print SLAVE "//\n// $discription\n//\n";
#Read the list of domains from the file containing the zone names...
@DOMAINS = (<INFILE>);
#Write the zone directives to the conf files...
foreach $DOMAIN (@DOMAINS) {
chomp $DOMAIN;
print MASTER "zone \"$DOMAIN\"\{\n\ttype master\;\n\tfile
\"$DIRECTORY\/$ZONEDB\"\;\n\t\n\}\;\n";
print SLAVE "zone \"$DOMAIN\"\{\n\ttype slave\;\n\tfile
\"$DIRECTORY\/$DOMAIN.$ZONEDB\"\;\n\tmasters\{$MASTER\;\}\;\n\}\;\n";
}
#Close all files, write an error message if not sucessful...
close INFILE || die "could not close file $!";
close MASTER || die "could not close file $!";
close SLAVE || die "could not close file $!";
Please keep in mind that this is one of the first perl scripts I wrote and
it is not pretty, but, it gets the job done...
It generates both the master and slave named.conf zone statements.
Be sure to copy it to a text editor and correct any line wrapping that may
have occurred during email transit.
hth,
Dave...
>
> Thanks a lot.
>
>
More information about the bind-users
mailing list