Proposal to add another option to configure the DNS cache

[Daniel Jeliński]

Hi Sergey,
Could you tell us a bit about the problem you're trying to solve?

In most deployments I would expect either a resolver cache, or a local
caching DNS server. Either of these makes our InetAddress caching
redundant.

The InetAddress cache has a few problems:
- it ignores the time-to-live (TTL) information provided by the DNS
server; other caches usually cache the entries until the TTL expires,
we have a fixed caching period.
- it caches all negative lookup results for a fixed period of time;
other caches cache NXDOMAIN replies which contain TTL information, and
do not cache lookups that failed because of server and network errors
- when the cache policy is set to NEVER, all requests for the same
server are serialized - if 100 threads try to resolve the same server,
100 requests will be made one after another.
However, with the default cache timeouts of 30/10 seconds, these
problems are usually unnoticeable.

I'd rather not extend the default caching periods; I've seen DNS
responses with 30 second TTL, and if we cache the results longer than
that, we might break someone's design.

Regards,
Daniel

pt., 10 mar 2023 o 11:12 Sergey Bylokhov <bylokhov at amazon.com> napisał(a):
>
> Hello
>
> I would like to discuss the possible improvement of the DNS cache which is implemented in the shared
> code in "InetAddress.java":
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/InetAddress.java#L923
> and controlled by the "InetAddressCachePolicy.java"
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/InetAddressCachePolicy.java#L32
>
> At the moment this cache can be configured by the application using the following two properties:
>    (1) "networkaddress.cache.ttl" - cache policy for successful lookups
>    (2) "networkaddress.cache.negative.ttl" - cache policy for negative lookups
>
> These properties are useful but have one limitation as the TTL value is directly related to storing
> the record in the cache.
>
>   - If an application wants to always have up-to-date data, it can always make requests to the
> server. But in this case, "negative responses"/errors can break the application.
>   - If an application wants to make fewer requests to the server, and the DNS value changes rarely
> it can set a long timeout. But obviously, this will lead to the record will be rarely updated. And
> if at the time of the update the failure happens - our cache will become useless as we will cache a
> negative response.
>
> It would be good to have benefits from both cases above without the negative part. I propose to
> implement the possibility to update/refresh entries in the cache periodically without deleting them.
>
> This can be implemented by an additional property like "networkaddress.extended.cache.ttl".
>
> Consider an example: the application may set the next values "networkaddress.cache.ttl" = 60 and
> "networkaddress.extended.cache.ttl" = 600. This will cache the record for 1 minute and then, if the
> next request is successful, re-cache the value for another 1 minute, and so on. If the next request
> is unsuccessful, it will fallback to the cached record for 9 minutes(10 minutes from the last
> successful lookup), and finally after a few attempts to update/re-cache the value will be deleted
> from the cache.
>
> Default behavior when this new property is not set will not be changed.
>
> Thoughts?
>
> --
> Best regards, Sergey.