Ktor client TLS versus java.net.InetAddress DNS: independent hostname verification and async resolution

Question

The Ktor client relies on the JVM’s SSLContext for TLS and hostname verification, while its DNS lookup is performed synchronously through java.net.InetAddress.
Ktor does not expose a flag to disable certificate validation or to supply an alternate DNS resolver, and engine‑specific settings such as sslContext or dnsResolver must be provided via the underlying HTTP engine, which varies between OkHttp, Jetty, and Undertow.
It is unclear whether a single configuration can independently control hostname checks and DNS behavior across all supported engines, requiring verification of the current Ktor version’s capabilities.
Can the Ktor client be configured to disable hostname verification while using a custom async DNS resolver?
Is there a supported way to set a per‑request DNS resolver that bypasses java.net.InetAddress?

Tasadduq Burney · Answer

Direct answer

No. Ktor does not provide a single cross-engine setting to disable TLS hostname verification, and it does not expose a generic asynchronous DNS resolver. A per-request DNS resolver that bypasses java.net.InetAddress is not supported in the public client API.

Confirmed behavior and engine dependency

Assuming Ktor 2.x, the client delegates TLS and hostname verification to the selected HTTP engine. OkHttp, Jetty, and Undertow each use their own SSL configuration objects, so a hostname-verifier override written for one engine does not transfer to another. DNS resolution is generally synchronous through java.net.InetAddress. OkHttp offers a client-wide Dns interface, but Ktor does not surface an equivalent async resolver across engines, and resolver settings apply at client or engine level rather than per request.

What remains version-dependent is the exact DSL path and class names for those engine hooks. Verify them against the Ktor API reference for your version before applying any configuration block.

Steps for this case

Confirm the target engine: OkHttp, Jetty, or Undertow. The available workaround changes by engine.
For OkHttp only, configure the engine-specific SSL block to supply a custom hostname verifier. Treat disabling hostname verification as a test-only weakening of TLS.
For OkHttp only, supply a client-wide okhttp3 Dns implementation if you must replace default lookup behavior. It is not per-request, and a blocking implementation can stall event-loop threads.
For Jetty or Undertow, expect engine-specific SSL context configuration and no Ktor-exposed async DNS hook.

Verification

Inspect the engine-specific configuration block in your client build and compile against the Ktor API reference for your version to confirm which TLS and DNS hooks exist. Do not disable hostname verification in production without documented risk acceptance.

Missing diagnostic detail: which HTTP engine and Ktor version are you targeting? That determines whether an OkHttp-specific path applies.

Ktor client TLS versus java.net.InetAddress DNS: independent hostname verification and async resolution

1 answer

Direct answer

Confirmed behavior and engine dependency

Steps for this case

Verification

Your perspective belongs here.

0 question comments