On Fri, Aug 29, 2008 at 08:46:00PM +0200, Thomas Viehmann wrote: > Hi, > > udns has the recent DNS problem in a pretty bad way (i.e. no random, not > even query IDs vs. not enough). And there is no indication that anyone > is working on getting it solved at the moment. (Last upstream release is > Jan 2007, the upstream mailing list archives have 2007 no activity > since the announcement of that, too.) > As udns is not in wide use across our archive, with only two packages > using it, it might be good to not release it with lenny. > For the two packages: > - jabberd2 is not in testing, > - libapache2-mod-defensible can be compiled without udns. > > Even better would be fixing, but I think this might be involved (based > on the "our design doesn't allow for port randomization") ... > Opinions? > > Kind regards > > T. > -- > Thomas Viehmann, http://thomas.viehmann.net/ > > Hello. This bug is likely a WONTFIX for the reasons already pointed out, because: a) udns design was intended to make it simple to write an application using it, which is accomplished by using only one socket. This restricts it to only one source port for all queries. Introducing random source port into the code would break its design. b) The author believes random query IDs would do more harm than incremental ones, since DNS error responses does not allow to distinguish the query responded by anything else than the query ID, which in the case of a collision (which is likely for only 16 bits). This could break robustness of the software giving only a slight security. Despite all this, since some other software have the same or similar security issues and are also used as stub resolvers (like glibc), we could do the same that was done for them: release an advisory warning the users about the possible issues and workarounds (stub resolvers need a trusted resolver in a trusted network). However, I think udns should still be left out of stable, since the upstream author has requested this from me in the last release, because he believes the software is still experimental (mainly the library API/ABI). Best Regards, Thadeu Cascardo.
Attachment:
signature.asc
Description: Digital signature