[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
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