Erlang inet DNS resolution and ssl certificate validation error separation

Question

Goal: Determine whether an Erlang/OTP application can distinguish a DNS resolution outcome from a TLS certificate validation failure when connecting to a hostname that resolves to multiple addresses.
The inet application may return several IPv4 and IPv6 records for one name, while the ssl application performs certificate verification only after a TCP/TLS handshake begins. Default ssl settings do not verify the peer hostname unless verify_peer and trusted CA certificates are configured, and failure tuples such as {error, closed} or {error, {alert, ...}} may not clearly separate network, DNS, and certificate causes. Behavior varies across OTP releases, and Erlang ssl does not expose DNSSEC or DANE validation from the resolver.
Questions:

Does ssl:connect/3 surface certificate hostname validation failures as distinct error tuples from DNS resolution failures when multiple addresses are returned?
Which OTP release first provides distinguishable alert or certificate validation reasons at the inet-to-ssl boundary?
Can an application reliably map a failed connection to a specific resolved address without enabling low-level trace options?

Tasadduq Burney · Answer

Direct answer
No, ssl:connect/3 does not return separate error tuples that differentiate DNS resolution failures from TLS certificate validation failures; the error reflects the final connection attempt after the inet lookup has been tried.

Explanation
The inet library returns a list of {IP,Family} tuples. ssl:connect/3 iterates that list until a TCP connection succeeds, so any failure reported originates from the last address that was attempted. Certificate validation failures are reported as {error, {ssl, certificate_verify_failed, Reason}}, while generic connection problems appear as {error, closed} or other socket‑level reasons. From OTP 19 onward the ssl module distinguishes certificate verification errors; earlier releases only returned {error, closed} for any failure, so the separation is version‑dependent.

Practical verification steps

Ensure the client is created with verify_peer set to true and that a trusted CA certificate is loaded.
Call ssl:connect/3 against a hostname with a valid certificate and another with an expired or mismatched certificate.
Observe the returned error tuple: a {error, {ssl, certificate_verify_failed, ...}} indicates a TLS validation problem, while {error, closed} or other socket errors indicate a connection‑level failure that may stem from DNS or address selection.
Check your OTP release with :erlang.system_info(otp_release) to confirm whether the certificate‑verification reason is available.

Missing diagnostic detail
Please provide the OTP version (or confirm that verify_peer is enabled) so we can verify that the certificate‑verification error tuple is present in your environment.

Erlang inet DNS resolution and ssl certificate validation error separation

1 answer

Direct answer

Explanation

Practical verification steps

Missing diagnostic detail

Your perspective belongs here.

0 question comments