dnsjava is an implementation of DNS in Java. It supports almost all defined record types (including the DNSSEC types), and unknown types. It can be used for queries, zone transfers, and dynamic updates. It includes a cache which can be used by clients, and an authoritative only server. It supports TSIG authenticated messages, partial DNSSEC verification, and EDNS0. It is fully thread safe.

dnsjava was started as an excuse to learn Java. It was useful for testing new features in BIND without rewriting the C resolver. It was then cleaned up and extended in order to be used as a testing framework for DNS interoperability testing. The high level API and caching resolver were added to make it useful to a wider audience. The authoritative only server was added as proof of concept.

This repository has been a mirror of the dnsjava project at Sourceforge since 2014 to maintain the Maven build for publishing to Maven Central. As of 2019-05-15, Github is officially the new home of dnsjava.

Please use the Github issue tracker and send - well tested - pull requests. The [email protected] mailing list still exists.

Some settings of dnsjava can be configured via system properties:

The dnsjava.options configuration options can also be set programmatically through the Options class. Please refer to the Javadoc for details.

dnsjava comes with several built-in resolvers:

• SimpleResolver: a basic resolver that uses UDP by default and falls back to TCP if required.
• ExtendedResolver: a resolver that uses multiple SimpleResolvers to send the queries. Can be configured to query the servers in a round-robin order. Blacklists a server if it times out.
• DohResolver: a proof-of-concept DNS over HTTP resolver, e.g. to use https://dns.google/query.

The project dnssecjava has a resolver that validates responses with DNSSEC.

dnsjava 3 has significant API changes compared to version 2.1.x and is neither source nor binary compatible. The most important changes are:

• The minimum supported version is Java 8
• Uses slf4j for logging and thus needs slf4j-api on the classpath
• The command line tools were moved to the org.xbill.DNS.tools package
• On Windows, JNA should be on the classpath for the search path
• The Resolver API for custom resolvers has changed to use CompletionStage<Message> for asynchronous resolving. The built-in resolvers are now fully non-blocking and do not start a thread per query anymore.
• Many methods return a List<T> instead of an array. Ideally, use a for-each loop. If this isn't possible, call size() instead of using length:
  • Cache#findAnyRecords
  • Cache#findRecords
  • Lookup#getDefaultSearchPath
  • Message#getSectionRRsets
  • SetResponse#answers
  • ResolverConfig
• RRset returns a List instead of an Iterator. Ideally, modify your code to use a for-each loop. If this is not possible, create an iterator on the returned list:
  • RRset#rrs
  • RRset#sigs
• Methods using java.util.Date are deprecated. Use the new versions with java.time.Instant or java.time.Duration instead
• The type hierarchy of SMIMEARecord changed, it now inherits from TLSARecord and constants are shared
• Records are no longer marked as Serializable. Use the RFC defined serialization formats:
  • toString(), rrToString() <-> fromString()
  • toWire() <-> fromWire(), newRecord()
• Message and Header properly support clone()

Java versions from 1.4 to 8 can load DNS service providers at runtime. The functionality was removed in JDK 9, a replacement is requested, but so far has not been implemented.

To load the dnsjava service provider, build dnsjava on JDK 8 and set the system property:

sun.net.spi.nameservice.provider.1=dns,dnsjava

This instructs the JVM to use the dnsjava service provide for DNS at the highest priority.

Run mvn package from the toplevel directory to build dnsjava. JDK 8 or higher is required.

Matt Rutherford contributed a number of unit tests, which are in the tests subdirectory. The hierarchy under tests mirrors the org.xbill.DNS classes. To run the unit tests, execute mvn test.

There's no standard way to determine what the local nameserver or DNS search path is at runtime from within the JVM. dnsjava attempts several methods until one succeeds.

• The properties dns.server and dns.search (comma delimited lists) are checked. The servers can either be IP addresses or hostnames (which are resolved using Java's built in DNS support).
• On Unix/Solaris, /etc/resolv.conf is parsed.
• On Windows, if JNA is available on the classpath, the GetAdaptersAddresses API is used.
• On Android, depending on the SDK level, either the properties net.dns[1234] or the ConnectivityManager is used (requires initialization).
• The sun.net.dns.ResolverConfiguration class is queried if enabled.
• If available and no servers have been found yet, JNDI-DNS is used.
• If still no servers have been found yet, use the fallback properties. This can be used to query e.g. a well-known public DNS server instead of localhost.
• As a last resort, localhost is used as the nameserver, and the search path is empty.

Javadoc documentation can be built with mvn javadoc:javadoc or viewed online at javadoc.io. See the examples for some basic usage information.

dnsjava is placed under the BSD license. Several files are also under additional licenses; see the individual files for details.

• Brian Wellington (@bwelling), March 12, 2004
• Various contributors, see Changelog
• Ingo Bauersachs (@ibauersachs), current maintainer

• Thanks to Network Associates, Inc. for sponsoring some of the original dnsjava work in 1999-2000.
• Thanks to Nominum, Inc. for sponsoring some work on dnsjava from 2000 through 2017.