Erlang inet DNS resolution and ssl certificate validation error separation

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?