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