Caching behaviour of InetAddress

Andreas Plesner Jacobsen apj.lists at code3.dk
Mon Feb 18 05:16:31 PST 2008


Alan Bateman wrote:

Alan,

>> I don't think it's a significant change, since that's how getByName() 
>> acts when the cache entries time out, so changing it would make it act 
>> a lot more consistently.
>>
>> Actually, I think it's worth debating whether or not InetAddress 
>> should cache lookups at all, I think it's more fitting to delegate 
>> that to the underlying OS.
>>
> Search for a ~1996 paper on DNS spoofing attacks from Princeton 
> University as that gives useful background on this topic and is the 
> original reason for the caching. When a security manager is set then it 
> caches forever and getByName will always return the same address. There 
> was some capitulation on this topic in jdk6 so that it doesn't cache 
> forever when there isn't a security manager. There was analysis done at 
> the time on the implications of the change but I don't know if that 
> included changing the behavior of the getByName method (Michael?).

Thanks for the background info. Incidentally, that brings us to a third 
inconsistent operating mode of getByName(), so we're up to three 
different behaviours:

1. When running under a security manager, we cache forever
2. When not running under a security manager, with more than ten seconds 
between name lookups, we return random answers (at least if the dns 
reply is delivered randomized to java)
3. When not running under a security manager, with less than ten seconds 
between name lookups, we return the same answer on every query.

As far as I can see from what I've been able to google, the problem lies 
in that applets may be cheated in connecting to a different host, and 
that this makes it easier (actually invisible) to the applet author that 
there may be more than one record in the dns reply.

I may not have a lot of say in this, but I still don't feel this is the 
right solution. Do you perhaps have some more resources to any previous 
discussion on the subject?

I think I'd prefer breaking compatibility and introducing a caching 
InetAddress implementation for applet programmers and make InetAddress 
work as expected. But then again, I don't have to do the required cleanup :)

-- 
Andreas



More information about the net-dev mailing list