Kafka SSL hostname verification behavior during DNS failover with ssl.endpoint.identification.algorithm=HTTPS

Context

Kafka clients using the default ssl.endpoint.identification.algorithm=HTTPS verify the broker certificate hostname against the DNS name used at connection establishment. The verification occurs once during the initial handshake and is not repeated for the lifetime of that connection.

Problem

In environments with DNS-based failover or rolling broker updates, the IP address behind a broker's DNS name can change while client connections remain open. Existing connections continue using the original IP and certificate, but new connections will resolve the updated DNS record and may fail verification if the certificate does not match the new hostname.

There is no built-in mechanism to trigger re-verification or connection refresh when DNS records change. The JVM DNS cache TTL (networkaddress.cache.ttl) further complicates timing, as clients may continue resolving stale IPs even after DNS updates propagate.

Open questions

1. What is the expected client behavior when a broker's DNS record changes mid-session — should the client proactively reconnect and re-verify, or is connection stability preferred?
2. Are there configuration patterns or extension points (custom SSL engine factories, connection listeners) that allow applications to implement DNS-change-aware reconnection logic without modifying Kafka internals?
3. How should operators coordinate certificate deployment (SAN coverage) across brokers to support seamless DNS failover while maintaining strict hostname verification?