Re: Modular DNS resolution

[Dalibor Topic]

Hi Bryce,

Bryce McKinlay wrote:
> On Sunday, Oct 5, 2003, at 23:25 Pacific/Auckland, Guilhem Lavaux wrote:

> I think we want to stick with always using the OS's gethostbyname(). 
> This ensures that the OS settings for name resolution get respected by 
> Java - I suspect things like /etc/hosts, and other name resolution 
> schemes like zeroconf/rendevous, etc may not get recognized by a Java 
> resolver without additional Java-specific configuration.

citing from the documentation for dnsjava on 
http://www.xbill.org/dnsjava/README :

Limitations:

There's no way to determine what the local nameserver is at runtime from 
within
the JVM.  First, the property 'dns.server' (a comma delimited list) is
checked.  These can either be IP addresses or hostnames (which are resolved
using Java's built in DNS support).  If the underlying OS is unix-based, the
dnsjava package can parse /etc/resolv.conf and determine the 
nameservers.  If
the underlying OS is Windows, winipcfg/ipconfig can be called and the output
parsed.  Note that this may fail for non-English versions of Windows.
Otherwise, or if these attempts fail, the default nameserver is
"localhost".  This is unavoidable.  Unfortunately, I have no idea how to
determine the nameserver for any other OSes.  Contributions of code
are welcome (see org/xbill/DNS/FindServer.java for the basic structure).

I don't know much about DNS resolution, but it sounds to me that the 
implementation cares about OS specific settings.

> The "additional insights" would certainly be useful for applications 
> that need to integrate tightly with DNS, however I don't think it would 
> be useful or neccessary to put this inside InetAddress itself - no more 
> information can be obtained given the existing InetAddress interface, 
> right?

I guess so.

> Surely it would be better to put this code in its own class under gnu.* 
> somewhere? Note that external resolvers can now easily create 
> InetAddress objects using the JDK 1.4 getByAddress() methods, which are 
> already implemented in classpath.

I'd prefer to move actual DNS resolution into its own VM-specific class, 
with the implementation being selectable by a system property.

That way, the traditional approach, to call the native platform's 
gethostbyname() can be capsuled in it's own class, but also allow those 
with specific needs (think bare-metal embedded systems, or VMs that 
don't have the need for native methods) to use a pure java way of doing 
DNS resolution. It wouldn't require putting the actual dnsjava code into 
Classpath's repository, or submitting it to FSF, but would allow users 
of Classpath to use it if they wish.

For the way it worked in kaffe, take a look at 
http://www.kaffe.org/doc/kaffe/FAQ.dns .

cheers,
dalibor topic