Re: HttpUrlConnection caching ip

From: Sam (samhunt90_at_hotmail.com)
Date: 07/20/04 

Date: 20 Jul 2004 07:23:27 -0700

"Christophe Darville" <cdarville@infonosis.com> wrote in message news:<40fcde79$0$6400$ba620e4c@news.skynet.be>...
> "Sam" <samhunt90@hotmail.com> wrote in message
> news:e20518e0.0407191600.458b2e93@posting.google.com...
> > "Christophe Darville" <cdarville@infonosis.com> wrote in message
> news:<40fbd33f$0$1237$ba620e4c@news.skynet.be>...
> > > Hello,
> > >
> > > I got an ip caching problem when using HttpUrlConnection class.
> > >
> > > When using the code :
> > >
> > > URL url = new URL("http://a.domain");
> > > HttpURLConnection connection = (HttpURLConnection) url.openConnection();
> > >
> > > The VM seems to cache the ip address associated with the domain
> "a.domain".
> > > If the ip associated with this domain change, the VM still connect to
> the
> > > old ip. The only way to connect to the new ip, is to restart the VM.
> > >
> > > I have tried
> > > java.security.Security.setProperty("networkaddress.cache.ttl", "0");
> > > but it does not work with HttpUrlConnection (it works fine with
> InetAddress
> > > class for instance).
> > >
> > > Any idea ?
> > >
> > > Thank you,
> > > Christophe
> >
> > Christope,
> >
> > There is a chance the is a DNS caching problem. When you look up the
> > IP address corresponding to a url, DNS looks inside it's local cache,
> > and if found DNS will use that cached IP address instead of going out
> > to the internet to look it up on a remote database. DNS records have
> > some kind of timeout paramter where they eventually expire. But
> > typically ip addresses for a static domain don't change rapidly, so it
> > could take a while.
> >
> > On some windows systems, you can use "nslookup" to see what ip address
> > is beeing returned. I think it works on unix too. You could play
> > around with that, maybe clear the cache or set a timeout.
> >
> > Good luck,
> > Sam90
>
> Sam,
>
> Unfortunately, this is not DNS caching problem. When I ping (on the same
> machine where my java application is running) the domain, the new ip address
> is exact (after a few seconds, of course) but it is never exact in the java
> application. The only way to use the new ip, is to restart the java
> application.
> So it is a DNS caching problem, but at the java level
>
> Christophe

Uhf. I had high hopes. It's the jvm that's caching it, not the URL nor
the connection class - in other words, you are running this code
before and after the ip address change?

>>URL url = new URL("http://a.domain");
>>HttpURLConnection connection = (HttpURLConnection)
url.openConnection();

And this code reflects the change?

>>String dottedQuad = InetAddress.getByName( "mindprod.com"
).getHostAddress();

This fact that this code even exists:

>> java.security.Security.setProperty("networkaddress.cache.ttl",
"0");

indicates that Java security is caching DNS address.

The more I look at it, the more it appears that for whatever reason,
the URL or HTTPURLConnection is ignoring the java security setting and
using the default, which is to keep the same address it found
"forever". This is presumably some static behavior of the command, and
could be a bug. You could probably find the source code and isolate
the problem if you were motivated, but otherwise you may need to find
an alternative the class in question. Sorry I couldn't figure it out.

Below is a relevant post I found on usenet which you've probably seen,
but I'm filing for prosperity:

InetAddress Caching

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.
By default, the result of positive host name resolutions are cached
forever, because there is no general rule to decide when it is safe to
remove cache entries. The result of unsuccessful host name resolution
is
cached for a very short period of time (10 seconds) to improve
performance.

Under certain circumstances where it can be determined that DNS
spoofing
attacks are not possible, a Java security property can be set to a
different Time-to-live (TTL) value for positive caching. Likewise, a
system
admin can configure a different negative caching TTL value when
needed.

Two Java security properties control the TTL values used for positive
and
negative host name resolution caching:

* networkaddress.cache.ttl (default: -1)
Indicates the caching policy for successful name lookups from the name
service. The value is specified as as integer to indicate the number
of
seconds to cache the successful lookup.
A value of -1 indicates "cache forever".

* networkaddress.cache.negative.ttl (default: 10)
Indicates the caching policy for un-successful name lookups from the
name s
ervice. The value is specified as as integer to indicate the number of
seconds to cache the failure for un-successful lookups.
A value of 0 indicates "never cache". A value of -1 indicates "cache
forever".

Regards,
Sam90

Relevant Pages

  • Re: Multiple instances of BIND at startup
    ... The caching name server will see tens ... of thousands of our clients requests to use as their DNS ... recursion yes; ...
    (freebsd-questions)
  • RE: Viewing Cached Items ISA 2004
    ... Turns out it was ISA caching. ... I disabled caching and it works fine now. ... > 'external' DNS name to access the website both internally and externally. ... > Set and setup a cache rule Not to cache the external DNS name. ...
    (microsoft.public.isa)
  • Re: Viewing Cached Items ISA 2004
    ... updates, or more aggressive caching, and so on) using cache policy rules. ... >> 'external' DNS name to access the website both internally and externally. ...
    (microsoft.public.isa)
  • RE: My kingdom for a working DNS
    ... >figure it's a system which checks with an external DNS ... A local caching nameserver does not ... Your DNS server does the same amount of work that your ISP's ... answer from the cache in about 1ms. ...
    (Fedora)
  • Re: DNS caching locally ...
    ... if all you need is caching (ie. you have upstream nameservers ... you can use), I'd suggest dnrd. ... Domain Name Relay Daemon is a caching, forwarding DNS proxy server. ...
    (freebsd-questions)