Elasticsearch TLS hostname verification with verification_mode=certificate and DNS round-robin load balancing

Goal

Determine whether Elasticsearch performs a reverse DNS lookup on the remote IP address when verification_mode is set to certificate and how the JVM's networkaddress.cache.ttl influences the hostname used in the TLS handshake when the underlying DNS record uses round-robin load balancing.

Constraints and uncertainty

In versions prior to 8.12, Elasticsearch has been observed to execute a reverse DNS lookup for logging even though hostname validation is skipped, producing unexpected log entries. It is unclear whether this lookup is an intentional diagnostic feature or an oversight. Additionally, Elasticsearch caches DNS results according to the JVM's networkaddress.cache.ttl setting, which can cause the node to continue using a stale IP address after the DNS record changes, potentially affecting which certificate is presented and whether verification succeeds.

Questions

• Is the reverse DNS lookup performed when verification_mode=certificate a deliberate logging mechanism or an unintended side‑effect?
• Does the networkaddress.cache.ttl value affect the hostname used in the TLS handshake (and thus the certificate presented) when verification_mode skips hostname validation?
• Has the reverse DNS lookup behavior been modified or removed in Elasticsearch 8.12 and later releases?