Bug 256450

Summary: dns/djbdns: Deprecate and set expiration date to 2021-09-06
Product: Ports & Packages Reporter: Daniel Engberg <diizzy>
Component: Individual Port(s)Assignee: David Thiel <lx>
Status: Open ---    
Severity: Affects Only Me CC: diizzy, felix, freebsd
Priority: --- Flags: bugzilla: maintainer-feedback? (lx)
Version: Latest   
Hardware: Any   
OS: Any   
Bug Depends on:    
Bug Blocks: 246317    
Attachments:
Description Flags
Patch for djbdns none

Description Daniel Engberg freebsd_committer 2021-06-06 18:24:03 UTC
Created attachment 225604 [details]
Patch for djbdns

This is now considered unmaintained by upstream and several have removed it from their package/doesn't offer it (CentOS, Debian (removed from stable), Fedora, OpenBSD, OpenSUSE, Ubuntu to mention a few).

For more technical insight https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796118 etc
Comment 1 David Thiel freebsd_committer 2021-06-06 18:40:21 UTC
While I agree that dnscache is somewhat obsolete, tinydns is still solid and widely used, and removing it would likely cause more frustration than good. Splitting it into separate ports would be better, but that would break patches (like the IPv6 one). I'm open to other suggestions, but I personally am not in favor of removal.
Comment 2 Daniel Engberg freebsd_committer 2021-06-06 19:24:38 UTC
Hi,

Perhaps another solution would be migrating to https://github.com/mbhangui/tinydnssec (another fork seems to be http://pjp.dgplug.org/ndjbdns/ but dead as far as I can tell) which at least is (somewhat?) maintained?

I do understand your concern however I also think that we need to consider the fact we should/need to move forward at some point and it's imho better sooner than later. 3 months might be a short in that regard, perhaps 6 months would be better depending on which route we'll take.
Comment 3 David Thiel freebsd_committer 2021-06-06 20:22:51 UTC
Of those two, I lean toward ndjbdns — it does switch to .conf files which would unfortunately require manual migration, and it is GPL, but at least it doesn't introduce a new dependency on another libc replacement. There's an updated fork of it here we could consider:

    https://github.com/samboy/ndjbdns

Another option could be going with the version included in this, which does at least consider FreeBSD:

    http://jdebp.uk./Softwares/djbwares/

Personally, the main thing keeping me on tinydns is tinydns-data. If there were anything that supported that format or spit out the abominable BIND format zone files from it, I'd be more inclined to abandon djbdns altogether.

Any thoughts on those?
Comment 4 Daniel Engberg freebsd_committer 2021-06-06 21:00:25 UTC
Hmm.. the samboy fork seems like a good tradeoff I we want to keep it?

I found this https://gist.github.com/gmr/10434366 but I haven't tested it myself and since it's from 2014 I would imagine that you need python 2.x
Comment 5 Leo Vandewoestijne 2021-06-17 12:44:37 UTC
(In reply to Daniel Engberg from comment #0)
> For more technical insight https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796118 etc
>
From that pointer I don't understand why a 6 y/o RC bug in Debian (Linux) today became the argument to remove it in FreeBSD, especially since it works i.c.w. daemontools. I fail to see the problem / did I miss something?

Is it truly unmaintained?
And even if, is that truly a problem?
Looking ahead into the future, in the hypothetical case of very-long awaited truly critical vulnerability in the tinydns daemon part, ain't the software then still useful for the tinydns-data part? (which creates a datatree which can even be served by PowerDNS).
Also tools like dnsdist -which many serious operators have in place- may still neutralize such hypothetical problem (or challenge).
Comment 6 Daniel Engberg freebsd_committer 2021-06-17 22:29:11 UTC
Hi Leo,

I suggest that you read all comments not just the top one, I think it'll give you a better view on the issue. It's already removed in many major distros https://repology.org/project/djbdns/versions and one could argue that it's not advisable to "promote"/have buggy/broken/abandoned software available when there are good alternatives. I'm not saying that pushing people out of their habbits is something we should promote but sometimes you may need a little push to move forward. If we can provide a solution with little to no friction that's even better.

Best regards,
Daniel
Comment 7 Leo Vandewoestijne 2021-06-21 14:33:03 UTC
(In reply to Daniel Engberg from comment #6)

> I suggest that you read all comments not just the top one
>
Implicates like if I didn't.
If your point was clear, I didn't had to ask for clarification.
Meanwhile: you avoid answering, so the questions remain.


> I think it'll give you a better view on the issue. It's already removed in many major distros https://repology.org/project/djbdns/versions
>
Supermarket K removes product X from their assortment because it doesn't fit perfectly well in their new shelves, does that immediately indicates product X is bad or harmful, such that supermarkt Z should drop it also?


> could argue that it's not advisable to "promote"/have buggy/broken/abandoned software available when there are good alternatives.
>
Buggy? Broken?
In my country such defaming is prosecutable both under civil and criminal law.

Abandoned?
After 2 decades of no updates you could also state it's pretty good in not being vulnerable, in no compare to any other DNS daemon.

Good alternatives?
For your common usecase, sure. But not for all of mine, and others.


> sometimes you may need a little push to move forward.
>
Stop pushing me please. Have dialog before dictating.
What makes you think I only need what you deem forward and don't need nothing else?


> If we can provide a solution with little to no friction that's even better.
>
Name at least 2 (two) options to synchronize 300 million RR's all at once, with checksum, twice a minute, without inefficient useless XFR overhead, nor depending on an extra backend, and can reload all that data in a split second.
(and please not a fork of something you're now removing the forks handle from).
IF you can "provide a solution that's even better" then I'm all ears, even more than I already am.

The last time when I talked with Facebook DNS engineers also they were using it the same way, distributing all their internal DNS to all their DC's.


I'm sorry to say, but I find the lack of any truly convincing argument and additional false arguments unfair and uncanny. And so I still fail to comprehend what is the real problem here.