[Xymon] Edges of the DNS test

[Jeremy Laidman]

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.

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.

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

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

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.

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.

J

[axfr]
        # Zone transfer test
        #
        # If you adjust the zone name "xymon-test", you must also
        # adjust the preceding two bytes (\0x00\0x0a=10 decimal) to
        # match the length of the zone and also adjust the 2nd byte
        # (0x1c=28 decimal) to be the zone name length
        # plus 18 (or the size of the whole send string minus 2).
        #
        # The third and fourth bytes (both 0xff) are simply the DNS query
        # ID, and will be the same in the response.
        #
        # We expect a response exactly the same but with "0x80 0x89" just
after
        # the ID for a "NOTAUTH" (RCODE=9) response.
        #
        # The zone to be queried must be such that it fails (either
        # a forward zone or a non-existent zone, giving NOTAUTH to dig),
        # otherwise the response length will be different and we won't be
        # able to match it in our expect string.
        #
        # If you want to query a valid domain, don't use send/expect at all.
        # because the first two bytes in the response can't be reliably
        # predicted.

        port 53
        send
"\x00\x1c\xff\xff\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"
        expect
"\x00\x1c\xff\xff\x80\x89\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"

[axfr2]
        # like axfr, but with RCODE=5 instead of 9
        port 53
        send
"\x00\x1c\xff\xff\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"
        expect
"\x00\x1c\xff\xff\x80\x85\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"

[axfr3]
        # like axfr2, but with RA (recursion allowed) bit clear (refused?)
        port 53
        send
"\x00\x1c\xff\xff\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"
        expect
"\x00\x1c\xff\xff\x80\x05\x00\x01\x00\x00\x00\x00\x00\x00\x0axymon-test\x00\x00\xfc\x00\x01"

[tcp53]
        # just check that the port is listening
        port 53



On Wed, 18 Jan 2023 at 09:20, John Thurston <john.thurston at alaska.gov>
wrote:

> 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:
>
> + change the test-name (i.e. it is always "dns")
>
> + force tcp or udp connections
>
> Has anyone found a way around these limitations?
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston    907-465-8591John.Thurston at alaska.gov
> Department of Administration
> State of Alaska
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20230118/ff984bde/attachment.htm>