As some of you have already found out
, Java's DNS cache policy is to cache DNS lookups for as long as the JVM is alive
Java-monitor now has a new probe that helps you examine the IP address lookup cache policy in your application server.
To enable this new feature, download and deploy the latest Java-monitor probe. Once it is deployed and operational, you can examine the DNS cache policy for a given host using the following steps:
In the host overview, click on the host that you'd like to examine. This brings you to the host page, with all the graphs. Select the link with the name "see all measurements". This brings you to the JMX page, which shows you all the detail of the data that is being monitored for your server. On that page, use your browser's search feature to find the word "DNSCachePolicy".
The attribute named "CacheSeconds" tells you how many seconds a DNS lookup will be cached. A value of 0 means that no caching is done, and a value of -1 means that all lookups are cached forever. You can change this value by specifying -Dsun.net.inetaddr.ttl property at startup.
There are several important factors to consider when picking a DNS query cache policy: security against DNS poisoning attacks and ability to respond to infrastructure changes.
The reason Sun has decided to use the infinite cache policy is to help safeguard a server against DNS poisoning attacks. Since the Java application server does not repeat DNS queries, it will not retrieve poisoned results but reuse the ones it has.
The unfortunate side effect of this policy is that if a server were to move to a new location and change its IP address, that server effectively becomes invisible to the JVM. This means that for JVM's and application servers that need to be on and available for months at a time, the DNS lookups cannot be cached infinitely. That would make your application server's uptime dependent on infrastructure changes that were designed to be relatively harmless.
As I write this, it occurs to me that this policy also kills any form of round-robin DNS strategy for load balancing backend servers. Woops.
Finally, there is the cost of DNS queries. Network calls to a DNS server are a lot slower than a local hash map lookup, especially if the primary DNS has failed and the secondary DNS server is taking over. If you are the one causing the switch you may have to way several seconds for your answer.
For my servers, I picked a value of 3600 seconds for sun.net.inetaddr.ttl (i.e. -Dsun.net.inetaddr.ttl=3600). I think that is a good tradeoff between the relativly high cost of DNS queries and the need to be able to respond to change.