Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

unknown option 'allow-update'

391 views
Skip to first unread message

schnitzel meister

unread,
May 4, 2005, 4:44:12 AM5/4/05
to
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.

Is it possible to use allow-update globally without adding the
statemet on a per-zone basis?

Thanks a lot.


Tom Schmitt

unread,
May 4, 2005, 11:41:45 AM5/4/05
to

> 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,

This is maybe not what you want: The "allow-update"-statement is used to
allow your secondary (or any other server) to send a DDNS-update to you. Not
for receiving one from you.
For this you need a NS-entry for your new secondary in the zone.


> I get the
> following error:
> named[2108]: /etc/bind/named.conf.options:45: unknown option
> 'allow-update='

Where comes the = from? The statement should be
allow-update { 1.2.3.4; }
There is no =


bye,
Tom.

--
+++ Neu: Echte DSL-Flatrates von GMX - Surfen ohne Limits +++
Always online ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl


David Botham

unread,
May 4, 2005, 11:52:04 AM5/4/05
to
bind-use...@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.
>
>

0 new messages