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

Votes:

0

Your Vote:

Up

Down

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 by  Jim Kirby (181) 2 1



Best Answer

Accepted Answer

Votes:

0

Your Vote:

Up

Down

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 by  Jim Kirby (181) 2 1



4 Replies

Votes:

0

Your Vote:

Up

Down

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] (19,480) 3 1



Accepted Answer

Votes:

0

Your Vote:

Up

Down

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 by  Jim Kirby (181) 2 1



Votes:

0

Your Vote:

Up

Down

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 by  marceloalonso (0)



Votes:

0

Your Vote:

Up

Down

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] (19,480) 3 1



Please log in or register to enter your reply.


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.

PRTG
Network Monitor
Intuitive to Use.
Easy to manage.

150.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Visit
www.paessler.com

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

Top Tags


View all Tags