Review of using Nag to check MS name resolution in AD environments [XP/2k/2k+3] - MS logon names etc.

[Paul L. Allen]

Stanley Hopcroft writes: 

> This may be of interest to those wishing to monitor their Micorosft
> AD/Dynamic DNS installation by ensuring that signficant names (such as 
> the names of domain controllers corresponding to a domain) are resolved 
> as expected.

I don't *wish* to do this (I think Microsoft products suck big time
on technical grounds and want as little as possible to do with them)
but I also know that one of our bigger clients for monitoring services
would love it if we could check stuff like this (they're also so
clueless that they're astounded we can monitor their IIS web server,
and will get blown away when we start monitoring their MS SQL server,
so unless we tell them this is a possibility they'll never know). 

> The problem for Nagios doing this is that as there are no options in 
> check_dns (1.3.1 and 1.4alpha0) or check_dig to accept RR types. 
> 
> Would this be a useful enhancement of check_dns and or check_dig?

I think it would be useful to allow an option to select RR type and
to do whatever processing is necessary for useful RR types - for
some definitions of "useful." 

The SRV query you just mentioned is useful in this context.  It's too
late for me to start looking at the latest check_dns and compare it
against the Microsoft article to see if a switch for RR type is all
that's needed or if the results of the query need some mangling to
be usable.  I'd hope that either the current options make it flexible
enough to cope or that, with careful design, post-processing options
that have to be added would be flexible enough to cope with all sorts
of other things. 

I can see where other RR types would be useful to some people.  The
paranoid might like to check that AXFR and IXFR fail (the check is
successful if they don't work) to make sure spammers can't harvest
domain names.  I think some people might want to check that at
least two MX records exist for critical, "bet the company" clients (the
ones where "ooops - we forgot to set up a backup MX server in the DNS"
is not an acceptable excuse and you end up bankrupt). 

I don't see checking LOC RRs as being of critical importance, but no
doubt somebody, somewhere, will have a requirement for it (maybe NASA
for its shuttle internet links, although they'd need a very low TTL).
But there could well be other RR types that some people would find it
useful to check, which is why I hope the post-processing is fairly
flexible (you can't cope with everything, but you may be able to cope
with common RR types if you give it a bit of thought). 

I can see that some people would like the TSIG and related RR types,
but that is probably a LOT of work. 

So, after that Joycian stream-of-consciousness, yeah, go for the SRV.
My preference is to add an RR type switch and at least enough
result-mangling switches to allow the MS SRV stuff to be handled.
Anything else is a bonus. 

-- 
Paul Allen
Softflare Support 




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Nagiosplug-devel mailing list
Nagiosplug-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f at public.gmane.org
https://lists.sourceforge.net/lists/listinfo/nagiosplug-devel
::: Please include plugins version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null