java should set networkaddress.cache.ttl

[donbowman]

Currently networkaddress.cache.ttl is unset, defaulting to -1. This is causing an infinite caching time of an address from DNS. (https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html)

I believe(?) /etc/java-8-openjdk/security/java.security should have something like networkaddress.cache.ttl=60.

I'm not sure if that file is used or /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/java.security though.

[patflynn]

@chanseokoh can you look into this?

[chanseokoh]

Sure. It doesn't look wrong to set it to 60 seconds. I'll just look into some other popular images before doing this.

[chanseokoh]

@donbowman I think this is unnecessary. Do you see an actual problem?

/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/java.security is a symbolic link pointing to /etc/java-8-openjdk/security/java.security in Distroless. The file has the comment about the property:

# The Java-level namelookup cache policy for successful lookups:
#
# any negative value: caching forever
# any positive value: the number of seconds to cache an address for
# zero: do not cache
#
# default value is forever (FOREVER). For security reasons, this
# caching is made forever when a security manager is set. When a security
# manager is not set, the default behavior in this implementation
# is to cache for 30 seconds.
#
# NOTE: setting this to anything other than the default value can have
#       serious security implications. Do not set it unless
#       you are sure you are not exposed to DNS spoofing attack.
#
#networkaddress.cache.ttl=-1

I confirm that the property is unset (null), regardless of whether a security manager is enabled. And when a security manager is not set (the default configuration unless you give -Djava.security.manager=...), the behavior is to cache for 30 seconds. So, if this matters, then I think it is only when you have a security manager, and in that special case, the note seems to suggest that you should clearly be aware of the consequences of settings this to a non-default value in your security context.

[donbowman]

Hmm.

I'm seeing an infinite cache (for low values of infinity :) ) effect. I'm using with druid and observing that when something external it refers to changes in Kubernetes (e.g. a service it refers to) that it does not seem to update after many minutes.

druid does not internally set any security context things, leaving the system-wide default. I'm not sure what else could affect it.

[chanseokoh]

Let's first confirm if the infinite cache effects is gone in your env when setting networkaddress.cache.ttl to 30 or 60. It won't be difficult at all for you to update /etc/java-8-openjdk/security/java.security in your image. (Just copy a file with the setting into that location to replace it.)

However, even if we confirm that the default 30-sec TTL behavior is not in place unlike documented, I feel I'm a bit hesitant to make it an explicit global in Distroless, as 1) the official OpenJDK image doesn't do it; 2) it is easy for users to update java.security for their usage; and 3) the short TTL will then become the default when a security manager is enabled, which is precisely the opposite of the original intention of making the 30-sec TTL to infinite when it is enable to according to the comment in java.security.

Anyways, I'd like to confirm first if the infinite cache effect is clearly due to networkaddress.cache.ttl.

[donbowman]

10:4, seems reasonable.

[chanseokoh]

I'll close this issue, as it seems we are in agreement with leaving the value as is.