Java's awful DNS caching

According to Sun's documentation, Java's DNS caching ignores the TTL provided in the DNS record, and by default caches DNS records indefinitely.

This causes enormous problems for Java VMs that run for days, weeks or months without stopping. They build up a very large DNS cache, and are unable to react to changes in the DNS system.

Here's a post describing such a problem in the open-source application LimeWire. At work we've had the same problems, with database DNS changes not being picked up by our Java-based application server.

This is an example of terrible malpractice in implementing a DNS cache upon which much software relies. Sun urgently needs to fix this setting to a sensible default.

Update 15 July 2008:

This behaviour has been changed in Java 1.6 according to the API documentation. The caching behaviour depends on whether a security manager is enabled or not, and the cache time with a security manager is implementation dependent:

By default, when a security manager is installed, in order to protect against DNS spoofing attacks, the result of positive host name resolutions are cached forever. When a security manager is not installed, the default behavior is to cache entries for a finite (implementation dependent) period of time. The result of unsuccessful host name resolution is cached for a very short period of time (10 seconds) to improve performance.

Portrait of Matt Ryall

About Matt

I’m a technology nerd, husband and father of four, living in beautiful Sydney, Australia.

My passion is building software products that make the world a better place. For the last 15 years, I’ve led product teams at Atlassian to create collaboration tools.

I'm also a startup advisor and investor, with an interest in advancing the Australian space industry. You can read more about my work on my LinkedIn profile.

To contact me, please send an email or reply on Twitter.