What does the 'dns' test do?

10 messages in this thread

list John Horne · Sun, 10 Mar 2019 21:17:37 +0000 ·

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.

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.

list Michael T Pins · Sun, 10 Mar 2019 16:15:07 -0600 (MDT) ·

▸ quoted from John Horne

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.

▸ quoted from John Horne

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.

list John Horne · Sun, 10 Mar 2019 23:08:25 +0000 ·

▸ quoted from Michael T Pins

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'?

▸ quoted from Michael T Pins

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.

▸ quoted from John Horne



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.

list Jeremy Laidman · Mon, 11 Mar 2019 12:34:42 +1100 ·

▸ quoted from John Horne

On Mon, 11 Mar 2019 at 10:08, John Horne <user-e95f1ec2f147@xymon.invalid> 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".

▸ quoted from John Horne


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

▸ quoted from John Horne


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

list John Horne · Tue, 12 Mar 2019 13:19:51 +0000 ·

▸ quoted from John Horne

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.

▸ quoted from John Horne



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.

list Sebastian Auriol · Tue, 12 Mar 2019 13:57:00 +0000 ·

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

▸ quoted from John Horne



On Tue, 12 Mar 2019 at 13:20, John Horne <user-e95f1ec2f147@xymon.invalid> 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>;

▸ quoted from John Horne


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.

list John Horne · Tue, 12 Mar 2019 15:23:46 +0000 ·

▸ quoted from Sebastian Auriol

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.

▸ quoted from Sebastian Auriol



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.

list John Thurston · Tue, 12 Mar 2019 07:38:35 -0800 ·

▸ quoted from John Horne

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    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Department of Administration
State of Alaska

list Sebastian Auriol · Tue, 12 Mar 2019 15:58:09 +0000 ·

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 <user-ce4d79d99bab@xymon.invalid>

▸ quoted from John Thurston

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    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Department of Administration
State of Alaska

list Adam Goryachev · Wed, 13 Mar 2019 10:18:51 +1100 ·

▸ quoted from John Horne

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.

What does the 'dns' test do? 🔗 link

What does the 'dns' test do?