You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Richard Wallace <rw...@thewallacepack.net> on 2007/01/17 05:46:53 UTC
Proposed protocol-dns changes
Hello,
Here are the first set of changes I'd like to contribute to the
protocol-dns subproject. Here's a list of things I've done.
1) Converted the enumeration types ServiceType, ProtocolType,
RecordClass, OpCode, RecordType, MessageType and ResponseCode into
actual Java 5 enums. Because we need to encode and decode the actual
values we can't rely on the ordinals the compiler will assign to them,
so I've used a technique I found on the Java Specialists site
(http://www.javaspecialists.co.za/archive/newsletter.do?issue=113), to
efficiently do a conversion between enums and values with minimal code
duplication.
2) Removed QuestionRecords and ResourceRecords classes since they were
really just type-safe wrappers around Lists and replaced their usage
with generic Lists.
3) Moved any encoding and decoding code that was in the MINA
ProtocolEncoder and ProtocolDecoder to classes in the
o.a.d.s.dns.io.encoder and io.decoder packages called DnsMessageEncoder
and DnsMessageDecoder, respectively.
4) Removed the dependency by the encoders and decoders in the
o.a.d.s.dns.io packages on MINA. The only thing they really used were
the ByteBuffers from MINA and it was a pretty simple task to just switch
to java.nio.ByteBuffers instead. The only hurdle I had to overcome was
in the allocation of temporary buffers for things like enecoding domain
names, which leads me to...
5) Instead of creating (or having to pull them from the MINA ByteBuffer
pool) several ByteBuffers during encoding, I simply wrote directly to
the buffer that was passed in. From what I could tell, the main reason
for allocating the temporary buffers was to do the actual encoding of
the domain name, get the byte array that was written to the buffer,
write the length of the data to the actual ByteBuffer, then write the
byte array from the temporary ByteBuffer. Instead, what I did was to
record the position of the ByteBuffer, increment it by one, write the
data (the domain name for instance), find the difference between the
starting position + 1 and the current position, then go back to the
starting position and write the length of the data and finally jump back
to the end of the data and go onto the next bit of encoding. This
should be more efficient because we're not constantly having to get
ByteBuffers from a pool or have new ones allocated, and we also don't
have to then create byte arrays and have the data from those temporary
ByteBuffers read into the byte arrays.
6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
utility class called ByteBufferUtil.
7) Changed the DnsMessage.transactionId property to be an int because it
actually needs to be an unsigned short.
8) Fixed a bug with decoding domain names when they are compressed. The
new position to jump to wasn't being calculated right all the time.
There also seemed to be an assumption that the first thing to do after
jumping was to read a label, but it could be the case that the new
position is another jump so we need to call recurseDomainName() right
after doing the jump in position.
9) Updated existing tests to actually check that what is encoded and
decoded are correct. For this I also had to add equals() and hashCode()
methods to classes that didn't already have them, like DnsMessage,
ResourceRecordImpl, and others. I simply used the commons-lang equals
and hashCode builders for this because I've found them to be
tremendously useful for this in the past.
10) Added additional test for MX query and response parsing. I used the
MX records from apache.org.
11) Added decoders to make the tests added in (10) pass. these are the
IPv6RecordDecoder, MailExchangeRecordDecoder, AddressRecordDecoder, and
NameServerRecordDecoder.
That should cover it all. I'd like to add a few more decoders for
things like TXT and SOA records. That should cover about 90% of the
records in use on most DNS servers.
Then I'd like to get things separated a little bit more and create
subprojects within protocol-dns. I'm thinking something like
protocol-dns/
core/
mina-shared/
server/
shared/
mina/
store/
client/
core would contain all the DNS message and record types as well as the
decoders and encoders in dns.io right now. mina-shared would contain
the ProtocolCodec stuff in dns.protocol.
server/shared would contain the DnsConfiguration and other stuff that
would be shard among server implementations, whether they use MINA or
some other IO framework and whether they use ApacheDS for the store or
some other backend like Bind zone files.
server/mina would contain the DnsProtocolHandler from dns.protocol as
well as the DnsServer class itself.
server/store would contain the the backend store type stuff. It would
probably wind up being separate subprojects itself, one for LDAP, JDBC,
or Bind zone files.
client would obviously contain any code for developers to generate and
send queries to dns servers, and maybe an implementation of the dig
command line tool.
I wouldn't mind actually seeing this becoming a separate project of it's
own, like dns.apache.org. That would be really cool.
What do you think of these changes?
Rich
Re: Proposed protocol-dns changes
Posted by Enrique Rodriguez <en...@gmail.com>.
On 1/29/07, Richard Wallace <rw...@thewallacepack.net> wrote:
...
> Everything looks good but I don't seem to have access to close the
> issue. I can reopen it, but that's it as far as the workflow actions go.
I committed your 2nd patch and marked the issue RESOLVED. You should
have permission to CLOSE the issue yourself this time.
Enrique
Re: Proposed protocol-dns changes
Posted by Enrique Rodriguez <en...@gmail.com>.
On 1/29/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 1/29/07, Richard Wallace <rw...@thewallacepack.net> wrote:
> > ... I'll attach them to the ticket, unless there is a more preferred
> > way. I created the MX-TRAFFIC.libpcap file just for completeness sake
> > and to match what was already there for the QUERY-* tests.
>
> I added the binary test files, enabled the tests, and marked the issue
> as RESOLVED. As issue reporter, you now have to review the commits
> and, if they are to your satisfaction, you need to CLOSE the issue.
Heads up, while I was in there I added a bunch of missing author and
version tags. You'll need to 'svn up', in case you have any
subsequent patches.
Enrique
Re: Proposed protocol-dns changes
Posted by Richard Wallace <rw...@thewallacepack.net>.
Enrique Rodriguez wrote:
> On 1/29/07, Richard Wallace <rw...@thewallacepack.net> wrote:
>> ... I'll attach them to the ticket, unless there is a more preferred
>> way. I created the MX-TRAFFIC.libpcap file just for completeness sake
>> and to match what was already there for the QUERY-* tests.
>
> I added the binary test files, enabled the tests, and marked the issue
> as RESOLVED. As issue reporter, you now have to review the commits
> and, if they are to your satisfaction, you need to CLOSE the issue.
>
> Enrique
Everything looks good but I don't seem to have access to close the
issue. I can reopen it, but that's it as far as the workflow actions go.
Rich
Re: Proposed protocol-dns changes
Posted by Enrique Rodriguez <en...@gmail.com>.
On 1/29/07, Richard Wallace <rw...@thewallacepack.net> wrote:
> ... I'll attach them to the ticket, unless there is a more preferred
> way. I created the MX-TRAFFIC.libpcap file just for completeness sake
> and to match what was already there for the QUERY-* tests.
I added the binary test files, enabled the tests, and marked the issue
as RESOLVED. As issue reporter, you now have to review the commits
and, if they are to your satisfaction, you need to CLOSE the issue.
Enrique
Re: Proposed protocol-dns changes
Posted by Richard Wallace <rw...@thewallacepack.net>.
Enrique Rodriguez wrote:
> On 1/16/07, Richard Wallace <rw...@thewallacepack.net> wrote:
>> Hello,
>>
>> Here are the first set of changes I'd like to contribute to the
>> protocol-dns subproject. Here's a list of things I've done.
>
> In general this patch looks good, but it doesn't appear to contain 2
> binary test PDU files, so 2 tests fail.
>
> MX-QUERY.pdu
> MX-RESPONSE.pdu
>
> It looks like there may be an eventual requirement for an MX-TRAFFIC?
That's my fault. I added them but didn't notice they didn't get
included in the diff. I completely forgot I even had binary files to
add. I'll attach them to the ticket, unless there is a more preferred
way. I created the MX-TRAFFIC.libpcap file just for completeness sake
and to match what was already there for the QUERY-* tests.
Rich
Re: Proposed protocol-dns changes
Posted by Alex Karasulu <ak...@apache.org>.
Richard,
Richard Wallace wrote:
> Enrique Rodriguez wrote:
...
>>> 6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
>>> utility class called ByteBufferUtil.
>> Regarding #6, in the early days of MINA we found we had a need for
>> unsigned values in various protocols so we put them directly on MINA's
>> ByteBuffer:
>>
>> http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/ByteBuffer.html
>>
>>
>> So, this may be a reason to use MINA ByteBuffer's.
> Ah. I didn't know those methods were on the MINA ByteBuffers. AFAIK
> they weren't being used by the protocol-dns before. A proposal came up
> a while ago on the MINA list to create a separate jar that just had the
> ByteBuffer in it. I wouldn't mind seeing the shared code using
> something like that.
>> I also don't see
>> any reason to reduce our dependency on MINA. Especially with more
>> complicated protocols, there is a need to use features of the
>> framework to reduce complexity. If the framework is truly pluggable,
>> then it isn't a framework, it's a component.
>>
> My only issue is with being too tightly coupled to any framework. I
> love MINA. It's the reason I'm interested in working on different
> networking protocol implementations. It's just really slick. But, I've
> learned not to put too many eggs in one basket.
I think the use of MINA will be inevitable. Having dependencies is not
such a bad thing. It's just something that needs to be managed.
Alex
Re: Proposed protocol-dns changes
Posted by Richard Wallace <rw...@thewallacepack.net>.
Enrique Rodriguez wrote:
> I agree with most of your changes and I intend to apply the patch once
> we work out the test failure issue (binary PDU's missing). It's good
> to see activity on the DNS protocol. My synopsys of your patch was
> that it contained good updates to JDK 1.5 and a couple nice bug fixes
> plus new features around decoding, required for DNS clients.
>
> I thinks it's good practice to break a patch up into a couple smaller
> patches. This patch broke in one place for me and there was the
> missing test files issue. I would have been able to apply parts
> faster. The patch naturally breaks down into sub-patches, which you
> were probably aware of as they are in order. The order also
> corresponds nicely to increasing complexity/invasiveness and
> increasing broken-ness. In short, the first 3 subpatches would have
> gone on relatively smoothly, leaving us to deal with the tests.
>
> 1-2) enums, type-safe wrappers (JDK 1.5 updates)
> 3-6) codec reorg w.r.t. MINA deps
> 7-8) bug fixes
> 9-11) test cases
>
I know, I agree. I just got up a good head of steam and just kept
going. I'll try and discipline myself a bit better in the future.
> The same concept goes for large emails, which makes it harder to find
> time to comment.
>
> Other comments:
>
> ...
>> 6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
>> utility class called ByteBufferUtil.
>
> Regarding #6, in the early days of MINA we found we had a need for
> unsigned values in various protocols so we put them directly on MINA's
> ByteBuffer:
>
> http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/ByteBuffer.html
>
>
> So, this may be a reason to use MINA ByteBuffer's.
Ah. I didn't know those methods were on the MINA ByteBuffers. AFAIK
they weren't being used by the protocol-dns before. A proposal came up
a while ago on the MINA list to create a separate jar that just had the
ByteBuffer in it. I wouldn't mind seeing the shared code using
something like that.
> I also don't see
> any reason to reduce our dependency on MINA. Especially with more
> complicated protocols, there is a need to use features of the
> framework to reduce complexity. If the framework is truly pluggable,
> then it isn't a framework, it's a component.
>
My only issue is with being too tightly coupled to any framework. I
love MINA. It's the reason I'm interested in working on different
networking protocol implementations. It's just really slick. But, I've
learned not to put too many eggs in one basket.
So what I'm suggesting we do is that most of our components should by
usable with any framework, such as the decoders/encoders and other core
classes. Then we tie it all together with the framework using one or
two other components. This is the same way the ldap protocol with the
ans1 encoding/decoding.
I kind of think of it like the OSGi stuff. We don't want to integrate
OSGi related stuff into everything we're doing, so we have the separate
subprojects that tie in our OSGi code.
Rich
Re: Proposed protocol-dns changes
Posted by Richard Wallace <rw...@thewallacepack.net>.
Enrique Rodriguez wrote:
> On 1/16/07, Richard Wallace <rw...@thewallacepack.net> wrote:
> ...
>> That should cover it all. I'd like to add a few more decoders
>> for things like TXT and SOA records. That should cover about 90%
>> of the records in use on most DNS servers.
>
> That would be nice. I also think CNAME, PTR, and SRV should be in
> that group. In particular, SRV is used during "KDC discovery" and
> to find LDAP servers, both of which are, of course, relevant to us.
>
>
> In order to combat spoofing/phishing we'll see the record types
> related to security rise in usage.
>
Ok, I missed those. I thought those were already implemented but I
was thinking of the encoders. You're right, we do need decoders for
those as well because they are other often used records.
>> Then I'd like to get things separated a little bit more and
>> create subprojects within protocol-dns. I'm thinking something
>> like protocol-dns/ core/ mina-shared/ server/ shared/ mina/
>> store/ client/
>
> I can see splitting to client, server, and shared. We've done that
> as protocal impl's get bigger. As I noted in a previous email, I
> don't agree with the need to totally abstract out MINA.
I'm fine with not putting the MINA stuff in a separate project, so
long as the core protocol code (like the encoders/decoders) don't
depend too heavily on MINA.
>
> I think making the store pluggable is a good idea. Though, the
> synergy with directories is quite nice. You can see in an old
> experimental build combining OSGi, Directory, and the DNS server
> provider how this looks in an LDAP browser:
>
> http://cwiki.apache.org/confluence/display/DIRxSRVx10/Configuration+Admin+with+LDAP+and+DNS
>
>
>
Oh I completely agree. A buddy and I have a small hosting business on
the side and we decided to use Power DNS for just that reason. Using
that, a custom module for apache httpd for looking up virtual domains
in ldap, and the postfix ldap authentication modules we were able to
get all our clients information in a nice tree structure very similar
to that. We haven't gotten around to writing all the management
interfaces and all for it, but it's so easy for the two of us to
administer with just phpldapadmin that we've never really had the need.
>> I wouldn't mind actually seeing this becoming a separate project
>> of it's own, like dns.apache.org. That would be really cool.
>
> I'm really glad to see activity on DNS. It is an important part of
> the over-arching concept of "realm control" but you need all of
> the protocols working, server-side, to pull it off and that is a
> ton of work.
>
> Enrique
Re: Proposed protocol-dns changes
Posted by Enrique Rodriguez <en...@gmail.com>.
On 1/16/07, Richard Wallace <rw...@thewallacepack.net> wrote:
> Hello,
>
> Here are the first set of changes I'd like to contribute to the
> protocol-dns subproject. Here's a list of things I've done.
In general this patch looks good, but it doesn't appear to contain 2
binary test PDU files, so 2 tests fail.
MX-QUERY.pdu
MX-RESPONSE.pdu
It looks like there may be an eventual requirement for an MX-TRAFFIC?
Here's the relevant section from the patch:
}
Index: src/test/resources/org/apache/directory/server/dns/protocol/MX-RESPONSE.pdu
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on:
src/test/resources/org/apache/directory/server/dns/protocol/MX-RESPONSE.pdu
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Index: src/test/resources/org/apache/directory/server/dns/protocol/MX-TRAFFIC.libpcap
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on:
src/test/resources/org/apache/directory/server/dns/protocol/MX-TRAFFIC.libpcap
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Index: src/test/resources/org/apache/directory/server/dns/protocol/MX-QUERY.pdu
===================================================================
Cannot display: file marked as a binary type.
svn:mime-type = application/octet-stream
Property changes on:
src/test/resources/org/apache/directory/server/dns/protocol/MX-QUERY.pdu
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Enrique
Re: Proposed protocol-dns changes
Posted by Richard Wallace <rw...@thewallacepack.net>.
Done and done.
https://issues.apache.org/jira/browse/DIRSERVER-831
Rich
Emmanuel Lecharny wrote:
> Richard Wallace a écrit :
>
> Richard,
>
> many thanks for the patch. We will look at it, for sure.
>
> Just one little thing : could you fill a JIRA and add your patch
> within ? This is mandatory, as you will have to transfer your IP to
> Apache Foundation in the process. (sorry about the burden, but
> Apache Foundation is very picky when it comes to IP :)
>
> Emmanuel
>
>> Hello,
>>
>> Here are the first set of changes I'd like to contribute to the
>> protocol-dns subproject. Here's a list of things I've done.
>>
>> 1) Converted the enumeration types ServiceType, ProtocolType,
>> RecordClass, OpCode, RecordType, MessageType and ResponseCode
>> into actual Java 5 enums. Because we need to encode and decode
>> the actual values we can't rely on the ordinals the compiler will
>> assign to them, so I've used a technique I found on the Java
>> Specialists site
>> (http://www.javaspecialists.co.za/archive/newsletter.do?issue=113),
>> to efficiently do a conversion between enums and values with
>> minimal code duplication.
>>
>> 2) Removed QuestionRecords and ResourceRecords classes since they
>> were really just type-safe wrappers around Lists and replaced
>> their usage with generic Lists.
>>
>> 3) Moved any encoding and decoding code that was in the MINA
>> ProtocolEncoder and ProtocolDecoder to classes in the
>> o.a.d.s.dns.io.encoder and io.decoder packages called
>> DnsMessageEncoder and DnsMessageDecoder, respectively.
>>
>> 4) Removed the dependency by the encoders and decoders in the
>> o.a.d.s.dns.io packages on MINA. The only thing they really used
>> were the ByteBuffers from MINA and it was a pretty simple task
>> to just switch to java.nio.ByteBuffers instead. The only hurdle
>> I had to overcome was in the allocation of temporary buffers for
>> things like enecoding domain names, which leads me to...
>>
>> 5) Instead of creating (or having to pull them from the MINA
>> ByteBuffer pool) several ByteBuffers during encoding, I simply
>> wrote directly to the buffer that was passed in. From what I
>> could tell, the main reason for allocating the temporary buffers
>> was to do the actual encoding of the domain name, get the byte
>> array that was written to the buffer, write the length of the
>> data to the actual ByteBuffer, then write the byte array from the
>> temporary ByteBuffer. Instead, what I did was to record the
>> position of the ByteBuffer, increment it by one, write the data
>> (the domain name for instance), find the difference between the
>> starting position + 1 and the current position, then go back to
>> the starting position and write the length of the data and
>> finally jump back to the end of the data and go onto the next bit
>> of encoding. This should be more efficient because we're not
>> constantly having to get ByteBuffers from a pool or have new ones
>> allocated, and we also don't have to then create byte arrays and
>> have the data from those temporary ByteBuffers read into the
>> byte arrays.
>>
>> 6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
>> utility class called ByteBufferUtil.
>>
>> 7) Changed the DnsMessage.transactionId property to be an int
>> because it actually needs to be an unsigned short.
>>
>> 8) Fixed a bug with decoding domain names when they are
>> compressed. The new position to jump to wasn't being calculated
>> right all the time. There also seemed to be an assumption that
>> the first thing to do after jumping was to read a label, but it
>> could be the case that the new position is another jump so we
>> need to call recurseDomainName() right after doing the jump in
>> position.
>>
>> 9) Updated existing tests to actually check that what is encoded
>> and decoded are correct. For this I also had to add equals() and
>> hashCode() methods to classes that didn't already have them,
>> like DnsMessage, ResourceRecordImpl, and others. I simply used
>> the commons-lang equals and hashCode builders for this because
>> I've found them to be tremendously useful for this in the past.
>>
>> 10) Added additional test for MX query and response parsing. I
>> used the MX records from apache.org.
>>
>> 11) Added decoders to make the tests added in (10) pass. these
>> are the IPv6RecordDecoder, MailExchangeRecordDecoder,
>> AddressRecordDecoder, and NameServerRecordDecoder.
>>
>> That should cover it all. I'd like to add a few more decoders
>> for things like TXT and SOA records. That should cover about 90%
>> of the records in use on most DNS servers.
>>
>> Then I'd like to get things separated a little bit more and
>> create subprojects within protocol-dns. I'm thinking something
>> like protocol-dns/ core/ mina-shared/ server/ shared/ mina/
>> store/ client/
>>
>> core would contain all the DNS message and record types as well
>> as the decoders and encoders in dns.io right now. mina-shared
>> would contain the ProtocolCodec stuff in dns.protocol.
>>
>> server/shared would contain the DnsConfiguration and other stuff
>> that would be shard among server implementations, whether they
>> use MINA or some other IO framework and whether they use ApacheDS
>> for the store or some other backend like Bind zone files.
>>
>> server/mina would contain the DnsProtocolHandler from
>> dns.protocol as well as the DnsServer class itself. server/store
>> would contain the the backend store type stuff. It would
>> probably wind up being separate subprojects itself, one for LDAP,
>> JDBC, or Bind zone files.
>>
>> client would obviously contain any code for developers to
>> generate and send queries to dns servers, and maybe an
>> implementation of the dig command line tool.
>>
>> I wouldn't mind actually seeing this becoming a separate project
>> of it's own, like dns.apache.org. That would be really cool.
>>
>> What do you think of these changes?
>>
>> Rich
>>
>>
>
Re: Proposed protocol-dns changes
Posted by Emmanuel Lecharny <el...@gmail.com>.
Richard Wallace a écrit :
Richard,
many thanks for the patch. We will look at it, for sure.
Just one little thing : could you fill a JIRA and add your patch within
? This is mandatory, as you will have to transfer your IP to Apache
Foundation in the process. (sorry about the burden, but Apache
Foundation is very picky when it comes to IP :)
Emmanuel
>Hello,
>
>Here are the first set of changes I'd like to contribute to the
>protocol-dns subproject. Here's a list of things I've done.
>
>1) Converted the enumeration types ServiceType, ProtocolType,
>RecordClass, OpCode, RecordType, MessageType and ResponseCode into
>actual Java 5 enums. Because we need to encode and decode the actual
>values we can't rely on the ordinals the compiler will assign to them,
>so I've used a technique I found on the Java Specialists site
>(http://www.javaspecialists.co.za/archive/newsletter.do?issue=113), to
>efficiently do a conversion between enums and values with minimal code
>duplication.
>
>2) Removed QuestionRecords and ResourceRecords classes since they were
>really just type-safe wrappers around Lists and replaced their usage
>with generic Lists.
>
>3) Moved any encoding and decoding code that was in the MINA
>ProtocolEncoder and ProtocolDecoder to classes in the
>o.a.d.s.dns.io.encoder and io.decoder packages called DnsMessageEncoder
>and DnsMessageDecoder, respectively.
>
>4) Removed the dependency by the encoders and decoders in the
>o.a.d.s.dns.io packages on MINA. The only thing they really used were
>the ByteBuffers from MINA and it was a pretty simple task to just switch
>to java.nio.ByteBuffers instead. The only hurdle I had to overcome was
>in the allocation of temporary buffers for things like enecoding domain
>names, which leads me to...
>
>5) Instead of creating (or having to pull them from the MINA ByteBuffer
>pool) several ByteBuffers during encoding, I simply wrote directly to
>the buffer that was passed in. From what I could tell, the main reason
>for allocating the temporary buffers was to do the actual encoding of
>the domain name, get the byte array that was written to the buffer,
>write the length of the data to the actual ByteBuffer, then write the
>byte array from the temporary ByteBuffer. Instead, what I did was to
>record the position of the ByteBuffer, increment it by one, write the
>data (the domain name for instance), find the difference between the
>starting position + 1 and the current position, then go back to the
>starting position and write the length of the data and finally jump back
>to the end of the data and go onto the next bit of encoding. This
>should be more efficient because we're not constantly having to get
>ByteBuffers from a pool or have new ones allocated, and we also don't
>have to then create byte arrays and have the data from those temporary
>ByteBuffers read into the byte arrays.
>
>6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
>utility class called ByteBufferUtil.
>
>7) Changed the DnsMessage.transactionId property to be an int because it
>actually needs to be an unsigned short.
>
>8) Fixed a bug with decoding domain names when they are compressed. The
>new position to jump to wasn't being calculated right all the time.
>There also seemed to be an assumption that the first thing to do after
>jumping was to read a label, but it could be the case that the new
>position is another jump so we need to call recurseDomainName() right
>after doing the jump in position.
>
>9) Updated existing tests to actually check that what is encoded and
>decoded are correct. For this I also had to add equals() and hashCode()
>methods to classes that didn't already have them, like DnsMessage,
>ResourceRecordImpl, and others. I simply used the commons-lang equals
>and hashCode builders for this because I've found them to be
>tremendously useful for this in the past.
>
>10) Added additional test for MX query and response parsing. I used the
>MX records from apache.org.
>
>11) Added decoders to make the tests added in (10) pass. these are the
>IPv6RecordDecoder, MailExchangeRecordDecoder, AddressRecordDecoder, and
>NameServerRecordDecoder.
>
>That should cover it all. I'd like to add a few more decoders for
>things like TXT and SOA records. That should cover about 90% of the
>records in use on most DNS servers.
>
>Then I'd like to get things separated a little bit more and create
>subprojects within protocol-dns. I'm thinking something like
>protocol-dns/
> core/
> mina-shared/
> server/
> shared/
> mina/
> store/
> client/
>
>core would contain all the DNS message and record types as well as the
>decoders and encoders in dns.io right now. mina-shared would contain
>the ProtocolCodec stuff in dns.protocol.
>
>server/shared would contain the DnsConfiguration and other stuff that
>would be shard among server implementations, whether they use MINA or
>some other IO framework and whether they use ApacheDS for the store or
>some other backend like Bind zone files.
>
>server/mina would contain the DnsProtocolHandler from dns.protocol as
>well as the DnsServer class itself.
>
>server/store would contain the the backend store type stuff. It would
>probably wind up being separate subprojects itself, one for LDAP, JDBC,
>or Bind zone files.
>
>client would obviously contain any code for developers to generate and
>send queries to dns servers, and maybe an implementation of the dig
>command line tool.
>
>I wouldn't mind actually seeing this becoming a separate project of it's
>own, like dns.apache.org. That would be really cool.
>
>What do you think of these changes?
>
>Rich
>
>
Re: Proposed protocol-dns changes
Posted by Enrique Rodriguez <en...@gmail.com>.
On 1/16/07, Richard Wallace <rw...@thewallacepack.net> wrote:
...
> That should cover it all. I'd like to add a few more decoders for
> things like TXT and SOA records. That should cover about 90% of the
> records in use on most DNS servers.
That would be nice. I also think CNAME, PTR, and SRV should be in
that group. In particular, SRV is used during "KDC discovery" and to
find LDAP servers, both of which are, of course, relevant to us.
In order to combat spoofing/phishing we'll see the record types
related to security rise in usage.
> Then I'd like to get things separated a little bit more and create
> subprojects within protocol-dns. I'm thinking something like
> protocol-dns/
> core/
> mina-shared/
> server/
> shared/
> mina/
> store/
> client/
I can see splitting to client, server, and shared. We've done that as
protocal impl's get bigger. As I noted in a previous email, I don't
agree with the need to totally abstract out MINA.
I think making the store pluggable is a good idea. Though, the
synergy with directories is quite nice. You can see in an old
experimental build combining OSGi, Directory, and the DNS server
provider how this looks in an LDAP browser:
http://cwiki.apache.org/confluence/display/DIRxSRVx10/Configuration+Admin+with+LDAP+and+DNS
> I wouldn't mind actually seeing this becoming a separate project of it's
> own, like dns.apache.org. That would be really cool.
I'm really glad to see activity on DNS. It is an important part of
the over-arching concept of "realm control" but you need all of the
protocols working, server-side, to pull it off and that is a ton of
work.
Enrique
Re: Proposed protocol-dns changes
Posted by Enrique Rodriguez <en...@gmail.com>.
I agree with most of your changes and I intend to apply the patch once
we work out the test failure issue (binary PDU's missing). It's good
to see activity on the DNS protocol. My synopsys of your patch was
that it contained good updates to JDK 1.5 and a couple nice bug fixes
plus new features around decoding, required for DNS clients.
I thinks it's good practice to break a patch up into a couple smaller
patches. This patch broke in one place for me and there was the
missing test files issue. I would have been able to apply parts
faster. The patch naturally breaks down into sub-patches, which you
were probably aware of as they are in order. The order also
corresponds nicely to increasing complexity/invasiveness and
increasing broken-ness. In short, the first 3 subpatches would have
gone on relatively smoothly, leaving us to deal with the tests.
1-2) enums, type-safe wrappers (JDK 1.5 updates)
3-6) codec reorg w.r.t. MINA deps
7-8) bug fixes
9-11) test cases
The same concept goes for large emails, which makes it harder to find
time to comment.
Other comments:
...
> 6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
> utility class called ByteBufferUtil.
Regarding #6, in the early days of MINA we found we had a need for
unsigned values in various protocols so we put them directly on MINA's
ByteBuffer:
http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/ByteBuffer.html
So, this may be a reason to use MINA ByteBuffer's. I also don't see
any reason to reduce our dependency on MINA. Especially with more
complicated protocols, there is a need to use features of the
framework to reduce complexity. If the framework is truly pluggable,
then it isn't a framework, it's a component.
I'll comment on the non-patch commentary in a separate email.
Enrique