random technical thoughts from the Nominet technical team

Nonblocking extensions to dnsjava

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 4 out of 5)
Loading ... Loading ...
Posted by alexd on Aug 8th, 2006

We have used the open source dnsjava library for several applications. For most purposes, the library works well. However, each query is run its own thread, on its own port. This means that for applications with high query volumes, an unacceptable number of threads and ports may be in use.

To solve this problem, we have implemented an extension to dnsjava-2.0.0. The extension adds a new Resolver implementation, NonblockingResolver, with the following features :

  • Java nio library used
  • Queries run in one thread, on one port (where possible). If two concurrent queries have been set by the application to have the same header ID, then they will be run on separate ports.
  • Original dnsjava Resolver::send and Resolver::sendAsync methods supported
  • A new callback interface (INonblockingResolver and ResponseQueue) is provided to allow one application thread to handle completion of all queries.

Here is some example code that uses the ResponseQueue [It is pretty contrived - a simple example like this would do just as well to use the standard Resolver callback] :

import org.xbill.DNS.*
import uk.nominet.dnsjnio.*
NonblockingResolver resolver = new NonblockingResolver("localhost");
Message query = getQuery("example.net");
Integer id = new Integer(idCount++); // Not the header ID, but can be!
ResponseQueue queue = new ResponseQueue();
resolver.sendAsync(query, id, queue);
Response result = queue.remove(); // This call blocks until the queue is not empty
assertTrue(result.getId() == id && !result.isException());

The blocking remove call would normally be done in the event loop, and any query completion will complete the call.

This code has been tested on Windows XP and Solaris. The Java nio library contains a native binary for the platform it runs on; although all platforms should run fine, there are not yet any guarantees. I’d be interested to hear if anybody has any success/problems with any other platforms.

The code can be downloaded from here

Note that dnsjava must be on your classpath

8 Responses

  1. techblog » Blog Archive » New release of dnsjnio Says:

    [...] Those who use the dnsjnio non-blocking I/O extension to dnsjava might be interested in a new release (0.9.6) which fixes a minor issue. [...]

  2. techblog » Blog Archive » DNSSEC zone walker Says:

    [...] In order to solve this problem, we first had to fix dnsjava. Rather than modify the library itself, we decided to make an independent extension. This extension extended the Resolver implementation to offer a new NonBlockingResolver, with a ResponseQueue interface to the caller. [...]

  3. Stefano Says:

    Hi Alex,

    it is great to see that someone is working on an asynch dns resolving library for Java. I was just thinking that the world is missing this and I was studying how to change dnsjava to support asynchronous resolution without the use of 1 thread for each lookup and after few searches I found this blog and I downloaded dnsjnio 0.9.6 for a test!

    I think you did a damn useful thing and I’m happy you decided to opensource it: why not to put it on a collaborative site (apache/googlecode/java.net/sourceforge/codehaus or anything similar) so that it will be more easy to provide patches, submit bugs and so on?

  4. Alex Says:

    Hi Stefano –

    Thanks very much for your feedback! It’s nice to know that dnsjnio is useful to somebody (although it would be even nicer to know what for!). Please let me know if you have any issues or questions.

    You’re right about the repository – I’ll try to get the project moved over to Sourceforge over the next few days. I’ll put a comment up here when I do.

    Thanks again,


  5. Stefano Says:

    I’m a PMC committer to Apache JAMES Server and Apache JAMES jSPF library.

    Currently I plan to refactor jSPF to be asynchronous and the first step was to be able to run asynchronous DNS calls because the SPF protocol is very DNS intensive!

    I also would like to use the asynch library for the SMTPServer and SMTPClient libraries in future, but one step at a time!.

    I already applied a small change to the library: Thread.setDaemon(true) for the 2 threads created by your lib. This let the process to correctly terminate when only those “processing” threads are left (I think this could be ok also in your/others scenario).

  6. Stefano Says:

    2 cents about the Sourceforge choice: I would try google code instead of sourceforge: sourceforge is slow and need project approval so it will require more time. Furthermore it gives you the basic tools you may need and simple wiki pages for any note you may want to add.

  7. Alex Says:

    I was keen to use sourceforge as the dnsjava project uses sourceforge, and it seemed a good idea to keep them fairly close.
    The new sourceforge project page is here :


    I’ll put out a new 0.9.7 release soon. This includes the setDaemon(true) call, as well as some tidying up of the code.

    I’d like to take the release to the 1.0.0 stage, but have so far been confounded by the lack of beta testers ;0) I’d be very interested to hear how you get on…

    I’ll put one more post up on this blog about the move to sourceforge, from where I will conduct all othe project communications.

    Thanks again for your interest in dnsjnio.


  8. techblog » Blog Archive » dnsjnio moved to sourceforge Says:

    [...] Now that I have finally found external interest in the dnsjnio project, it seems wise to move it to a better home (one with automatic patch support, defect tracking, mailing lists, etc.). Since the dnsjava project (for which dnsjnio is an extension) uses sourceforge, I thought I might as well put dnsjnio there as well. [...]

Leave a Comment

Please note: Comment moderation is enabled and may delay your comment. There is no need to resubmit your comment.

Recent Posts

Highest Rated