<div dir="ltr">John, the DNS probe code is implemented using the (third party) c-ares library, which makes it a bit more work to customising how it operates. Another common problem with DNS probes is that the timeout cannot be modified, likely due to the same constraints. I'm sure c-ares can do TCP probes, but the DNS code in xymonnet hasn't been written to enable that mode.<div><br></div><div>The xymonnet code would certainly be able to set the testname to whatever it wanted. But from what I can see, there's no way to modify it using configurations, and the "dns" test name is hard-coded.</div><div><br></div><div>I do TCP probes of DNS servers. The protocols.cfg (which only deals with TCP) comes with an [axfr] test, so you can use that. I've extended mine to check for a few different RCODE values because some DNS servers respond with something other than "OK" (eg REFUSED). I also have a simple TCP connection test that doesn't bother to send a query (see below for snippets from protocols.cfg).</div><div><br></div><div>These are all zone transfer attempts. Theoretically, you could probably craft up a regular query packet, but I haven't done that for some reason (perhaps I tried but couldn't get it to work).</div><div><br></div><div>Ultimately, you could just disable the DNS tests and roll your own script to parse hosts.cfg for the DNS clauses; that way you can also specify your own test name, and allow UDP or TCP to be indicated by a modification of the configuration structure. Perhaps you could change "dns=..." into "dns-tcp=..." etc.</div><div><br></div><div>I've often thought about doing this, as my main focus is on DNS services, and I've certainly found the xymonnet probes to be a little restricted - great for general server monitoring, but it doesn't have quite the flexibility that I'd like. A separately maintained extension script might be just the thing. It'd probably want to use "dig" or similar, to get the fine-grained timing info, and have access to flags and result codes. My only concern about this, in comparison to using xymonnet with the c-ares library, is that calling the "dig" executable for every host/test will not scale as well, with all the overhead of forking and execing - this is where c-ares comes into its own as it performs asynchronously, and I would think it is much more efficient at handling lots of concurrent queries.</div><div><br></div><div>J</div><div><br></div><div>[axfr]<br> # Zone transfer test<br> #<br> # If you adjust the zone name "xymon-test", you must also<br> # adjust the preceding two bytes (\0x00\0x0a=10 decimal) to<br> # match the length of the zone and also adjust the 2nd byte<br> # (0x1c=28 decimal) to be the zone name length<br> # plus 18 (or the size of the whole send string minus 2).<br> #<br> # The third and fourth bytes (both 0xff) are simply the DNS query<br> # ID, and will be the same in the response.<br> #<br> # We expect a response exactly the same but with "0x80 0x89" just after<br> # the ID for a "NOTAUTH" (RCODE=9) response.<br> #<br> # The zone to be queried must be such that it fails (either<br> # a forward zone or a non-existent zone, giving NOTAUTH to dig),<br> # otherwise the response length will be different and we won't be<br> # able to match it in our expect string.<br> #<br> # If you want to query a valid domain, don't use send/expect at all.<br> # because the first two bytes in the response can't be reliably<br> # predicted.<br><br> port 53<br> send "\x00\x1c\xff\xff\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"<br> expect "\x00\x1c\xff\xff\x80\x89\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"<br><br>[axfr2]<br> # like axfr, but with RCODE=5 instead of 9<br> port 53<br> send "\x00\x1c\xff\xff\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"<br> expect "\x00\x1c\xff\xff\x80\x85\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"<br><br>[axfr3]<br> # like axfr2, but with RA (recursion allowed) bit clear (refused?)<br> port 53<br> send "\x00\x1c\xff\xff\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"<br> expect "\x00\x1c\xff\xff\x80\x05\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"<br><br>[tcp53]<br> # just check that the port is listening<br> port 53<br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 18 Jan 2023 at 09:20, John Thurston <<a href="mailto:john.thurston@alaska.gov">john.thurston@alaska.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>The basic "dns" test in Xymon (currently running
4.3.30-1.el7.terabithia) is frustrating me. As far as I can tell,
there is no way to:</p>
<p>+ change the test-name (i.e. it is always "dns")</p>
<p>+ force tcp or udp connections</p>
<p>Has anyone found a way around these limitations?<br>
</p>
<pre cols="72">--
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
<a href="mailto:John.Thurston@alaska.gov" target="_blank">John.Thurston@alaska.gov</a>
Department of Administration
State of Alaska</pre>
</div>
_______________________________________________<br>
Xymon mailing list<br>
<a href="mailto:Xymon@xymon.com" target="_blank">Xymon@xymon.com</a><br>
<a href="http://lists.xymon.com/mailman/listinfo/xymon" rel="noreferrer" target="_blank">http://lists.xymon.com/mailman/listinfo/xymon</a><br>
</blockquote></div>