[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modular DNS resolution

From: Dalibor Topic
Subject: Re: Modular DNS resolution
Date: Mon, 06 Oct 2003 17:12:59 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312

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 :


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/ 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 .

dalibor topic

reply via email to

[Prev in Thread] Current Thread [Next in Thread]