Checking for zone expiration?

[Alan Batie]

We had a rather key zone mysteriously expire on a slave this morning -
the log files show a transfer a couple weeks ago, but it hadn't been
updated so there was no reason for one since and there were no log
entries about failed connection attempts. I was wondering if there's a
way to check the remaining time on a zone for monitoring? If you fetch
the SOA, you get the full ttl, for obvious reasons, not the server's
timer...

[Barry Margolin]

In article <mailman.837.1337627...@lists.isc.org>,

Check the modification time of the zone file on the slave server, that's
when it was last refreshed.

--
Barry Margolin
Arlington, MA

[Mike Hoskins]

as usual there is more than one way to skin a cat... another
network-based way that doesn't involve local mtime checks would be
querying the master soa from your monitoring host, and then hitting each
slave on port 8080 (or whatever) via statistics-channels (if you enable
it) as mentioned earlier on the list. the statistics view returns xml you
can parse which includes the zones and serials for each zone in each view
on the slave.

[Warren Kumari]

On May 21, 2012, at 3:16 PM, Alan Batie wrote:

> We had a rather key zone mysteriously expire on a slave this morning -
> the log files show a transfer a couple weeks ago, but it hadn't been
> updated so there was no reason for one since and there were no log
> entries about failed connection attempts. I was wondering if there's a
> way to check the remaining time on a zone for monitoring?

Why yes, yes there is…

I wrote a tool to do this a while back -- http://code.google.com/p/dns-slave-expire-checker/

Basically, it runs on the slave and checks to see if the MTIME on the file is getting close to the TTL. If so it will generate a warning, if the zone expires it will generate an error.

I don't think I ever mentioned it's existence to anyone, so YMMV, etc.
Lemme know if it sucks/ has bugs / causes male pattern baldness and I'll try take care of that…

W

> If you fetch
> the SOA, you get the full ttl, for obvious reasons, not the server's
> timer...
>

> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
>
> bind-users mailing list
> bind-...@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>

[Chris Thompson]

On May 21 2012, Alan Batie wrote:

>We had a rather key zone mysteriously expire on a slave this morning -
>the log files show a transfer a couple weeks ago, but it hadn't been
>updated so there was no reason for one since and there were no log
>entries about failed connection attempts.

Do you have "try-tcp-refresh no" in your named.conf options? If so,
and the slave had lost connectivity with the master, the SOA lookups
failing would not have triggered a transfer attempt and so you would
not see any "xfer-in" errors.

> I was wondering if there's a

>way to check the remaining time on a zone for monitoring? If you fetch

>the SOA, you get the full ttl, for obvious reasons, not the server's
>timer...

As Barry Margolin posted, check the mtime on the slave's zone file,
as BIND updates this each time it determines a new zone transfer is
not required.

Often, a good check for there being any zones verging towards
expiring is to look at the end of an "ls -ltr" listing of the
directory in which zone files are stored. For automation, use
something like "find [directory] -name [pattern] -mtime +3".
This works better if the files for "type slave" zones are kept
in a separate directory (or directories) from the "type master"
ones, if any.

--
Chris Thompson
Email: ce...@cam.ac.uk

[Mark Pettit]

On May 21, 2012, at 2:02 PM, Mike Hoskins wrote:

> as usual there is more than one way to skin a cat... another
> network-based way that doesn't involve local mtime checks would be
> querying the master soa from your monitoring host, and then hitting each
> slave on port 8080 (or whatever) via statistics-channels (if you enable
> it) as mentioned earlier on the list. the statistics view returns xml you
> can parse which includes the zones and serials for each zone in each view
> on the slave.

I have not tried this, so pardon me if I misunderstand, but getting the zones and serials from each zone on a slave does not help you determine if a zone is about to expire.

If a zone doesn't change for two years, the serial will never change. But the refresh timer will expire over and over, and each time the zone must be refreshed. The only guaranteed way I know of to determine whether or not it's been refreshed is to check the mtime on the zone file on the slave.

[Mike Hoskins]

-----Original Message-----
From: Mark Pettit <pet...@yahoo-inc.com>
Date: Monday, May 21, 2012 3:53 PM
To: Microsoft Office User <mich...@cisco.com>
Cc: Barry Margolin <bar...@alum.mit.edu>,
"comp-protoc...@isc.org" <comp-protoc...@isc.org>
Subject: Re: Checking for zone expiration?

*sigh* thanks for the stupidity catch, i jumped the gun -- just enabled
statistics-channels and trying to find more uses for it! ;-)

maybe this could be a feature in a future bind release (per-zone
expiration timer in statistics output). we generally always work to move
anything we can from local/shell-based checks to network queries.

[Alan Batie]

Thanks! I'll try the various monitoring options... I don't have
"try-tcp-refresh no", so I'm afraid that doesn't explain it either...

[Mark Andrews]

While not a help at the moment, BIND 9.10 has "rndc zonestatus" which
will report when the zone is due expire.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

[Jan-Piet Mens]

Warren,

> I wrote a tool to do this a while back --
> http://code.google.com/p/dns-slave-expire-checker/

Cool stuff and very useful. I took it for a tiny spin, and here are my
EUR 0.02 :)

1. Doesn't seem to grok all RRtypes in slave zones, due probably to
missing functionality of dnspython; the following diagnostic on a
zone containing a KEY RR:

Unable to parse /var/named/jpmens.org: /var/named/jpmens.org:107:
generic rdata does not start with \#

2. The program should perhaps ignore non-zone files (e.g. *.key, *.jnl,
*.jbk), although that can be influenced with `-f'...

In particular, directories ought to either be skipped or descended
into.

3. Parsing of large zone files takes quite a while... (dnspython)

4. I spent a bit of time debugging becausse a slave zone wouldn't parse:
dnspython raised a dns.zone.NoSOA exception. Only *after* debugging,
did I read the FM to discover that zone file-names are origin names;
maybe add this a bit more prominently to the top of the fine manual? :)

Regards,

-JP

[Matus UHLAR - fantomas]

>On May 21 2012, Alan Batie wrote:
>>We had a rather key zone mysteriously expire on a slave this morning -
>>the log files show a transfer a couple weeks ago, but it hadn't been
>>updated so there was no reason for one since and there were no log
>>entries about failed connection attempts.

On 21.05.12 22:27, Chris Thompson wrote:
>Do you have "try-tcp-refresh no" in your named.conf options? If so,
>and the slave had lost connectivity with the master, the SOA lookups
>failing would not have triggered a transfer attempt and so you would
>not see any "xfer-in" errors.

Isn't there anything other that will trigger transfer attempt, or is it
useless in such case?
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends?