DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33226>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33226

           Summary: TTL DNS cache security setting in java.net.InetAddress
                    is not honored when set within Servlet on Sun 1.4.2 VM
                    on linux, but is honored in stand-alone java app
           Product: Tomcat 4
           Version: 4.1.18
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Unknown
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: [EMAIL PROTECTED]
                CC: [EMAIL PROTECTED]


1.  From within a stand-alone jdk 1.4.2 app, (like in static void main(String[]
arg)),  do a:
        java.security.Security.setProperty( "networkaddress.cache.ttl", "0" );

    This successfully changes the ttl dns cache setting, because 
        java.security.Security.getProperty( "networkaddress.cache.ttl" );
    returns "0".

    Now, 
        System.out.println( java.net.InetAddress.getByName( "earthlink.net" ) ) 
    will result in a particular IP resolution like:
        earthlink.net/207.217.121.217

    However, "earthlink.net", for example, has multiple IP addresses that it 
    round robins through.  This can be seen from printing out InetAddress[] 
    return from:
        java.net.InetAddress.getAllByName( "earthlink.net" );

    Now, subsequent java.net.InetAddress.getByName ( "earthlink.net" ) calls  
    will show IP addresses cycled in a round-robin manner.

    This all works as expected according to:
        http://java.sun.com/j2se/1.4.2/docs/api/java/net/InetAddress.html


2.  Now, do essentially the same thing in a servlet deployed on Tomcat 4.1.18:

    In a browser hit this url to execute the servlet code below:
http://myHost/servletPath?host=earthlink.net
    
    public class TestDnsServlet extends HttpsServlet
    {
        private void doGet(HttpServletRequest request, HttpServletResponse 
response)
        throws ServletException, IOException
        {
            Security.setProperty( "networkaddress.cache.ttl", "0" );
    
            try
            {
                PrintWriter out = response.getWriter();
                String hostname = request.getParameter( "host" );
                
                out.println("<html><body>\n");
             
                out.println("networkaddress.cache.ttl = " +
Security.getProperty("networkaddress.cache.ttl") + "<br>\n");
                            
                InetAddress[] IP = InetAddress.getAllByName( hostname );
                out.println( hostname + ":<BR>\n" );
                for (int j=0; j<IP.length; j++)
                {
                    out.println( "  " + IP[j] + "<BR>\n");
                }
    
                out.println();
                for (int j=0; j<20; j++)
                {
                    out.println( "IP lookup: " + InetAddress.getByName( hostname
) + "<BR>\n" );
                }
                
                out.println("</body></html>\n");
            }
            catch (UnknownHostException e)
            {
                System.err.println( "  unknown host" );
            }
            catch (IOException e)
            {
                e.printStackTrace();
            }
        }


RESULTS of (2):
    The multiple InetAddress.getByName() calls in the above for-loop all return
the first IP returned from InetAddress.getAllByName() as though it is cached,
even though the network.cache.ttl setting is clearly changed to "0".
    This makes it seem like Tomcat is somehow intercepting the call and
providing its own implementation??  Perhaps the pluggable DNS Provider made
available by JDK 1.4.2 are being used?


EXPECTATION:
    (2) should work the same as (1).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to