Caching behaviour of InetAddress
I've recently been introduced to the caching behaviour of InetAddress,
and I think it may be improved.
The javadoc reads:
The InetAddress class has a cache to store successful as well as
unsuccessful host name resolutions. The positive caching is there to
guard against DNS spoofing attacks; while the negative caching is used
to improve performance.
And that is all fine and well, but for multihomed hosts, I believe the
current behaviour is
1) Not documented properly
2) Not correct
Coming from a unix-world, I'm used to the resolver handing out
RR-replies in random order, and thus I would expect InetAddress to do
the same, but a short test (courtesy of Arne Vajhøj) shows that
InetAddress.getByName() will return the same IP for a lookup when the
lookup is performed within the 10-second range of the cache:
public class DNSLookup {
private static final String MS = "www.microsoft.com";
public static void main(String[] args) throws Exception {
Map m = new HashMap();
InetAddress[] all = InetAddress.getAllByName(MS);
for(InetAddress one : all) {
m.put(one.getHostAddress(), 0);
}
for(int i = 0; i < 1; i++) {
String ms = InetAddress.getByName(MS).getHostAddress();
m.put(ms, m.get(ms) + 1);
}
for(Entry e : m.entrySet()) {
System.out.println(e.getKey() + ": " + e.getValue());
}
}
}
Outputs:
207.46.19.190: 0
207.46.193.254: 1
207.46.192.254: 0
207.46.19.254: 0
While I would expect the replies to distribute to about 2500 on each
(which it will if the cache isn't used).
--
Andreas
Re: Caching behaviour of InetAddress
Andreas Plesner Jacobsen wrote: I've recently been introduced to the caching behaviour of InetAddress, and I think it may be improved. The javadoc reads: The InetAddress class has a cache to store successful as well as unsuccessful host name resolutions. The positive caching is there to guard against DNS spoofing attacks; while the negative caching is used to improve performance. And that is all fine and well, but for multihomed hosts, I believe the current behaviour is 1) Not documented properly 2) Not correct Coming from a unix-world, I'm used to the resolver handing out RR-replies in random order, and thus I would expect InetAddress to do the same, The specification could be improved but changing InetAddress.getByName to return a random address is a significant change that could break existing applications. It might be better to define a new method, perhaps "getAnyByName", that randomly chooses one of the cached addresses for the host (or does a lookup if not in the cache). That would be a convenience to applications to avoid needing to invoke getAllByName and choose an address themselves. -Alan.
Re: Caching behaviour of InetAddress
Alan Bateman wrote: Alan, The specification could be improved but changing InetAddress.getByName to return a random address is a significant change that could break existing applications. It might be better to define a new method, perhaps "getAnyByName", that randomly chooses one of the cached addresses for the host (or does a lookup if not in the cache). That would be a convenience to applications to avoid needing to invoke getAllByName and choose an address themselves. 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. -- Andreas
Re: Caching behaviour of InetAddress
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
Re: Caching behaviour of InetAddress
Andreas Plesner Jacobsen wrote: : 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?). -Alan.
Re: Caching behaviour of InetAddress
a) The java.net cache is replicating the NSCD (OS caching), which are the appropriate layer for this kind of caching. b) If a security policy requires a kind of caching, then the replaceable and extensible security manager architecture should be used for this. On 2/18/08, Andreas Plesner Jacobsen <[EMAIL PROTECTED]> wrote: > > > 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. > >
Re: Caching behaviour of InetAddress
* Alan Bateman: > 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. That paper is probably out of date by now. Interaction of expiry and poisoning hasn't been fully understood back then. > When a security manager is set then it caches forever and getByName > will always return the same address. This is probably related to DNS pinning/anti-pinning attacks, not to cache poisoning.
Re: Caching behaviour of InetAddress
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. -Alan.
