[Xymon] Edges of the DNS test
John Thurston
john.thurston at alaska.gov
Wed Jan 18 02:25:53 CET 2023
Thank you for that comprehensive reply, Jeremy.
I hadn't thought about the prospect of embedding binary send-strings in
my protocols.cfg. That has some appeal, and I may explore it.
For now, my primary consideration has been how to separately deliver the
status of the authority and resolver, when those two functions co-exist
on a single host. I wanted to generate two different columns, like so:
0.0.0.0 dns.bar.com # dns=aDNS=SOA:bar.com dns=rDNS=A:google.com
But that isn't going to happen. So I'm using two fake-hosts, and a
combo-test to get that result
0.0.0.0 dns.bar.com #
10.1.2.3 dns.authority # noconn testip nodisp dns=SOA:bar.com
10.1.2.3 dns.resolver # noconn testip nodisp dns=A:google.com
# In the combo.cfg
dns.bar.com.aDNS = dns.authority.dns
dns.bar.com.rDNS = dns.resolver.dns
I consider it an ugly hack, but it will get the job done for a few days.
--
Do things because you should, not just because you can.
John Thurston 907-465-8591
John.Thurston at alaska.gov
Department of Administration
State of Alaska
On 1/17/2023 4:08 PM, Jeremy Laidman wrote:
>
>
>
> *CAUTION:* This email originated from outside the State of Alaska mail
> system. Do not click links or open attachments unless you recognize
> the sender and know the content is safe.
>
> 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-8591
> John.Thurston at alaska.gov
> Department of Administration
> State of Alaska
>
> _______________________________________________
> Xymon mailing list
> Xymon at xymon.com
> http://lists.xymon.com/mailman/listinfo/xymon
> <https://gcc02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.xymon.com%2Fmailman%2Flistinfo%2Fxymon&data=05%7C01%7Cjohn.thurston%40alaska.gov%7C0f39f3db274e4f57bcec08daf8f09aee%7C20030bf67ad942f7927359ea83fcfa38%7C0%7C0%7C638096009525541889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qEEAg77me8GRFX%2FLdqkb5PxGPJ9YAfr7CZMdzRqGpkQ%3D&reserved=0>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20230117/ee011166/attachment.htm>
More information about the Xymon
mailing list