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
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
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>
participants (2)
-
jeremy＠laidman.org
-
john.thurston＠alaska.gov