[Xymon] What does the 'dns' test do?

[Jeremy Laidman]

On Mon, 11 Mar 2019 at 10:08, John Horne <john.horne at plymouth.ac.uk> wrote:

> Okay, but what if FQDN names are not used, and the 'testip' option is set?
> So for example: 10.1.2.3 bob # testip !dns
>

It expands the shortname in the same way as if you typed "ping bob".

Does it do something like a reverse lookup - e.g. 'dig -x 10.1.2.3 @10.1.2.3
> '?
> Or does it do a lookup like 'dig bob @10.1.2.3'?
>

No, it uses the default domain and/or search list. So if you have "domain
example.com" in /etc/resolv.conf, it will do like "dig bob.example.com @bob",
or if "--dns=ip" is used, it would be "dig bob.example.com @<IP.of.b.ob>".
Although the exact behaviour in terms of determining how shortname
expansion works, is dependent on the c-ares library, and might not be
exactly the same as your system's libresolv.


> I assume the 'dns' test uses UDP port 53?


yes

The timeout servers should have had
> the UDP port opened up to them from the Xymon server. I'm wondering if
> either
> the TCP port has been opened on our network or if the Xymon test is using
> TCP
> instead of UDP.
>

No, it's unlikely to be anything to do with TCP. If a DNS service listens
only on the localhost address, queries from other nodes should be treated
the same as if there is no DNS service running at all - typically an
immediate "port unreachable" response or a timeout.

If you receive a timeout, it's almost certainly because the query was
dropped before it got to the TCP/IP protocol stack. This could be a
firewall device blocking the traffic, or a host-based firewall dropping the
traffic.

For Linux-based iptables/netfilter firewalling, you're likely to see this
behaviour if a packet does not match the permitted traffic, and instead
matches the default DROP policy. You would get the same behaviour for any
service not explicitly allowed (eg: telnet bob 13579). However, if the
iptables rules specify a REJECT response rather than a DROP, then the
kernel will send back an icmp-port-unreachable response (although you can
configure the response to be one of several other ICMP packets).

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xymon.com/pipermail/xymon/attachments/20190311/c6c80239/attachment.html>