I don't know if I'm misreading the OP, but if the plugins start timing out on only the boxes whose primary DNS is being rebooted, would adding a caching DNS server to the Nagios box really make a difference?<br><br>

I think the root cause to these timeouts is that the Nagios plugin timeout is happening before the connection to the primary DNS on the target machine has a chance to time out and then connect to the secondary DNS.<br><br>
The correct course of action to resolve this would be to either make sure that the DNS connection on the target machines fail quicker, or that Nagios/the plugin waits longer for a result from the check. The DNS failover is working as designed here but you're not giving it enough time to kick in.<br>
<br><div class="gmail_quote">On Tue, Jun 9, 2009 at 5:37 PM, Russell Adams <span dir="ltr"><<a href="mailto:RLAdams@adamsinfoserv.com" target="_blank">RLAdams@adamsinfoserv.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Really the best choice is to using caching DNS on the Nagios<br>
server. I'd recommend dnsmasq, it just does caching locally without<br>
needing to do big zone transfers. It has low overhead and simple<br>
configuration as a result.<br>
<br>
Enjoy.<br>
<div><div></div><div><br>
On Tue, Jun 09, 2009 at 11:19:20AM -0400, Andrew Davis wrote:<br>
> I've observed an interesting issue with Nagios. Our environment is a mix<br>
> of UNIX, Linux, Apple, and Windows. The core of the network is Active<br>
> Directory including two AD servers that are both our primary, internal<br>
> DNS servers. All non-Windows systems have a resolv.conf that looks like:<br>
><br>
>    *nameserver 10.1.1.13<br>
>    nameserver 10.1.1.14<br>
>    domain int.our.domain<br>
>    search int.our.domain*<br>
><br>
> About half of the servers have the nameserver entries inverted (ie: .14<br>
> first, .13 second).<br>
><br>
> The issue is that anytime one of the nameservers is rebooted (at least<br>
> once a month if staying current on patches thanks to Black Tuesdays),<br>
> whichever hosts have that nameserver listed first in its resolv.conf<br>
> start throwing the following errors:<br>
><br>
>    *CRITICAL - Plugin timed out while executing system call.*<br>
><br>
> This occurs for multiple tests for each host. Obviously, there's a name<br>
> resolution correlation here. If the nameserver with .13 is rebooted, all<br>
> hosts (about half of them) that list this IP first in their resolve.conf<br>
> then timeout for multiple tests. If the .14 server is rebooted, all the<br>
> other hosts timeout. Interestingly, none of the Windows clients issue<br>
> errors... only UNIX, Linux, and Mac's... only those with an<br>
> /etc/resolv.conf. The end result is a host of "false positives", but<br>
> more importantly it looks bad on availability reports and causes<br>
> phones/pagers to go ballistic with unneeded emails.<br>
><br>
> I'm trying to find a solution and I can't find one that I like:<br>
><br>
> Solution 1) is to cluster the DNS servers. We have lots of clusters<br>
> here. This isn't good, though, as you don't normally cluster DNS<br>
> servers... they're meant to be redundant for a reason... one fails and<br>
> it uses the next one.<br>
><br>
> Solution 2) is to setup a service/host dependency. My thought would be<br>
> either a host dependency that says if either .13 or .14 are down, then<br>
> don't alert for any other host that uses them. Or a service to host<br>
> dependency... if the DNS service is down, then don't alert on any of<br>
> these dependent hosts. Honestly, I'm not sure if you can mix host and<br>
> service dependencies like this... plus... if the DNS server is actually<br>
> down, then the DNS service is down, so better to use a host dependency.<br>
> The problem is that now we're not alerting on any dependent hosts which<br>
> themselves could have a legitimate issue we want to know about. Plus,<br>
> what happens if the DNS server actually dies and take a few hours/days<br>
> to rebuild/restore? At this point, the dependent hosts aren't watched<br>
> for a very long time.<br>
><br>
> Solution 3) is to setup a UNIX/Linux DNS server that slaves all zones<br>
> from the AD servers and have all UNIX/Linux/Apple clients query from<br>
> this server. This would work except that A) I need two of them to keep<br>
> redundancy and B) I've now added an extra layer of complication to<br>
> resolve an application (Nagios)... not exactly good practice.<br>
><br>
> Solution 4) is to set the timeout value of a host querying a DNS server.<br>
> Perhaps adjust the client to timeout on the first listed nameserver<br>
> after only 10 seconds, then try the next one? Since most Nagios tests<br>
> have a minimum timeout value of 30 seconds, if the first DNS query timed<br>
> out after 10 seconds, it would go to the next one with, hopefully,<br>
> enough time to respond. The downside is having to adjust every single<br>
> server.<br>
><br>
> Has anyone else seen this? Anyone else using Windows AD servers to<br>
> provide DNS for *nix servers?<br>
><br>
> --<br>
><br>
><br>
>  A. Davis<br>
>  Email:     <a href="mailto:nccomp@gmail.com" target="_blank">nccomp@gmail.com</a><br>
><br>
>  "There is no limit to what a man can accomplish<br>
>   if he doesn't care who gets the credit." - Ronald Reagan<br>
><br>
<br>
</div></div>> ------------------------------------------------------------------------------<br>
> Crystal Reports - New Free Runtime and 30 Day Trial<br>
> Check out the new simplified licensing option that enables unlimited<br>
> royalty-free distribution of the report engine for externally facing<br>
> server and web deployment.<br>
> <a href="http://p.sf.net/sfu/businessobjects" target="_blank">http://p.sf.net/sfu/businessobjects</a><br>
> _______________________________________________<br>
> Nagios-users mailing list<br>
> <a href="mailto:Nagios-users@lists.sourceforge.net" target="_blank">Nagios-users@lists.sourceforge.net</a><br>
> <a href="https://lists.sourceforge.net/lists/listinfo/nagios-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-users</a><br>
> ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.<br>
> ::: Messages without supporting info will risk being sent to /dev/null<br>
<br>
<br>
------------------------------------------------------------------<br>
Russell Adams                            RLAdams@AdamsInfoServ.com<br>
<br>
PGP Key ID:     0x1160DCB3           <a href="http://www.adamsinfoserv.com/" target="_blank">http://www.adamsinfoserv.com/</a><br>
<br>
Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3<br>
<br>
------------------------------------------------------------------------------<br>
Crystal Reports - New Free Runtime and 30 Day Trial<br>
Check out the new simplified licensing option that enables unlimited<br>
royalty-free distribution of the report engine for externally facing<br>
server and web deployment.<br>
<a href="http://p.sf.net/sfu/businessobjects" target="_blank">http://p.sf.net/sfu/businessobjects</a><br>
_______________________________________________<br>
Nagios-users mailing list<br>
<a href="mailto:Nagios-users@lists.sourceforge.net" target="_blank">Nagios-users@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/nagios-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-users</a><br>
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.<br>
::: Messages without supporting info will risk being sent to /dev/null<br>
</blockquote></div><br>