How to check slave zone freshness

[Warren Kumari]

There is also transfer logs -- you could watch those and see if you are
getting any failures, but this seem, um, more brittle..

W

On Mon, Feb 8, 2016 at 6:22 AM Klaus Darilion <klaus.mailinglists at pernau.at>
wrote:

>
>
> 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 at eric:/etc/namedb/slave# date
> > Mon Feb  8 08:36:58 EST 2016
> > root at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160208/e7ec3736/attachment.html>