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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
