On Tue, Feb 09, 2016 at 06:00:40PM -0500, Robert Edmonds wrote: > Matija Nalis wrote: > > dnscache component only is RC-buggy. The solution has been proposed > > by Robert Edmonds (remove only buggy component /usr/bin/dnscache). > > > > It is not upstream orphaned. > > As far as I can tell, the only maintenance activity that djbdns has > received from its upstream developer has been the release of a two-line > patch, about 7 years ago: > > http://marc.info/?l=djbdns&m=123613000920446&w=2
I would consider a fact that software did not have serious security bug nor other compelling need to change for 7 years a big *plus* for using it, not as a problem. (But then again, I'm one of those guys running stuff on Debian Stable or even oldstable LTS) > The only upstream maintenance attention djbdns has received in the past > 15 years has been related to the security guarantee, and that security > guarantee is very narrowly tailored to problems that DJB finds > worthwhile; attacks enabled by the ease of forging UDP packets on the > Internet, or denial-of-service attacks are both specifically excluded > classes of problems. While I'd love to engage to in comparative analyses of various DNS software, or discuss how for example any DNS software supporting DNSSEC is by far a biggest denial-of-service amplifier attack, how BIND and other DNS tools were not even considered for removal even after having way bigger problems with forged UDP packets (for example, see https://cr.yp.to/talks/2012.03.08-1/slides.pdf) or note that other DNS software does not offer *any* gurantees at all, I do not feel that this bug report is a right place for it. > Other routine maintenance such as updating the list of root nameserver > address hints has simply been neglected. E.g., the dnsroots.global file One might say that editing a default list of servers is in domain of responsibility of sysadmin, not programmer (hey, I still remember days of AlterNIC and not using default InterNIC root server list). Still, I did offer to fix that trivial bug. > > It is just stable piece of software which does not change often, as it > > was engineered on KISS principle, so it does not *need* to be changed. > > That is great engineering feat, and I'd love if way more software > > would be like that instead of having everincreasing featurecreep. > > Many djbdns users speak about how well engineered or elegant the servers > are, but I suspect this comes from the experience of configuring the > daemons (which have very few configuration knobs compared to other DNS > implementations), rather than reading the code. Here are comments from > a security researcher with extensive experience analyzing source code: What does anecdotal rants with beauty of the code have to do with this bug? While I have not editied djbdns source (didn't have the need!) I did modify DJB's qmail and ucspi-tcp code written in similar style at times past, and had much less difficulty than average (see http://linux.voyager.hr/ for patches). But yes, the admin part is where tinydns and friends just shines. Does the job fast, efficient, with minimum administrative overhead, not getting in the way, providing the extremly easy way to integrate into it's surroundings. And no uneeded updates breaking stuff. Excellent security record for all tools but dnscache (and even there, it was first with improved protections > > I do not know why you think it *has* to be heavily patched. > > It works for me without patching just fine, for example. > > Many users have requirements that are not satisfied by the original > djbdns-1.05 source release. For example, the following post from a > Facebook developer mentions that tinydns is used at Facebook, with > multiple patches, including an in-house IPv6 support patch: > > > https://lists.dns-oarc.net/pipermail/dns-operations/2016-February/014250.html well, yes, adding support for whole new core layer3 technology does usually require some work. Upstream didn't do it as he doesn't belive it was the right way to do thinks (http://cr.yp.to/djbdns/ipv6mess.html). Some might agree that it could've been done way better. Too late for that now, IPv6 is here to stay. > > The recent DNS standards (DNSSEC, I assume) it doesn't support is by > > design, as it is deemed broken by upstream author (see > > http://dnscurve.org/ for more details, for example) and the whole > > point of KISS principle is to keep it simple and use modular design > > for extra bloat if wanted (for example, even DJB's dnscurve is to be > > implemented as separate independent software part, and not patching > > tinydns with its functionality) > > Can you cite any evidence that djbdns has a modular design, or that > enhancements can be implemented modularly, without patching core parts only by my own experience; I do not recall any papers being published on the subject. > The only modularity I can see in djbdns is that recursive and > authoritative name service have been split into separate but still > monolithic daemons. But this is the case for many other DNS servers > anyway. yes, separate binaries for doing separate tasks, which can be chained together to accomplish something bigger than the sum of its parts. Not only the tinynds/rbldns/walldns/pickdns/dnscache daemon distinction, or axfrdns which runs on tinydns-data output too, but also the commandline tools - you'd put axfr-get into you scripting pipeline, you'd use rsync over ssh or netcat over openvpn to sync authorative servers, put put some sed(1)s between dnstrace and dnsfilter, you'll create your backend cdb database by running a Makefile (even default install does that!) which uses your own tools (for example for providing IPv6, DNSSEC or any yet-unknown DNS protocol extension or implementing dyndns-alike functionality without changing single line of DJB source code -- and yes I've had a need and done fair number of such things). Daemon output would go to multilog by default , but you might want to insert your perl script in between that pipeline to raise nagios passive check if something interested is detected, or put in awk and tee to keep a separate copy of stuff you want to debug or make your munin stats of. Or any of million other lets-combine-different-pieces that such modularity offers. But still, while I love to talk about comparative advantages of DNS programs, I see little that advocating djbdns advantages can do to alleviate this RC-bug. People like it or don't, and use it or don't. But that isn't related with its RC-bugginess. > Tinydns is not as problematic as dnscache; I don't know of any bugs that > would prevent tinydns alone from remaining in the archive. Why "tinydns alone"? Do you have problems with axfrdns? walldns? rbldns? pickdns? Any of the command line tools (axfr-get, dnsip, dnsipq, dnsname, dnstxt, dnsmx, dnsfilter, dnsqr, dnsq, dnstrace)? And which problem if so? Because all of them are there in djbdns (or dbndns) package. Or did you want to say that you're fine with "all of the djbdns EXCEPT the dnscache binary" (which sounds reasonable to me)? > > I'm not a DD, but I am willing to do the work if it will be accepted. > > > > For that, I propose to do the following: > > - fix J-ROOT > > - split djbdns source package into: > > - djbdns-dnscache (dnscache only), > > - djbdns-auth (authorative DNS servers, like tinydns, axfrdns, walldns), > > - djbdns-tools (all the command line tools) > > > > Are there other issues that need fixing in order for most of djbdns > > package (everything except dnscache) friends not be RC-buggy? only > > djbdns-dnscache can remain RC-buggy then (until patched by someone). All of your answer above seems to indicate that there is no other objections but to dnscache part of the djbdns - is that correct? > > Would that work for everyone? So, would that work (containing all the RC problems only in djbdns-dnscache package) in order for other parts of djbdns to remain securely in Debian archives? > Why do you think the RC bugs in dnscache will suddenly get fixed after > many years of not being fixed, simply because /usr/bin/dnscache has been > shifted to a different binary package? I do not thinks it would SOLVE dnscache problems, but I think that it would ISOLATE them, allowing the other parts of djbdns to exist in Debian Stable, while only djbdns-dnscache remains being RC-buggy (until someone possibly step up to fix it, or is it perhaps removed from unstable) I'm not that well versed in Debian policy intricacies though (not being the DD and all), so I would appreciate some education if that is not possible (eg. if a RC bug in one binary package MUST lead to removal of all binary packages which share the same source package). > Your proposal also ignores the 'dbndns' binary package, which is built > by src:djbdns. IIUC, this package split exists because some djbdns > users prefer a less patched variant while others prefer additional > patches. If that scheme were still maintained (but split into > djbdns-dnscache/dbndns-dnscache, djbdns-auth/dbndns-auth, etc.), there > would still be a binary package containing an RC buggy component. My offer extends to dbndns as you described it, yes. To sum: if dnscache is deemed to be broken beyond repair by powers-that-be (which I do not personally agree with, but will accept), I would like other (very usable!) parts of djbdns to remain in Debian (and so am offering to do the work needed). -- Opinions above are GNU-copylefted.
