What does the 'dns' test do?
Hi,
Using the 4.3.28 Terabithia RPMs, can someone tell me what the 'dns' test actually does?
We actually negate the test ('!dns'), and run a client-side dns test ('dnsr') to check that resolution is working. As far as I remember the standard 'dns' test checks that the client DNS service can resolve something. This will always fail in our case as the client DNS service is always restricted to just the local host. (No querying allowed from an external server.)
I'm trying to work out why most of our servers are taking less than a second - giving a 'Server unavailable' reply, but others are taking around 20 seconds for a 'Timeout' reply. I know why the timeout is 20 seconds, I'm just wondering why it's not giving a 'Server unavailable' reply.
Thanks,
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
John Horne writes:
Using the 4.3.28 Terabithia RPMs, can someone tell me what the 'dns' test actually does?
It uses the C-ARES libraries to do a DNS lookup for hostname on hostname. In other words, if you have a server named bob, it will do a DNS lookup for "bob" on host bob.
We actually negate the test ('!dns'), and run a client-side dns test ('dnsr') to check that resolution is working. As far as I remember the standard 'dns' test checks that the client DNS service can resolve something. This will always fail in our case as the client DNS service is always restricted to just the local host. (No querying allowed from an external server.)
I'm trying to work out why most of our servers are taking less than a second - giving a 'Server unavailable' reply, but others are taking around 20 seconds for a 'Timeout' reply. I know why the timeout is 20 seconds, I'm just wondering why it's not giving a 'Server unavailable' reply.
What happens if you try to telnet to port 53 from your xymon server to the various servers?
"Server unavailable" means the server in question is either refusing connections on port 53, or it's responding with some sort of error message.
"Timeout" generally means it's listening on port 53, but doesn't actually answer. (Or something is sending port 53 packets to /dev/null, so xymon never gets any response.)
To be precise - xymon will say "Server unavailable" if the C-ARES library returns ARES_ECONNREFUSED, and it will say "Timeout" if the C-ARES library returns ARES_ETIMEOUT.
On Sun, 2019-03-10 at 16:15 -0600, Michael T Pins wrote:
John Horne writes:
Using the 4.3.28 Terabithia RPMs, can someone tell me what the 'dns' test actually does?
It uses the C-ARES libraries to do a DNS lookup for hostname on hostname. In other words, if you have a server named bob, it will do a DNS lookup for "bob" on host bob.
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
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'?
To be precise - xymon will say "Server unavailable" if the C-ARES library returns ARES_ECONNREFUSED, and it will say "Timeout" if the C-ARES library returns ARES_ETIMEOUT.
Yes, I think this is where the problem lies. Servers giving a 'Server unavailable' reply are actually connected to, but the local (client) firewall rejects them trying to connect on UDP port 53 (for DNS). For the other servers, the network does not even allow a connection. So the DNS request just times out. The request doesn't even get to the server to be answered or rejected.
I assume the 'dns' test uses UDP port 53? 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.
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
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
On Sun, 2019-03-10 at 21:17 +0000, John Horne wrote:
Hi,
Using the 4.3.28 Terabithia RPMs, can someone tell me what the 'dns' test actually does?
We actually negate the test ('!dns'), and run a client-side dns test ('dnsr') to check that resolution is working. As far as I remember the standard 'dns' test checks that the client DNS service can resolve something. This will always fail in our case as the client DNS service is always restricted to just the local host. (No querying allowed from an external server.)
I'm trying to work out why most of our servers are taking less than a second
- giving a 'Server unavailable' reply, but others are taking around 20 seconds for a 'Timeout' reply. I know why the timeout is 20 seconds, I'm just wondering why it's not giving a 'Server unavailable' reply.
Hi,
Thanks for the replies about this.
It seems the network infrastructure in which our monitoring server sits is blocking ICMP from some networks. Clients in those networks are correctly sending back an ICMP reject via its local firewall, but these are blocked. So the Xymon server times out the connection instead. I've asked if ICMP rejects can be allowed through.
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
I don't really understand why you would be negating the dns test on the server, rather than just removing it altogether. You will be slowing down xymonnet if you have tests that are getting blocked by firewalls / iptables. If you're interested in a test that checks iptables is running, I made a simple extension script I might be able to share.
Kind regards,
SebA
On Tue, 12 Mar 2019 at 13:20, John Horne <john.horne at plymouth.ac.uk> wrote:
On Sun, 2019-03-10 at 21:17 +0000, John Horne wrote:
Hi,
Using the 4.3.28 Terabithia RPMs, can someone tell me what the 'dns' test actually does?
We actually negate the test ('!dns'), and run a client-side dns test ('dnsr') to check that resolution is working. As far as I remember the standard 'dns' test checks that the client DNS service can resolve something. This will always fail in our case as the client DNS service is always restricted to just the local host. (No querying allowed from an external server.)
I'm trying to work out why most of our servers are taking less than a second
- giving a 'Server unavailable' reply, but others are taking around 20 seconds for a 'Timeout' reply. I know why the timeout is 20 seconds, I'm just wondering why it's not giving a 'Server unavailable' reply.
Hi,
Thanks for the replies about this.
It seems the network infrastructure in which our monitoring server sits is blocking ICMP from some networks. Clients in those networks are correctly sending back an ICMP reject via its local firewall, but these are blocked. So the Xymon server times out the connection instead. I've asked if ICMP rejects can be allowed through.
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<; http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On Tue, 2019-03-12 at 13:57 +0000, SebA wrote:
I don't really understand why you would be negating the dns test on the server, rather than just removing it altogether. You will be slowing down xymonnet if you have tests that are getting blocked by firewalls / iptables. If you're interested in a test that checks iptables is running, I made a simple extension script I might be able to share.
The check is to ensure that the local (client) DNS service is not 'open'. That is, that it will not resolve queries from external sources. (And hence prevents amplification attacks.) We run a separate client DNS test to ensure that local resolution is working, and, of course, a 'proc' check that 'named' is running.
The 'dns' test/ICMP problem has only just appeared when we moved the monitoring server. But without knowing what it was that the test was trying to resolve made it a bit difficult to diagnose.
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
On 3/12/2019 5:57 AM, SebA wrote:
I don't really understand why you would be negating the dns test on the server, rather than just removing it altogether.
A negated test is affirming a service is _not_ accessible. Removing the test is not caring if the service is answering. These are two different business needs.
Even if one confirms by some other means that a firewall product is running, there is only one way to confirm that product is doing its job. One must attempt to gain entry and see that access is denied.
-- 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
Yeah, I understand the difference, and now I understand why you're doing it. :-)
Kind regards,
SebA
On Tue, 12 Mar 2019 at 15:39, John Thurston <john.thurston at alaska.gov> wrote:
On 3/12/2019 5:57 AM, SebA wrote:
I don't really understand why you would be negating the dns test on the server, rather than just removing it altogether.
A negated test is affirming a service is _not_ accessible. Removing the test is not caring if the service is answering. These are two different business needs.
Even if one confirms by some other means that a firewall product is running, there is only one way to confirm that product is doing its job. One must attempt to gain entry and see that access is denied.
-- 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
On 13/3/19 12:19 am, John Horne wrote:
On Sun, 2019-03-10 at 21:17 +0000, John Horne wrote:
Hi,
Using the 4.3.28 Terabithia RPMs, can someone tell me what the 'dns' test actually does?
We actually negate the test ('!dns'), and run a client-side dns test ('dnsr') to check that resolution is working. As far as I remember the standard 'dns' test checks that the client DNS service can resolve something. This will always fail in our case as the client DNS service is always restricted to just the local host. (No querying allowed from an external server.)
I'm trying to work out why most of our servers are taking less than a second
- giving a 'Server unavailable' reply, but others are taking around 20 seconds for a 'Timeout' reply. I know why the timeout is 20 seconds, I'm just wondering why it's not giving a 'Server unavailable' reply.
Hi,
Thanks for the replies about this.
It seems the network infrastructure in which our monitoring server sits is blocking ICMP from some networks. Clients in those networks are correctly sending back an ICMP reject via its local firewall, but these are blocked. So the Xymon server times out the connection instead. I've asked if ICMP rejects can be allowed through.
Maybe also refer them to this: http://shouldiblockicmp.com/
ie, don't block all ICMP.... some is required so that the Internet thing works properly...
Regards, Adam
-- Adam Goryachev Website Managers www.websitemanagers.com.au
The information in this e-mail is confidential and may be legally privileged. It is intended solely for the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please notify us immediately. Please also destroy and delete the message from your computer. Viruses - Any loss/damage incurred by receiving this email is not the sender's responsibility.
participants (6)
-
jeremy＠laidman.org
-
john.horne＠plymouth.ac.uk
-
john.thurston＠alaska.gov
-
mailinglists＠websitemanagers.com.au
-
mtpins＠nndev.org
-
spah＠syntec.co.uk