Hi, Matija:
Matija Nalis wrote:
> On Tue, Oct 06, 2015 at 04:26:49PM +0200, Ondřej Surý wrote:
> > > On Tue, Sep 08, 2015 at 08:29:18PM +0200, Moritz Mühlenhoff wrote:
> > > > On Wed, Aug 19, 2015 at 05:45:30PM +0200, Moritz Muehlenhoff wrote:
> > > > > djbdns is RC-buggy for many years now and was out of testing since
> > > > > 2009.
> > > > > Should we remove it from unstable?
> > >
> > > No, I don't think so.
> >
> > Any solid arguments supporting your opinion?
> >
> > djbdns is RC buggy, upstream orphaned, outdated, has to be heavily
> > patched, doesn't support recent DNS standards and it still even carries
> > old J-ROOT IP address that was decommissioned a ***13*** years ago.
>
> 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
That email states that "The next release of djbdns will be backed by a
new security guarantee", but no new release has been published since
then. The latest version on cr.yp.to is still djbdns 1.05, released
about 15 years ago, so presumably the original djbdns security guarantee
is still in effect:
https://cr.yp.to/djbdns/guarantee.html
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.
Other routine maintenance such as updating the list of root nameserver
address hints has simply been neglected. E.g., the dnsroots.global file
shipped in djbdns-1.05 lists five IP addresses (out of thirteen) that
are no longer official root server IP addresses, if I counted correctly.
Developers of actively maintained recursive DNS servers promptly update
these values in their next scheduled release, especially after the
widely publicized "old L-root" incident:
http://research.dyn.com/2008/05/identity-theft-hits-the-root-n-1/
djbdns may not be "orphaned" upstream in the literal definition, but it
is certainly unmaintained by now.
> 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:
tptacek 2304 days ago
DJB's code is a lot of things, but when someone says "beautiful" is
one of them, I start thinking about how I might quiz them to get
them to prove that they've actually read it. Smarter coders than me
have sat in rooms for nightlong studies of qmail and come to the
conclusion that, while clever, the C code in qmail and djbdns has
clearly been compiled down from some higher level language[1]. If
that code is anything, it is idiosyncratic.
[1] Having asked this question directly to DJB in person, I can say
that I am at least convinced he wrote this stuff in C.
[...]
tptacek 2304 days ago
The formatting, the heavy reliance on idiosyncratic CPP macros,
and more than anything else the repetitively procedural nature
of it is what set off alarm bells for us.
But really that's just the way he codes. It's very intricate.
It's like a very ugly Swiss watch.
[...]
(https://news.ycombinator.com/item?id=890558)
> 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
> 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
of the daemons? For instance, how could the duplicate query merging
functionality needed by #516394 be implemented as a modular add-on, or
fixing the failure to resolve certain kinds of hard-to-resolve domains
identified in #796118? Felix von Leitner's patch adding IPv6 support is
several thousand lines long and modifies many core parts of the daemons,
especially dnscache, for example. At least the first two examples are
arguably quality-of-implementation issues for existing features, not the
addition of new feature "bloat".
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.
> J-ROOT should be trivial to patch, care to file a bug for that?
>
> > I myself started my DNS journey with djbdns years ago, and I always
> > loved the code-style. It's very well written, but the world has moved
> > on, and it's time to *let it go*. Just let it go and let it rest in
> > peace, Gerrit.
>
> Ondřej, I see that you advertise competing DNS product; but really,
> there are some people more happy with tinydns than with any other
> peace of DNS software out there.
Tinydns is not as problematic as dnscache; I don't know of any bugs that
would prevent tinydns alone from remaining in the archive.
> 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).
>
> Would that work for everyone?
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?
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.
--
Robert Edmonds
edmo...@debian.org
