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?
Article Comments
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).
Aug, 2011 - Permalink
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?
Aug, 2011 - Permalink
The "DNS Name"-Setting only applies to the name for PRTG (it's host), not anything else. Sensors themselves don't use it.
Aug, 2011 - Permalink
Dear Jim,
have you tried pausing/resuming the sensor? Is it only one sensor? Can you try adding a new sensor?
best regards.
Aug, 2011 - Permalink