Bit of a late reply, but I am slowly digging through my mail archive ...
Den 2013-11-01 21:43, John Thurston skrev:
It's funny you bring this up right now. I am currently struggling with my pre-production xymon instance. The only way I seem able to get it to behave is to start xymonnet with --no-ares. When using c-ares, I routinely get hundreds of test failures due to inability to resolve names.
I've been working on this today and have found the undocumented option to xymonnet "--maxdnsqueue". With this, I can limit the number of queries xymonnet sends to name servers in each batch. When I set it to =10, I get solid results. When I set it to =25 (or higher), I get hundreds of name resolution failures.
When I use --no-ares, it also works fine.
My original question remains, "Why is c-ares the default rather than the system resolver?" But more important is the practical question . .
Xymon uses the c-ares resolver because your system resolver library can only handle one lookup at a time, and may take a very long time to timeout if a DNS server is not responding.
A consequence of this is that Xymon can quite easily flood a normal DNS server with queries, resulting in DNS lookups failing. I suspect that is what happens in your case. The simplest solution for this (and I would recoomend this for anyone running a Xymon network probe) is to install a local caching DNS server, which forwards all requests to your normal DNS servers. Such a setup is completely transparent to how Xymon works, but it moves the load to a dedicated DNS server running on your Xymon box. Since it will cache all of the responses after the initial request, it will be much more reliable and fast.
So you can choose: a) Run xymonnet with --no-ares and live with the fact that xymonnet may take a very long time to run, resulting in purple tests and status messages not being up-to-date; or b) install a local caching BIND server where you put the normal DNS servers in the "forwarders" section.
Regards, Henrik