Am 08.02.2016 um 14:59 schrieb Warren Kumari: > The standard, compatible way to do this is simply to do a lookup for the > SOA record and make sure that the serial number matches what you expect > it to be / what is on the master. I'm not sure what monitoring tool you > are using (or if you are writing your own), but most standard monitoring > tools have such a script already written - > e.g: > https://exchange.nagios.org/directory/Plugins/Network-Protocols/DNS/checkexpire/details
This does not detect problems between the master and slave as long as the master is not updated. Further I can not fetch the serial easily from the slave as our slave is a "bump in the wire" signer, so the SOA is the internal increased "DNSSEC serial". So I would need to extract it from the local zone files/journal. > I believe that BIND also updates the mtime on the zone file when it does > the check (not only when something changes): > root@eric:/etc/namedb/slave# date > Mon Feb 8 08:36:58 EST 2016 > root@eric:/etc/namedb/slave# ls -al superficialinjurymonkey.com > <http://superficialinjurymonkey.com>* > -rw-r--r-- 1 named named 714 Feb 8 03:51 superficialinjurymonkey.com > <http://superficialinjurymonkey.com> > -rw-r--r-- 1 named named 1236 Feb 8 03:51 superficialinjurymonkey.com.jnl > root@eric:/etc/namedb/slave# > > So, you should be able to just run 'ls' and see if the 'mtime' is larger > than you expect... This is an interesting hint and good starting point. Thanks. Nevertheless, additionally I would to need to extract the SOA refresh value for every zone to find out if a zone is not fresh any more. Thanks Klaus _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
