From maradns at gmail.com Fri Mar 2 11:25:43 2012 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 2 Mar 2012 11:25:43 -0500 Subject: [MaraDNS list] New MaraDNS donation links Message-ID: In this posting, I discuss the new links for making MaraDNS donations. == Adios PayPal == PayPal is not the most friendly company for processing donations for open-source projects. Ever since the Diaspora PayPal incident and the Regretsy PayPal incident, I have been looking for a viable PayPal alternative. I have now found one. == Hola WePay == My good friend Sean Lynch pointed me to WePay. I am now using WePay for accepting donations for MaraDNS. Donations are completely voluntary and I currently do not sell extended technical support or any other MaraDNS-related services. If you find MaraDNS useful, please make a $25 MaraDNS donation at WePay: https://www.wepay.com/donations/198134 People who are interested in signing up for WePay for their own open-source or other project can register here: https://www.wepay.com/x1hqecu Disclaimer: This second link is an affiliate link. I encourage people who are using MaraDNS and want to collect payments for any reason to use this link to help support MaraDNS maintenance. == If you would prefer to make a smaller donation == Students, teachers, retired and other people on fixed incomes, or plain old cheapskates who do not want to make a $25 WePay donation can make a Flattr donation instead. Yes, I would prefer a WePay donation. But I have also opened up a Flattr account so that more people can donate, irregardless [1] of their income. == All donations are optional == Since MaraDNS is an open-source project, all donations are of course optional. However, donations are the best way for MaraDNS users to show their appreciation for all of the hard work I have done making and the work I continue to do maintaining MaraDNS. - Sam [1] "Irregardless" is a word because I say it's a word. From kumba at gentoo.org Sat Mar 3 00:43:59 2012 From: kumba at gentoo.org (Joshua Kinard) Date: Sat, 03 Mar 2012 00:43:59 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? Message-ID: <4F51AF9F.9060604@gentoo.org> I am looking at migrating a small, internal DNS server on my home network over to MaraDNS-2.x from PowerDNS (only because PowerDNS 3.0 no longer supports the LDAP backend module), but I am puzzled over how MaraDNS and Deadwood talk to each other (if they do at all). Being that MaraDNs is the authoritative server and Deadwood the recursive server, what's the correct way to run both on the same host such that A/AAAA queries for an internal host get answered by MaraDNS and queries for everything else are answered by Deadwood? Under PowerDNS, you point pdns to the "recursor" (precursor) via IP, and pdns will use the recursor to query for any domain that it is not authoritative for. I cannot find the equivalent configuration for this in MaraDNS/Deadwood, or I am not configuring it correctly. Having used PowerDNS for so long, I am not sure what MaraDNS' equivalent terminology for this setup is in the documentation. It's also possible that because the documentation attempts to service both MaraDNS 1.4 and MaraDNS 2.0 questions simultaneously, where one did both authoritative/recursive and the other does authoritative only, that this adds to the confusion. Current setup: - MaraDNS listening on an internal IP for DNS queries. - Deadwood listening on Loopback for recursive queries. Actions: - Queries for internal hosts to MaraDNS resolve correctly. - Queries for external hosts to Deadwood resolve correctly. - Queries for external hosts (e.g., Google) to MaraDNS do NOT resolve. For item #3, my thinking is that MaraDNS should first look to see if it can answer the external query, then if not, have some way to kick the query over to Deadwood. Once Deadwood determines if it can answer, then it should either return an answer or NXDOMAIN back to MaraDNS, which then forwards it back to the client. Correct? Thanks! -- Joshua Kinard Gentoo/MIPS kumba at gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic From kumba at gentoo.org Sat Mar 3 04:34:21 2012 From: kumba at gentoo.org (Joshua Kinard) Date: Sat, 03 Mar 2012 04:34:21 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: <4F51AF9F.9060604@gentoo.org> References: <4F51AF9F.9060604@gentoo.org> Message-ID: <4F51E59D.1090709@gentoo.org> On 03/03/2012 00:43, Joshua Kinard wrote: > > I am looking at migrating a small, internal DNS server on my home network > over to MaraDNS-2.x from PowerDNS (only because PowerDNS 3.0 no longer > supports the LDAP backend module), but I am puzzled over how MaraDNS and > Deadwood talk to each other (if they do at all). > > Being that MaraDNs is the authoritative server and Deadwood the recursive > server, what's the correct way to run both on the same host such that A/AAAA > queries for an internal host get answered by MaraDNS and queries for > everything else are answered by Deadwood? > > Under PowerDNS, you point pdns to the "recursor" (precursor) via IP, and > pdns will use the recursor to query for any domain that it is not > authoritative for. I cannot find the equivalent configuration for this in > MaraDNS/Deadwood, or I am not configuring it correctly. Having used > PowerDNS for so long, I am not sure what MaraDNS' equivalent terminology for > this setup is in the documentation. > > It's also possible that because the documentation attempts to service both > MaraDNS 1.4 and MaraDNS 2.0 questions simultaneously, where one did both > authoritative/recursive and the other does authoritative only, that this > adds to the confusion. > > Current setup: > - MaraDNS listening on an internal IP for DNS queries. > - Deadwood listening on Loopback for recursive queries. > > Actions: > - Queries for internal hosts to MaraDNS resolve correctly. > - Queries for external hosts to Deadwood resolve correctly. > - Queries for external hosts (e.g., Google) to MaraDNS do NOT resolve. > > For item #3, my thinking is that MaraDNS should first look to see if it can > answer the external query, then if not, have some way to kick the query over > to Deadwood. Once Deadwood determines if it can answer, then it should > either return an answer or NXDOMAIN back to MaraDNS, which then forwards it > back to the client. Okay, I found the thread from October that partially clarified the way to make MaraDNS and Deadwood talk to each other: Make MaraDNS bound to loopback (127.0.0.1) and make Deadwood listen on the private internal interface (I have already disabled filtering of RFC1918 addresses). Then configure Deadwood to treat my local "root" domain as different from the ICANN roots and fire the request to 127.0.0.1 so MaraDNS can answer. That works, but.... Deadwood will report back that the lookup is non-authoritative, which is correct, but since it asked MaraDNS for the query, can't it speak "on behalf of"? Maybe I am missing something in my understanding here, because I've used PowerDNS for so long. It seems like having Deadwood and MaraDNS talk directly to each other, perhaps via UNIX socket or some other internal messaging mechanism might be more appropriate, versus having to query one server for the Internet, and a second server for the local network. Also, for Deadwood, how can I have it listen on both IPv4 and IPv6 simultaneously? MaraDNS has indepdent variables for ipv4 and ipv6 addresses, but Deadwood only has "bind_address", which only appears to accept a single value. Thanks! -- Joshua Kinard Gentoo/MIPS kumba at gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic From maradns at gmail.com Sat Mar 3 17:52:22 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 3 Mar 2012 17:52:22 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: <4F51E59D.1090709@gentoo.org> References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> Message-ID: > Deadwood will report back that the lookup is non-authoritative, which is > correct, but since it asked MaraDNS for the query, can't it speak "on behalf > of"? The following patch will set the "AA" bit for all of Deadwood's replies: http://maradns.org/deadwood/patches/deadwood-3.2.02-kumba.patch It is non-trivial to have Deadwood set the AA bit for some replies and have the AA bit cleared for other replies. I'm also not really in an economic position to make something like this a user-settable flag. Thank you for your understanding, - Sam From maradns at gmail.com Sat Mar 3 17:54:00 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 3 Mar 2012 17:54:00 -0500 Subject: [MaraDNS list] MaraDNS 1 is only supported for security bugs Message-ID: This is a heads-up that MaraDNS 1 is no longer supported for anything besides security holes; I mentioned this policy at the beginning of the year. I actually have been phasing out of support for MaraDNS 1 since 2009: http://maradns.blogspot.com/2009/05/alexa-top-500-list.html http://maradns.blogspot.com/2010/08/deadwood-2904-released.html http://samiam.org/blog/20120101.html Since I understand a lot of MaraDNS users do not carefully read my blog, and since I have made updates to MaraDNS 1 this year, I can see why some people are not aware of my support boundaries for MaraDNS 1. This in mind, I have updated the relevant download pages for MaraDNS 1 to make it clear only security support is supplied for this older software. I wish I was in an economic position to supply full support for all MaraDNS releases, as well as being able to add DNSSEC support as well as better integration between the authoritative and recursive parts of MaraDNS 2, but unfortunately no one with deep pockets has offered to pay me to work on MaraDNS full time. - Sam From kumba at gentoo.org Sat Mar 3 20:01:49 2012 From: kumba at gentoo.org (Joshua Kinard) Date: Sat, 03 Mar 2012 20:01:49 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> Message-ID: <4F52BEFD.1030807@gentoo.org> On 03/03/2012 17:52, Sam Trenholme wrote: >> Deadwood will report back that the lookup is non-authoritative, which is >> correct, but since it asked MaraDNS for the query, can't it speak "on behalf >> of"? > > The following patch will set the "AA" bit for all of Deadwood's replies: > > http://maradns.org/deadwood/patches/deadwood-3.2.02-kumba.patch > > It is non-trivial to have Deadwood set the AA bit for some replies and > have the AA bit cleared for other replies. I'm also not really in an > economic position to make something like this a user-settable flag. > > Thank you for your understanding, Thanks, I'll experiment with this. I also seemed to have stumbled on an IPv6 bug with Deadwood, in that it does not bind to Unique Local Addresses (Defined by IANA as fc00::/7, but only fd00::/8 is currently in use by the RFC specification). Going to run gdb/ddd on it to trace where/why, just to eliminate the issue being something with my virtual machine's configuration. Seems so far to point at do_bind() in DwSocket.c not getting something back that it likes. -- Joshua Kinard Gentoo/MIPS kumba at gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic From maradns at gmail.com Sun Mar 4 00:07:46 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 4 Mar 2012 00:07:46 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: <4F52BEFD.1030807@gentoo.org> References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> Message-ID: > I also seemed to have stumbled on an IPv6 bug with Deadwood, in that it does > not bind to Unique Local Addresses (Defined by IANA as fc00::/7, but only > fd00::/8 is currently in use by the RFC specification). Works for me. Look at this script: http://maradns.org/deadwood/browse-source/stable/sqa/basic_ipv6_test/do.test This is a SQA regression that I run before making a Deadwood release; if this regression fails, I don't make a Deadwood release until the regression passes again. This test passes both on "bare metal" and in a OpenVZ virtual container. For people who can't or won't read the shell script, the test has Deadwood bind to fd4d:6172:6144:4e53::1 and use this IP without problem. > Going to run gdb/ddd on it to trace where/why, just to eliminate the issue > being something with my virtual machine's configuration. ?Seems so far to > point at do_bind() in DwSocket.c not getting something back that it likes. Let us know what your solution to the problem is. Keep in mind that IPv6 is horribly broken in Linux in a number of ways. - Sam From maradns at gmail.com Sun Mar 4 00:22:58 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 4 Mar 2012 00:22:58 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> Message-ID: > This is a SQA regression that I run before making a Deadwood release; > if this regression fails, I don't make a Deadwood release until the > regression passes again. ?This test passes both on "bare metal" and in > a OpenVZ virtual container. Note to self: This regression is actually broken. While, if properly compiled, both MaraDNS and Deadwood can bind to and use IPv6 addresses like fd4d:6172:6144:4e53::1 and fd4d:6172:6144:4e53::2, the SQA regression no longer correctly tests for this. MaraDNS needs to be compiled with special flags to use IPv6 and this SQA test was never correctly updated to use MaraDNS 2's new IPv6 compile-time flags. I should fix the IPv6 regressions one of these years. I'm in no real hurry to do so. - Sam From kumba at gentoo.org Sun Mar 4 19:16:45 2012 From: kumba at gentoo.org (Joshua Kinard) Date: Sun, 04 Mar 2012 19:16:45 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> Message-ID: <4F5405ED.2050004@gentoo.org> On 03/04/2012 00:22, Sam Trenholme wrote: >> This is a SQA regression that I run before making a Deadwood release; >> if this regression fails, I don't make a Deadwood release until the >> regression passes again. This test passes both on "bare metal" and in >> a OpenVZ virtual container. > > Note to self: This regression is actually broken. While, if properly > compiled, both MaraDNS and Deadwood can bind to and use IPv6 addresses > like fd4d:6172:6144:4e53::1 and fd4d:6172:6144:4e53::2, the SQA > regression no longer correctly tests for this. > > MaraDNS needs to be compiled with special flags to use IPv6 and this > SQA test was never correctly updated to use MaraDNS 2's new IPv6 > compile-time flags. > > I should fix the IPv6 regressions one of these years. I'm in no real > hurry to do so. Just so I understand, you're saying that Deadwood should bind to a ULA address, but just the SQA regression is broken? The only compile-time flags that I can observe being passed for IPv6 is -DIPV6. That said, though, I pinned the issue down to a little bit of PEBKAC and a possible bug in Gentoo init scripts, or just the Kernel disabling binds while duplicate address detection (DAD) is on-going. My virtual machine appears to boot up *too* fast for several services trying to bind to IPv6 (sshd and Deadwood), thus the binds are getting denied because the kernel disallows binds to "tentative" addresses. I have a workaround in place that mitigates this. So, that problem is solved. Celebrate! How about the interaction between MaraDNS and Deadwood? I did find that the one example of having Deadwood apply a different "root" for a private network to work okay, but it seems like the two daemons should try to link to each other in some format. I believe PowerDNS allows for one to talk to the other over IPv4, IPv6, or even a UNIX socket. I am not certain of the security implications of such a setup, however, and I know security is one of your primary goals with MaraDNS. But it would eliminate the need for Deadwood selectively setting the AA bit, and instead just forward the response it would get from MaraDNS. Cheers, -- Joshua Kinard Gentoo/MIPS kumba at gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic From maradns at gmail.com Mon Mar 5 03:46:13 2012 From: maradns at gmail.com (Sam Trenholme) Date: Mon, 5 Mar 2012 03:46:13 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: <4F5405ED.2050004@gentoo.org> References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> Message-ID: > Just so I understand, you're saying that Deadwood should bind to a ULA > address, but just the SQA regression is broken? ?The only compile-time flags > that I can observe being passed for IPv6 is -DIPV6. That is correct. Deadwood correctly binds to a ULA address, but the SQA regression for making sure Deadwood works with IPv6 is broken (it's roughly a two-line fix, but I'm not doing it right now because I really need to stop having MaraDNS distract from my day job). IPv6 works with Deadwood in theory--well, except for ugly corner cases like glueless NS referrals which have AAAA but no A records--but this has not been tested. > So, that problem is solved. ?Celebrate! I'm glad you have resolved your issue. > it seems like the two daemons should try to link > to each other in some format. My original plan was to merge Deadwood's code with MaraDNS' authoritative code. Unfortunately, Deadwood took a couple of years longer to finish than I thought it originally would, and I got engaged and married before Deadwood was fully recursive. I don't know if your engaged or married, Joshua, so please don't take this the wrong way: I discovered that marriage changed my fundamental life priorities. I realized I no longer had time to perform professional quality software development "for fun and for free" any more. So, I made a promise to declare Deadwood and MaraDNS finished once full recursion was implemented, and canceled plans to merge Deadwood with MaraDNS. I finished Deadwood in September of 2010 and have been only maintaining Deadwood and MaraDNS since then. [1] I think these things are worthwhile to do. I think one advantage MaraDNS and Deadwood have is security, yes, and Deadwood has the best security a recursive DNS server can have short of implementing DNSSEC [2] [3]. I think another advantage is that Deadwood is tiny and MaraDNS really small; this works really great in MIPS routers and other embedded environments. Since I am no longer in a position to implement significant new features for MaraDNS and Deadwood, I would love to hand things over to a maintainer. I am not going to hand over the reins lightly; anyone who becomes MaraDNS' maintainer would have to demonstrate a long-term interest in MaraDNS' code base that lasts at least a year. Also, I ask that they increase the major version number of MaraDNS and Deadwood (MaraDNS 3 and Deadwood 4, or more simply MaraDNS/Deadwood 4) and I will continue to fix security problems found in MaraDNS 1, as well as performing basic bug fixes for MaraDNS 2, Deadwood 2, and Deadwood 3. - Sam [1] To be pedantic, I used to ask for donations and passed a tip hat around so that I could get paid to work on MaraDNS. My hopefully final funding drive was last November; I got enough money to touch up a couple of minor things that didn't get in to Deadwood 3.0, and to fully babysit MaraDNS until mid-March. [4] [2] This does not mean security problems are never discovered in Deadwood or MaraDNS. It, however, means that I take responsibility for said security problems and issue updates. [3] http://maradns.org/deadwood/doc/Recursive-algorithm.html [4] I will no longer be regularly looking at the mailing list as of March 15; people with MaraDNS support concerns will have to wait until around the end of the month for me to respond to queries posted here after that date. From remco at webconquest.com Mon Mar 5 03:55:53 2012 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 5 Mar 2012 09:55:53 +0100 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Sam, Over the years you have repeatedly mentioned that you no longer had the time or desire to work on maradns without fair compensation. That seems fair and understandable to me, and I'm sure most people will understand this as well. That said, I do see support and feature requests appearing regulary on this list by people who'd like to see MaraDNS being developed further. What do you see as needed to enable this? Just a maintainer to step forward? Suggest people create their own fork? Or would perhaps a model with shared development (using git or similar) already go a long end? Or is maradns (other than bug- and security fixes) "complete" for you? In short, maradns is your project and as such people see you as the authorative lead of the project, yet your goals for it and the desires of the user community seem to diverge more and more. How would you prefer to see this resolved? Thanks, as always, Remmy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJPVH+ZAAoJEOsuQJrxVIpnCFQP/1m/mTrXy2txzlBb+k6gTB3L DPlK1NfyVo/CKNoVLCPippeF72IYE6PcMWYg5x/JWjEMRAk4w7Z/NSwcOlm1sl4g C+LQpvIfHVtuw97ImxIFZ1bLECVjQdpt3LVFD5N4wiRC21N2SpRGdkFgif3MtU8c s7Ual7ai57oKOKuR9e9107fEgxBhkh9Gas+pziHCWJ+0rpNHmSuez3Q7lFD87BNf HRJqYvMjcKYgwoyYR+hkJjBHYfntDrylrbMQTatV7gMMz42/KXBS5Nu668HeMKr5 EGpAunTsjc2I8BN+zTNBDetSqwVKMhXpjmCwPijUW9Rif//QNA2JU7GdNcD2uXUh SAAJklF3y1k/qKjYvLGzb9wFZRj7g/19xGGCr7NmoiafCkGwi0dZkp8TxafkioJp daUxWxNXp6wFvnEHjOWOj4J7Hcxz4ItXx+TvKJxgZSHtCCYM/2ShmGhCbsA8b45t K/LaK/AEzn3Vye24yty1X+lRMNvQc2RasiKx5uWHYb7/HLlsURJAHcSvteF1sA98 A3JT6eZ5/HW1MMbeienfxoIO6JTJFGEQY/P0hCS2KpjV7BThyOp0FpUb3E8HgIgP hQxxLzNhhrG1UrLH8USuoAV1+ccW1pXzCgZbMho8RwJnYZJypj+ib7HmKLPFzrlz I959OEkQAYmxcbmltAM1 =YXwy -----END PGP SIGNATURE----- From maradns at gmail.com Tue Mar 6 11:36:16 2012 From: maradns at gmail.com (Sam Trenholme) Date: Tue, 6 Mar 2012 11:36:16 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> Message-ID: > That said, I do see support and feature requests appearing regulary on > this list by people who'd like to see MaraDNS being developed further. > > What do you see as needed to enable this? Just a maintainer to step > forward? Exactly. For new features to be developed, we need to have someone who is willing to take responsibility for all bugs caused by new features, and who is skilled enough in C to fix any and all such bugs if needed. For example, let's look at this thread on the mailing list: http://woodlane.webconquest.com/pipermail/list/2010-August/000635.html Here, a bug was reported with MaraDNS. Even though the person who wrote the code causing this bug has left the MaraDNS community years before, I took responsibility for the bug and fixed it. > Or would perhaps a model > with shared development (using git or similar) already go a long end? I have no problem with a Git development model, as long as someone besides myself is willing to be the person designated responsible for any and all bugs in the Git branch of MaraDNS. I don't want MaraDNS to have the same problems that Claws Mail, an unofficial fork of Sylpheed, has: While Claws Mail has a lot of features Sylpheed doesn't have, it also is a lot more unstable and crashes more frequently. > is maradns (other than bug- and security fixes) "complete" for you? That is correct. MaraDNS is finished for me. I will remain the person responsible for bugs in the code, but will only check the mailing list roughly once a month or so to see what bugs have been reported. There's a pretty good chance that, once IPv6 is prominent enough that my home internet connection gives me an IPv6 IP, I will make sure MaraDNS and Deadwood are fully functional on an IPv6 network. Yes, this means I will probably have to add a bunch of ugly code for glueless NS referrals to first look for an A record, then look for an AAAA record if the A record is reported as not existing. > your goals for it and the desires of > the user community seem to diverge more and more. How would you prefer to > see this resolved? I would love to have a maintainer who is willing to oversee new features being implemented and is willing to take responsibility for all bugs caused by said features. - Sam From kumba at gentoo.org Tue Mar 6 18:10:03 2012 From: kumba at gentoo.org (Joshua Kinard) Date: Tue, 06 Mar 2012 18:10:03 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> Message-ID: <4F56994B.8030404@gentoo.org> On 03/05/2012 03:46, Sam Trenholme wrote: > I don't know if your engaged or married, Joshua, so please don't take > this the wrong way: I discovered that marriage changed my fundamental > life priorities. I realized I no longer had time to perform > professional quality software development "for fun and for free" any > more. I understand enough, especially on the "for free" bit. Software development is, by no means, a trivial task and many hours are often put into it, so there is nothing wrong with attempting to seek some form of compensation or ceasing work due to lack of available funds. But on the "for fun" part, that is one of the most important aspects. Software development always has to have some kind of "fun" in it in order for it to be enjoyable. Once you hit that wall where a particular project is no longer fun, then it is quite understandable that it is time to move on to new challenges. Because recapturing that lost fun is often an enigmatic challenge itself and few ever accomplish it. > So, I made a promise to declare Deadwood and MaraDNS finished once > full recursion was implemented, and canceled plans to merge Deadwood > with MaraDNS. I finished Deadwood in September of 2010 and have been > only maintaining Deadwood and MaraDNS since then. [1] A congratulations is in order here! It is rare for anyone to ever announce that a software project, even just a specific version of it, is "finished". Often, the goal is to just start on the next version and figure out what the next gizmotronic gonkulator to add is. > I think these things are worthwhile to do. I think one advantage > MaraDNS and Deadwood have is security, yes, and Deadwood has the best > security a recursive DNS server can have short of implementing DNSSEC > [2] [3]. I think another advantage is that Deadwood is tiny and > MaraDNS really small; this works really great in MIPS routers and > other embedded environments. I agree on the routers bit. I might have to look into getting Deadwood to build on the OpenWRT toolchain (or see if they haven't already included it) and try to get it running on my router, and keep the authoritative component to just my internal system. My primary work in the MIPS world has been more focused on the older, larger SGI workstations, though that has fallen behind a bit as I get tied up with Life and all the little details it includes. In this vein, the docs I followed to get a test setup running had me use Deadwood's "upstream_servers" to point to a MaraDNS instance as authoritative for my local network root (though Deadwod strips the AA bit). Is the reverse possible? I.e., have MaraDNS configured to answer all local queries, but anything it doesn't recognize, to ask to a Deadwood instance? I didn't see such an example in the example configs (though I might have missed it). I'll poke through the full example config later to check. > Since I am no longer in a position to implement significant new > features for MaraDNS and Deadwood, I would love to hand things over to > a maintainer. I am not going to hand over the reins lightly; anyone > who becomes MaraDNS' maintainer would have to demonstrate a long-term > interest in MaraDNS' code base that lasts at least a year. Also, I > ask that they increase the major version number of MaraDNS and > Deadwood (MaraDNS 3 and Deadwood 4, or more simply MaraDNS/Deadwood 4) > and I will continue to fix security problems found in MaraDNS 1, as > well as performing basic bug fixes for MaraDNS 2, Deadwood 2, and > Deadwood 3. Perhaps you should look at how the Linux kernel management works these days. Torvalds has largely stated that he doesn't really write any new code for the kernel, but spends most of his time commenting on submitted code and reviewing patches and handling the releases of the primary branch. Other individuals take up the roles of being subsystem maintainers and releasing new versions in other branches (such as -stable). While you probably don't even have time enough for that, creating some sort of "lead maintainer" positions, one for MaraDNS and another for Deadwood, might be worth looking into. They would handle the existing codebases, process new patches and prepare new versions for release. You could maintain final review before new releases (or even on new patches), so as to safeguard MaraDNS/Deadwood's history of being small and secure. Not that I've done a qualitative, objective analysis on that approach, but it might require less time investment than writing all new code and managing releases yourself, while still allowing you enough ample time to stay in touch with the project. Food for thought, perhaps. Cheers! -- Joshua Kinard Gentoo/MIPS kumba at gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic From kumba at gentoo.org Tue Mar 6 18:21:54 2012 From: kumba at gentoo.org (Joshua Kinard) Date: Tue, 06 Mar 2012 18:21:54 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> Message-ID: <4F569C12.7000605@gentoo.org> On 03/06/2012 11:36, Sam Trenholme wrote: > There's a pretty good chance that, once IPv6 is prominent enough that > my home internet connection gives me an IPv6 IP, I will make sure > MaraDNS and Deadwood are fully functional on an IPv6 network. Yes, > this means I will probably have to add a bunch of ugly code for > glueless NS referrals to first look for an A record, then look for an > AAAA record if the A record is reported as not existing. My ISP is Comcast, and despite the poor quality of their customer service, they are the only residential-grade ISP working really hard towards full IPv6 deployment. They've even stated that they may not default to full /64 handouts for all customers, but might even go down to /112 or /128, based on customer need. But, that's still a ways off. For now, I setup a small IPv6 network internally, using ULA addresses (because I want an easy-to-remember prefix and am not planning on being acquired by a large enterprise anytime soon). This allows for basic testing and understanding of what IPv6 is and how to work with it. I even have an IPv6 firewall ruleset ready once I get an external IPv6 address. If you find the time, perhaps this is something worth trying out to add more IPv6 functionality to MaraDNS. One of my primary motivations for trying to move off of PowerDNS is its default backend is a database (specifically, MySQL), which seems silly for a DNS server. I instead used LDAP as a backend (okay, I managed a NetWare network once and loved storing DNS inside of eDirectory). But The PowerDNS LDAP backend is unmaintained as of v3.0 and already has bugs in properly resolving IPv6 PTR records when using a simple LDAP tree layout. This brought me to look at MaraDNS because of the use of text files for storage, but I might also give BIND another shot, too. That all said, and possibly due to some of my inexperience in advanced C projects and not a deep understanding of DNS, wouldn't looking through the results of a DNS response for any A records before AAAA be just a basic, repeated string search? I would imagine that shouldn't be *too* ugly a piece of code. What about looking for AAAA before A? I have noticed that a lot of dual-stack network implementations do this by querying first for AAAA, then trying again for A when they get NXDOMAIN or another such error. Cheers, -- Joshua Kinard Gentoo/MIPS kumba at gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic From maradns at gmail.com Tue Mar 6 20:47:25 2012 From: maradns at gmail.com (Sam Trenholme) Date: Tue, 6 Mar 2012 20:47:25 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: <4F569C12.7000605@gentoo.org> References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> <4F569C12.7000605@gentoo.org> Message-ID: > My ISP is Comcast, and despite the poor quality of their customer service, > they are the only residential-grade ISP working really hard towards full > IPv6 deployment. Well, since I'm using Comcast right now, I will hopefully have IPv6 sooner rather than later. I might even have Deadwood's and MaraDNS' IPv6 functionality fully tested by the end of the year. >?This > brought me to look at MaraDNS because of the use of text files for storage, > but I might also give BIND another shot, too. NSD uses text files converted in to binary data for storage but has no recursion (use Unbound). BIND is the only currently maintained DNS server with both recursion and authoritative DNS in the same daemon. The thinking with Unbound/NSD and Deadwood/MaraDNS is that you have one daemon which supplies answers to DNS questions, and another daemon which looks for answers to DNS questions. They are rather distinct roles best served by distinct daemons. > That all said, and possibly due to some of my inexperience in advanced C > projects and not a deep understanding of DNS, wouldn't looking through the > results of a DNS response for any A records before AAAA be just a basic, > repeated string search? ?I would imagine that shouldn't be *too* ugly a > piece of code. ?What about looking for AAAA before A? ?I have noticed that a > lot of dual-stack network implementations do this by querying first for > AAAA, then trying again for A when they get NXDOMAIN or another such error. I see you haven't become acquainted with the monstrosity that is DNS. When you get a NS referral, the referral is by name, not by IP. A DNS response referring you to another DNS server doesn't say "the DNS server for whatever.foo is 10.1.2.3". No, it tells you something like "the DNS server for whatever.foo has the name dns.isp.foo". If you're lucky, you will also get a "glue" record: "the IP for dns.isp.foo is 10.1.2.3" and maybe even "The IP6 for dns.isp.foo is fd4d:6172:6144:4e53::10:123". Glues NS referrals are pretty easy to deal with and Deadwood should handle that case with both IP4 and IP6 just fine (IP6 hasn't been tested, mind you). Now, in an IPv4 only network, if we get a glueless NS referral, we then simply look for the IP4 IP for that record, find it, and then solve the query. In a mixed IP4 and IP6 network, DNS gives us no information whether the glueless NS referral is found on an IP4 network, an IP6 network, or both. So, we would have to do the following: * Look for the IP4 for the glueless NS referral. * If we're given a "not there" or NX reply, look for the IP6 for the glueless NS referral. * Once we get this IP6 address, ask for information from that DNS server and continue our search. It can be done, but the code to do it will be rather ugly, especially since Deadwood uses the "select() model" instead of threads to do all of this processing. It will probably take a couple of months to pull off. I'm not going to touch this until I am on an IPv6 network at home. There's also the issue with adding IPv6 to the Windows Deadwood service. - Sam From maradns at gmail.com Wed Mar 7 00:10:45 2012 From: maradns at gmail.com (Sam Trenholme) Date: Wed, 7 Mar 2012 00:10:45 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: <4F56994B.8030404@gentoo.org> References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> <4F56994B.8030404@gentoo.org> Message-ID: > A congratulations is in order here! ?It is rare for anyone to ever announce > that a software project, even just a specific version of it, is "finished". > ?Often, the goal is to just start on the next version and figure out what > the next gizmotronic gonkulator to add is. I think closure on a software project is important: http://maradns.blogspot.com/2009/09/rant-putting-closure-on-project.html > I agree on the routers bit. ?I might have to look into getting Deadwood to > build on the OpenWRT toolchain You should ask Sebastian M?ller about Deadwood on OpenWRT: http://woodlane.webconquest.com/pipermail/list/2010-September/000672.html I used to mirror the files, but haven't ever since Deadwood got updated. Deadwood compiles nicely and pretty much any ISA out there (the coding style is completely endian-neutral; all numbers are big-endian numbers when stored in files or transmitted over the wire) > ?Is the reverse possible? ?I.e., have MaraDNS configured to answer all local > queries, but anything it doesn't recognize, to ask to a Deadwood instance? Only in MaraDNS 1. Here's a howto which explains how to do something similar: http://samiam.org/blog/20111128.html > Perhaps you should look at how the Linux kernel management works these days. > ?Torvalds has largely stated that he doesn't really write any new code for > the kernel, but spends most of his time commenting on submitted code and > reviewing patches and handling the releases of the primary branch. I really don't have time to even look at patches and bless them :( > While you probably don't even have time enough for that, creating some sort > of "lead maintainer" positions, one for MaraDNS and another for Deadwood, > might be worth looking into. ?They would handle the existing codebases, > process new patches and prepare new versions for release. ?You could > maintain final review before new releases (or even on new patches), so as to > safeguard MaraDNS/Deadwood's history of being small and secure. For me, it would be better if the maintainer took all responsibility. All the bugs are their responsibility; just let me update MaraDNS 2, Deadwood 3, and supply secuirty patches to MaraDNS 1. From remco at webconquest.com Wed Mar 7 00:41:03 2012 From: remco at webconquest.com (Remco Rijnders) Date: Wed, 7 Mar 2012 06:41:03 +0100 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> <4F56994B.8030404@gentoo.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Mar 07, 2012 at 12:10:45AM -0500, Sam wrote in : > >> Perhaps you should look at how the Linux kernel management works these days. >> ?Torvalds has largely stated that he doesn't really write any new code for >> the kernel, but spends most of his time commenting on submitted code and >> reviewing patches and handling the releases of the primary branch. > >I really don't have time to even look at patches and bless them :( > >> While you probably don't even have time enough for that, creating some sort >> of "lead maintainer" positions, one for MaraDNS and another for Deadwood, >> might be worth looking into. ?They would handle the existing codebases, >> process new patches and prepare new versions for release. ?You could >> maintain final review before new releases (or even on new patches), so as to >> safeguard MaraDNS/Deadwood's history of being small and secure. > >For me, it would be better if the maintainer took all responsibility. >All the bugs are their responsibility; just let me update MaraDNS 2, >Deadwood 3, and supply secuirty patches to MaraDNS 1. Sam, Would it be agreeable to you if we put maradns and deadwood in a git tree, and at the same time branch them into a development / new major version tree for new developments to take place in while the community / maintainer(s) to be get up to speed? That way you can have / keep your responsibility for your code while still keeping an eye (should you so desire) on the evolution of the code in the development area. Furthermore, it would make it easier to cherrypick patches from one tree and apply them to the other. I understand your time constraints but I have the feeling I might not be the only one willing to be a (small) part of such a thing. Even if we do not have anywhere near the skills you have, we can see where this will take us? In the worst case, it fails horribly or goes out silently. Furthermore, I also do understand that any of us could create such a thing easily, but it would be nice if we have you in support of it. Thanks, Remmy are just a few of us here -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJPVvTvAAoJEOsuQJrxVIpnDmYP/13C4sgiD3ZVJshxIaOXLOcM MM9JIQCiaIWrVQA/v4FQxsOCBUNktGRxhe1I4lF8tX5Fw176K4OflGz8a8prtoCl GetyAkRgJEflcarYBwDni6PcLsqPv0Kk2l6+8Yu2yKLBYVwh2QI7ZoKI1d3evlsV lQUH8u3dOWrWNN52ts4kgO19j4OgE548XQ/QP3t6Ud5o9PgNW8xPBu1RXgu6Kh4S 5x27614bH2ndGB+yMCGAGbVvmbrN/k8V5L5Ph5M3phPxJJpP5Fvz55mBZ/idYCVA TOTeI55mxtz3QpajQxRJ8VhjfZIQzfjD6oi/CLhE25uXmsNAUYyFoSwUbulDbwa0 of7cUop813kCmc5EAuN9fPviQmkrqB37+DKf+L0dXyv7YHg8Q/qhayUD+1ZCVu0W cpy4xeBYl4XioH9H5h8PprCffvb7LT2+PeDzo11C+4xGkG02U81JEd4kA+RWWe88 QV5Q2kzyY8pbsjk4Qw60/L8scje5zqcm+ZXHipLdkWi72JdqCkaVC0+7ls2wqQe9 b9FM4lrEPSIgLI2eD3wWZ+yZObFjxbn0BqcuVRWr9xMIbh7alvGaISMTuQds9hPd Vkbflp6VG5zUu82mVdujS6p/NhinywgvJ7qPngY5/K6nZ25Y3XC7bmEVnDAUp5kt 9pUIZjqCghwWB+dE9Zd8 =C89f -----END PGP SIGNATURE----- From remco at webconquest.com Wed Mar 7 00:47:04 2012 From: remco at webconquest.com (Remco Rijnders) Date: Wed, 7 Mar 2012 06:47:04 +0100 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> Message-ID: On Tue, Mar 06, 2012 at 11:36:16AM -0500, Sam wrote in : >> That said, I do see support and feature requests appearing regulary on >> this list by people who'd like to see MaraDNS being developed further. >> >> What do you see as needed to enable this? Just a maintainer to step >> forward? > >Exactly. For new features to be developed, we need to have someone >who is willing to take responsibility for all bugs caused by new >features, and who is skilled enough in C to fix any and all such bugs >if needed. > >For example, let's look at this thread on the mailing list: > >http://woodlane.webconquest.com/pipermail/list/2010-August/000635.html > >Here, a bug was reported with MaraDNS. Even though the person who >wrote the code causing this bug has left the MaraDNS community years >before, I took responsibility for the bug and fixed it. While I applaud your responsibility in resolving this particular bug, I don't think it is realistic to expect people to be around forever to fix the bugs their own code introduced. People lose interest, move on to other things, get married, have health issues, etc. etc. No one would blame you for changing priorities in your life either, though everyone would be happy if you stayed with your baby maradns as time and energy permits it. Once a patch is accepted, it is the responsibility of the community to maintain that code. Not that of the original coder (who might of course have a personal interest in keeping it well maintained!), nor that of you as the sole person working on maradns. If we can find a way to share the burden, everyone will be better and happier for it. Remmy From remco at webconquest.com Wed Mar 7 00:49:00 2012 From: remco at webconquest.com (Remco Rijnders) Date: Wed, 7 Mar 2012 06:49:00 +0100 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> <4F56994B.8030404@gentoo.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Mar 07, 2012 at 06:41:03AM +0100 I wrote in : > >Thanks, > >Remmy >are just a few of us here That last line was of course nothing but an editing error on my part. Not sure how I managed to let that one slip in! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJPVvbLAAoJEOsuQJrxVIpnJ5IQAK7UcRW8iQgY6hm5Wbv6oAE2 dYckGBYBtrPrEHQcwdCCDgvp3rsAAGvH7YLqrSQisVvPTGXep3QKOk2TX3mI5lLS zUULUc+KNVG6sBiQyH4keE6tDsif3Mbi8HbUqZAP73xxhVQoX4tKbm4Eba6VuU1w xv7/18MaI84FY8Tu8arHmhgM2thzpYeqHZXZmXEsSWkGsxa3b7HQsrCv+wi/zrk4 fd36eeppTJ2l+K1HkR56jOgA2kV7hthjF0v5E7xjgR6EuDdfm6pKeH5U2MkyOerK z7lYFg/Lxv/h0ma7kcgLOZecVmXdf+vaxNRU9RTl5u6JyqvVSBXA7Lfb5U5yNuQJ p0sbop/xSBK+IPFDve6Azjl5oK2nnDHoOpGVBzNgJjJU3ESNPMktF/HxWwjWDqqY rmaFZO3rztoWiL1tWKzJkm5/9KbhoT/A40AJ0I3l93kFVdnThvxatR6ayCMbvZUx ZSQRh2ac3s68lNK2kW8DQgqRrhhWeAmvn2RlJLVA663WNuEFGVIGS6gFbg769SUW ShhXVJIBy5k0uMG+huoDroUcsr8jWejUuAPnfBhCgRbDzLYOTygC7EfKEgFL7EJ7 ea+JmYczb4csbyDv/3aIRWfVmUfkLaV6PfMU9l6R7Byha2/Jjd/ua8r86/8lpd50 dO6of7AgvutEWsbSzlQN =AUlg -----END PGP SIGNATURE----- From maradns at gmail.com Wed Mar 7 02:44:50 2012 From: maradns at gmail.com (Sam Trenholme) Date: Wed, 7 Mar 2012 02:44:50 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> <4F56994B.8030404@gentoo.org> Message-ID: > Would it be agreeable to you if we put maradns and deadwood in a git tree, > and at the same time branch them into a development / new major version > tree for new developments to take place in while the community / > maintainer(s) to be get up to speed? That way you can have / keep your > responsibility for your code while still keeping an eye (should you so > desire) on the evolution of the code in the development area. > Furthermore, it would make it easier to cherrypick patches from one tree > and apply them to the other. You are free to put up a GIT tree for MaraDNS 3/Deadwood 4. Please be sure to increment the major version numbers, and please be sure to make it clear that I am not responsible for any bugs in this GIT tree. I am responsible for security (and no other) bugs in MaraDNS 1.4 (1.3 until December 21). I am responsible for security and other important bugs in MaraDNS 2, Deadwood 2, and Deadwood 3. > it would be nice if we have you in support of it. You have my support, as long as it's made crystal clear that, while this fork is official, I, Sam Trenholme, am not responsible for this branch of the code and can not answer any bug reports (even security ones) or any other concerns one may have about this code. I want to keep the community, small as it is, together, and I do not want to leave MaraDNS development scattered. Now personally, I think there's a really good chance this GIT tree will go the way of Xconq, Freedoom, or the Dents DNS server (unmaintained, dead). But, then again, I once told Gwen Stefani's sister that No Doubt would never become famous, so my predictions have been wrong before. - Sam From maradns at gmail.com Wed Mar 7 03:15:57 2012 From: maradns at gmail.com (Sam Trenholme) Date: Wed, 7 Mar 2012 03:15:57 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> <4F56994B.8030404@gentoo.org> Message-ID: > Would it be agreeable to you if we put maradns and deadwood in a git tree, > and at the same time branch them into a development / new major version > tree for new developments to take place in while the community / > maintainer(s) to be get up to speed? Another very important point. The community is free to have their own git tree. They are free to call it MaraDNS 3...although, I think the name MaraDNS-ng makes a lot more sense. Indeed, scrap MaraDNS 3/Deadwood 4. Call it MaraDNS-ng or whatever. You can keep the name MaraDNS in it. I will link to it from maradns.org and maradns.com, and even host release tarballs of it on maradns's web page (with big huge NOT SUPPORTED BY SAM TRENHOLME disclaimers). However, one issue which has torn apart open source communities time and again is money. I ask for donations on MaraDNS.org. I have ads on MaraDNS.org. I don't get much revenue from either, but just so people know: Any and all revenue from these donations and ads is for me, to defray my monetary expenses hosting MaraDNS and to compensate me for my time and effort developing MaraDNS and continuing to maintain MaraDNS. I've seen a lot of open source types get upset that any money changes hands with an open source project, so I want to make it clear that yes, it's not much money, but I do ask for and do deserve being compensated for my work. MaraDNS-ng (or whetever it ends up being called) is welcome to have their own funding drives and to develop their own methods on how to split up the money. - Sam From maradns at gmail.com Wed Mar 7 03:20:29 2012 From: maradns at gmail.com (Sam Trenholme) Date: Wed, 7 Mar 2012 03:20:29 -0500 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> Message-ID: > I don't think it is realistic to expect people to be around forever to fix the > bugs their own code introduced. I don't either, but there has to be someone responsible for the bugs. Someone with a sign above their head saying "The buck stops here with MaraDNS bugs". It can, naturally, be multiple people. If there is no longer such a person, then MaraDNS will no longer be a viable DNS server; I may as well make maradns.org a redirect to unbound.net in that case. - Sam From jefsey at jefsey.com Wed Mar 7 08:41:52 2012 From: jefsey at jefsey.com (JFC Morfin) Date: Wed, 07 Mar 2012 14:41:52 +0100 Subject: [MaraDNS list] How to get MaraDNS and Deadwood to talk to each other? In-Reply-To: References: <4F51AF9F.9060604@gentoo.org> <4F51E59D.1090709@gentoo.org> <4F52BEFD.1030807@gentoo.org> <4F5405ED.2050004@gentoo.org> Message-ID: <7.0.1.0.2.20120307125741.060a8d00@jefsey.com> At 09:20 07/03/2012, Sam Trenholme wrote: > > I don't think it is realistic to expect people to be around > forever to fix the > > bugs their own code introduced. > >I don't either, but there has to be someone responsible for the bugs. >Someone with a sign above their head saying "The buck stops here with >MaraDNS bugs". It can, naturally, be multiple people. > >If there is no longer such a person, then MaraDNS will no longer be a >viable DNS server; I may as well make maradns.org a redirect to >unbound.net in that case. Sam and all, I tried to start a fork (not a continuation) of MaraDNS as alfaDNS (http://alfadns.org) and I supported it with small money and I continue (I hope so, I am a little lost with the Flattr account I subscribed for that). 1. The need I have is for what I call an ML-DNS logic (fully Internet DNS, IDNA2008 compliant and much more, multi-layer, multi-lingual digital name system) prototype that I could use to explore, test and document NETIX as part of the Internet+ architecture. If some want to know the architectural framework: http://www.ietf.org/internet-drafts/draft-iucg-internet-plus-09.txt and the context: http://www.ietf.org/internet-drafts/draft-iucg-iutf-tasks-00.txt. An example of my need is CLASSes MaraDNS does not support (but several concurrent copies can run several CLASSes in prototype mode). I just tell this to underline that the market is wide. The Internet+ is the existing Internet concepts that I made Vint Cerf to acknowledge (this lead to the IDNA2008 consensus which was blocked otherwise), that are progressively embodied in Google+. Google+ is to make the Internet a Google network, Internet+ is to make it a people centric network. 2. So, the real issue for me was to *learn* how to *build* MaraDNS from Sam. And to use his experience (and code parts), before rebuilding or extending MaraDNS. Sam has not got the time and money I would have like to pay him for that. 3. I was hit by health issues those last months and family load (aged parents who died one year ago, and aftermaths) so I am quite late. My project was : - to document the MaraDNS code. Complete reverse engineering. But I had not the money to buy a decent program with outputs I could understand (I am only a C "amator"). - to motivate a few students to take over the maintenance of MaraDNS hopefully as a class task under the supervision of a teacher who could have related with Sam on a retainer from his school. - to build with former students a small development team to develop alfaDNS as an example, a tool-kit, people could use to adapt their own ML-DNS architecture after we could have enrolled Sam into writing a book on "how to build and port your own digital name server and metadata registry". I wished to explain this because this is different from only maintaining it, and might motivate a community on a long range. jfc PS. ML-DNS was discussed and partly documented by me as a facilitator of the iucg at ietf.org mailing list (Internet users contributing group). Basically it is a multilingual and multilayer front end for an extended MaraDNS and Deadwood functions (plus others) system, operating label conversion algorithm and parser. It should be used to support personal (private external virtual network) roots (multiclasses) and a very extended private IANA system. The target is a really distributed fringe to fringe Internet+ 100% compatible and compliant with the end to end Internet. It only is the applications of RFC 791, 1121, 1958 and 3439 on the Internet architecture in including the principle of subsidiarity which was the fundament of the IDNA2008 consensus (local mapping intelligence on the fringe). Multilayer refers to the fact that the DNS supports 65.536 CLASSes (and therefore root files) and that IDNA has permitted to uncover the supposedly missing "presentation layer" ("xn--" actually represents a presentation) and that domain name resolution may work with a domain name pile in different formats, etc. for different protocols. This is exactly what ICANN has suggested for the DNS in its ICP-3 policy statement. The market is interesting: everyone can have his own legitimate, RFC conformant TLD. This is NOT open roots. This is open Internet. Actually it is openning the whole digital ecosystem, because digital names are not only bound to the Internet (my real interest lies in the Intersem, i.e. the semantic internet of ideas, but this is another story. Even if the SAS (semantic addressing system) will need a name serveur). From maradns at gmail.com Sun Mar 11 14:25:52 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 11 Mar 2012 14:25:52 -0400 Subject: [MaraDNS list] MaraDNS 2.0.06 and 1.4.11 released Message-ID: I have updated MaraDNS to use Deadwood 3.2.02. Deadwood 3.2.02 is a security update to Deadwood 3.2.01. This update has been done in both MaraDNS 2 and MaraDNS 1.4; MaraDNS 2.0.06 and MaraDNS 1.4.11 are the releases with this update. MaraDNS 1.3 is not affected because it does not include Deadwood. For people who want to file a CVE report: Deadwood releases before Deadwood 3.2.02 allow entries to remain in the cache for a long time. In light of the Ghost domain exploit, this is a security problem. Deadwood 3.2.02 is updated to only allow entries to remain in the cache for one day. If max_ttl is set, one can choose store an entries in the cache for up to 90 days. It can be downloaded here: http://www.maradns.org/download/2.0/2.0.06/ http://www.maradns.org/download/1.4/ I plan to work on MaraDNS/Deadwood again one day this month, after the 20th, unless a critical security bug is found. From maradns at gmail.com Sat Mar 17 13:10:02 2012 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 17 Mar 2012 13:10:02 -0400 Subject: [MaraDNS list] MaraDNS 1 (legacy) security bugfix Message-ID: Security fix for MaraDNS 1: Maximum TTL is now one day, to avoid ghost domain-style attacks with the legacy version of MaraDNS. This is akin to the recent Deadwood update. It can be downloaded here: http://www.maradns.org/download/1.4/ http://www.maradns.org/download/1.3/ Updated changelog is at http://maradns.org/changelog.html Patch is at http://maradns.org/download/patches/security/maradns-1.4.11-ghostdomain.patch I plan to work on MaraDNS/Deadwood again one day this month, after the 20th, unless a critical security bug is found. - Sam From maradns at gmail.com Thu Mar 22 15:53:57 2012 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 22 Mar 2012 15:53:57 -0400 Subject: [MaraDNS list] New MaraDNS CVE: 2012-1570 Message-ID: In this post, I discuss CVE-2012-1570 as well as Deadwood 2.3. == CVE-2012-1570 == CVE-2012-1570 is the CVE number assigned for MaraDNS updates made in light of the "ghost domain" bug. I have already updated Deadwood as well as the legacy MaraDNS 1 branch; this CVE just formally declares these updates to be serious security updates. Here is a rundown of all MaraDNS versions affected by the ghost domain security bug: * All MaraDNS 0 releases with recursion (Do NOT use; not maintained) * All MaraDNS 1.0 releases (Do NOT use; not maintained) * All MaraDNS 1.1 releases (Do NOT use; not maintained) * All MaraDNS 1.2 releases (Do NOT use; not maintained) * All MaraDNS 1.3 releases besides 1.3.07 (Do NOT use; not maintained) * All MaraDNS 1.3.07 releases before MaraDNS 1.3.07.15 * All MaraDNS 1.4 releases before MaraDNS 1.4.12 * All MaraDNS 2 releases before MaraDNS 2.0.06 * All Deadwood 3 (subpackage of MaraDNS) releases before Deadwood 3.2.02 * All Deadwood 2 releases besides 2.3 (Do NOT use; not maintained) * All Deadwood 2.3 releases before Deadwood 2.3.08 The following releases have been patched to address this bug: MaraDNS 1.3.07.15, 1.4.12, 2.0.06, as well as Deadwood 3.2.02 and Deadwood 2.3.08 have been released to address this security bug. It is very important that all MaraDNS users update to one of these versions. Please note that MaraDNS 1.3.07 will no longer be supported on December 21, 2012. Please upgrade to MaraDNS 1.4 or 2.0 at your soonest convenience if feasible. Here is an update guide: http://maradns.org/tutorial/update.html Distributions and users who wish to continue, against my wishes, supporting an outdated version of MaraDNS 1 may (or may not) be able to update MaraDNS 1 by using this patch: http://maradns.org/download/patches/security/maradns-1.4.11-ghostdomain.patch == Deadwood update == As noted above, I have updated the older "tiny" branch of Deadwood to address the important "ghost domain" bug; Deadwood 2.3.08 has been released. This took all morning to do; the "tiny" branch has diverged from the main branch of Deadwood enough that it was necessary to completely redo the patch by hand. After doing that, a number of SQA regressions failed because CentOS 5 has changed enough since the last time I ran the Deadwood 2.3 regressions: example.com has a different A record, netstat's output format has changed, and Valgrind complains about "possibly lost" memory it wasn't complaining about before. I had to verify the failed SQA regressions were caused by issues external to Deadwood, and that the code changes did not break anything. It can be downloaded here: http://www.maradns.org/deadwood/tiny/ At this point, I am only supporting Deadwood 2.3 for security and other critical bugs. Deadwood 2.3 only makes sense if one is in an environment where it's better to have a 32 kilobyte non-recursive DNS cache instead of a 64 kilobyte fully recursive DNS cache. Also: Because of how Deadwood 2.3 works, records with TTLs longer than one day will show a longer TTL when said record is retrieved. This update only affects how long the record is stored in Deadwood 2.3's cache. If there is any suspicion that resolvers downstream from a Deadwood 2.3 cache honor large TTLs, please upgrade to Deadwood 3. Also note that Deadwood 2.3 doesn't properly age TTLs. I plan to work on MaraDNS/Deadwood again one day next month, after the 20th, unless another critical security bug is found. - Sam (Now, back to my day job)