[Pkg-xmpp-devel] pushing udns into squeeze

[Michael Tokarev]

Thadeu Lima de Souza Cascardo wrote:
> Hello, folks.

Hello.
Thank you for bringing this issue up again.

> While udns has no entered etch or lenny, we should reconsider that
> situation in the case of squeeze. Some software in Debian depends or may
> be improved while depending on udns. libapache2-mod-defensible, for
> example, was rebuilt without udns for the lenny release. Now, jabberd2
> depends on udns and can only go into a stable release if udns goes too
> or udns stops being used by it.
> 
> Although Michael didn't think it was ready for release some three years
> ago and not a lot has changed in the library since then, it has being
> used by these software in response to its usefulness and quality. I
> don't know if Michael has reconsidered, but I'd like to know his opinion
> as of now.

Yes I had plans for udns, but now I don't think I'll ever finish it.
Maybe, who knows, but well...

I'm watching another project, ldns, which is a base for unbound and nsd
nameservers (see www.unbound.net).  It is much more adequate for today,
in my opinion anyway, than my attempt with udns.  And almost as easy to
use as udns, but at the same time much more correct and also supports
DNSSEC out of the box.

> Regarding the security issue, which Michael has already answered about
> in his comments in the source code even before people have published
> their exploit results and many servers had their code changed to make
> them safer, I don't think udns requires any change.

All the (similar) security issues with stub resolvers w.r.t. on LANs
are real issues, unfortunately.  Yes I added that "famous" comment to
the code explaining it (and it was interesting to re-read it today ;)
and noticed that it's very difficult to deal with the issue on LAN
with its speeds.  On LAN, the only way to solve all the issues of this
sort is to use DNSSEC or IPSEC between a stub resolver and nearby
(on the LAN) recursive resolver, or better yet, between local (on
localhost) caching resolver and nearby (on LAN) recursive resolver.
As I mentioned earlier, ldns has DNSSEC support out of the box.

> It's a stub resolver and many other stub resolvers have not changed
> anything in response to the announcement of the increased possibility of
> an attack. And stub resolvers should use secure servers in a secure
> environment/network.
> 
> I think we could release some notes in README.Debian regarding this and
> close this bug altogether and let udns move into squeeze and keep it
> there for the release, allowing other packages to follow, including
> jabberd2.

Given the fact that I did not update the code in all these years (oh
well)...  I've nothing against including udns into Debian anymore.

The only concern I had is that I planned to change the API.  But it
looks like it wont be done and better alternatives emerges.

Thanks!

/mjt