<div dir="ltr">Mark<div><br></div><div>I think more DNS checks would be really useful for many, but I would say that we'd be going down a rabbit hole chasing this.  The DNS check you've described is worthwhile to do for many people (myself included), but is only one of many that would need to be done to ensure that a name or domain is resolvable.</div>

<div><br></div><div>For example, should the same checks be done for the parent zone(s)?  Should we check the WHOIS record for impending zone expiry date?  Should we check that there is more than one NS record?  Should we check that the NS records don't all point at the same IP addresses?  For high-turn-over (eg dynamic) zones, the masters nameservers might only rarely be in sync, or the serial number might typically change before all of the SOA lookups are complete.  What about when there's a stealth master that can't be queried?  What about reporting on slave zones that about to expire?  Or zones that have semantic errors such as MX records that refer to CNAME records, or host records with underlines, or CNAME loops?  Should we be checking DNSSEC signatures?</div>

<div><br></div><div>Hmm, that list turned into a bit of a rant, really.  Sorry.  You can probably guess that I think about this stuff a fair bit, and many of the things I've listed are more "niche" than others, but still.</div>

<div><br></div><div><div>For each possible test anyone might want to include, each installation might need different ways of reporting and/or recording statistics, and so it would get complex very quickly.  Do you report a yellow if only 3 out of 4 NS servers are the same, or 7 out of 8?  If the master's serial number somehow goes backwards, do we show seven servers wrong or is it just one?  You you assume that the master is in the MNAME field, or would you get the option to override?  If two hosts have different values for the MNAME field, which do you consider master?  Or in this case, do you care?  Also, which host(s) would you report the status against?  Do you have to create hosts.cfg entries for every NS, and then maintain that list by tracking the NS records as they change over time, or do you create a pseudo-host for each domain, or some of each?</div>

<div><br></div><div>Woops, there I go ranting again, sorry.</div><div><br></div><div>Such complexity and flexibility is better implemented outside Xymon, to keep the Xymon core as simple and easy to maintain as possible.<div>

<br></div><div>I think the best solution is for each installer to decide on their own detection and reporting requirements, and create or install ext scripts to suit each case.  In fact, I'm surprised there aren't any on Xymonton.org already, but that's where I would expect such code to reside.  I'd be happy to assist with developing ext scripts for enhanced DNS checks.</div>

</div></div><div><br></div><div>J</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 8 January 2014 07:56, Mark Felder <span dir="ltr"><<a href="mailto:feld@feld.me" target="_blank">feld@feld.me</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there any hope of enhancing the DNS check capability beyond its<br>
current functionality? It would be nice if it could detect all the NS<br>
for the domain you're monitoring to compare the SOA serial of all the NS<br>
servers and go red if they're not in sync.<br>
_______________________________________________<br>
Xymon mailing list<br>
<a href="mailto:Xymon@xymon.com">Xymon@xymon.com</a><br>
<a href="http://lists.xymon.com/mailman/listinfo/xymon" target="_blank">http://lists.xymon.com/mailman/listinfo/xymon</a><br>
</blockquote></div><br></div>