From Spam Tools
From: | Bruce Campbell <bc@apnic.net> |
Date: | Fri, 8 Jun 2001 18:36:24 +1000 (EST) |
Reply-To: |
On 7 Jun 2001, spamtools-digest wrote:
> Date: Wed, 06 Jun 2001 14:26:32 -0700
> From: "Ronald F. Guilmette" <rfg@monkeys.com>
> Subject: [spamtools] Domain-based blackhole list
( Personally, I think that ignoring a whole 2LD when a more specific 3LD
exists is stupid, eg 'devils.ru' vs 'free-access.devils.ru', however
thats an issue with how much you want to blinker your virtual
(DNS) eyes ;) )
> I don't have a good answer for that question yet. It appears that neither
> BIND nor any Internet RFCs have really addressed the problem of distributing
> named.conf file changes to multiple slave servers.
The design of most nameserver software assumes a mostly static set of
zones, so changes to the nameserver's configuration file are kept to a
minimum.
> My impression is that other people who have needed or wanted to do this
> sort of thing have been using things like `rdist' and/or `tftp' to perform
> the distributions of the named.conf file changes.
In my case, I've got a number of remote nameservers which are only logged
into once a month. The named.conf files are updated via rsync when
required. A seperate script checks for changes every 15 minutes, and
issues an ndc reload if required (you don't want to just reload every 15
minutes as this slows response time down during this time, and while not
an issue for us, losing your hard-earnt cache is an issue for ISPs).
A suggestion that utilises the DNS as the distribution method would be to
define a zone 'secondaries.example.com' containing information such as:
devils.ru IN A nameserver.to.secondary.from
IN TXT "Secondary a fake devils.ru from
nameserver.to.secondary.from. Blocked
due to child porn, see
http://reporting.url/yadda"
Once you've got your zone 'secondaries.example.com' being secondaried
around the place, you can add/remove fake zones to the master as above (I
believe the gist of the example is easy to understand), it gets
distributed around the place by BIND as per SOA serial# checks.
A script that reads the disk file every <insert time period here> would
then regenerates an appropriate named.conf-format file, and issues ndc
reload if required (return value of RCS is a good guide).
Hrm, the generate a named.conf-format file is simple, as per the following
very-definitely-not-one-line-and-probably-doesn't-work script:
--
#!/usr/bin/perl
open( INPUT, "slave.file" ) || die "slave.file is not readable";
my $magic_cross_check = "secondaries.example.com";
my $cur_origin = undef;
my $cur_rec = undef;
my $comment = undef;
my @prim_ips = ();
while( my $line = <INPUT> ){
if( $line =~ /^\$ORIGIN\s+(\S+)\s*$/ ){
$cur_origin = $1;
}
# Don't attempt to process glue or other cruft.
next unless( $cur_origin =~ /^$magic_cross_check$/ );
if( $line =~ /^(\S+)\s+/ ){
my $new_rec = $1;
if( defined( $cur_rec ) ){
&dump_cur_rec( $cur_rec, $comment, @prim_ips );
}
$comment = undef;
@prim_ips = ();
$cur_rec = $new_rec;
}
if( $line =~ /(A|A6|AAAA)\s+(\S+)\s*$/ ){
push @prim_ips, $2;
}elsif( $line =~ /(TXT)\s+(\S+)\s*$/ ){
$comment .= $2 . " ";
}
}
&dump_cur_rec( $cur_rec, $comment, @prim_ips );
sub dump_cur_rec($$@){
my $cur_rec = shift;
my $comment = shift;
my @masters = @_;
print <<EOT
// Secondaried as per $comment
zone "$cur_rec" {
type slave;
file "sec.$cur_rec";
masters {
EOT
foreach my $to_print( @masters ){
print "\t\t$to_print;\n";
}
print <<EOT
}
}
EOT
}
--
Writing a script to check that the above perlism does produce output, and
issuing ndc reload if needed is your problem ;)
Alternatively, you could ask the authors of nameserver software to add a
feature such 'The nameserver can dynamically receive a list of zones to
secondary, adding and removing zones as appropriately, and this is handled
by the secondarying of a defined zone', eg:
zone "secondaries.example.com" {
type slave;
file "sec.secondaries.example.com";
masters 10.0.0.1;
// Use this zone to provide extra zone secondary definitions.
use-as-secondary-named-conf {
// If we've defined a zone in named.conf, don't permit
// a duplicate zone from this source
permit-redefine-existing-zones no;
// IPs that we can secondary these fake zones from. Other
// nominated IPs within the zone cause an error
allow-secondaries-from {
10.0.0.1; // My primary
10.1.2.3; // I trust this chap to generate my
// fake zones.
}
}
}
Hrm, this actually has possibilities, although I'd want to use DNSSEC to
secondary my magic zone that has effective control of what my nameserver
secondaries.
--
Bruce Campbell <bruce.campbell@apnic.net> +61-7-3367-0490
Systems Administrator APNIC
IECC Searchware 1.3