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

[Subhendu Ghosh]

On Thu, 26 Feb 2004, Paul L. Allen wrote:

> 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. 
> 
> 

Yes to an option to handle RR - but even with SRV we need to handle 
priority (as with MX).

using resolver interface would be nice
-- 

-sg