Caching behaviour of InetAddress
Alan.Bateman at Sun.COM
Mon Feb 18 13:37:50 PST 2008
Andreas Plesner Jacobsen wrote:
> 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.
That is basically it as per jdk6 (caching was always forever in releases
prior to jdk6). The spec doesn't require a particular caching period and
in the Sun implementation it is 30 seconds (and 10 seconds for
unsuccessful lookups). You can of course configure the caching period or
disable it completely by means of security properties.
> 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 don't think this issue has been discussed on this mailing list but if
you google for DNS pinning you should find a lot on this topic. Many
other technologies and products (browsers, plug-ins, ...) also pin.
More information about the net-dev