Page Comparison

h1. Java DNS Caching Solutions
As part of the CAS High Availability upgrade, CAS will be changing its IP address.  This change will be carried out on the Campus DNS servers which will have their outbound TTL for the cas.ucdavis.edu hostname set to 10 minutes prior to the change.

However, as we discovered in the original High Availability rollout attempt, Java-based CAS clients do not automatically pick up the DNS changes.  This is caused by an underlying security setting of the Java Virtual Machine that caches DNS resolutions permanently between restarts.  This causes those clients to break after the DNS switch, as they do not update their IP address to the new setting.

||Affected Clients||Unaffected Clients||
|If your service uses one of the following clients, *YOU MUST* use one of the workarounds listed below.
* Ja-Sig Java CAS client (all versions)
* JSP CAS Client
* Cold Fusion (cas_auth_dbcache and cas_auth_filecache)|If your service uses one of the following clients *DOit is NOT* use one NECESSARY to implement any of the listed workarounds.
* mod_auth_cas
* .NET CAS clients
* ASP CAS Clients
* CASAuthN ISAPI Client
* Zope / Plone Client|

h2. Workarounds
The following workarounds and resolutions will allow your Java-based CASified application to properly authenticate to CAS after the High Availability upgrade.

h3. Workaround #1 - Update JDK to 1.6.0 or greater
Java 1.6 introduced a change to the default DNS caching behaviour. The default value for networkaddress.cache.ttl changed from -1 (cache forever) to a system-dependent value, but only if you have no security manager installed. The idea was for this to work as a robustness against DNS cache poisoning.

{note:Check your local system configuration}
Please note that upgrading to JDK 1.6.0 may not resolve DNS caching issues if the system-dependent value is set to cache indefinitely.  Please check your system settings for DNS caching before relying on this solution.
{note}


h3. Workaround #2 - Change the DNS TTL for the JVM
There are two ways to change the DNS behavior for a JVM.  The most reliable method is to change the settings in the java.security file for the JVM.  It is also possible to pass commandline parameters, but this is not guaranteed to work.  Each of the options are outlined below:
{indent}
h4. Change JVM security properties - RECOMMENDED
Change the following properties in  the java.security file located in %JRE%\lib\security.

* *networkaddress.cache.ttl* (default: -1)
    Specified in java.security to indicate the caching policy for successful 
    name lookups from the name service. The value is specified as as integer 
    to indicate the number of seconds to cache the successful lookup.
** A value of -1 indicates "cache forever".
** We recommended a value of 300 (5 minutes) to ensure your application picks up the CAS DNS change in a timely manner.
* *networkaddress.cache.negative.ttl* (default: 10)
    Specified in java.security to indicate the caching policy for un-successful
    name lookups from the name service. The value is specified as as integer to 
    indicate the number of seconds to cache the failure for un-successful lookups.
** A value of 0 indicates "never cache". A value of -1 indicates "cache forever". 
** We do not recommend changing this setting from the default.

h4. Command line properties

* *sun.net.inetaddr.ttl*
    This is a sun private system property which corresponds to networkaddress.cache.ttl. 
    It takes the same value and has the same meaning, but can be set as a command-line 
    option. However, the preferred way is to use the security property mentioned above. 
** Apply this setting by adding *-Dsun.net.inetaddr.ttl=300* to the JAVA_OPTS of your application.
** We recommended a value of 300 (5 minutes) to ensure your application picks up the CAS DNS change in a timely manner.
* *sun.net.inetaddr.negative.ttl*
    This is a sun private system property which corresponds to networkaddress.cache.negative.ttl. 
    It takes the same value and has the same meaning, but can be set as a command-line option. 
    However, the preferred way is to use the security property mentioned above.
** Apply this setting by adding *-Dsun.net.inetaddr.negative.ttl=10* to the JAVA_OPTS of your application.
** We do not recommend changing this setting from the default.
{indent}
{info:title=Restart Required}
Please note that after applying either of these properties, you must restart Java in order for the changes to take effect.
{info}
h3. Workaround #3 - Perform a server restart after the CAS HA Upgrade
While this solution will not account for any future DNS changes, likely the easiest approach is to simply schedule a server restart after the CAS HA Upgrade is complete.  We will clearly indentify the upgrade window for the HA upgrade so that you may schedule your server restart with confidence.