Querying the SOA timers

[pyh at mail.nsbeta.info]

I once wrote a perl script for nagios plugin and posted it to the list.
Just to check both master and slave's serial number to see if they are the 
same to verify the zone data in every name server is correct. 

#!/usr/bin/perl
use strict;
use Net::DNS;
use Getopt::Std; 

my %opts;
getopts('hm:s:z:', \%opts);
if ($opts{'h'}) {
    usage();
}
my $master = $opts{'m'} || usage();
my $slave = $opts{'s'} || usage();
my $zone = $opts{'z'} || usage(); 

my $s1 = qrsoa($master,$zone);
my $s2 = qrsoa($slave,$zone); 

if ($s1 != -1 && $s1 == $s2) {
    print "OK\n";
    exit 0;
} else {
    print "CRITICAL: zone $zone sync error\n";
    exit 2;
} 


sub qrsoa {
    my $host = shift;
    my $zone = shift;
    my $res   = Net::DNS::Resolver->new(nameservers => [$host]);
    my $query = $res->query($zone, "SOA");
    return $query ? ($query->answer)[0]->serial : -1;
} 

sub usage {
    print <<EOF;
    Usage: $0 -m 8.8.8.8 -s 8.8.4.4 -z example.com
    -m  master DNS ip or name
    -s  slave DNS ip or name
    -z  zone name
    -h  show this help page
EOF
    exit 0;
} 

HTH.
Regards. 

Balder writes: 

> Hello, 
> 
> I have had a bit of a Google but I have been unsuccessful in finding
> an answer to this one.   We currently have bind acting as a slave
> server for a number of different zones.  The owners of these zones
> sometimes change configuration without letting us know, resulting in
> zones expiring.  I would like to know if there is a way to query how
> long is left to run on the various timers listed in the SOA.   What i
> would like is the following information about a given zone
>        * The Date and time the last notify was received (was it successful)
>        * The Date and time the zone was last refreshed (was it successful)
>        * The Date and time of the next refresh
>        * The Date and time the zone will expire
> Is this information readily available in bind and if so how would i
> query it.  If not, does anyone have  any ideas about how this
> information could be reliably collected.  This information would more
> then likely be used in either a nagios check or a daily email. 
>