dnsjnio-user Mailing List for dnsjnio
Status: Beta
Brought to you by:
alexd_nom
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
(13) |
May
(10) |
Jun
(25) |
Jul
|
Aug
(1) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(11) |
Jul
(5) |
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
From: The m. l. f. d. i. <dns...@li...> - 2009-12-10 14:24:52
|
> dnsjava 2.0.7 has been released and now it should be possible to > refactor dnsjnio to its own package ;-) I have now (finally) completed this work. dnsjnio-1.0.3 no longer hacks into the org.xbill.DNS namespace. Thanks for your help, and apologies for the extended delay, Alex. |
From: The m. l. f. d. i. <dns...@li...> - 2009-12-10 14:23:14
|
Hi - I've just released a new version (1.0.3) of dnsjnio. There are no functional changes. However, the org.xbill.DNS namespace is no longer used by dnsjnio. This has been allowed by changes in the dnsjava library - please use version 2.0.8 or higher of dnsjava with this version of dnsjnio. You will need to make small modifications to client code, to reflect the changes in namespace. Thanks to everyone who helped with this! Alex. P.S. Please let me know if you have any issues with this release. |
From: The m. l. f. d. i. <dns...@li...> - 2009-10-21 06:42:38
|
Hi Stefano - > dnsjava 2.0.7 has been released and now it should be possible to > refactor dnsjnio to its own package ;-) Thanks for the info! I'm currently flat out trying to get the first release of OpenDNSSEC finished. However, I really will try to find a spare morning to do this dnsjnio work just as soon as I can! Thanks, Alex. |
From: The m. l. f. d. i. <dns...@li...> - 2009-10-20 17:27:38
|
The mailing list for dnsjnio issues ha scritto: > Hi Stefano - > >> Brian applied the changes we asked to cvs, so when the next dnsjava will >> be released dnsjnio will be able to stop using the org.xbill package. >> >> I just updated both projects to trunk and checked that this statement is >> true (it requires few changes in dnsjnio, of course). > > Well done! Thanks very much for your help with this. > > I'm more than happy to make the required changes to dnsjnio, and bring > out a new release once the dnsjava changes have been released. dnsjava 2.0.7 has been released and now it should be possible to refactor dnsjnio to its own package ;-) > I'm extremely busy just now, but will make sure that I get this done > soon after the dnsjava release. I'll try to make the changes before > then, just in case ;^) Stefano |
From: The m. l. f. d. i. <dns...@li...> - 2009-07-31 09:25:24
|
On Tue, Jul 14, 2009 at 8:41 AM, The mailing list for dnsjnio issues<dns...@li...> wrote: >> i've made progress with repackaging and releasing dnsjava for Maven >> and OSGi, and now understand the process > >> there are a couple of ways that we could move forward with OSGi and >> maven enabled version of dnsjavanio: >> >> 1. i could supply patches for a mavenised build for dnsjavanio and >> help setup a synchronizing repository for the project (which would >> then need to be maintained) > > At the risk of sounding lazy, I sympathise with Brian's concerns over > maintenance. > > I'll be bringing out a new dnsjnio release soon (to move away from the > org.xbill.DNS package, now that dnsjava allows me to). However, in the > absence of bug reports / patches, I don't expect to be making many more > dnsjnio releases. > >> 2. i could just maintain a downstream repackaged releases in >> dnsjava-osgi (as per dnsjava) > > Sounds easy from my point of view! ;^) fine by me > I'd be happy to point to it from the dnsjnio project. cool i'll let you know once it's done - robert |
From: The m. l. f. d. i. <dns...@li...> - 2009-07-14 07:43:20
|
> i've made progress with repackaging and releasing dnsjava for Maven > and OSGi, and now understand the process > there are a couple of ways that we could move forward with OSGi and > maven enabled version of dnsjavanio: > > 1. i could supply patches for a mavenised build for dnsjavanio and > help setup a synchronizing repository for the project (which would > then need to be maintained) At the risk of sounding lazy, I sympathise with Brian's concerns over maintenance. I'll be bringing out a new dnsjnio release soon (to move away from the org.xbill.DNS package, now that dnsjava allows me to). However, in the absence of bug reports / patches, I don't expect to be making many more dnsjnio releases. > 2. i could just maintain a downstream repackaged releases in > dnsjava-osgi (as per dnsjava) Sounds easy from my point of view! ;^) I'd be happy to point to it from the dnsjnio project. Thanks, Alex. |
From: The m. l. f. d. i. <dns...@li...> - 2009-07-14 07:29:32
|
On Mon, Jul 13, 2009 at 10:17 AM, The mailing list for dnsjnio issues<dns...@li...> wrote: > Hi Stefano - > >> Brian applied the changes we asked to cvs, so when the next dnsjava will >> be released dnsjnio will be able to stop using the org.xbill package. >> >> I just updated both projects to trunk and checked that this statement is >> true (it requires few changes in dnsjnio, of course). > > Well done! Thanks very much for your help with this. +1 > I'm more than happy to make the required changes to dnsjnio, and bring out a > new release once the dnsjava changes have been released. great :-) i've made progress with repackaging and releasing dnsjava for Maven and OSGi, and now understand the process (i've created a suitable project - http://sourceforge.net/projects/dnsjava-osgi/ https://www.ohloh.net/p/dnsjavaosgi - set up a synchronizing repository for Maven - http://repo1.maven.org/maven2/net/sf/dnsjava-osgi/dnsjava-osgi/ - and an OSGi enabled build process. if anyone else wants to volunteer to help maintain further releases, i'd be happy to grant karma. just contact me off list.) there are a couple of ways that we could move forward with OSGi and maven enabled version of dnsjavanio: 1. i could supply patches for a mavenised build for dnsjavanio and help setup a synchronizing repository for the project (which would then need to be maintained) 2. i could just maintain a downstream repackaged releases in dnsjava-osgi (as per dnsjava) opinions? - robert |
From: The m. l. f. d. i. <dns...@li...> - 2009-07-13 09:48:15
|
Hi Stefano - > Brian applied the changes we asked to cvs, so when the next dnsjava will > be released dnsjnio will be able to stop using the org.xbill package. > > I just updated both projects to trunk and checked that this statement is > true (it requires few changes in dnsjnio, of course). Well done! Thanks very much for your help with this. I'm more than happy to make the required changes to dnsjnio, and bring out a new release once the dnsjava changes have been released. I'm extremely busy just now, but will make sure that I get this done soon after the dnsjava release. I'll try to make the changes before then, just in case ;^) Thanks, Alex. |
From: The m. l. f. d. i. <dns...@li...> - 2009-07-11 15:34:33
|
Brian applied the changes we asked to cvs, so when the next dnsjava will be released dnsjnio will be able to stop using the org.xbill package. I just updated both projects to trunk and checked that this statement is true (it requires few changes in dnsjnio, of course). Stefano The mailing list for dnsjnio issues ha scritto: > Brian Wellington ha scritto: >> On Sat, 13 Jun 2009, Stefano Bagnara wrote: >> >>> Brian Wellington ha scritto: >>>> On Fri, 12 Jun 2009, Stefano Bagnara wrote: >>>> >>>>> Brian Wellington ha scritto: >>>>>> On Mon, 8 Jun 2009, Al...@no... wrote: >>>>>> >>>>>>> I'd like to sound you out on a small potential patch for dnsjava. The >>>>>>> patch would allow dnsjnio to exist in its own namespace, and not to >>>>>>> have >>>>>>> to declare classes in the org.xbill.DNS package (an ugly hack >>>>>>> which is >>>>>>> starting to get in the way). >>>>>>> >>>>>>> Basically, the patch would involve changing the access of some >>>>>>> classes in >>>>>>> the org.xbill.DNS package. >>>>>>> >>>>>>> If you thought you might be able to include such a patch, I'd happily >>>>>>> knock one up against the latest dnsjava code (or the 2.0.6 release - >>>>>>> whichever was easiest for you) and submit it before the next dnsjava >>>>>>> release. Does this sound reasonable? >>>>>> Without knowing what the changes are, it's hard to say. >>>>>> >>>>>> Brian >>>>> Hi Brian, >>>>> >>>>> maybe a small list is better than a diff in this case. It is all about >>>>> package visibility to be changed to public in order to allow usage in >>>>> different packages. >>>>> >>>>> dnsjnio needs all of this to be made public: >>>>> >>>>> DClass.check method >>>>> Type.check method >>>> These both look reasonable. >>> ok >>> >>>>> Mnemonic class (for the Mnemonic.toInteger(dclass) usage) >>>> This certainly isn't needed. It's an internal optimization, and >>>> external code can just use "new Integer(dclass)". >>> Right, I never looked at the implementation and I thought it was a >>> generic "mapper". Now I see it is similar to the Integer.valueOf(int) >>> Java 5 method. I agree that this is not a requirement in order to >>> implement dnsjnio in its own package. >>> >>>>> Message.TSIG_VERIFIED field >>>>> Message.tsigState (we need to set this to TSIG_VERIFIED in a custom >>>>> resolver) >>>> I'm not sure if it's better to make the fields public or to add >>>> setSigned() and setVerified() accessors. It really doesn't make sense >>>> to export Message.TSIG_VERIFIED and not the other constants. >>> Yes, setSigned/setVerified make sense! Do you want me to provide a patch >>> for this stuff or do you prefer to simply do the change as we >>> described it? >> I looked again, and wonder if it isn't better to simply make >> TSIG.verify() and TSIG.StreamVerifier.verify() set tsigState. The TSIG >> code sets the state the Message.TSIG_SIGNED when adding a TSIG, so >> setting it to Message.TSIG_VERIFIED/FAILED/INTERMEDIATE when verifying >> seems like it would be more consistent than having the Resolver do it. >> >> If this sounds ok, I can probably do it over the weekend. > > Yes, we do exactly what you already do in simpleresolver: read the > result of verify and set VERIFIED/FAILED accordint to it. So if you move > it to verify (or you create a new method like doVerify in order to not > break backward compatibility for verify users) dnsjnio won't need access > to that stuff anymore (and also your SImpleResolver). > > Thank you for looking into this! > > Stefano > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Dnsjnio-user mailing list > Dns...@li... > https://lists.sourceforge.net/lists/listinfo/dnsjnio-user > |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-13 02:05:07
|
On Sat, 13 Jun 2009, Stefano Bagnara wrote: >> I looked again, and wonder if it isn't better to simply make >> TSIG.verify() and TSIG.StreamVerifier.verify() set tsigState. The TSIG >> code sets the state the Message.TSIG_SIGNED when adding a TSIG, so >> setting it to Message.TSIG_VERIFIED/FAILED/INTERMEDIATE when verifying >> seems like it would be more consistent than having the Resolver do it. >> >> If this sounds ok, I can probably do it over the weekend. > > Yes, we do exactly what you already do in simpleresolver: read the > result of verify and set VERIFIED/FAILED accordint to it. So if you move > it to verify (or you create a new method like doVerify in order to not > break backward compatibility for verify users) dnsjnio won't need access > to that stuff anymore (and also your SImpleResolver). I just committed changes to the TSIG code to set the appropriate status on the passed in Message, and updated the callers (SimpleResolver and ZoneTransferIn) to not directly access the tsigState field. If what's currently checked will work for you, there's nothing else blocking a release. Thanks! Brian |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-12 23:52:37
|
Brian Wellington ha scritto: > On Sat, 13 Jun 2009, Stefano Bagnara wrote: > >> Brian Wellington ha scritto: >>> On Fri, 12 Jun 2009, Stefano Bagnara wrote: >>> >>>> Brian Wellington ha scritto: >>>>> On Mon, 8 Jun 2009, Al...@no... wrote: >>>>> >>>>>> I'd like to sound you out on a small potential patch for dnsjava. The >>>>>> patch would allow dnsjnio to exist in its own namespace, and not to >>>>>> have >>>>>> to declare classes in the org.xbill.DNS package (an ugly hack >>>>>> which is >>>>>> starting to get in the way). >>>>>> >>>>>> Basically, the patch would involve changing the access of some >>>>>> classes in >>>>>> the org.xbill.DNS package. >>>>>> >>>>>> If you thought you might be able to include such a patch, I'd happily >>>>>> knock one up against the latest dnsjava code (or the 2.0.6 release - >>>>>> whichever was easiest for you) and submit it before the next dnsjava >>>>>> release. Does this sound reasonable? >>>>> >>>>> Without knowing what the changes are, it's hard to say. >>>>> >>>>> Brian >>>> >>>> Hi Brian, >>>> >>>> maybe a small list is better than a diff in this case. It is all about >>>> package visibility to be changed to public in order to allow usage in >>>> different packages. >>>> >>>> dnsjnio needs all of this to be made public: >>>> >>>> DClass.check method >>>> Type.check method >>> >>> These both look reasonable. >> >> ok >> >>>> Mnemonic class (for the Mnemonic.toInteger(dclass) usage) >>> >>> This certainly isn't needed. It's an internal optimization, and >>> external code can just use "new Integer(dclass)". >> >> Right, I never looked at the implementation and I thought it was a >> generic "mapper". Now I see it is similar to the Integer.valueOf(int) >> Java 5 method. I agree that this is not a requirement in order to >> implement dnsjnio in its own package. >> >>>> Message.TSIG_VERIFIED field >>>> Message.tsigState (we need to set this to TSIG_VERIFIED in a custom >>>> resolver) >>> >>> I'm not sure if it's better to make the fields public or to add >>> setSigned() and setVerified() accessors. It really doesn't make sense >>> to export Message.TSIG_VERIFIED and not the other constants. >> >> Yes, setSigned/setVerified make sense! Do you want me to provide a patch >> for this stuff or do you prefer to simply do the change as we >> described it? > > I looked again, and wonder if it isn't better to simply make > TSIG.verify() and TSIG.StreamVerifier.verify() set tsigState. The TSIG > code sets the state the Message.TSIG_SIGNED when adding a TSIG, so > setting it to Message.TSIG_VERIFIED/FAILED/INTERMEDIATE when verifying > seems like it would be more consistent than having the Resolver do it. > > If this sounds ok, I can probably do it over the weekend. Yes, we do exactly what you already do in simpleresolver: read the result of verify and set VERIFIED/FAILED accordint to it. So if you move it to verify (or you create a new method like doVerify in order to not break backward compatibility for verify users) dnsjnio won't need access to that stuff anymore (and also your SImpleResolver). Thank you for looking into this! Stefano |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-09 08:01:07
|
On Tue, Jun 9, 2009 at 7:33 AM, The mailing list for dnsjnio issues<dns...@li...> wrote: > Well, if anyone wants to try sneaking a patch past Brian, you're more than > welcome. Personally, I don't think it's worth the effort. brian would prefer a downstream fork for maven and OSGi too. maintaining a dnsjava-osgi (following the felix naming convention) forked from each source release would allow the patch to be applied. - robert |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-09 06:33:53
|
Well, if anyone wants to try sneaking a patch past Brian, you're more than welcome. Personally, I don't think it's worth the effort. Alex. ----- Forwarded by Alex Dalitz/Nominet on 09/06/2009 07:32 ----- Brian Wellington <bwe...@xb...> wrote on 08/06/2009 20:10:57: > Brian Wellington <bwe...@xb...> > 08/06/2009 20:10 > > To > > Al...@no... > > cc > > dns...@li... > > Subject > > Re: Small patch for dnsjnio compatibility > > On Mon, 8 Jun 2009, Al...@no... wrote: > > > I'd like to sound you out on a small potential patch for dnsjava. The > > patch would allow dnsjnio to exist in its own namespace, and not to have > > to declare classes in the org.xbill.DNS package (an ugly hack which is > > starting to get in the way). > > > > Basically, the patch would involve changing the access of some classes in > > the org.xbill.DNS package. > > > > If you thought you might be able to include such a patch, I'd happily > > knock one up against the latest dnsjava code (or the 2.0.6 release - > > whichever was easiest for you) and submit it before the next dnsjava > > release. Does this sound reasonable? > > Without knowing what the changes are, it's hard to say. > > Brian > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > dnsjava-users mailing list > dns...@li... > https://lists.sourceforge.net/lists/listinfo/dnsjava-users |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-08 10:09:46
|
The mailing list for dnsjnio issues ha scritto: >> Brian Wellington committed some patch to dnsjava repository the last >> week, so maybe it is the right time to propose a change that allow >> dnsjnio to extend the behaviour in its own packages. >> >> I don't remember exactly the issue, but if no one find the time early >> I'll try to look at what is needed the next weekend. >> >> I guess if we provide a patch now dnsjava 2.0.7 could include it. > > I have already provided Brian with a patch to include dnsjnio in dnsjava. > I think he was going to review it, but I never heard back on that subject. > That's why I started the dnsjnio project (several years ago). I remember! > It may be that he would be more inclined to take a smaller patch, which > modified the access level of some of the org.xbill.DNS classes. On the > basis of past experience, I won't hold my breath. Yes, I was thinking to this solution. IIRC it should be a matter to change some package visibility to public (or maybe protected). Unfortunately Brian prepare releases very rarely, but if we are lucky we fixed some bugs and maybe he will try a release soon. 2.0.6 is 16 months old and 12 changes took place in this 16 months. http://dnsjava.cvs.sourceforge.net/viewvc/dnsjava/dnsjava/Changelog?view=log&pathrev=HEAD Stefano |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-08 09:16:46
|
> Brian Wellington committed some patch to dnsjava repository the last > week, so maybe it is the right time to propose a change that allow > dnsjnio to extend the behaviour in its own packages. > > I don't remember exactly the issue, but if no one find the time early > I'll try to look at what is needed the next weekend. > > I guess if we provide a patch now dnsjava 2.0.7 could include it. I have already provided Brian with a patch to include dnsjnio in dnsjava. I think he was going to review it, but I never heard back on that subject. That's why I started the dnsjnio project (several years ago). It may be that he would be more inclined to take a smaller patch, which modified the access level of some of the org.xbill.DNS classes. On the basis of past experience, I won't hold my breath. Alex. |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-08 08:57:54
|
>>> Are you aware that dnsjnio includes classes in the org.xbill.DNS > package >>> because it does extends protected classes from dnsjava? > >> maybe (but then again there are workarounds that could be explored) > > You'd need a new release of dnsjava to change the package of some of the > dnsjnio code. Most lives in its own dnsjnio package - but I had to add > some to org.xbill.DNS because there was no public extension mechanism in > dnsjava. This could be fairly easily changed in a new dnsjava release - I > could then move all the dnsjnio classes into their own package. Of course, > I'd ideally move the whole thing into dnsjava as an optional I/O system, > and obviate the requirement for a second project... Brian Wellington committed some patch to dnsjava repository the last week, so maybe it is the right time to propose a change that allow dnsjnio to extend the behaviour in its own packages. I don't remember exactly the issue, but if no one find the time early I'll try to look at what is needed the next weekend. I guess if we provide a patch now dnsjava 2.0.7 could include it. Stefano |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-08 08:11:12
|
Hi - > >> i'd like to be able to use dnsjnio more easily downstream in maven and > >> OSGi environments. for maven this means uploading releases to the > >> central repository. for OSGi this means including some additional meta > >> data in the META-INF. > >> > >> the easiest way to achieve both would be to create a suitable maven > >> build for the current release and then maintain it in addition to the > >> existing ant one. there are two ways i could go about this: either > >> forking downstream the source of each release with added maven build > >> or by supplying patches for an upstream maven build here and then > >> arranging for a maven synchronization repository. > >> > >> opinions? > > I'd be happy to apply any maven patches that folk considered a good idea. > > Are you aware that dnsjnio includes classes in the org.xbill.DNS package > > because it does extends protected classes from dnsjava? > maybe (but then again there are workarounds that could be explored) You'd need a new release of dnsjava to change the package of some of the dnsjnio code. Most lives in its own dnsjnio package - but I had to add some to org.xbill.DNS because there was no public extension mechanism in dnsjava. This could be fairly easily changed in a new dnsjava release - I could then move all the dnsjnio classes into their own package. Of course, I'd ideally move the whole thing into dnsjava as an optional I/O system, and obviate the requirement for a second project... Thanks, Alex. |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-07 14:35:32
|
On Sun, Jun 7, 2009 at 1:03 PM, The mailing list for dnsjnio issues<dns...@li...> wrote: > The mailing list for dnsjnio issues ha scritto: >> hi >> >> i'd like to be able to use dnsjnio more easily downstream in maven and >> OSGi environments. for maven this means uploading releases to the >> central repository. for OSGi this means including some additional meta >> data in the META-INF. >> >> the easiest way to achieve both would be to create a suitable maven >> build for the current release and then maintain it in addition to the >> existing ant one. there are two ways i could go about this: either >> forking downstream the source of each release with added maven build >> or by supplying patches for an upstream maven build here and then >> arranging for a maven synchronization repository. >> >> opinions? > > Are you aware that dnsjnio includes classes in the org.xbill.DNS package > because it does extends protected classes from dnsjava? sort of :-) > Maybe this will be a blocker when you try to OSGify dnsjava+dnsjnio. maybe (but then again there are workarounds that could be explored) - robert |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-07 13:05:19
|
The mailing list for dnsjnio issues ha scritto: > hi > > i'd like to be able to use dnsjnio more easily downstream in maven and > OSGi environments. for maven this means uploading releases to the > central repository. for OSGi this means including some additional meta > data in the META-INF. > > the easiest way to achieve both would be to create a suitable maven > build for the current release and then maintain it in addition to the > existing ant one. there are two ways i could go about this: either > forking downstream the source of each release with added maven build > or by supplying patches for an upstream maven build here and then > arranging for a maven synchronization repository. > > opinions? Are you aware that dnsjnio includes classes in the org.xbill.DNS package because it does extends protected classes from dnsjava? Maybe this will be a blocker when you try to OSGify dnsjava+dnsjnio. Stefano |
From: The m. l. f. d. i. <dns...@li...> - 2009-06-07 11:26:25
|
hi i'd like to be able to use dnsjnio more easily downstream in maven and OSGi environments. for maven this means uploading releases to the central repository. for OSGi this means including some additional meta data in the META-INF. the easiest way to achieve both would be to create a suitable maven build for the current release and then maintain it in addition to the existing ant one. there are two ways i could go about this: either forking downstream the source of each release with added maven build or by supplying patches for an upstream maven build here and then arranging for a maven synchronization repository. opinions? - robert |
From: The m. l. f. d. i. <dns...@li...> - 2008-09-18 04:03:29
|
Hi - I'm very pleased to announce that dnsjnio version 1.0.0 has now been released! The fixes since version 0.9.9 are as follows : o Race conditions fixed (including NPE). o Single-port operation removed for UDP. o TCP single-port and multiple-port race conditions fixed. o Retry behaviour in ExtendedNonblockingResolver doubles timeout for each retry. o Port randomisation now done by dnsjnio - not left to host O/S. o Different QID now used for each query in round-robin or timeouts. o Timeout semantics changed slightly in SingleResolver.sendAsync(). o Redundant error message removed. o Test code fixed. I am not aware of any issues with the current code - please let me know if you have any problems. Thanks, Alex. |
From: The m. l. f. d. i. <dns...@li...> - 2008-08-21 18:16:56
|
The mailing list for dnsjnio issues ha scritto: > Hi - > > I've now fixed the random port issue, and the QID issue. java.nio already > ensures that only datagrams from connected sockets are accepted. The > first, DNSSEC, issue is one for dnsjava. > > A new beta release is available at : > > https://dnsjnio.svn.sourceforge.net/svnroot/dnsjnio/tags/dnsjnio-1.0.0-beta/dnsjnio-1.0.0-beta-2.jar > > I'd be very grateful for any feedback on this. > > Thanks, I upgraded the dependency in jspf trunk and the continuos integration environment didn't complain. Stefano |
From: The m. l. f. d. i. <dns...@li...> - 2008-08-20 10:50:52
|
Hi - I've now fixed the random port issue, and the QID issue. java.nio already ensures that only datagrams from connected sockets are accepted. The first, DNSSEC, issue is one for dnsjava. A new beta release is available at : https://dnsjnio.svn.sourceforge.net/svnroot/dnsjnio/tags/dnsjnio-1.0.0-beta/dnsjnio-1.0.0-beta-2.jar I'd be very grateful for any feedback on this. Thanks, Alex. dns...@li... wrote on 14/08/2008 15:17:20: > Just a quick note to let you know that a colleague has raised some issues > with DNS clients (with particular regard to Net::DNS, but other DNS > clients suffer from the same flaws - including dnsjava and dnsjnio). I > intend to fix these issues before the 1.0.0 release. > > FYI, the issues are : > > 1) dnssec-bis apparently allows AD=1, without EDNS being required. > Previously, setting dnssec on in client libraries would automatically set > EDNS on (generally with a packet size of over 1000). > 2) The same query ID is used for all packets involved in a round-robin > query sequence (multiple nameservers, then multiple packets per server in > case of timeouts). A different qid should be used for each packet. > 3) The O/S is generally asked to assign a random port, rather than a > random number being selected and then used to try to open a port (this > will also have to cope with ports being in use). > 4) Net::DNS does not check that the IP a response was received from was > the IP the corresponding query was sent to. I think my libraries may also > not check. > > In the light of the recent interest in DNS surrounding the Kaminsky > attack, I think these issues are well worth fixing for the 1.0.0 release. > > If you're desperate for a real release that fixes the race issues, please > let me know, and I'll put that out, closely followed by an update for the > security issues. > > Thanks, > > > Alex. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Dnsjnio-user mailing list > Dns...@li... > https://lists.sourceforge.net/lists/listinfo/dnsjnio-user |
From: The m. l. f. d. i. <dns...@li...> - 2008-08-14 14:17:29
|
Hi - Just a quick note to let you know that a colleague has raised some issues with DNS clients (with particular regard to Net::DNS, but other DNS clients suffer from the same flaws - including dnsjava and dnsjnio). I intend to fix these issues before the 1.0.0 release. FYI, the issues are : 1) dnssec-bis apparently allows AD=1, without EDNS being required. Previously, setting dnssec on in client libraries would automatically set EDNS on (generally with a packet size of over 1000). 2) The same query ID is used for all packets involved in a round-robin query sequence (multiple nameservers, then multiple packets per server in case of timeouts). A different qid should be used for each packet. 3) The O/S is generally asked to assign a random port, rather than a random number being selected and then used to try to open a port (this will also have to cope with ports being in use). 4) Net::DNS does not check that the IP a response was received from was the IP the corresponding query was sent to. I think my libraries may also not check. In the light of the recent interest in DNS surrounding the Kaminsky attack, I think these issues are well worth fixing for the 1.0.0 release. If you're desperate for a real release that fixes the race issues, please let me know, and I'll put that out, closely followed by an update for the security issues. Thanks, Alex. |
From: The m. l. f. d. i. <dns...@li...> - 2008-08-14 10:43:12
|
Hi Stefano - > >> I'd be very grateful if you could give it a shot and let me know how it > >> goes. > > We set up a couple of continuos integration machines building and > > running tests for jSPF every 5-10 minutes. > > > > Previously we saw "our" race issue once on ten builds, so we should see > > it soon if this is not the fix. > > We already had 120 build/tests from one machine and 350 in the other > with no failure... good news ATM. News like this, I like! ;0) Thanks for the update. The chap who reported the original bug is away this week; I hope to ask him to beta test this release when he returns next week. Assuming that all goes well with him, and you have still had no issues, then I'll hope to make a 1.0.0 release before I go up to Edinburgh at the end of next week. Failing that, I'll get it done in the first week of September. Thanks for your help! Alex. |