Having worked with dnsjava, I felt there were some significant issues with it
for the types of applications I wanted to develop.
Specifically,
* I want mutable objects, that can be selectively made immutable.
- dnsjava records are always immutable.
* I want my objects to always work the same no matter if a message has been
"built"/marshaled/unmarshaled.
- some methods, specifically on the Message object behave differently if
you are working with a message that has been parsed from the wire VS one your
are building programatically. For example, if you call Message.setTsig(..) and
later call Message.getTsig() you would expect to get back the TSIG you set
previously. With dnsjava you only get a TSIG back from getTsig() if the
message was parsed from the wire.
* I want all overloaded messages to behave similarly, as a Java coder would
expect.
- Message.toWire() and Message.toWire(int) in dnsjava have some differences
in how they behave. For example, if you had called Message.setTsig(..) you
would expect the TSIG to be written in the DNS message when calling .toWire()
or .toWire(int). The TSIG is only written when .toWire(int) is called.
* I wanted a better OO design and I wanted to use Java 5 language features.
- a DNS Header as a separate object doesn't really make a lot of sense to
me. It only has worth as part of a message. It should at best be an inner
class that is not directly exposed as an object outside of Message, if such a
class even exits. All operations that are in dnsjava's Header should be on a
Message object.
- Because Header is a separate object from Message, it is possible for
strange things to happen in dnsjava. For example, your header could say there
are 2 records in the answer section, even though there are none or vice versa.
- There are response codes for messages, TSIGRecords, and a few other
record types. Even though the response code for NOERROR is always the same
value, the various response codes should probably be inner enums of the
appropriate object types. It wouldn't make sense to specify an NXDOMAIN
response code for a TSIGRecord, but with dnsjava you can.
- Data class only makes sense on records. There should probably be an
inner enum on Record that defines what they are instead of it being a separate
class.
- dnsjava doesn't track some data that it should. For example, if you
parse a message off the wire, you should be able to do something like
TSIG.verify(incomingMessage), because the incomingMessage should know what the
bytes were on the wire. dnsJava doesn't keep track of the original bytes, so
you have to. Because of details I won't get into it's necessary to track the
original message bytes for TSIG validation. You cannot simply re-construct the
byte stream by calling Message.toWire().
* I wanted more separation between a DNS parsing library and things built with
it.
- For example, dnsjava includes a resolver and a minimal DNS server along
with all of the parsing code. It's great this is supplied as part of the
project, but they should be separate modules (jars) within the project. If
your building a DNS server using dnsjava there is no reason to have dnsjava's
server and resolver present. It's not a big deal that they are, but i feel
they should be separate.
- I wanted the parsing library as separate from the IO implementation as
possible.
* I wanted a better exception hierarchy that would allow a developer to know
exactly what went wrong instead of just a single exception for all errors.
* I wanted support for evolving standards like NSEC3, IDN, etc.
* I wanted to do everything possible to make it as fast as possible w/o trading
off good design.
* I wanted everything fully javadoc'd.
Considering all the above, and more, I thought starting from scratch would be
the best approach. I don't want this to sound like a dnsjava bash fest though.
Brian's done some great work developing dnsjava and making it open source.
I've learned a lot from using it and reviewing it's code. I'd just like to
develop something with a better "Java feel". Consider it dnsjava 2.0.
Rob
----- Original Message ----
From: Stefano Bagnara <[EMAIL PROTECTED]>
To: dev@mina.apache.org
Sent: Thursday, June 21, 2007 6:21:55 PM
Subject: Re: DNS Protocol (Was: DHCP Protocol Home)
Hi Rob,
I'm happy you hear another voice!! (and more code!)
Can you describe why you decided to create your own library instead of
using dnsjava and what you think are the peculiarity of your code?
Stefano
Rob Butler ha scritto:
> Hello all,
>
> I've been out of town, so I am just catching up on my e-mail now.
>
> I humbly pose myself as the "DNS Expert" you've been looking for. Here's one
> of my public projects you can take a look at: http://bind-dlz.sf.net .
>
> I have already started work on a new Java DNS library. I expect I will be
> releasing this as BSD, but I could make it Apache licensed. My day job keeps
> me _very_ busy so I only get to work on it in fits and spurts. It's nowhere
> near ready for use yet. It will probably be some time before I can get a
> site setup to host the SVN repo and code. I don't know if I would want to
> make it an Apache project or not.
>
> I don't want to be one of those folks that promises the world and then
> disappears. So I completely understand if you want to start your own effort
> instead of waiting for my stuff. At a minimum I could help guide the project
> and make suggestions.
>
> Rob
____________________________________________________________________________________
Need a vacation? Get great deals
to amazing places on Yahoo! Travel.
http://travel.yahoo.com/
