Limits: Custom DNS resolver vs Host header mismatch in Ktor client

Goal

We want to issue an HTTPS request to a server identified by an IP address while setting the Host header to a domain that has a valid TLS certificate. The request should perform DNS resolution via a custom resolver so that the domain maps to the desired IP, and the TLS handshake should validate the certificate against that domain.

Constraints

Using the default Jetty engine, Ktor delegates DNS lookup to the JVM’s java.net.InetAddress resolver. The engine does not expose a public API to swap the resolver without changing the underlying engine. Setting validateCertificates = false disables hostname checks entirely, which is unacceptable for production use.

Uncertainty

When a custom resolve function is supplied in the Host header, the underlying TLS handshake still uses the IP address resolved by the JVM, leading to a hostname mismatch and certificate validation failure. It is unclear whether Ktor can be configured to use the custom resolver for both the HTTP request and the TLS handshake, or if this behavior is an inherent limitation.

Questions

• Is there a documented way to plug a custom DNS resolver into Ktor while preserving hostname verification for HTTPS requests?
• Can the Jetty engine be configured to use a custom resolver for TLS handshakes without disabling validateCertificates?
• What are the recommended patterns for testing such scenarios in a way that does not expose the client to man‑in‑the‑middle attacks?