RE: Avoid server lookups for localhost in SPI and PTR queries

[Bauersachs I. <ing...@fh...>]

Thanks for looking into it!

>> I'm trying to integrate DNSJAVA's SPI in Jitsi and had a few issues:
>> - Some JVM internals (seed generation for randomness) call
>> InetAddress.getLocalHost. This causes a lookup to the configured DNS server,
>> which usually doesn't know of localhost (or on Windows, my machine name).
> 
> I'm not sure if this is usually the case.  It's the case sometimes, but it
> depends on a lot of things.

Windows, Ubuntu, OpenSuse and Fedora in default installations all return the hostname (not localhost), so this is where my "usually" came from. I don't know about other (non-Sun/OpenJDK) VMs.

>> - SSL/TLS sockets try to obtain the hostname from InetAddress objects,
>> which causes PTR query when the InetAdresses object was not pre-initialized
>> with the hostname.
>> 
>> Attached is a patch to DNSJAVA that solves these issues. Would you mind
>> applying it to trunk?
> 
> I think some of it can be applied, but not all.
> 
> The changes to ARecord/AAAARecord look ok.  I believe someone else suggested
> similar changes at some point, and I don't think there are any downsides.
> I'll commit this part.

That would be nice, thanks! :-)

> The change in Address might be ok, but I don't know why setting the hostname
> to a literal address representation is an improvement over not being set.  If
> it is a good idea, then all the other places in Address doing the same things
> should also be changed.

The benefit over not specifying it, is avoiding a PTR query. If someone indeed does want a PTR query it could be sent through the library or obtained with InetAddress.getCanonicalHostName().
It of course might depend on the point of view of whether avoiding a PTR query is an advantage or not. As there are sometimes problems with unnecessary delays due to these PTRs, I see more advantage than disadvantage.
I agree that the other methods should then also be changed.
 
> The SPI changes are not backwards compatible in the case where a lookup of
> localhost would work, which is almost always the case on non-Windows machine,
> and often the case on Windows machines.  Specifically, an application looking
> up "localhost" might get any combination of 127.0.0.1, ::1, or a routable
> address, depending on the configuration of the machine and the local DNS
> server.  This also uses undocumented internal classes, and I have no way of
> knowing whether the code would work at all across the set of supported
> platforms and Java versions.

That is indeed true :(
Would it be an option to make this workaround configurable through a system property?

Problem is: without such a check there are huge delays and the SPI becomes almost unusable. I updated the change (attached) so that it uses the default addresses (those returned without dnsjava as an SPI) for a query to localhost, so the results should cover the variety of possible localhost answers.

I'm not sure whether it's much of a problem to use those internal classes. Generally it's bad of course, but the whole SPI implementation is already based on something Sun/Oracle declared as internal (sun.* namespace and "These properties may not be supported in future releases.") A failure to access those internals would only result in the default behavior of asking the server.

>> More of a general question: The project uses a very unusual file-layout for
>> Java projects and the Ant buildscript also needed some modifications to get
>> the stuff running. Would it be an option to bring that in a more "standard"-
>> compliant layout? I'd help of course if you're interested. :-)
> 
> The dnsjava code base precedes whichever standard you're talking about, and
> in the 13 years or so that I've been developing it, there have been more
> standards than I can count.  I don't see any reason to change everything to
> comply with the current one.

I guess there is no real standard, that's why I put it into quotes. Forget it :-)

> Brian

Ingo