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

Answer to the exact questions

• Reverse DNS lookup: When verification_mode=certificate Elasticsearch performs a reverse DNS lookup only for diagnostic logging. It is not part of the TLS verification process and does not influence which certificate the server presents.
• Impact of networkaddress.cache.ttl: The JVM cache controls how long a forward DNS answer (the IP chosen for the SNI hostname) is kept. A long TTL can keep the node bound to a stale IP, thereby keeping the same certificate until the TTL expires. The reverse lookup used for logging is also cached, but it does not affect the handshake.
• Behavior in 8.12+: The reverse‑DNS logging side‑effect has not been formally removed in the 8.12 release notes. Whether it was altered depends on the exact minor release you are running; review the release notes or source for your version to confirm.

Background and confirmed facts

The verification_mode=certificate setting tells the Elasticsearch SSL layer to trust a peer only if the certificate chain is signed by a trusted CA and the certificate is within its validity period. Hostname/SAN matching is skipped. The TLS handshake still uses the SNI string supplied by the client, which comes from the forward DNS resolution of the hostname you configured.

Elasticsearch’s security code historically resolves the remote IP to a hostname and logs it for audit purposes. This reverse lookup is a logging side‑effect, not a verification step, and is performed even when hostname validation is disabled.

Because the JVM’s networkaddress.cache.ttl (or sun.net.inetaddr.ttl) governs all InetAddress resolutions, it affects both the forward lookup that determines which IP to connect to and the reverse lookup that is logged. A cached forward answer can keep a node connected to the same IP (and thus the same certificate) even after the round‑robin DNS record has changed.

How to verify the behavior in your cluster

1. Check the JVM cache setting on each Elasticsearch node. The effective value is usually defined in JAVA_OPTS or jvm.options as -Dsun.net.inetaddr.ttl=60 (60 s is the default). You can also inspect java.security on the node for networkaddress.cache.ttl entries.

2. Enable SSL debug logging to see if a reverse PTR lookup occurs. Add -Djavax.net.debug=ssl to the JVM options or set the Elasticsearch SSL logger to DEBUG or TRACE level. Restart the node and observe the logs when a client connects.

3. Test round‑robin behavior by creating two simple HTTP servers behind a round‑robin A record that each present a distinct certificate. Point an Elasticsearch client (or another TLS client) at the hostname, then flip the DNS record to the other IP. With a long networkaddress.cache.ttl, the client should continue to connect to the original IP and receive the original certificate until the TTL expires.

4. Review release notes for the exact Elasticsearch 8.x minor version you are running. The 8.12 release notes do not mention removal of reverse‑DNS logging, but the source code for org.elasticsearch.transport.netty.ssl should be examined if you suspect a change.

Missing diagnostic detail needed for a definitive recommendation

• Which exact 8.x minor release (e.g., 8.12.0, 8.13.1) is your cluster running? This determines whether the reverse‑DNS logging side‑effect has been altered.
• Do you observe any PTR records for the IPs behind your round‑robin A record, or are they generic? Lack of PTR records can make the log entries misleading.

Providing these details will allow a precise assessment of whether the reverse‑DNS lookup behavior has been modified in your environment.