Bug#796118: Re: Should djbdns be removed?

[Matija Nalis]

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=123613000920446=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 

Bug#796118: Re: Should djbdns be removed?

[Robert Edmonds]

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=123613000920446=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 

Bug#796118: Re: Should djbdns be removed?

[Matija Nalis]

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. 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.

I do not know why you think it *has* to be heavily patched. 
It works for me without patching just fine, for example.

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)

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.

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?

-- 
Opinions above are GNU-copylefted.

Bug#796118: Re: Should djbdns be removed?

[Ondřej Surý]

> 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.

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.

Cheers,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server