Ballerina http:Client secureSocket: when verifyHostName=false hides a trust or DNS fault

When a Ballerina Swan Lake http:Client call fails TLS validation, the secureSocket record offers two levers: a cert field for custom trust (a PKCS12 truststore or PEM file) and a verifyHostName boolean that switches name checking off. Certificate validation is enabled by default, and the documented escape hatch for a name-mismatch failure is setting verifyHostName to false.

The same symptom can come from two unrelated causes:

• an incomplete trust chain on the client side, or
• DNS resolving the service hostname to an endpoint whose certificate does not match — stale container DNS, a load balancer, or a wildcard mismatch.

Ballerina runs on a JVM, so hostname resolution and its caching follow Java resolver behavior, and pooled keep-alive connections keep using the IP they were opened with. DNS-related failures can therefore look intermittent and timing-dependent.

Disabling verifyHostName silences both causes at once and leaves the client willing to accept certificates issued for other hosts, which is not acceptable outside isolated debugging. Field names and defaults have also varied across Swan Lake minor releases.

Which check reliably separates a trust-chain failure from a DNS-resolution failure before touching verifyHostName? Is there a supported way to influence the JVM's DNS cache TTL from a Ballerina distribution, or does that remain a JDK-specific setting outside the language?