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
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.
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.
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?
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
(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).
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
(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.
Just another "vote" to keep in the tree. It continues to work almost flawlessly for me. I love the way it has not changed for so many years. If anything, expand the patch options for it so that it becomes *more* useful.
Maintainer reset.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=09b46a68171312152af074f5bf8aa2336a87e797 commit 09b46a68171312152af074f5bf8aa2336a87e797 Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2023-02-27 20:40:02 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2023-02-27 20:45:18 +0000 dns/djbdns-tools: Deprecate and set expiration date to 2023-06-30 Project hasn't been centrally managed since last release in 2001 and there are various third party patches to keep it somewhat relevant with todays standards. Port has also been unmaintained since last maintainer stepped down several months ago. PR: 256450 dns/djbdns-tools/Makefile | 3 +++ 1 file changed, 3 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1bece199848e019caee2104727d30353177ed978 commit 1bece199848e019caee2104727d30353177ed978 Author: Daniel Engberg <diizzy@FreeBSD.org> AuthorDate: 2023-02-27 20:32:43 +0000 Commit: Daniel Engberg <diizzy@FreeBSD.org> CommitDate: 2023-02-27 20:45:18 +0000 dns/djbdns: Deprecate and set expiration date to 2023-06-30 Project hasn't been centrally managed since last release in 2001 and there are various third party patches to keep it somewhat relevant with todays standards. Port has also been unmaintained since last maintainer stepped down several months ago. PR: 256450 dns/djbdns/Makefile | 3 +++ 1 file changed, 3 insertions(+)
Port and related ones are now deprecated with a relevant epiration date.
I've since discovered this has been removed. One more nail in the FreeBSD coffin. There's a reason why I've used FreeBSD since the early days and that's because the ports tree mainly. I could easily use what *I* wanted -- djbdns being one of them. The arguments presented above are hogwash. It's software that works and needs no updating and contrary to what some believe isn't buggy -- it just works(tm). Leo's comments are extremely valid and it'd be a waste of breadth to reiterate them. Instead, I'll state something different which is: - The software ISN'T DEPRECATED. Contrary to what the port maintainers think, it's still in use all over the world. - The software is extremely useful. - It doesn't need updating. Has anyone tried actually downloading the source as is and running on their system? I have, and you know what? It works perfectly fine. But biggest of all: - Having this port in the ports tree hurts absolutely no one. Seriously, if the software doesn't get updated because it doesn't have too, then there's no need for port maintenance. Imbecile's. /rant over
I'm not happy being named by name i.c.w. such hostile words. Please bare in mind such addressing is harmfull to the motivation of volunteers, who I believe have prosper intentions, and contribute their valuable time, and therefor deserve more respect - even while having different opinions.
(In reply to Leo Vandewoestijne from comment #15) We all do mistakes, I don't see an issue as long as you learn from them. If there's disagreement I welcome a discussion as long as it's within CoC. Best regards, Daniel
I went and created an account just for this. I 2023. The djbdns is just perfect software for what it does, no need to "update" it. So what if it is 20 years old. There are a lot of real bugs in some other packaged that are not being fixed for years, and this is being remove because it does not have any bugs needed to be fixed? We are really living in idiocracy. https://www.imdb.com/title/tt0387808/ "It's software that works and needs no updating and contrary to what some believe isn't buggy -- it just works(tm)." It caused a major pain for me to install it from source and compile and then send it over to pfsense ... all that work... sad ... very sad...
Due to popular demand, I'll go ahead and see if I can restore the port.
Unless there's going to be a maintained "community/open" repo (and effort) there's no valid reason for doing so. It doesn't follow todays practices, you need to patch it heavily and these patches are also incompatible with each other. All attempts (to my knowledge) of creating a unified repo been abandoned several years ago. There have been no offers made for maintaining a repo or even the port itself. This was also resolved months ago by removing it. The ports tree is also not the correct way of maintaining a project, a separate repo should be used and it should be a genuine attempt of doing so to be even considered.
Closing this as there have been no progress since removal almost 6 months ago.
This is still planned, I just didn't have the time to work on it yet.
By request of diizzy@, efforts to restore the port are now being tracked in bug #275803. Please subscribe to that bug if you wish to be kept up to date.