rosanna.lee@eng 1999-10-21
A DNS provider would address the following issues:
1. Name resolution.

There are several high-priority bugs in classes_net filed against name
resolution. The core of the problem is that the name resolution code
relies on the platform native nameservice API to resolve names, and
different platforms sometime have different nameservices. By providing
a pure Java DNS client, for those applications that care, they can
explicitly request the use of DNS and get around any platform
dependencies. For now, the caching bugs in the networking code get
around the problem by using an undocumented system property to control
caching. The DNS service provider could be used by the InetAddress
class, so that the InetAddress class is not dependent on
platform-specific name resolution code. It could also be used by the
InetAddress to do caching in a way compatible with the TTL settings on
the DNS servers.

2. Locating LDAP servers. There is an IETF proposal (by Microsoft) to
locate LDAP services using SRV records in the DNS. For Windows NT
2000, this is the way NT clients locate their LDAP/Active Directory
servers. This allows clients to know "automatically" (i.e., without
per-client administration) how to locate LDAP servers. Our LDAP client
(the JNDI/LDAP service provider) currently must explicitly name the
LDAP server. The ability to read SRV records from the DNS from a Java
program (as provided by the DNS provider) would allow the LDAP service
provider to automatically locate the LDAP service when such a feature
is enabled in an environment such as an NT 2000 network.

3. Locating other services.
As NT 2000 becomes deployed and services use RFC 2052 and its variations
to hold service address information, Java applications
that want to work using that model need access to DNS SRV records.

4. Mail address data. Allows Java applications, such as JavaMail,
to have access to mail address data (such as MX records) stored in the DNS.

5. Java client access to DNS data. Several external customers have requested this.

Note: This feature is part of the J2SE Reference implementation.
However, it does not add any APIs to the J2SE specification,
is not covered by the TCK, and is not a required part of the
J2SE platform.