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