JVM-wide SSL truststore configuration versus DNS TTL tuning for Liquibase remote changelog loading

Direct Answer

The two settings solve orthogonal problems: javax.net.ssl.trustStore controls which server certificates the JVM accepts, while networkaddress.cache.ttl controls how long InetAddress caches DNS answers. When you have both a self‑signed certificate and frequently changing DNS records, you need both levers—neither replaces the other.

Prefer a narrowly scoped truststore in an isolated JVM (or container) and align the JVM DNS cache TTL with the authoritative DNS zone TTL rather than treating either setting as a universal fix.

Minimizing Truststore Blast Radius

1. Run Liquibase in a dedicated JVM or container so the custom truststore affects only that process.
2. Create a truststore containing only the self‑signed certificate or its issuing CA:

   keytool -importcert -alias liquibase-remote -file selfsigned.crt -keystore liquibase-truststore.jks -storepass changeit

3. Launch Liquibase with:

   java -Djavax.net.ssl.trustStore=liquibase-truststore.jks \
        -Djavax.net.ssl.trustStorePassword=changeit \
        -jar liquibase.jar ...

4. Verify the truststore contents:

   keytool -list -keystore liquibase-truststore.jks -storepass changeit

If Liquibase must share a JVM, programmatic SSLSocketFactory or SSLContext injection is safer than global system properties—but only if the Liquibase HTTP client exposes that hook.

DNS TTL Threshold Guidance

There is no universal threshold. A practical compromise is to set the JVM positive cache TTL no higher than the DNS record TTL. For moderately dynamic records, 30–60 seconds often balances lookup volume and responsiveness. Also configure networkaddress.cache.negative.ttl (default 10 s) to avoid caching NXDOMAIN responses too long.

Set via security properties (preferred) or system property fallback:

# java.security or -Djava.security.properties==/path/override
networkaddress.cache.ttl=30
networkaddress.cache.negative.ttl=10

Remember: JVM settings do not override OS or container resolver caching.

Verification Steps

1. Confirm effective DNS cache values at runtime:

   jshell> import java.security.Security;
   jshell> Security.getProperty("networkaddress.cache.ttl")
   jshell> Security.getProperty("networkaddress.cache.negative.ttl")

2. Test DNS freshness after a record change:

   for i in {1..5}; do java -cp . ResolveTest example.com; sleep 10; done

   where ResolveTest calls InetAddress.getAllByName and prints addresses.

3. Confirm truststore contains only intended entries (step 4 above).
4. Run a second HTTPS client in the same JVM to verify the truststore change does not affect unrelated connections.

One Missing Diagnostic Detail

What is the authoritative DNS record TTL for the hostname Liquibase contacts? That value should drive the networkaddress.cache.ttl setting; without it, any number is a guess.