From teamxlink at live.com Fri Jul 6 17:31:52 2012 From: teamxlink at live.com (Team Xlink) Date: Fri, 6 Jul 2012 21:31:52 +0000 Subject: [MaraDNS list] Would anyone like to help transition Debain MaraDNS onto 2.0 In-Reply-To: <4FE8DEA5.9040603@periapt.co.uk> References: <4FE8DEA5.9040603@periapt.co.uk> Message-ID: I'm willing to help test when I can. I love MaraDNS, it's easy to configure, the only thing it lacks is a simple way to do CNAME records, maybe it could just resolve the name using a specified external DNS server for CNAME or the one that the computer is using. Thank you. > Date: Mon, 25 Jun 2012 22:56:53 +0100 > From: nicholas at periapt.co.uk > To: list at maradns.org > CC: 678460 at bugs.debian.org > Subject: [MaraDNS list] Would anyone like to help transition Debain MaraDNS onto 2.0 > > I reckon I've got Debian MaraDNS good shape *apart* from the fact that > the 2.x series is still only in experimental. I've been thinking long > and hard about the best way to do it. I've changed my mind about the > best way to go about it. I am now inclined to a rather simple and > straightforward approach (new maradns2 source package). I am however > quite open to discuss it. Another thing that has changed is that I don't > particularly feel like doing this on my own anymore. > > If you are interested in Debian packaging and MaraDNS then this is a > good opportunity. If - as part of the deal - you want to get other > software into Debian I can probably help you with that as well. If for > some reason I don't feel comfortable actually sponsoring your package, I > can at least help you get it to a good standard and point you at the > right people. From harlan at bloomenterprises.org Wed Jul 11 23:02:26 2012 From: harlan at bloomenterprises.org (Harlan H. Bloom) Date: Wed, 11 Jul 2012 22:02:26 -0500 (CDT) Subject: [MaraDNS list] Copyright Dates In-Reply-To: <17112887.3897.1342062018310.JavaMail.harlan@star8> Message-ID: <4826741.3941.1342062143428.JavaMail.harlan@star8> Hi Sam, You do not need to reply to this email, at least right now if you don't want to. The next time you are working on MaraDNS, you may wish to update the copyright dates to include 2012. While compiling the latest version of MaraDNS, that it still said 2011 as the newest date. Just trying to help you protect your great work. Have a Great Day! Harlan... From tomek at pipebreaker.pl Tue Jul 17 07:17:01 2012 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Tue, 17 Jul 2012 13:17:01 +0200 Subject: [MaraDNS list] [PATCH] Provide systemd unit files Message-ID: <20120717111701.GC21792@mother.jarsat.pl> Hi, Attached patch provides systemd unit files for maradns 2.0. It was developed against maradns-Q.20120521.1. Systemd is service management system available in number of distributions, and will be core part of RHEL7. Thus, future CentOS and similar RH-clones will also use systemd. Shipping unit files upstream makes distribution work easier and reduces differences between various distribution. In case of maradns, it will also make Duende obsolete. Please apply. -- Tomasz Torcz Only gods can safely risk perfection, xmpp: zdzichubg at chrome.pl it's a dangerous thing for a man. -- Alia -------------- next part -------------- From d82391b6f2c2a3632d3a6bfea91e120d8694bbb4 Mon Sep 17 00:00:00 2001 From: Tomasz Torcz Date: Mon, 16 Jul 2012 16:04:59 +0200 Subject: [PATCH] add systemd unit files (Fedora 15 and later, RHEL7) --- build/install.sh | 10 ++++++++++ build/maradns-deadwood.service | 11 +++++++++++ build/maradns-zoneserver.service | 11 +++++++++++ build/maradns.service | 11 +++++++++++ 4 files changed, 43 insertions(+) create mode 100644 build/maradns-deadwood.service create mode 100644 build/maradns-zoneserver.service create mode 100644 build/maradns.service diff --git a/build/install.sh b/build/install.sh index 2e81170..fabc4f6 100755 --- a/build/install.sh +++ b/build/install.sh @@ -211,3 +211,13 @@ if [ -d $RPM_BUILD_ROOT/etc/rc.d/init.d ] ; then fi fi +# copy systemd unit files if systemd is available +UNITDIR=$( pkg-config --variable=systemdsystemunitdir systemd ) +if [ -d "$UNITDIR" ]; then + echo Installing systemd unit files in $UNITDIR + cp $BUILDDIR/maradns.service $UNITDIR/maradns.service + cp $BUILDDIR/maradns-zoneserver.service $UNITDIR/maradns-zoneserver.service + cp $BUILDDIR/maradns-deadwood.service $UNITDIR/maradns-deadwood.service +fi + + diff --git a/build/maradns-deadwood.service b/build/maradns-deadwood.service new file mode 100644 index 0000000..db822fb --- /dev/null +++ b/build/maradns-deadwood.service @@ -0,0 +1,11 @@ +[Unit] +Description=MaraDNS secure Domain Name Server (DNS) recursive resolver +Documentation=man:Deadwood(1) +Requires=network.target + +[Service] +ExecStart=/usr/sbin/Deadwood +Restart=always + +[Install] +WantedBy=multi-user.target diff --git a/build/maradns-zoneserver.service b/build/maradns-zoneserver.service new file mode 100644 index 0000000..12ca8f2 --- /dev/null +++ b/build/maradns-zoneserver.service @@ -0,0 +1,11 @@ +[Unit] +Description=MaraDNS Zoneserver handles DNS zone transfers and any TCP DNS queries +Documentation=man:zoneserver(8) +Requires=network.target + +[Service] +ExecStart=/usr/sbin/zoneserver -f /etc/mararc +Restart=always + +[Install] +WantedBy=multi-user.target diff --git a/build/maradns.service b/build/maradns.service new file mode 100644 index 0000000..8e3a1ff --- /dev/null +++ b/build/maradns.service @@ -0,0 +1,11 @@ +[Unit] +Description=MaraDNS secure Domain Name Server (DNS) +Documentation=man:maradns(8) +Requires=network.target + +[Service] +ExecStart=/usr/sbin/maradns -f /etc/mararc +Restart=always + +[Install] +WantedBy=multi-user.target -- 1.7.10.4 From maradns at gmail.com Sat Jul 21 15:11:46 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 21 Jul 2012 15:11:46 -0400 Subject: [MaraDNS list] MaraDNS and Deadwood updates ; djbdns rant Message-ID: ==Deadwood update== I have updated the patch resolving the problem Deadwood had with es-us.noticias.yahoo.com last month so that, should a similar issue pop up in the future, Deadwood logs messages (starting at log level 100) describing the issue. In addition, in light of Rich Felker's concerns a couple of months ago with MaraDNS' handling of malloc() I have replaced all calls to "malloc()" in the code with "dw_malloc()", which is simply a macro that is replaced with "malloc()". Doing this would make it easier for one to replace malloc() in Deadwood with something that more gracefully handles malloc() failures, such as blocking Deadwood until malloc() succeeds again, or by having malloc() failures terminate Deadwood and wrapping Deadwood in a script that restarts it when terminated. Since I am in debug, not develop mode, I have no plans to implement this kind of code myself. Deadwood was written for Linux and Windows; Linux does not, by default, have malloc() fail; it simply terminates processes that use too much memory. For the record: MaraDNS terminates upon a malloc() failure. Deadwood's behavior is undefined should malloc() fail. If anyone is using MaraDNS in an environment where a kernel allows malloc() to return a NULL pointer, it is best to wrap MaraDNS is a script that restarts it when it terminates. If using Deadwood in an environment where malloc() may return NULL, please replace the dw_malloc() macro with a function that can properly handle a malloc() failure. (I know some of this has already been covered on the mailing list, but there are a lot of MaraDNS users who do not pay attention to the mailing list nor the blog, so I sometimes repeat myself) It can be downloaded here: http://www.maradns.org/deadwood/snap/ I plan to work on MaraDNS/Deadwood again one day next month in August, after the 20th, unless a critical security bug with a CVE number is found. My next TO DO item for MaraDNS is to get back to updating MaraDNS for CentOS/Scientific Linux 6. ==Harlan== Harlan: As it turns out, I have already updated the copyright in the last development snapshot for MaraDNS. Since users seem to not find these snapshots -- And, yes, I have been giving links in my blog [1] -- I have updated http://maradns.org/download.html to point to the development snapshots. ==djbdns userbase rant== I need to stop trying to point out djbdns' problems with its users; pretty much every time I do, the djbdns user is completely unwilling to acknowledge that, yes, djbdns has security problems. They usually, as part of their denial mechanism, accuse me of spamming for MaraDNS. djbdns was a breath of fresh air in the late 1990s when running a DNS server meant exposing your computer to potential remote root exploits. It's too bad it came with a crappy license and an attitude that it was somehow magically perfect and never needed to be updated. It's too bad there are still ostriches in 2012 with their head in the sand and pretend its security problems (such as CVE-2012-1191 and CVE 2008-4392) do not exist. This denial is understandable: Djbdns users took a perverse pleasure wagging their male reproductive organ around and boasting how much more secure they were than those pathetic BIND users. It's hard for a person with that kind of attitude to admit they are wrong. For the record: Yes, djbdns has a better security record than MaraDNS. Indeed, Unbound has a better security record than MaraDNS. djbdns doesn't have a monopoly on DNS securty: NSD has (knock on wood) a perfect security record and while Unbound has twice as many CVE reports as djbdns' recursor, Unbound does quite a bit more than djbdns and their security holes are usually things like "DNSSEC in this particular setup may not be as secure as it should be". ==Patches== Right now, I am not readily incorporating third party patches in to MaraDNS. The reason is because I become responsible for any and all bugs a given patch creates once I accept the patch; I have had issues over the years with patches causing bugs to pop up which I then had to fix. Hopefully, someone else can get MaraDNS-ng going where patches can be accepted. - Sam [1] For example, the MaraDNS update in http://samiam.org/blog/20120521.html points to the version with copyright dates updated for 2012 From dalias at aerifal.cx Sat Jul 21 18:51:55 2012 From: dalias at aerifal.cx (Rich Felker) Date: Sat, 21 Jul 2012 18:51:55 -0400 Subject: [MaraDNS list] MaraDNS and Deadwood updates ; djbdns rant In-Reply-To: References: Message-ID: <20120721225155.GB544@brightrain.aerifal.cx> On Sat, Jul 21, 2012 at 03:11:46PM -0400, Sam Trenholme wrote: > ==Deadwood update== > > I have updated the patch resolving the problem Deadwood had with > es-us.noticias.yahoo.com last month so that, should a similar issue > pop up in the future, Deadwood logs messages (starting at log level > 100) describing the issue. In addition, in light of Rich Felker's > concerns a couple of months ago with MaraDNS' handling of malloc() I > have replaced all calls to "malloc()" in the code with "dw_malloc()", > which is simply a macro that is replaced with "malloc()". > > Doing this would make it easier for one to replace malloc() in > Deadwood with something that more gracefully handles malloc() > failures, such as blocking Deadwood until malloc() succeeds again, or > by having malloc() failures terminate Deadwood and wrapping Deadwood > in a script that restarts it when terminated. Since I am in debug, not > develop mode, I have no plans to implement this kind of code myself. > Deadwood was written for Linux and Windows; Linux does not, by > default, have malloc() fail; it simply terminates processes that use > too much memory. This is false. Even if you leave overcommit enabled, 32-bit Linux on a machine with >3gb of memory will run out of virtual address space before it runs out of physical memory and thus malloc will return null. This is an extremely common (possibly majority) setup. > ==djbdns userbase rant== > > I need to stop trying to point out djbdns' problems with its users; > pretty much every time I do, the djbdns user is completely unwilling > to acknowledge that, yes, djbdns has security problems. They usually, > as part of their denial mechanism, accuse me of spamming for MaraDNS. I understand that you don't want to spend more time working on MaraDNS and that's a valid sentiment. However, I think your handling of the issues I've reported can equally be characterized as denialism. If you're sure all failed allocations cause SIGSEGV due to immediate dereferencing at zero (or low) offset, then the bug is at worst "MaraDNS can be made to crash", but the attitude that MaraDNS has undefined behavior under resource exhaustion is very troubling from a security standpoint. I think it would be a lot more fair to users to say something along the lines of "This problem exists, and it may be serious, but I'm not willing to devote time to fixing it." Rich From maradns at gmail.com Sat Jul 21 22:40:55 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 21 Jul 2012 22:40:55 -0400 Subject: [MaraDNS list] MaraDNS and Deadwood updates ; djbdns rant In-Reply-To: <20120721225155.GB544@brightrain.aerifal.cx> References: <20120721225155.GB544@brightrain.aerifal.cx> Message-ID: >> Linux does not, by >> default, have malloc() fail; it simply terminates processes that use >> too much memory. > > This is false. Even if you leave overcommit enabled, 32-bit Linux on a > machine with >3gb of memory will run out of virtual address space > before it runs out of physical memory and thus malloc will return > null. This is an extremely common (possibly majority) setup. This type of configuration is an edge case and does not represent a typical Linux installation. My hard limit for 32-bit systems is 2 gigs of memory and it's well known it's not a good idea to have over 2 gigs for a 32-bit OS. malloc() does not return void on the systems I develop on. Processes get killed first. Linux systems where malloc() fails do exist, yes, but are not very common. > I understand that you don't want to spend more time working on MaraDNS > and that's a valid sentiment. However, I think your handling of the > issues I've reported can equally be characterized as denialism. Exactly. MaraDNS is finished. I devote, pretty consistently, an hour every month to keeping it up to date with bugs and that does include the occasional proactive security update. > the attitude that MaraDNS has > undefined behavior under resource exhaustion is very troubling from a > security standpoint. It's an issue, yes, but it's not a "very troubling" problem. It's only a very troubling problem when there is anything in MaraDNS' code that allows an attacker to exhaust the memory resources on the machine running MaraDNS is using. Whenever I find a memory leak in MaraDNS, I fix it and am honest about the leak's existence. Indeed, all of MaraDNS's CVE reports in the last year have come up because of my own proactive look at MaraDNS' codebase and fixing security problems I find. > I think it would be a lot more fair to users to > say something along the lines of "This problem exists, and it may be > serious, but I'm not willing to devote time to fixing it." This is exactly what I did! Let's see http://samiam.org/blog/20120721.html and the head of this thread: "For the record: MaraDNS terminates upon a malloc() failure. Deadwood's behavior is undefined should malloc() fail. If anyone is using MaraDNS in an environment where a kernel allows malloc() to return a NULL pointer, it is best to wrap MaraDNS is a script that restarts it when it terminates. If using Deadwood in an environment where malloc() may return NULL, please replace the dw_malloc() macro with a function that can properly handle a malloc() failure." Since I had some spare time today to devote to Deadwood after fixing up the code around the failure that caused es-us.noticias.yahoo.com to not resolve a couple of months ago, I went to some effort to replace all of the malloc() calls with dw_malloc() macros: http://maradns.org/deadwood/browse-source/head/update/3.2.03/deadwood-3.2.02-dw_malloc.patch Now that malloc() has been replaced with dw_malloc(), there are three ways of handling malloc() failures: * We have dw_malloc() failures terminate the Deadwood process. I actually have been meaning to do this for a while. I can then modify Duende to restart Deadwood whenever it terminates because of a malloc() failure (I can give it a special "malloc() puked" exit code). I don't entirely like this approach because I can't think of a clean way of automatically restarting a stopped service on Windows. * We can have dw_malloc() be a potentially blocking call, and freeze the entire Deadwood process should a malloc() return NULL, and keep Deadwood frozen until malloc() succeeds again. I like this a little more: It's fairly easy to implement and Deadwood doesn't fail because of a temporary malloc() failure, but just does nothing until malloc() is working again. It's also a more cross-platform solution. * Anyone is welcome to look at all 41 places in Deadwood's code where malloc() is called (now with the dw_malloc() name) and refactor all that code to handle malloc() failures reasonably gracefully. I myself am not about to do this. If someone does this, don't submit patches to me -- I'm not accepting patches right now -- but maybe we can get MaraDNS-ng rolling so that there's a code base others can hack on. Just remember: I'm not responsible for any bugs any of this refactoring introduces. * I'm not even going to think about how to update MaraDNS until Deadwood has been updated. Now that that is said, I am not going to devote any more time right now to looking at handling malloc() returning NULL. I have spent too much time on this issue already, and there are other more important issues with MaraDNS. Once MaraDNS is fully functional on CentOS 6, and once all known "this host does not resolve with Deadwood" issues are fixed (they are right now, knock on wood), I may be able to look in to how to better handle malloc() returning NULL again. I will let the list know when and if that happens. If it were 2007 again, and I knew then what I know today, I probably would have done things differently. [1] I have never been 100% happy that the amount of memory Deadwood uses is somewhat unpredictable. But, Deadwood and MaraDNS are finished so it's water under the bridge now. This is my last posting to the mailing list until late August unless either: * A security hole with a CVE number is discovered. * Someone on the list sets up a git/cvs/svn/whatever repository for MaraDNS-ng. I could very well bless said branch as being the official successor of MaraDNS. "This host does not resolve in Deadwood" bug reports are welcome. I will not look at any such reports until the end of August, but getting Deadwood's lingering resolution bugs ironed out is still important to me. - Sam [1] Such as having the LRU cache Deadwood uses to be a fixed-sized cache, and not perform any malloc()s once the cache is initialized at system startup time. This approach has it own issues: Such a scheme would use more memory, which is somewhat offset because the amount of memory used is fixed, and such a scheme would have placed hard limits on the size of binary strings one could store in Deadwood's cache. I would probably have also set up the non-blocking select() state machine code keeping track of unfinished DNS queries to use a fixed amount of memory; that's the other major area where Deadwood does a lot of malloc()s and free()s of memory. Doing this for the TCP code would have been non-trivial. From tomek at pipebreaker.pl Sun Jul 22 14:46:21 2012 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Sun, 22 Jul 2012 20:46:21 +0200 Subject: [MaraDNS list] MaraDNS and Deadwood updates ; djbdns rant In-Reply-To: References: Message-ID: <20120722184621.GB2384@mother.jarsat.pl> On Sat, Jul 21, 2012 at 03:11:46PM -0400, Sam Trenholme wrote: > ==Patches== > > Right now, I am not readily incorporating third party patches in to > MaraDNS. The reason is because I become responsible for any and all > bugs a given patch creates once I accept the patch; I have had issues > over the years with patches causing bugs to pop up which I then had to > fix. Does it include trivial patch by me, adding systemd unit? It changes no code. -- Tomasz Torcz To co nierealne -- tutaj jest normalne. xmpp: zdzichubg at chrome.pl Ziomale na ?ycie maj? tu patenty specjalne. From dalias at aerifal.cx Sun Jul 22 18:08:20 2012 From: dalias at aerifal.cx (Rich Felker) Date: Sun, 22 Jul 2012 18:08:20 -0400 Subject: [MaraDNS list] MaraDNS and Deadwood updates ; djbdns rant In-Reply-To: References: <20120721225155.GB544@brightrain.aerifal.cx> Message-ID: <20120722220819.GD544@brightrain.aerifal.cx> On Sat, Jul 21, 2012 at 10:40:55PM -0400, Sam Trenholme wrote: > >> Linux does not, by > >> default, have malloc() fail; it simply terminates processes that use > >> too much memory. > > > > This is false. Even if you leave overcommit enabled, 32-bit Linux on a > > machine with >3gb of memory will run out of virtual address space > > before it runs out of physical memory and thus malloc will return > > null. This is an extremely common (possibly majority) setup. > > This type of configuration is an edge case and does not represent a > typical Linux installation. I don't think I've seen or heard of desktop or server Linux system with less than 4-8 gigs of total ram+swap in the past 5+ years, except in the minimalist/old-hardware-enthusiast circles I frequent. :-) > My hard limit for 32-bit systems is 2 > gigs of memory and it's well known it's not a good idea to have over 2 > gigs for a 32-bit OS. Citation needed. I've never heard this recommendation, especially not if you're counting ram+swap where the classic (and very misguided) recommendation is to have swap size equal to 2x physical ram size. > malloc() does not return void on the systems I > develop on. Processes get killed first. Linux systems where malloc() > fails do exist, yes, but are not very common. Any properly deployed server will be such a system. > > the attitude that MaraDNS has > > undefined behavior under resource exhaustion is very troubling from a > > security standpoint. > > It's an issue, yes, but it's not a "very troubling" problem. It's What I meant was "very troubling" was the idea that "it could do anything when memory runs out" rather than "it will do something bad when memory runs out, but the badness is limited to the server exiting and not any sort of privilege elevation, information leak, or malicious data injection". I took your "undefined behavior" phrasing as meaning the former. > Now that malloc() has been replaced with dw_malloc(), there are three > ways of handling malloc() failures: > > * We have dw_malloc() failures terminate the Deadwood process. I > actually have been meaning to do this for a while. I can then modify > Duende to restart Deadwood whenever it terminates because of a > malloc() failure (I can give it a special "malloc() puked" exit code). > I don't entirely like this approach because I can't think of a clean > way of automatically restarting a stopped service on Windows. If memory was exhausted, restarting the process will probably be impossible, meaning your nameserver goes down semi-permanently. This is why a server that's robust against DoS should handle allocation failure gracefully (for example, dropping caches) or better yet not do any essential allocations after startup; once you give up the existence of your process there's no guarantee you'll get it back. > * We can have dw_malloc() be a potentially blocking call, and freeze > the entire Deadwood process should a malloc() return NULL, and keep > Deadwood frozen until malloc() succeeds again. I like this a little > more: It's fairly easy to implement and Deadwood doesn't fail because > of a temporary malloc() failure, but just does nothing until malloc() > is working again. It's also a more cross-platform solution. This will help if the failure is caused by commit charge exhaustion (other apps), but not if it's caused by exhaustion of the process's virtual address space or vm size ulimit, unless there are other threads running that might free some memory. > * Anyone is welcome to look at all 41 places in Deadwood's code where > malloc() is called (now with the dw_malloc() name) and refactor all > that code to handle malloc() failures reasonably gracefully. I myself > am not about to do this. If someone does this, don't submit patches > to me -- I'm not accepting patches right now -- but maybe we can get > MaraDNS-ng rolling so that there's a code base others can hack on. > Just remember: I'm not responsible for any bugs any of this > refactoring introduces. This is definitely The Right Thing, but I respect that you don't have the time/motivation to do it or even review the patches if somebody else does it. You don't owe anybody your time. > [1] Such as having the LRU cache Deadwood uses to be a fixed-sized > cache, and not perform any malloc()s once the cache is initialized at > system startup time. This approach has it own issues: Such a scheme > would use more memory, which is somewhat offset because the amount of > memory used is fixed, and such a scheme would have placed hard limits > on the size of binary strings one could store in Deadwood's cache. If it were my project, this is definitely the approach I'd go with. Or possibly a hybrid approach where the LRU cache would be enlarged (up to a sane limit) if possible before discarding old data, but where the failure to enlarge would not be a fatal error and would just cause the smaller existing cache to keep getting (re)used. Rich From Bradley at NorthTech.US Mon Jul 23 02:54:21 2012 From: Bradley at NorthTech.US (Bradley D. Thornton) Date: Sun, 22 Jul 2012 23:54:21 -0700 Subject: [MaraDNS list] MaraDNS and Deadwood updates ; djbdns rant In-Reply-To: References: Message-ID: <500CF51D.9090602@NorthTech.US> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 07/21/2012 12:11 PM, Sam Trenholme wrote: > doesn't have a monopoly on DNS securty: NSD has (knock on wood) a > perfect security record... http://packetstormsecurity.org/files/114889/Debian-Security-Advisory-2515-1.html - -- Bradley D. Thornton Manager Network Services NorthTech Computer TEL: +1.310.388.9469 (US) TEL: +44.203.318.2755 (UK) TEL: +41.43.508.05.10 (CH) http://NorthTech.US -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Find this cert at x-hkp://pool.sks-keyservers.net iQEcBAEBAwAGBQJQDPUdAAoJEE1wgkIhr9j3z1gIALu2skgReAX7qlWhFwG9Lxan 0EDafm+Bi43TzJ6wgU4dk1Gwhsy4aLOz5jnMU0CU2ouf+3sFWeQjCqBNws5SPOrC PI7hPaeCIJGMLo60HxewIyYK9UxQu6BDBNWX+W9laCLQGfmA0JysAYgMQaam/ClY MKQXXYYXkmTKbWE5JD68ePDLaxkL/dnuHMPD6ZYTwBGhxi673+kM9vViHkUUpmxP 4d/dQceQctgRwMoHRFxipYOelzEiCewpoZ7WGmAWgejUYjgn/mWNoH7OYdPW72hG gpdYS30dmdYFrMoeP08571dShTdJstNLBBW6NQJ+5fZnP+yxl/EnxKJUOYzIzSY= =w9/c -----END PGP SIGNATURE----- From maradns at gmail.com Mon Jul 23 11:45:04 2012 From: maradns at gmail.com (Sam Trenholme) Date: Mon, 23 Jul 2012 11:45:04 -0400 Subject: [MaraDNS list] Rich whining about threads in 2007 Message-ID: http://marc.info/?l=maradns-list&m=117390206723939&w=2 March 12 2007: On Thu, Mar 01, 2007 at 04:39:39PM -0800, RC wrote: > On Thu, 1 Mar 2007 16:49:54 -0600 > "Sam Trenholme" wrote: > > > What libc does the NetBSD on your 386 have. If you're > > using glibc, consider using uclibc ( http://uclibc.org ). > > BSD != Linux > > The BSDs use their own libc. It's somewhere around half as large as > glibc to begin with. And I sincerely doubt it would even be possible > to get uclibc working on anything other than Linux. I have a libc that's pretty much kernel-agnostic (or maybe it's better to say agnustic? :) and something like 1/2 to 2/3 the size of uClibc, but with no pthreads implementation and I'd really rather not have one, ever. Any chance that mara will someday do recursion without threads? (In the mean time I could make an ugly minimal fake thread library to get maradns to work, but it would be nice not to have to do that.) Rich ---- Yeah sure, but it took over three years to get there. And now the twit is whining about how malloc() is handled. - Sam From maradns at gmail.com Mon Jul 23 12:25:43 2012 From: maradns at gmail.com (Sam Trenholme) Date: Mon, 23 Jul 2012 12:25:43 -0400 Subject: [MaraDNS list] Rich whining about threads in 2007 In-Reply-To: References: Message-ID: WARNING: RANT FOLLOWS I'm very sorry to send this to the list. Rich: I'm sorry to use the word whining. I meant to send this to myself...but Gmail fucked up and sent it to the list. Probably a Freudian slip, looking back. So, excuse me while I make this personal and act unprofessionally. Since I'm not getting paid a living wage for MaraDNS, this is not a professional product. Anyway, now that this is out, I will go public about my personal feelings about Rich's email. I'm really frustrated with his attitude. Yes, I appreciate his help making Duende around 2003, but that was a long time. I looked it up, and back in 2007 he whined that MaraDNS used threads. So, WITHOUT GETTING PAID FOR MY WORK, a few months later I started making, from scratch a non-threaded version of MaraDNS (Deadwood). Yeah, there were a lot of other reasons I did it. Security holes started getting discovered in MaraDNS, so I felt a rewrite to minimize them further was in order. I have never been happy with MaraDNS' old threading model; it was always meant to be a prototype replaced with something else. But this email from 2007 was one of the motivating factors for starting work on Deadwood. My frustration with Rich is that he left the MaraDNS community. His feedback on using a different memory allocation scheme would have been valuable in late 2007 once non-recursive caching Deadwood prototypes were out the door. I had a lot more free time back then than I do now and Rich and I could have had the malloc() problem solved in 2008. Indeed, Jean-Jacques Sarton contributed a lot of IPv6 code to Deadwood in late 2007 and Deadwood's IPv6 support is a lot better because of his support. But, no, Rich left the community. He did not read the MaraDNS blog nor the mailing list when I started Deadwood: http://maradns.blogspot.com/2007/10/groundbreaking-of-deadwood-project.html He was not there when I was struggled to get the LRU cache to work in late 2007; that alone took about a month. He was not there when I slowly made the program more and more Windows compatible. He was not there when I pulled my hair out implementing a non-threaded TCP client that has no blocking system calls (it's not trivial, I assure you). He was not there as I struggled to get incomplete CNAMEs and glueless NS records to resolve correctly in Deadwood (CNAMEs alone were a nightmare and I'm still ironing out bugs in that code, as seen with the recent es-us.noticias.yahoo.com update) I worked my butt off for free on and off for three years to get Deadwood 3.0 with full recursion out the door. He we are, five years later. I have given Rich everything he asked for back in 2007: MaraDNS now no longer uses any threads. So, what does he do? He complains about how MaraDNS and Deadwood handle malloc(). I'm sorry, Rich, but MaraDNS is never going to be a perfect program. No, it's handling of malloc() is not perfect for edge cases when malloc() actually fails. There are probably a bunch of places where Deadwood still dereferences a NULL pointer in the code, something I'm slowly cleaning up. There are certainly a number of other bugs in Deadwood, including, yes, security bugs. And, yes, Deadwood does not support DNSSEC, so most users are probably better off using BIND or Unbound. But, you know, I'm proud of Deadwood. It took me three years, but, unlike Unbound and unlike BIND, I wrote an entire recursive DNS client without (by and large) being paid for my time. Unlike djbdns, the only other volunteer-written finished DNS program [1], I still support the program and take responsibilities for its bugs--even though I'm not getting paid to do so. So yeah, Rich, I'm sick and tired of you trying to justify why this malloc() thing is such a horrible bug. Because it isn't. And, if this really mattered to you, you would have been there in 2007 when I was getting Deadwood off the ground. I built that thing completely from scratch. Everything: The crypto lib, the LRU cache, the string library, all of the DNS parsing functions, the non-threaded UDP and TCP client. I only got help for some little bits: The Windows service code (but I had a functioning Windows service before I got any help) and the IPv6 code (but I wrote all of the recursive code to handle IPv6 myself). You know, I am no Republican (as can be seen glancing at my Facebook public posts). But, they do have a legitimate point: There are takers and there are givers. Takers are people who are a net drain on society; givers are the people who do the hard work to make things happen. Takers always complain that the givers aren't giving them enough, or that the giver didn't do things the right way, or what not. But, you know, I would rather be a giver and have all of the takers whine about how I don't give them everything they want for free than be a taker and a net drain to society. This will be my last posting on the malloc() issue until when and if I decide to fix it. Rich could not wait for me to start writing the non-threaded MaraDNS code before leaving the community back in 2007, and he may not have the patience for me to deal with more important issues before dealing with the malloc() issue. - Sam [1] PowerDNS does not count since it was originally a commercial product. On Mon, Jul 23, 2012 at 11:45 AM, Sam Trenholme wrote: > http://marc.info/?l=maradns-list&m=117390206723939&w=2 > > March 12 2007: > > On Thu, Mar 01, 2007 at 04:39:39PM -0800, RC wrote: >> On Thu, 1 Mar 2007 16:49:54 -0600 >> "Sam Trenholme" wrote: >> >> > What libc does the NetBSD on your 386 have. If you're >> > using glibc, consider using uclibc ( http://uclibc.org ). >> >> BSD != Linux >> >> The BSDs use their own libc. It's somewhere around half as large as >> glibc to begin with. And I sincerely doubt it would even be possible >> to get uclibc working on anything other than Linux. > > I have a libc that's pretty much kernel-agnostic (or maybe it's better > to say agnustic? :) and something like 1/2 to 2/3 the size of uClibc, > but with no pthreads implementation and I'd really rather not have > one, ever. Any chance that mara will someday do recursion without > threads? > > (In the mean time I could make an ugly minimal fake thread library to > get maradns to work, but it would be nice not to have to do that.) > > Rich > > ---- > > Yeah sure, but it took over three years to get there. And now the > twit is whining about how malloc() is handled. > > - Sam From jefsey at jefsey.com Tue Jul 24 13:18:23 2012 From: jefsey at jefsey.com (JFC Morfin) Date: Tue, 24 Jul 2012 19:18:23 +0200 Subject: [MaraDNS list] Rich whining about threads in 2007 In-Reply-To: References: Message-ID: Once for all. MaraDNS is what it is. And it does meet brillantly my evaluation of the average users' need. And I want to state that I am glad of having known a guy like Sam, and proud to have supported him as I could. I am sorry that time and health did not permit me to help him more and subsidise him for a while and for a fork as I hoped I could through a californian VC friend, Sam having found a job. Best jfc At 18:25 23/07/2012, Sam Trenholme wrote: >WARNING: RANT FOLLOWS > >I'm very sorry to send this to the list. Rich: I'm sorry to use the >word whining. I meant to send this to myself...but Gmail fucked up >and sent it to the list. Probably a Freudian slip, looking back. So, >excuse me while I make this personal and act unprofessionally. Since >I'm not getting paid a living wage for MaraDNS, this is not a >professional product. > >Anyway, now that this is out, I will go public about my personal >feelings about Rich's email. I'm really frustrated with his attitude. > Yes, I appreciate his help making Duende around 2003, but that was a >long time. I looked it up, and back in 2007 he whined that MaraDNS >used threads. So, WITHOUT GETTING PAID FOR MY WORK, a few months >later I started making, from scratch a non-threaded version of MaraDNS >(Deadwood). > >Yeah, there were a lot of other reasons I did it. Security holes >started getting discovered in MaraDNS, so I felt a rewrite to minimize >them further was in order. I have never been happy with MaraDNS' old >threading model; it was always meant to be a prototype replaced with >something else. But this email from 2007 was one of the motivating >factors for starting work on Deadwood. > >My frustration with Rich is that he left the MaraDNS community. His >feedback on using a different memory allocation scheme would have been >valuable in late 2007 once non-recursive caching Deadwood prototypes >were out the door. I had a lot more free time back then than I do now >and Rich and I could have had the malloc() problem solved in 2008. > >Indeed, Jean-Jacques Sarton contributed a lot of IPv6 code to Deadwood >in late 2007 and Deadwood's IPv6 support is a lot better because of >his support. > >But, no, Rich left the community. He did not read the MaraDNS blog >nor the mailing list when I started Deadwood: > >http://maradns.blogspot.com/2007/10/groundbreaking-of-deadwood-project.html > >He was not there when I was struggled to get the LRU cache to work in >late 2007; that alone took about a month. He was not there when I >slowly made the program more and more Windows compatible. He was not >there when I pulled my hair out implementing a non-threaded TCP client >that has no blocking system calls (it's not trivial, I assure you). >He was not there as I struggled to get incomplete CNAMEs and glueless >NS records to resolve correctly in Deadwood (CNAMEs alone were a >nightmare and I'm still ironing out bugs in that code, as seen with >the recent es-us.noticias.yahoo.com update) > >I worked my butt off for free on and off for three years to get >Deadwood 3.0 with full recursion out the door. He we are, five years >later. I have given Rich everything he asked for back in 2007: >MaraDNS now no longer uses any threads. So, what does he do? He >complains about how MaraDNS and Deadwood handle malloc(). > >I'm sorry, Rich, but MaraDNS is never going to be a perfect program. >No, it's handling of malloc() is not perfect for edge cases when >malloc() actually fails. There are probably a bunch of places where >Deadwood still dereferences a NULL pointer in the code, something I'm >slowly cleaning up. There are certainly a number of other bugs in >Deadwood, including, yes, security bugs. And, yes, Deadwood does not >support DNSSEC, so most users are probably better off using BIND or >Unbound. > >But, you know, I'm proud of Deadwood. It took me three years, but, >unlike Unbound and unlike BIND, I wrote an entire recursive DNS client >without (by and large) being paid for my time. Unlike djbdns, the >only other volunteer-written finished DNS program [1], I still support >the program and take responsibilities for its bugs--even though I'm >not getting paid to do so. > >So yeah, Rich, I'm sick and tired of you trying to justify why this >malloc() thing is such a horrible bug. Because it isn't. And, if >this really mattered to you, you would have been there in 2007 when I >was getting Deadwood off the ground. I built that thing completely >from scratch. Everything: The crypto lib, the LRU cache, the string >library, all of the DNS parsing functions, the non-threaded UDP and >TCP client. I only got help for some little bits: The Windows service >code (but I had a functioning Windows service before I got any help) >and the IPv6 code (but I wrote all of the recursive code to handle >IPv6 myself). > >You know, I am no Republican (as can be seen glancing at my Facebook >public posts). But, they do have a legitimate point: There are takers >and there are givers. Takers are people who are a net drain on >society; givers are the people who do the hard work to make things >happen. Takers always complain that the givers aren't giving them >enough, or that the giver didn't do things the right way, or what not. > >But, you know, I would rather be a giver and have all of the takers >whine about how I don't give them everything they want for free than >be a taker and a net drain to society. > >This will be my last posting on the malloc() issue until when and if I >decide to fix it. Rich could not wait for me to start writing the >non-threaded MaraDNS code before leaving the community back in 2007, >and he may not have the patience for me to deal with more important >issues before dealing with the malloc() issue. > >- Sam > >[1] PowerDNS does not count since it was originally a commercial product. > >On Mon, Jul 23, 2012 at 11:45 AM, Sam Trenholme wrote: > > http://marc.info/?l=maradns-list&m=117390206723939&w=2 > > > > March 12 2007: > > > > On Thu, Mar 01, 2007 at 04:39:39PM -0800, RC wrote: > >> On Thu, 1 Mar 2007 16:49:54 -0600 > >> "Sam Trenholme" wrote: > >> > >> > What libc does the NetBSD on your 386 have. If you're > >> > using glibc, consider using uclibc ( http://uclibc.org ). > >> > >> BSD != Linux > >> > >> The BSDs use their own libc. It's somewhere around half as large as > >> glibc to begin with. And I sincerely doubt it would even be possible > >> to get uclibc working on anything other than Linux. > > > > I have a libc that's pretty much kernel-agnostic (or maybe it's better > > to say agnustic? :) and something like 1/2 to 2/3 the size of uClibc, > > but with no pthreads implementation and I'd really rather not have > > one, ever. Any chance that mara will someday do recursion without > > threads? > > > > (In the mean time I could make an ugly minimal fake thread library to > > get maradns to work, but it would be nice not to have to do that.) > > > > Rich > > > > ---- > > > > Yeah sure, but it took over three years to get there. And now the > > twit is whining about how malloc() is handled. > > > > - Sam