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.
