(adding back net-dev) Hi Autumn, Thanks for the clarifications.
The JDK usually doesn't do any logging unless asked to; I don't think a misused property warrants a warning on stderr. I think we can add a set of system properties to configure caching. Would you be interested in that? We originally used security properties because DNS spoofing was a big concern; it's much less of a concern today. Alas, we can't match the names of the security properties - the naming convention dictates that all new system property names start with "jdk." or "java.". Our documentation can mislead users into thinking that they could configure caching using system properties. I filed https://bugs.openjdk.org/browse/JDK-8323089 for that. Regards, Daniel pon., 29 sty 2024 o 18:43 Capasso, Autumn <autum...@amazon.com> napisał(a): > > Hi Daniel, > I wanted to thank you so much for all the information you took the time to > provide I really appreciate it. We noticed many developers had misconfigured > security properties and seem unsure of how to use them on Github, and > Stackoverflow we are purposing a mechanism to warn developers through stderr > about misconfigured Security properties that have been mistaken for system > properties. Developers think they’re changing a System property and they not > get their desired effect. I created a JBS issue that I have included in this > email. We would like to focus on the DNS cache TTL property. During our > investigation of this issue we noticed many developers had misconfigured > security properties. One example is a search on Github for > -Dnetworkaddress.cache.ttl: > https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code<https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code> > this search illustrates how developers mistake security settings for system > properties and end up with misconfigurations. > > Thank you so much, > Autumn > > On 1/5/24, 6:32 AM, "Daniel Jeliński" <djelins...@gmail.com > <mailto:djelins...@gmail.com>> wrote: > > > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you can confirm the sender and know the > content is safe. > > > > > > > Hi Autumn, > Thanks for bringing it up here. > The documentation could definitely use some improvement; we could make > the property documentation link to the Security class, which in turn > documents the use of the java.security file. We should also remove > these security properties from the system properties list > (https://docs.oracle.com/en/java/javase/21/docs/api/system-properties.html > <https://docs.oracle.com/en/java/javase/21/docs/api/system-properties.html>). > > > I'm not sure about exposing the DNS configuration as system > properties. The configuration can already be set using undocumented > system properties, but only if the corresponding security property is > not set (so, for example, sun.net.inetaddr.ttl will work, but > sun.net.inetaddr.negative.ttl will not). There's probably a reason why > these properties are not documented, others could explain. > > > As I'm sure you found out already, the default TTL is 30 seconds for > successful lookups, 10 seconds for failed lookups. What kind of values > would you use to reduce the DNS pressure? > > > If you're looking to reduce the DNS activity, there are many other > options to choose from: > - use a local caching DNS resolver like systemd-resolved > - cache the resolved InetAddress instance on the application level > - use a custom address resolution service provider (requires JDK 18+, > see https://openjdk.org/jeps/418 <https://openjdk.org/jeps/418>) > - use the hosts file > - use a local caching DNS server > > > The default JDK resolver uses the standard C APIs to resolve DNS > hostnames, and has no access to the TTL information returned by the > server. Further, negative caching does not differentiate between a > negative response and a DNS failure. For that reason you should prefer > using caches that have access to that information. > > > Let me know if that helps. > Regards, > Daniel > > > czw., 4 sty 2024 o 22:45 Capasso, Autumn <autum...@amazon.com > <mailto:autum...@amazon.com>> napisał(a): > > > > We began investigating this issues when we noticed many developers had > > misconfigured security properties. One example is a search on github for > > Dnetworkaddress.cache.ttl: > > https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code > > <https://github.com/search?q=-Dnetworkaddress.cache.ttl&type=code> this > > search illustrates the how developers mistake security settings for system > > properties and end up with misconfigurations. We see developers are > > misconfiguring networkaddress.cache.ttl and > > networkaddress.cache.negative.ttl settings, Often in the effort to increase > > the TTL for entries in the DNS cache, they mistakenly change the > > networkaddress.cache.ttl on the command line which does nothing. This means > > teams don’t actually end up raising the DNS cache TTL. Inadvertently > > leaving the cache TTL too low places more pressure on DNS servers. We would > > be open to at first narrowing the scope from all security properties to > > just the DNS cache properties and doing a proof of concept. We’ve also > > gotten the suggestion of implementing it by adding system property > > overrides for those DNS security properties. > > > > > > > > Thank you in advance, > > > > Autumn Capasso > > > > > > > > > > >
