A failed connection explains a limit in the report’s coverage. It may also reveal a real service problem, but the error category alone is not enough to identify the cause.
Error categories
| Category | Interpretation | What to investigate |
|---|---|---|
| DNS Resolution Errors | The name could not be resolved as needed for inspection. | Whether the name still exists, DNS service health, and whether the discovery entry is historical. |
| Private Address Resolution | A name resolved to a private or internal address that the public scanner does not inspect. | Whether that exposure is intentional; use an appropriate internal assessment for the service. |
| Connection & Timeout Errors | The network connection did not complete or the listener did not respond as expected. | Firewall policy, routing, server availability, and stale addresses. |
| TLS Handshake Errors | TLS negotiation could not complete. | Protocol compatibility, TLS configuration, and any special client requirements. |
| Certificate Errors | The presented certificate or chain failed validation. | Hostname coverage, validity dates, issuer trust, and intermediate certificates. |
| Other Errors | The failure did not fit a more specific category. | The exact error text and the endpoint involved. |
Do not turn an evidence gap into a diagnosis
A DNS failure does not always mean a name permanently does not exist; a lookup can fail temporarily. A timeout does not establish a certificate problem. Private-address resolution is not a reason to publish an internal service merely to make the scan succeed.
Likewise, an endpoint that failed the handshake has not passed the cipher, protocol, or certificate checks that depend on completing that inspection. Read missing and inconclusive results alongside any reassuring summary.
Investigate one endpoint at a time
Record the scan date, hostname, IP address, port, and full error. Compare them with the intended deployment and with a connection from an appropriate network. If only one address fails, check that node or route rather than changing every server.
After resolving the cause, retest and confirm that the endpoint now produces usable evidence. If a service was intentionally retired, verify DNS cleanup and remember that historical discovery names may continue appearing.