What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

"DNS could not be resolved (socket error # 11004)" although nslookup and "ipconfig /displaydns" prod

Votes:

0

We have an HTTP sensor that went into error state with the message "DNS could not be resolved (socket error # 11004)". However on the probe (core server) nslookup returns the correct address. Also when we run "ipconfig /displaydns" to see the resolver cache the correct address is listed for the website. Even more, if we fire up firefox we are able to successfully bring up the sensor's page.

Short of restarting the probe or core services, what can we do to fix this problem?

dns falsealarms http-sensor

Created on Jul 28, 2011 8:44:28 PM



Best Answer

Accepted Answer

Votes:

0

Pause/resume does not change anything. I forgot to mention, this sensor is part of a PRTG cluster and both probes in the cluster exhibit the same behavior (the machine resolves but PRTG does not). Also, this problem started when we changed the glue records (authoritative DNS as listed in Whois) for that domain.

A clone of the sensor had the same problems but a new sensor that we created from scratch worked fine. We figured out that there was an invisible character trailing the URL on the settings page. Apparently the servers at the previous DNS provider were ignoring this trailing character but our new DNS was throwing a NXDOMAIN response which is the response we want for lookups with invalid characters. (a cheap hedge against DNS poisoning).

Created on Aug 1, 2011 1:48:51 PM



4 Replies

Votes:

0

Dear Jim,

have you tried pausing/resuming the sensor? Is it only one sensor? Can you try adding a new sensor?

best regards.

Created on Aug 1, 2011 12:06:18 PM by Torsten Lindner [Paessler Support]



Accepted Answer

Votes:

0

Pause/resume does not change anything. I forgot to mention, this sensor is part of a PRTG cluster and both probes in the cluster exhibit the same behavior (the machine resolves but PRTG does not). Also, this problem started when we changed the glue records (authoritative DNS as listed in Whois) for that domain.

A clone of the sensor had the same problems but a new sensor that we created from scratch worked fine. We figured out that there was an invisible character trailing the URL on the settings page. Apparently the servers at the previous DNS provider were ignoring this trailing character but our new DNS was throwing a NXDOMAIN response which is the response we want for lookups with invalid characters. (a cheap hedge against DNS poisoning).

Created on Aug 1, 2011 1:48:51 PM



Votes:

0

I have the same problem, and I'm back to creating sensors, but I still have the same response. Now I tried setting the parameter DNS NAME into System Administration page, and the sensor of ping now appears as: Bad Destination (ICMP error # 11018). You can help me with this issue?

Created on Aug 17, 2011 8:04:16 PM



Votes:

0

The "DNS Name"-Setting only applies to the name for PRTG (it's host), not anything else. Sensors themselves don't use it.

Created on Aug 18, 2011 2:02:37 PM by Torsten Lindner [Paessler Support]




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.