From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.4 released (NS delegation fixed) Date: Tue, 23 May 2006 08:12:45 +0000 (UTC) I have just released MaraDNS 1.2.07.4. This releases has one major fix: * I broke NS delegation sometime during the 1.1 development cycle and failed to test this during the testing cycle. I was playing around with MaraDNS today and realized that NS delegation was broken and fixed it. NS delegation is when a DNS server says "I don't have the record for joe.foo.example.com, but the name server for foo.example.com is ns.foo.example.com with the IP 10.1.2.3". This used to be a lot more common, but is fairly rare in these days where people will just register a new domain name instead of having a host have a name besides "www.sillynamehere.com" [1]. I also have some other minor updates: There were some minor bugs with the mararc parser which I have fixed. I have updated the documentation (minor tweaks to the MaraDNS man page; made changes to the webpage so that it validates; etc). The files are available here: http://www.maradns.org/download.html And here: http://sourceforge.net/projects/maradns - Sam [1] Hey, no one has sillynamehere.com yet. Go figure. From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Minor correction on NS delegation bug Date: Wed, 24 May 2006 05:28:13 +0000 (UTC) >I broke NS delegation sometime during the 1.1 development cycle and failed >to test this during the testing cycle. Actually, this first was broken in MaraDNS 1.2.06, when I added the FQDN4 record. NS delegation was never broken in the 1.2.03 branch. Note to self: Have a fairly extensive regression before releaseing a stable upgrade of MaraDNS. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.5 released (star records fixed) Date: Mon, 29 May 2006 09:06:45 +0000 (UTC) I have just released MaraDNS 1.2.07.5. This releases has one major fix: * Star records now work with the ANY query. Unlike the NS delegation fix, ANY queries have never been quite right until 1.2.07.5; the 1.0 branch did not correctly handle ANY queries, but instead just returned A and MX records (and optionally NS and SOA records). The 1.2 branch returns all records attached to a given name, but I forgot to get this to work with star records until today's 1.2.07.5 release. As an aside, star records can potentially cause a DNS packet to be over 512 bytes in length; MaraDNS can also serve longer packets over TCP, but this requires a special setup, described here: http://www.maradns.org/tutorial/dnstcp.html The files are available here: http://www.maradns.org/download.html And here: http://sourceforge.net/projects/maradns - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS.org is down; use sourceforge to download instead Date: Mon, 5 Jun 2006 00:54:02 +0000 (UTC) I'm aware that MaraDNS.org is currently down; people who need to download MaraDNS in the meantime can use http://sourceforge.net/projects/maradns to download MaraDNS files. Here is the GPG sig for maradns-1.2.07.5.tar.gz: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBEeqm3C+jWrh5h/KYRApOJAKCP/zNdsIjJ5ynvQk0bTKPNoj4xyACbBgXW XnSgV6+VqgKxfu7h4nZ2j4s= =VRpK -----END PGP SIGNATURE----- And the one for maradns-1-2-07-5-win32.zip: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBEeqm3C+jWrh5h/KYRApOJAKCP/zNdsIjJ5ynvQk0bTKPNoj4xyACbBgXW XnSgV6+VqgKxfu7h4nZ2j4s= =VRpK -----END PGP SIGNATURE----- - Sam From: Remco Rijnders To: list@NOSPAM.org Subject: Re: [MARA] MaraDNS.org is down; use sourceforge to download instead Date: Mon, 5 Jun 2006 04:47:20 +0200 --nextPart1517343.xFSqSbNeg4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Op Monday 05 June 2006 02:54, schreef Sam Trenholme: > I'm aware that MaraDNS.org is currently down; people who need to download > MaraDNS in the meantime can use http://sourceforge.net/projects/maradns to > download MaraDNS files. The website www.maradns.org should be back up again. My apologies for any=20 inconvenience experienced during the downtime. Remco --nextPart1517343.xFSqSbNeg4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEg5tEP0wYCuTizasRAl7cAKC2MIzGiYE8xA2Ua/odV5RGMB8WggCfZPh6 RevBjoAP8NJwQQqZdsO/r68= =zW// -----END PGP SIGNATURE----- --nextPart1517343.xFSqSbNeg4-- From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS web page back up again Date: Mon, 5 Jun 2006 04:25:42 +0000 (UTC) The MaraDNS web page is up again within 30 minutes of me informing Remco that it was down. Thanks, Remco, for the prompt response! - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.08 released (development release) Date: Sun, 11 Jun 2006 09:14:17 +0000 (UTC) There is a new development-only release of MaraDNS...MaraDNS 1.2.08. This is not a stable release. This is a devlopment release because I have implemented some minor new features which may introduce new bugs, such as the time I broke NS delegation in MaraDNS 1.2.06. The first new feature I have implemented are SPF records. SPF, a.k.a. "Sender Policy Framework" is a way of using DNS to make it harder to forge email. SPF can use TXT records, but RFC4408 also has a SPF record (which is identical to a TXT record except for its numeric record type) which MaraDNS now fully supports. Now, whether SPF is a good thing or not is another discussion. I personally prefer Yahoo's domain keys, since Yahoo's solution doesn't have SPF's problem with bouncing email sent through a mail forwarder that doesn't change the MAIL FROM value. Yes, it would be nice if SMTP servers always changed the MAIL FROM when forwarding email, but if we're going to fantasize, I can think of some far more pleasant fantasies that don't involve so much technology. The other feature I have added is the retry_cycles mararc variable, which lets the DNS admin configure how many times MaraDNS tries contacting all of the DNS servers to resolve a given name before giving up. The default value for this is two; the hard-coded value for this in pre-1.2.08 releases of MaraDNS is one. I think this will make MaraDNS a little more reliable and a better recursive DNS resolver. I have done some basic testing and documentation: Yes, SPF records work exactly as expected. I also ran MaraDNS through about two hours of stress-testing and no crashes nor freeze-ups showed up. Like, I said, this is a development release. Use at your own risk, as always. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Some weirdness with www.microsoft.com Date: Tue, 13 Jun 2006 08:19:58 +0000 (UTC) I'm got a couple of reports that MaraDNS is having some trouble with resolving www.microsoft.com. I can see these issues myself and I'll see if there is something I can do to improve things. Until I have a real fix, one can minimize the microsoft.com problems by increasing the minimum TTL (time a record is in the cache) to one hour by adding the following lines to one's mararc: min_ttl = 3600 min_ttl_cname = 3600 Basically, here is what is going on when trying to resolve www.microsoft.com: * One asks for www.microsoft.com from a root server * The root server refers you to a .com server * The .com server refers you to a microsoft.com DNS server * The microsoft.com DNS server tells you that www.microsoft.com is a CNAME record pointing to toggle.www.ms.akadns.net. * We then have to ask the root servers about toggle.www.ms.akadns.net * The root servers refer us to a .net server * This .net server refers you to the akadns.net servers * The akadns.net servers tells us that toggle.www.ms.akadns.net is a CNAME for g.www.ms.akadns.net, that g.www.ms.akadns.net is a CNAME for lb1.www.ms.akadns.net, and that lb1.www.ms.akadns.net has about 6 IP address. This is all in a single DNS packet. * However, I believe MaraDNS doesn't take this all at once so she asks about g.www.ms.akadns.net, then asks for lb1.www.ms.akadns.net, then finally gets an answer. This can break down. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Microsoft doesn't follow DNS standards Date: Wed, 14 Jun 2006 04:26:49 +0000 (UTC) I found out why MaraDNS was having such a hard time resolving microsoft.com, and have fixed the issue. The MaraDNS resolver has always rejected any DNS packet with an answer (in the answer section) that is not a direct (or direct-made-CNAME) answer to our question. Almost all DNS traffic acts this way. This behavior has been in use for over three years without anyone telling me that MaraDNS does not resolve domains. Indeed, this behavior follows the standards, by rejecting non-compliant DNS packets. Indeed, section 3.7 of RFC1034 says that the answer section of a DNS packet contains records that "directly answer the query". Alas, akadns.net, microsoft.com's nameservers, break the standards and sends out answers that are *not* direct answers to DNS queries in the answer section of a DNS packet. Instead, Microsoft's DNS nameservers put, in the answer section of their DNS replies, records that belong in the additional section, which is for "RRs which may be helpful in using the RRs in the other sections." (again, as per RFC1034 section 3.7). Well, since Microsoft.com is so popular, I have to change my code to not follow the standards so that microsoft.com may resolve. Which is exactly what I have done. Instead of rejecting the entire packet with the incorrect DNS record in the answer section of the DNS packet, we now skip past any answers which are not direct replies (or replies with the RR type changed to CNAME) to the question we asked. This fixes the microsoft.com problems. Since I have only done basic testing of this patch, and have not verified that there are security consequences because of this change, the only version of MaraDNS with this fix is the current daily snapshot, available here: http://www.maradns.org/download/1.2/snap/200606/maradns-Q.20060613.1.tar.bz2 I also have GPG sigs for this daily snapshot: http://www.maradns.org/download/1.2/snap/200606/ For people who are using MaraDNS and need microsoft.com to resolve *right now*, use the daily snapshot. I am going to fairly quickly make some more formal releases of MaraDNS with this patch applied, once I make sure there are no security or other consequences and perform some stress testing on the fix. - Sam Date: Wed, 14 Jun 2006 13:26:39 +0700 From: Roy Lanek To: list@NOSPAM.org Subject: Re: [MARA] Microsoft doesn't follow DNS standards > Well, since Microsoft.com is so popular, I have to > change my code to not follow the standards so that > microsoft.com may resolve. "[C]ourage is the first of human qualities because it is the quality which guarantees the others" Aristotle. > Since I have only done basic testing of this patch, and > have not verified that there are security consequences > because of this change, [...] The next "change" you will take it more relaxed and easy still. And so on (a' la Peano). Cheers, /Roy Lanek -- ######################## buruk muka cermin dibelah ##### . slackware ###### ugly face, the mirror is split ##### +-----linux ###### [blaming the wrong cause or creating a scapegoat] ######################## From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.09 released (microsoft.com fix) Date: Wed, 14 Jun 2006 10:51:13 +0000 (UTC) MaraDNS 1.2.09 is MaraDNS 1.2.08 with the microsoft.com fix which I have been talking about on the mailing list. I have spent the last few hours stress-testing the recursive resolver for the new 1.2.09 release, without seeing any memory leaks nor crashes. I have also carefully looked at the microsoft.com fix to make sure that there are no security consequences from incorporating this patch. The only possible security consequence is that MaraDNS now needs a little more CPU power to reject a packet with multiple spoofed answers in the answer section of a DNS reply. The 1.2.09 release is a development release; people are encouraged to download this release to help me test MaraDNS. It can be downloaded here: http://www.maradns.org/download/1.2/1.2.09/ Or here: http://sourceforge.net/projects/maradns - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.6 and 1.0.38 released Date: Fri, 16 Jun 2006 19:23:32 +0000 (UTC) MaraDNS 1.2.07.6 and 1.0.38 released. This is a backport of the microsoft.com fix to both the stable and legacy branches of MaraDNS. In addition, I have removed the raw á character from the maradns man page for the 1.2.07.6 release (this made the Debian linter upset). The 1.2.07.6 release is available here: http://www.maradns.org/download.html And here: http://sourceforge.net/project/showfiles.php?group_id=24033&package_id=16396&release_id=425299 The 1.0.38 release is available here: http://www.maradns.org/download/1.0/ As an aside, I am no longer making RPM files for the 1.0 legacy branch of MaraDNS unless there is considerable demand from the MaraDNS community. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.10 released (final pre-Mexico release) Date: Wed, 21 Jun 2006 09:47:08 +0000 (UTC) Since I am about to leave the country and will be on an extended road trip with limited access to the internet, I have released a development release of MaraDNS today, the four-year anniversary of the 1.0.00 release of MaraDNS (and the six-month anniversary of the 1.2.00 release). The changes are fairly minor, mainly consisting of documentation touch-ups addressing some minor Debian bugs. I have finally gotten the raw unicode á out of the maradns man page, for example. This will be my last release for a while barring some urgent security matter (not likely, considering MaraDNS' security history). It can be downloaded here: http://www.maradns.org/download/1.2/1.2.10/ Or here: http://sourceforge.net/projects/maradns - Sam From: "Gian Spicuzza" To: Sam Trenholme , list@NOSPAM.org Subject: Re: [MARA] MaraDNS 1.2.10 released (final pre-Mexico release) Date: Wed, 21 Jun 2006 11:48:20 -0500 Sam, Thanks for the heads up. Have a fun and safe trip! Don't drink the water ;-) -Gian > Since I am about to leave the country and will be on an extended road > trip with limited access to the internet, I have released a development > release of MaraDNS today, the four-year anniversary of the 1.0.00 release > of MaraDNS (and the six-month anniversary of the 1.2.00 release). > > The changes are fairly minor, mainly consisting of documentation > touch-ups addressing some minor Debian bugs. I have finally gotten > the raw unicode á out of the maradns man page, for example. > > This will be my last release for a while barring some urgent security > matter (not likely, considering MaraDNS' security history). > > It can be downloaded here: > > http://www.maradns.org/download/1.2/1.2.10/ > > Or here: > > http://sourceforge.net/projects/maradns > > - Sam > > > Warm Regards, Gian G. Spicuzza Co-Founder, GS Enterprises P: +1-401-419-4399 E: GianSpi@NOSPAM.org W: www.GSent.org h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; Date: Thu, 22 Jun 2006 15:29:34 -0300 From: Daniel To: list@NOSPAM.org Subject: Re: [MARA] MaraDNS 1.2.10 released (final pre-Mexico release) Buenas viaje! Daniel Zilli > Since I am about to leave the country and will be on an extended road > trip with limited access to the internet, I have released a development > release of MaraDNS today, the four-year anniversary of the 1.0.00 release > of MaraDNS (and the six-month anniversary of the 1.2.00 release). > > The changes are fairly minor, mainly consisting of documentation > touch-ups addressing some minor Debian bugs. I have finally gotten > the raw unicode á out of the maradns man page, for example. > > This will be my last release for a while barring some urgent security > matter (not likely, considering MaraDNS' security history). > > It can be downloaded here: > > http://www.maradns.org/download/1.2/1.2.10/ > > Or here: > > http://sourceforge.net/projects/maradns > > - Sam > > > From: Casey Bralla To: list@NOSPAM.org Subject: Server Won't Recurse Date: Mon, 26 Jun 2006 21:44:41 -0400 I'm sure that I am doing something very simple that is wrong, but can't figure out the problem. I was hoping someone could offer some assistance. I'm trying to setup an authoritative & recursive name server behind a NAT firewall. I own the domian, and have the registrar's records piointing to my server. I have been using posadis for the past year or so, but it started to give me trouble, and doesn't seem to be maintained much any more. Therefore, I'm trying to move to maradns. I've got maradns servering my domain just fine, but it won't recurse and send along queries for addresses outside my local network. For example: dig www.NerdWorld.org returns correct IP data (71.224.4.252) dig www.IBM.com returns a "not known" I've set the root_servers variables as: root_servers = {} root_servers["."] = "icann" and have verified that the icann.org IP list is accurate (at least the first couple). Posadis (when it wasn't otherwise crashing) would answer this query just fine. Can someone please point me where to look for more troubleshooting? Thanks! -- Casey Bralla Chief Nerd in Residence The NerdWorld Organisation http://www.NerdWorld.org From: Casey Bralla To: list@NOSPAM.org Subject: Re: Server Won't Recurse - Solved Date: Tue, 27 Jun 2006 19:46:41 -0400 I knew it had to be easy I had confused the "recursive_acl" parameter to mean the address to listen *on*, not to listen *from*. It all works fine now. On Monday 26 June 2006 21:44, Casey Bralla wrote: > I'm sure that I am doing something very simple that is wrong, but can't > figure out the problem. I was hoping someone could offer some assistance. > > I'm trying to setup an authoritative & recursive name server behind a NAT > firewall. I own the domian, and have the registrar's records piointing to > my server. I have been using posadis for the past year or so, but it > started to give me trouble, and doesn't seem to be maintained much any > more. Therefore, I'm trying to move to maradns. > > I've got maradns servering my domain just fine, but it won't recurse and > send along queries for addresses outside my local network. > > For example: > > dig www.NerdWorld.org returns correct IP data (71.224.4.252) > dig www.IBM.com returns a "not known" > > I've set the root_servers variables as: > root_servers = {} > root_servers["."] = "icann" > > and have verified that the icann.org IP list is accurate (at least the > first couple). > > Posadis (when it wasn't otherwise crashing) would answer this query just > fine. > > Can someone please point me where to look for more troubleshooting? > Thanks! -- Casey Bralla Chief Nerd in Residence The NerdWorld Organisation http://www.NerdWorld.org From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] I've finished my road trip Date: Tue, 11 Jul 2006 17:57:16 +0000 (UTC) Just letting everyone know that I finished my road trip (I'm now in Mexico), and that I will be able to semi-frequently address MaraDNS concerns. I'm also letting people know that the only support for MaraDNS 1.0 that I will provide is bugfix support; if you send me a "how do I" question and are still using 1.0, I'll ask you to upgrade to 1.2 or reply on the documentation supplied with 1.0 to resolve your problem. If you don't tell me which version of MaraDNS you're using and have a "how do I" question, I'll ask you which version of MaraDNS you're using (and, usually, will ask you for your mararc file and any relevant zone files) before answering your question. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.7 release (very minor bugfix) Date: Wed, 12 Jul 2006 22:15:45 +0000 (UTC) I have released MaraDNS 1.2.07.7 today. This is a very (and I mean very) minor bugfix release. Basically, I have backported the 1.2.10 fix with there being hi-bit characters in man pages to the stable branch. Basically, Perl is rather annoying. In order to set things up so Perl 5.8.0 can correctly have hi-bit characters, you have to use syntax that breaks Perl 5.8.8's handling of hi-bit characters. Personally, I feel that Perl's release process is very unprofessional; something as basic as hi-bit character support should not have its syntax changed in such a way that it is impossible to have the same script handle hi-bit characters with both Perl 5.8.0 and Perl 5.8.8. My workaround is to have the Perl script in question die if you try to run it with Perl 5.8.0; this result in me having to compile and install Perl 5.8.8 on my CentOS 3 system before I can build MaraDNS. Perl's a hack. I think a business is silly to have their enterprise depend on it. Python, on the other hand, is a lot more professional about not making changes which break scripts unless at least the minor version number changes. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Current work being done on MaraDNS Date: Thu, 13 Jul 2006 15:05:34 +0000 (UTC) Right now, I'm working on adding a number of obscure RR types to the CSV2 zone parser. An RR type is the name of a DNS record, such as "A", "MX", or "SRV". DNS has been around for over 23 years; in that time, a lot of weird RR types that no one uses have been proposed. So far, I've added most of the obscure RFC1035 RR types. This work can be seen here: http://www.maradns.org/download/1.2/snap/200607/ Disclaimer: These are "bleding edge" releases not guaranteed to compile, much less do anything useful. The plan is to eventually have BIND zone file support. This is an open source project: "plan" is very much the operative word here and I'm not making any promises. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.11 released (zone files now support many more RRs) Date: Tue, 18 Jul 2006 20:13:49 +0000 (UTC) I have just release MaraDNS 1.2.11. I have added support for a lot of obscure RRs in CSV2 zone files: HINFO, WKS, MD, MF, MB, MG, MINFO, MR, AFSDB, RP, X25, ISDN, RT, NSAP, NSAP-PTR, PX, GPOS, and LOC [1]. I have also made it so the email address in the SOA email field doesn't need an @ (you can use a '.' instead). Basically, with all of these RRs added to csv2 zone files, we're a lot closer to having BIND zone file support. I'm not sure how I'm going to split up the CSV2 parsing code to also support BIND zone files; I can either hack things up so that the same code has a "BIND zone file" and a "CSV2 zone file" mode, or I can just copy all of the code. The first solution seems better. Also, Vlatko Kosturjak from Croatia has kindly provided me a patch to add chkconfig support to MaraDNS's RPM spec file; alas, by the time I got the patch, the MaraDNS 1.2.11 packages were already built. 1.2.12's RPM spec file will have chkconfig support. Additionally, I have been told of a "quick and dirty" way to make any 32-bit .exe file a bona fide Windows service. The trick doesn't seem to work with MaraDNS 1.2.11, alas--but I may be able to make some changes to the source code of MaraDNS to make it work. If so, MaraDNS 1.2.12 will have this support. - Sam [1] OK, LOC is an RR that I have seen "in the wild"; all of the other RRs only seem to exist in dusty RFCs. From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.8 release (important bugfix) Date: Mon, 24 Jul 2006 03:24:53 +0000 (UTC) I have a new release of the stable branch of MaraDNS, 1.2.07.8, that fixes a fairly important memory leak. Basically, MaraDNS would leak about 300 bytes of memory every time someone asked for a PTR (reverse DNS lookup) record, the PTR pointed to a CNAME, and the CNAME did not point to a valid PTR record. Fairly rare, but 300 bytes leaked whenever it happened. I encourage all distributions to upgrade MaraDNS to 1.2.07.8 at their soonest convenience. This leak is also in the 1.0 code; I will release a 1.0.39 in the next few days with this memory leak fix backported. 1.2.07.8 also has some other bugfixes from the testing/development branch backported: * Backport of adding infomation about dangling CNAMEs to FAQ from testing branch (see Debian bug #373781) * Backport of explicit exit 0 added to MaraDNS start/stop script (Debian bug #374655) * Backport of 1.2.11 bugfix: We can now have email addresses without @ (using . instead) * Vlatko Kosturjak from Croatia has added chkconfig support to the RPM spec file. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.0.39 release (backport of 1.2.07.8 fix) Date: Mon, 24 Jul 2006 19:25:03 +0000 (UTC) First of all, I looked at older releases of MaraDNS and verified that this memory leak was introduced in the 1.0.33 and 1.1.50 releases of MaraDNS. Basically, when I fixed a compression error bug in those releases of MaraDNS, I accidently introduced a slow memory leak. The reason why the SQA process didn't catch this leak is because the stress test scripts don't make the kinds of queries that caused the leak. Sometimes bug fixes introduce their own bugs. Needless to say, I'm not going to make any changes to the recursive code until I make revisions to MaraDNS' entire SQA process. The SQA process needs an overhaul. Anyway, I have backported the fix to the 1.0 branch, and have released MaraDNS 1.0.39. People stillusing the 1.0 branch are encouraged to update to 1.0.39. It is available here: http://www.maradns.org/download.html - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.12.01 release (testing release) Date: Wed, 26 Jul 2006 19:11:09 +0000 (UTC) At this point, a csv2 zone file has all of the features that a RFC1035-compliant "master file" has, albeit in a slightly different syntax. Now that I have done this, I am releasing a maradns-1.2.12.01 release of MaraDNS. Basically, going from a BIND zone file to a MaraDNS csv2 zone file is now a matter of writing a good Python script. This is a testing release; the reason for the four-part numbering scheme is to remind myself not to add new features to MaraDNS until this release is well tested. Here is the change log: * Memory leak plugged: MaraDNS' resolver was leaking about 300 bytes whenever someone asked for a PTR that pointed to a CNAME that didn't point to a legitimate PTR. * Vlatko Kosturjak from Croatia has added chkconfig support to the RPM spec file. * Documentation on making MaraDNS a Win32 service added. * Truncation of records too long to fit in a 512-byte packet now done in a RFC2181-compliant manner. * Slash commands added to csv2 zone files: '/serial', which allows the serial for a zone file to be automatically updated whenever the zone file is edited; '/ttl', which allows the default TTL to be changed; '/origin', which allows the origin to be changed; '/opush' and '/opop' which allow the origin's values to be put on a stack; and '/read', which allows another file to be included in a zonefile. * Some tidying of the Csv2 parsing code to deallocate unneeded memory resources; this should lower MaraDNS memory usage when a large number of csv2 zone files exist. * Records stored in the authoritative half are now always marked "authoritative" in the DNS header; records not in a zone will simply not have NS records in the NS/AR section of the answer. * Download page revamped to be faster and easier to use. My future plans for MaraDNS: Write that Python script to convert to and from BIND zone files. Improve the SQA process so I can have automated regressions which cover most of MaraDNS' features. Add a FAQ about the importance of using dig's +norecurse option when troubleshooting NS delegation problems. Have read BIND zone file support. Have real Notify/IXFR/AXFR support. This list will probably take five years to do. In the meantime, there is 1.2.07.8 for most people, and 1.2.12.01 for testers. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] A new look at djbdns for 2006 Date: Sat, 5 Aug 2006 18:25:36 +0000 (UTC) Hello, everyone, I'm letting everyone know that, among other things, I'm working on some advocacy documents for MaraDNS. The only document that I have finished is the one that is critical of DjbDNS. I will include a draft version of the document here; if anyone feels it is inaccurate or has any other comments about the document, let me know. It is my goal to have this document point out the very real issues with djbdns without coming off as trolling nor posting flamebait. - Sam Here is the document: ------8<-----8<-----8<-----8<------8<-----8<-----8<-----8<----- It is very difficult for me to be critical of djbdns. Djbdns came out at a time when the only other viable name server was the very insecure BIND8. It allowed people who needed a DNS server to have a secure solution at a time when BIND had security patches released almost monthly. I myself have used it to keep installations I administered at the time secure. In addition, Dr. Bernstein, djbdns' author, has written a number of documents about keeping DNS secure which were very valuable during the design phase of MaraDNS, and have undoubtably improved MaraDNS' security. I have a good deal of respect for Dr. Bernstein's coding abilities. That said, djbdns has a number of issues which make it not practical to deploy on new installations. Djbdns has not changed one iota for over five years. In addition, it is not legal to distribute a changed version of djbdns. This is the number one problem with djbdns: Djbdns is *not* open source. Its license is not compatible with one fundamental pillar of open source: The right to distribute modified versions of a program. This is a very practical problem: There are high profile internet sites that djbdns' recursive resolver plain simply can not resolve. In order to make djbdns' recursive resolver resolve these sites, after downloading djbdns, you need to find the patch that fixes the broken recursive resolver, apply the patch, and hope the patch doesn't break anything. This isn't the only problem with djbdns' recursive resolver. Its list of root servers is out of date by five years; two root servers have changed since then. This makes the recursive server less reliable; fixing this requires changing the configuration by hand, or by applying yet another third-party patch. Installing djbdns is non-trivial; you need to download and install no less than three different packages. Djbdns will not compile on a modern Linux system; you need to find the secret incantation to make it compile. Compare this to MaraDNS, where installing is as simple as downloading one package and typing in "make; make install". Once djbdns is installed, you will find some directories in the root of your filesystem that weren't there before. This breaks UNIX and Linux standards on how the filesystem can be organized. All of these issues could be fixed if Dr. Bernstein had release djbdns under an open-source compatible license. I understand that such modified versions of djbdns may introduce security problems that Dr. Bernstein's code does not have. The solution is simple: Distribute djbdns under a LaTeX license, which is open source compatible and would require modified versions of djbdns to be called something besides djbdns. There are a number of programs which are still being actively maintained long after the original author stopped contributing to the project. The fvwm project is still thriving even though Rob Nation stopped working on the project over 12 years ago. When Atheos development stopped, its users forked the code and started the Syllable project. Both Perl and Python are no longer being actively worked on by their primary developers; most, if not all, code changes now come from other people. djbdns has a good security record; however, it is not the only dns server with good security. No stable version of MaraDNS on a non-Linux system has ever had an exploitable security problem. The one and only denial-of-service problem was caused by Linux's broken TCP/IP stack and not by MaraDNS, and has long since been fixed. Djbdns users are not the most polite people out there. The very first email I got when I publically announced MaraDNS was a very rude message from a djbdns advocate who told me it wasn't worth my time to write a DNS server, since djbdns works fine. I replied that, yes djbdns is an excellent name server, but is under a restrictive license, and that I would not develop MaraDNS had djbdns been released under a more open license. He knew I was right, and didn't reply back. I'm not the only person to be treated rudely by djbdns' users. When one person pointed out yet another bug with djbdns' recursive resolver, he was told that people who have this problem that it was "their own fault". In more detail, if someone has a domain with an provider and, for whatever reason, wants to change providers with their current provider's help, djbdns' cache will incorrectly point to the old provider until the cache program is restarted. Dr. Bernstein, as far as I can tell, has no intention to fix this issue, nor any other issue with djbdns. He acts too arrogantly to acknowledge that his programs have bugs, much less fix his bugs--I have never seen him admit his program has a bug. This goes back to the djbdns license; the person who blamed the user for a djbdns problem really had no other choice. He could not patch djbdns and distribute a modified djbdns to fix the issue. While he could made a patch available, the number of djbdns users who would actually apply the patch is next-to-zero. Since Dr. Bernstein has abadoned djbdns, there is no system in place to allow people to fix issues with djbdns. Djbdns was the best DNS option available when it came out. That was over five years ago. Since then, the internet has changed and djbdns has not kept up. Now that BIND9, MaraDNS, and PowerDNS have a proven security record, and are both under an open-source license and being actively maintained, there is no longer any reason to use djbdns. From: Remco =?utf-8?q?R=C4=B3nders?= To: list@NOSPAM.org Subject: Re: [MARA] A new look at djbdns for 2006 Date: Sun, 6 Aug 2006 10:05:31 +0200 --nextPart230994831.vTB9HKRqaU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Op Saturday 05 August 2006 20:25, schreef Sam Trenholme: > Hello, everyone, > > I'm letting everyone know that, among other things, I'm working on > some advocacy documents for MaraDNS. The only document that I have > finished is the one that is critical of DjbDNS. I will include a draft > version of the document here; if anyone feels it is inaccurate or > has any other comments about the document, let me know. > > It is my goal to have this document point out the very real issues with > djbdns without coming off as trolling nor posting flamebait. > > - Sam Hi Sam, The document seems good to me. That said, it will draw reactions sooner or= =20 later, no matter how you word things as some will always feel attacked when= =20 you have (valid) criticism on their $package_of_choice. That said, I have a few minor comments to make: > Djbdns users are not the most polite people out there. The very first > email I got when I publically announced MaraDNS was a very rude message > from a djbdns advocate who told me it wasn't worth my time to write a > DNS server, since djbdns works fine. I replied that, yes djbdns is an > excellent name server, but is under a restrictive license, and that I > would not develop MaraDNS had djbdns been released under a more open > license. He knew I was right, and didn't reply back. > > I'm not the only person to be treated rudely by djbdns' users. When one > person pointed out yet another bug with djbdns' recursive resolver, he > was told that people who have this problem that it was "their own fault". > In more detail, if someone has a domain with an provider and, for whatever > reason, wants to change providers with their current provider's help, > djbdns' cache will incorrectly point to the old provider until the cache > program is restarted. I don't think the djbdns user community should be painted this black. Yes,= =20 some of them might be rude, just as some on the bind list can be a bit cros= s=20 at times. I think this is one of the few times where you should be happy th= at=20 maradns doesn't have as big an uptake yet as bind or djbdns as there will=20 always be rude people. The more people you get together, the bigger the odd= s=20 you'll have a few rude ones amongst them; And they tend to be the more voca= l=20 ones too! > This goes back to the djbdns license; the person who blamed the user > for a djbdns problem really had no other choice. He could not patch > djbdns and distribute a modified djbdns to fix the issue. Perhaps you can substantiate this a bit more or rework it some more into th= e=20 previous paragraphs, maybe turn around the order? State that because the=20 license is like this and that, that at times people on the userlist get a b= it=20 short with others when the 10th person in a month shows up with a question= =20 that could have been fixed in the software if only ... > Now that BIND9, MaraDNS, and PowerDNS have a proven > security record, and are both under an open-source license and being > actively maintained, there is no longer any reason to use djbdns. You name three, but refer to them as 'both'. =3D=3D=3D I think it's great that you are working on some advocay documents. As you k= now=20 I really like mara, and at times have wondered why it didn't receive more=20 uptake than it has. Over the years you have added quite a few features and= =20 mara has really gone quite some lenghts from being a 'simple' nameserver to= =20 one that comes with a wide variety of features and uses. Thank you for your work on it! Kind regards, Remco --nextPart230994831.vTB9HKRqaU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE1aLpP0wYCuTizasRAlq6AJ44UtmnArHYpK8keO8H6Il/VMW0aQCdEamJ FwUIunG3DCFwwcLWTVd0Oqg= =VpGU -----END PGP SIGNATURE----- --nextPart230994831.vTB9HKRqaU-- Date: Sun, 06 Aug 2006 10:31:06 +0200 From: Peter Randow To: list@NOSPAM.org Subject: Re: [MARA] A new look at djbdns for 2006 Hi Sam Trenholme softly whispered: * No stable version of MaraDNS on a non-Linux * system has ever had an exploitable security problem. Is this a typo? Or were there especially on Linux systems security problems? Greetings Peter From: Remco =?utf-8?q?R=C4=B3nders?= To: list@NOSPAM.org Subject: Re: [MARA] A new look at djbdns for 2006 Date: Sun, 6 Aug 2006 10:46:06 +0200 --nextPart2492155.IRYllqIGAc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Op Sunday 06 August 2006 10:31, schreef Peter Randow: > * No stable version of MaraDNS on a non-Linux > * system has ever had an exploitable security problem. > > Is this a typo? > Or were there especially on Linux systems security problems? Peter, There once was a problem that only affected systems running Linux. See http://www.maradns.org/security.html for all known security issues that= =20 have affected / impacted mara over time. The one Sam referred to is #3, and= =20 could cause mara to freeze.=20 See also=20 http://marc.10east.com/?l=3Dmaradns-list&m=3D111543365524290&w=3D2 and http://marc.10east.com/?l=3Dmaradns-list&m=3D111543639932692&w=3D2 for a little more info on this. Sincerely, Remco R=C4=B3nders --nextPart2492155.IRYllqIGAc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE1axVP0wYCuTizasRAovoAJ4sb12I+yk553b5mFlrH+eSV8y2dACdEhS5 gJYp27xdy4KAyDGZpF0zb3A= =hAWQ -----END PGP SIGNATURE----- --nextPart2492155.IRYllqIGAc-- From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Another advocacy document written Date: Sun, 6 Aug 2006 17:27:32 +0000 (UTC) First of all, I would like to thank Remmy and everyone else for their feedback on my djbdns advocacy page. I will incorporate this feedback in to the document. As for MaraDNS' security: Yes, there was an issue caused by the Linux kernel which allowed a malformed packet to freeze MaraDNS. This is the only real security issue that a stable release of MaraDNS has had; there have also been academic attacks like "you may be able to obtain the key used for the query id/port number if you send 20,000,000 special packets" and what not which I have also addressed. Second of all, I wrote a similar document for BIND yesterday, which I will include at the end of this message. Third of all, I know I'm behind on personal mail. I will catch as soon as my job search calms down. - Sam Here is the document: ------8<-----8<-----8<-----8<------8<-----8<-----8<-----8<----- BIND9 is the emacs of DNS servers: It includes everything but the kitchen sink. This results in a full-featured DNS server that has about 5,000 features you will never use. This results in BIND being a very large application. On my system, a stripped BIND 9.2.6 binary is some 1,117,348 bytes in size. The maradns binary is only 150,432 bytes in size. The zoneserver binary, if needed, is only 107,360 bytes in size--resulting in a combined size of 257,792 bytes. This is a fraction of the size of BIND, making MaraDNS more suitable for embedded applications or on systems with limited resources (such as heavily loaded web servers). BIND's configuration is somewhat cryptic. For example, here a BIND setup that uses a custom root server; this shell scipt will set up all the files needed to start up BIND9 and run named in the current directory: cat > named.conf << EOF options { directory "$( pwd )"; pid-file "named.pid"; allow-query { 127.0.0.1/8; }; }; zone "." { type hint; file "root.hint"; }; EOF cat > root.hint << EOF \$TTL 86400 . IN NS a.root.bogus. a.root.bogus. IN A 127.0.3.1 EOF chown root:root . named -c named.conf Note that this basic configuration needs two different files with two different syntaxes. Compare this to MaraDNS, which needs just one simple four-line file: cat > mararc << EOF chroot_dir = "$( pwd )" ipv4_bind_addresses = "127.0.0.1" recursive_acl = "127.0.0.1/8" root_servers["."] = "127.0.3.1" EOF maradns -f mararc One key difference between this simple MaraDNS configuration and the corresponding simplified named configuration is that the named server will run as root with full access to the filesystem; the corresponding simple MaraDNS confiuration will run as "nobody" in a limited-access chroot() environment. While it is possible to run BIND as an unprivileged user in a chroot() environment, this configuration is non-trivial and not fully described in BIND's documentation. Indeed, BIND9 has had one remotely exploitable buffer overflow. Basically, older versions of BIND9 linked to the OpenSSL library, which had the offending buffer overflow. This is why MaraDNS has a strong "not invented here" policy; the only external libraries that MaraDNS uses are the libc library and the pthreads library. The reason for this is to minimize security problems that external libraries may cause--a problem that bit BIND9. BIND, to its credit, does have a number of features which I haven't yet implemented in MaraDNS. BIND supports standard RFC-compliant zone files. While MaraDNS' csv2 zone file format is mostly BIND-like, there are differences that make the two zone files incompatible. I plan on writing a converter in the near future and eventually having full RFC zone file support. BIND, of course, also has full support for being a DNS slave, including NOTIFY and IXFR support--features which I may eventually add to MaraDNS. In conclusion, while BIND9 has better RFC compliance and more features, it is a far bigger program that is more difficult to configure than MaraDNS. It is a bigger binary that uses up more memory than MaraDNS. Its security history is not as good as MaraDNS' security history. The two DNS servers have different compromises between code size, features, ease of use, and security. Date: Sun, 06 Aug 2006 12:55:45 -0700 From: RC Subject: Re: [MARA] A new look at djbdns for 2006 To: list@NOSPAM.org On Sat, 5 Aug 2006 18:25:36 +0000 (UTC) Sam Trenholme wrote: > This is a very practical problem: There are high profile internet > sites that djbdns' recursive resolver plain simply can not resolve. "plain simply" Choose one. From: Sam Trenholme To: list@NOSPAM.org Subject: Re: [MARA] A new look at djbdns for 2006 Date: Mon, 7 Aug 2006 15:31:49 +0000 (UTC) >> This is a very practical problem: There are high profile internet >> sites that djbdns' recursive resolver plain simply can not resolve. > Choose one. This last January, www.edmunds.com and www.infiniti.com. They may or may not work today; djbdns certainly hasn't fixed the issue which caused the problem. Reference: http://marc.theaimsgroup.com/?l=djbdns&m=113733374006571 - Sam P.S. And, yes, I'll be nicer to the djbdns community when the final version of the advocacy document is finished. From: Remco =?utf-8?q?R=C4=B3nders?= To: list@NOSPAM.org Subject: Re: [MARA] Another advocacy document written Date: Mon, 7 Aug 2006 18:42:04 +0200 --nextPart1567185.MDQdGA41V5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sam, Some small comments on your 2nd text: > This results in a full-featured DNS server that has > about 5,000 features you will never use. > > This results in BIND being a very large application. =20 One "this results" too many, it doesn't sound good when read out loud, so y= ou=20 might want to rephrase either one of them. > BIND, to its credit, does have a number of features which I haven't > yet implemented in MaraDNS. BIND supports standard RFC-compliant zone > files. While MaraDNS' csv2 zone file format is mostly BIND-like, there > are differences that make the two zone files incompatible. I plan on > writing a converter in the near future and eventually having full RFC > zone file support. BIND, of course, also has full support for being > a DNS slave, including NOTIFY and IXFR support--features which I may > eventually add to MaraDNS. > > In conclusion, while BIND9 has better RFC compliance and more features, What I find missing in your text, and that could quite well be because I am= =20 mistaken or that you disagree on this, is the reason that BIND is more RFC= =20 compliant than Mara is and has all these exotic features. Could it be becau= se=20 there is such a tight link / overlap between the people who write bind and= =20 those who write (some of) the RFC's? I remember reading criticisms on thing= s=20 being made a standard that only served as a marginally useful feature for=20 bind servers. Or, on the other hand, things not being made into a standard= =20 because it didn't fit into the way that the bind codebase is organised? I=20 don't have any links to any of that at hand here, so it's not impossible th= at=20 I might have a wrong picture of all this, but what's your take on this? Other than that, the text reads fine to me and seems to address some good=20 points. Kind regards, Remco --nextPart1567185.MDQdGA41V5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE1216P0wYCuTizasRAvVrAJwKQ13S5UopmBSivl1WW10DYe4lsgCgrYwn ElCOixKSZXbzc+ggT0inzBg= =7+8O -----END PGP SIGNATURE----- --nextPart1567185.MDQdGA41V5-- Date: Tue, 08 Aug 2006 00:44:01 -0700 From: RC Subject: Re: [MARA] A new look at djbdns for 2006 To: list@NOSPAM.org On Mon, 7 Aug 2006 15:31:49 +0000 (UTC) Sam Trenholme wrote: > > Choose one. > > This last January, www.edmunds.com and www.infiniti.com. They may or > may not work today; djbdns certainly hasn't fixed the issue which > caused the problem. I wasn't asking for examples, actually, I was just trying to offer a grammar correction. "plain simply" is redundant repetitious reiterating, if you get my drift gist. And now I've spent WAY too much time on the issue... Date: Tue, 8 Aug 2006 09:54:27 +0200 (CEST) Subject: Re: [MARA] A new look at djbdns for 2006 From: "Remco Rijnders" To: list@NOSPAM.org > I wasn't asking for examples, actually, I was just trying to offer a > grammar correction. "plain simply" is redundant repetitious > reiterating, if you get my drift gist. > > And now I've spent WAY too much time on the issue... Ah well, I think the inclusion of these examples and the relevant links to the mailinglists do make a useful addition to Sam's text though, so it's a good amendment none the less :) (As was your grammar fix) Kind regards, Remco From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.12.02 release (stable release) Date: Mon, 14 Aug 2006 20:52:04 +0000 (UTC) I have just released MaraDNS 1.2.12.02, which is a stable release of MaraDNS that is suitable for including with distributions. I have done a lot of testing in preparing this release. The most notable testing is that I finally have run MaraDNS through the very useful Valgrind tool (http://valgrind.org) Valgrind found only one error in the code: There was an off-by-one error in the ipv6 address parsing code. Fortunatly, MaraDNS' string library has measures in place to protect against these kinds of errors; the error was in no way exploitable. There were also a number of memory leaks, none of which were critical. A critical memory leak is one that happens while MaraDNS is serving DNS records, since the leak can potentially leak memory again and again until memory runs out. All of the leaks found by Valgrind are ones that just make MaraDNS use more memory than should be used while loading zone files. With one notable exception, I plugged all of these leaks for the 1.2.12.02 release. The one notable exception is one where I will have to make some fairly significant changes to the recursive code to plug; I will work on this leak in the up-and-coming post-1.2.12 branch of MaraDNS. I have also done a lot of DNS stress testing, both "dry" offline testing and real-world online testing. No memory leaks nor crashes were found. Daniel Zilli has also contributed a shell script to help people configure MaraDNS. A number of other bugs were fixed in the 1.2.12.02 release; details are in the changelog: http://www.maradns.org/changelog.html Now I have to decide whether it's more important to write the Bind zone file conversion Python script, or plug the one last leak that Valgrind reports. The advantage of writing the Python script first is that I don't have to maintain two branches of MaraDNS, since it doesn't have the potential make the C code any less stable. If people are a little reluctant to jump from 1.2.07 to 1.2.12, I can make a 1.2.07.9 release available which incorporates most of the 1.2.12.02 bugfixes in to the 1.2.07 branch. Let me know. - Sam Date: Thu, 17 Aug 2006 10:20:52 -0400 To: list@NOSPAM.org Subject: Re: [MARA] Another advocacy document written From: Rich Felker On Mon, Aug 07, 2006 at 06:42:04PM +0200, Remco Rijnders wrote: > What I find missing in your text, and that could quite well be because I am > mistaken or that you disagree on this, is the reason that BIND is more RFC > compliant than Mara is and has all these exotic features. Could it be because > there is such a tight link / overlap between the people who write bind and > those who write (some of) the RFC's? I agree that this is probably the reason. Any standard based on a single implementation (as opposed to the implementation being based on a standard, or the standard being based on the common features of a multitude of existing implementations) is automatically suspect. Rich From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS: Volunteers needed Date: Wed, 23 Aug 2006 17:33:00 +0000 (UTC) Hello, everyone, Someone sent me an email pointing out that MaraDSN no longer has French documtation. The reason why I have dropped the French documentation is because it was out of date--the documentation was for MaraDNS 1.0 and a lot of new features have been added to 1.2 that I would like to see French-speaking users take advantage of. At times, I do remove older user-contributed material. My rule is that I remove material that hasn't been updated for over two years and hasn't been updated since that last major release of MaraDNS. I, so far, have removed two items that were in MaraDNS 1.0 in the 1.2 tree: * The maragen m4 macros. I will reinstates these if they ever get updated to make csv2 zone files. * The French documentation. Hasn't been updated since before the 1.0 release. If people want to see MaraDNS documented in French, download the last 1.2.07 or 1.0 release of MaraDNS and update the documentation to be current with 1.2. The disadvantage of an open-source project is that I can't spend thousands of dollars getting all of the translated documents updated with each new release of MaraDNS. The advantage is that you don't have to indirectly pay for said translation. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.4 released (NS delegation fixed) Date: Tue, 23 May 2006 08:12:45 +0000 (UTC) I have just released MaraDNS 1.2.07.4. This releases has one major fix: * I broke NS delegation sometime during the 1.1 development cycle and failed to test this during the testing cycle. I was playing around with MaraDNS today and realized that NS delegation was broken and fixed it. NS delegation is when a DNS server says "I don't have the record for joe.foo.example.com, but the name server for foo.example.com is ns.foo.example.com with the IP 10.1.2.3". This used to be a lot more common, but is fairly rare in these days where people will just register a new domain name instead of having a host have a name besides "www.sillynamehere.com" [1]. I also have some other minor updates: There were some minor bugs with the mararc parser which I have fixed. I have updated the documentation (minor tweaks to the MaraDNS man page; made changes to the webpage so that it validates; etc). The files are available here: http://www.maradns.org/download.html And here: http://sourceforge.net/projects/maradns - Sam [1] Hey, no one has sillynamehere.com yet. Go figure. From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Minor correction on NS delegation bug Date: Wed, 24 May 2006 05:28:13 +0000 (UTC) >I broke NS delegation sometime during the 1.1 development cycle and failed >to test this during the testing cycle. Actually, this first was broken in MaraDNS 1.2.06, when I added the FQDN4 record. NS delegation was never broken in the 1.2.03 branch. Note to self: Have a fairly extensive regression before releaseing a stable upgrade of MaraDNS. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.5 released (star records fixed) Date: Mon, 29 May 2006 09:06:45 +0000 (UTC) I have just released MaraDNS 1.2.07.5. This releases has one major fix: * Star records now work with the ANY query. Unlike the NS delegation fix, ANY queries have never been quite right until 1.2.07.5; the 1.0 branch did not correctly handle ANY queries, but instead just returned A and MX records (and optionally NS and SOA records). The 1.2 branch returns all records attached to a given name, but I forgot to get this to work with star records until today's 1.2.07.5 release. As an aside, star records can potentially cause a DNS packet to be over 512 bytes in length; MaraDNS can also serve longer packets over TCP, but this requires a special setup, described here: http://www.maradns.org/tutorial/dnstcp.html The files are available here: http://www.maradns.org/download.html And here: http://sourceforge.net/projects/maradns - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS.org is down; use sourceforge to download instead Date: Mon, 5 Jun 2006 00:54:02 +0000 (UTC) I'm aware that MaraDNS.org is currently down; people who need to download MaraDNS in the meantime can use http://sourceforge.net/projects/maradns to download MaraDNS files. Here is the GPG sig for maradns-1.2.07.5.tar.gz: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBEeqm3C+jWrh5h/KYRApOJAKCP/zNdsIjJ5ynvQk0bTKPNoj4xyACbBgXW XnSgV6+VqgKxfu7h4nZ2j4s= =VRpK -----END PGP SIGNATURE----- And the one for maradns-1-2-07-5-win32.zip: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBEeqm3C+jWrh5h/KYRApOJAKCP/zNdsIjJ5ynvQk0bTKPNoj4xyACbBgXW XnSgV6+VqgKxfu7h4nZ2j4s= =VRpK -----END PGP SIGNATURE----- - Sam From: Remco Rijnders To: list@NOSPAM.org Subject: Re: [MARA] MaraDNS.org is down; use sourceforge to download instead Date: Mon, 5 Jun 2006 04:47:20 +0200 --nextPart1517343.xFSqSbNeg4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Op Monday 05 June 2006 02:54, schreef Sam Trenholme: > I'm aware that MaraDNS.org is currently down; people who need to download > MaraDNS in the meantime can use http://sourceforge.net/projects/maradns to > download MaraDNS files. The website www.maradns.org should be back up again. My apologies for any=20 inconvenience experienced during the downtime. Remco --nextPart1517343.xFSqSbNeg4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEg5tEP0wYCuTizasRAl7cAKC2MIzGiYE8xA2Ua/odV5RGMB8WggCfZPh6 RevBjoAP8NJwQQqZdsO/r68= =zW// -----END PGP SIGNATURE----- --nextPart1517343.xFSqSbNeg4-- From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS web page back up again Date: Mon, 5 Jun 2006 04:25:42 +0000 (UTC) The MaraDNS web page is up again within 30 minutes of me informing Remco that it was down. Thanks, Remco, for the prompt response! - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.08 released (development release) Date: Sun, 11 Jun 2006 09:14:17 +0000 (UTC) There is a new development-only release of MaraDNS...MaraDNS 1.2.08. This is not a stable release. This is a devlopment release because I have implemented some minor new features which may introduce new bugs, such as the time I broke NS delegation in MaraDNS 1.2.06. The first new feature I have implemented are SPF records. SPF, a.k.a. "Sender Policy Framework" is a way of using DNS to make it harder to forge email. SPF can use TXT records, but RFC4408 also has a SPF record (which is identical to a TXT record except for its numeric record type) which MaraDNS now fully supports. Now, whether SPF is a good thing or not is another discussion. I personally prefer Yahoo's domain keys, since Yahoo's solution doesn't have SPF's problem with bouncing email sent through a mail forwarder that doesn't change the MAIL FROM value. Yes, it would be nice if SMTP servers always changed the MAIL FROM when forwarding email, but if we're going to fantasize, I can think of some far more pleasant fantasies that don't involve so much technology. The other feature I have added is the retry_cycles mararc variable, which lets the DNS admin configure how many times MaraDNS tries contacting all of the DNS servers to resolve a given name before giving up. The default value for this is two; the hard-coded value for this in pre-1.2.08 releases of MaraDNS is one. I think this will make MaraDNS a little more reliable and a better recursive DNS resolver. I have done some basic testing and documentation: Yes, SPF records work exactly as expected. I also ran MaraDNS through about two hours of stress-testing and no crashes nor freeze-ups showed up. Like, I said, this is a development release. Use at your own risk, as always. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Some weirdness with www.microsoft.com Date: Tue, 13 Jun 2006 08:19:58 +0000 (UTC) I'm got a couple of reports that MaraDNS is having some trouble with resolving www.microsoft.com. I can see these issues myself and I'll see if there is something I can do to improve things. Until I have a real fix, one can minimize the microsoft.com problems by increasing the minimum TTL (time a record is in the cache) to one hour by adding the following lines to one's mararc: min_ttl = 3600 min_ttl_cname = 3600 Basically, here is what is going on when trying to resolve www.microsoft.com: * One asks for www.microsoft.com from a root server * The root server refers you to a .com server * The .com server refers you to a microsoft.com DNS server * The microsoft.com DNS server tells you that www.microsoft.com is a CNAME record pointing to toggle.www.ms.akadns.net. * We then have to ask the root servers about toggle.www.ms.akadns.net * The root servers refer us to a .net server * This .net server refers you to the akadns.net servers * The akadns.net servers tells us that toggle.www.ms.akadns.net is a CNAME for g.www.ms.akadns.net, that g.www.ms.akadns.net is a CNAME for lb1.www.ms.akadns.net, and that lb1.www.ms.akadns.net has about 6 IP address. This is all in a single DNS packet. * However, I believe MaraDNS doesn't take this all at once so she asks about g.www.ms.akadns.net, then asks for lb1.www.ms.akadns.net, then finally gets an answer. This can break down. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Microsoft doesn't follow DNS standards Date: Wed, 14 Jun 2006 04:26:49 +0000 (UTC) I found out why MaraDNS was having such a hard time resolving microsoft.com, and have fixed the issue. The MaraDNS resolver has always rejected any DNS packet with an answer (in the answer section) that is not a direct (or direct-made-CNAME) answer to our question. Almost all DNS traffic acts this way. This behavior has been in use for over three years without anyone telling me that MaraDNS does not resolve domains. Indeed, this behavior follows the standards, by rejecting non-compliant DNS packets. Indeed, section 3.7 of RFC1034 says that the answer section of a DNS packet contains records that "directly answer the query". Alas, akadns.net, microsoft.com's nameservers, break the standards and sends out answers that are *not* direct answers to DNS queries in the answer section of a DNS packet. Instead, Microsoft's DNS nameservers put, in the answer section of their DNS replies, records that belong in the additional section, which is for "RRs which may be helpful in using the RRs in the other sections." (again, as per RFC1034 section 3.7). Well, since Microsoft.com is so popular, I have to change my code to not follow the standards so that microsoft.com may resolve. Which is exactly what I have done. Instead of rejecting the entire packet with the incorrect DNS record in the answer section of the DNS packet, we now skip past any answers which are not direct replies (or replies with the RR type changed to CNAME) to the question we asked. This fixes the microsoft.com problems. Since I have only done basic testing of this patch, and have not verified that there are security consequences because of this change, the only version of MaraDNS with this fix is the current daily snapshot, available here: http://www.maradns.org/download/1.2/snap/200606/maradns-Q.20060613.1.tar.bz2 I also have GPG sigs for this daily snapshot: http://www.maradns.org/download/1.2/snap/200606/ For people who are using MaraDNS and need microsoft.com to resolve *right now*, use the daily snapshot. I am going to fairly quickly make some more formal releases of MaraDNS with this patch applied, once I make sure there are no security or other consequences and perform some stress testing on the fix. - Sam Date: Wed, 14 Jun 2006 13:26:39 +0700 From: Roy Lanek To: list@NOSPAM.org Subject: Re: [MARA] Microsoft doesn't follow DNS standards > Well, since Microsoft.com is so popular, I have to > change my code to not follow the standards so that > microsoft.com may resolve. "[C]ourage is the first of human qualities because it is the quality which guarantees the others" Aristotle. > Since I have only done basic testing of this patch, and > have not verified that there are security consequences > because of this change, [...] The next "change" you will take it more relaxed and easy still. And so on (a' la Peano). Cheers, /Roy Lanek -- ######################## buruk muka cermin dibelah ##### . slackware ###### ugly face, the mirror is split ##### +-----linux ###### [blaming the wrong cause or creating a scapegoat] ######################## From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.09 released (microsoft.com fix) Date: Wed, 14 Jun 2006 10:51:13 +0000 (UTC) MaraDNS 1.2.09 is MaraDNS 1.2.08 with the microsoft.com fix which I have been talking about on the mailing list. I have spent the last few hours stress-testing the recursive resolver for the new 1.2.09 release, without seeing any memory leaks nor crashes. I have also carefully looked at the microsoft.com fix to make sure that there are no security consequences from incorporating this patch. The only possible security consequence is that MaraDNS now needs a little more CPU power to reject a packet with multiple spoofed answers in the answer section of a DNS reply. The 1.2.09 release is a development release; people are encouraged to download this release to help me test MaraDNS. It can be downloaded here: http://www.maradns.org/download/1.2/1.2.09/ Or here: http://sourceforge.net/projects/maradns - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.6 and 1.0.38 released Date: Fri, 16 Jun 2006 19:23:32 +0000 (UTC) MaraDNS 1.2.07.6 and 1.0.38 released. This is a backport of the microsoft.com fix to both the stable and legacy branches of MaraDNS. In addition, I have removed the raw á character from the maradns man page for the 1.2.07.6 release (this made the Debian linter upset). The 1.2.07.6 release is available here: http://www.maradns.org/download.html And here: http://sourceforge.net/project/showfiles.php?group_id=24033&package_id=16396&release_id=425299 The 1.0.38 release is available here: http://www.maradns.org/download/1.0/ As an aside, I am no longer making RPM files for the 1.0 legacy branch of MaraDNS unless there is considerable demand from the MaraDNS community. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.10 released (final pre-Mexico release) Date: Wed, 21 Jun 2006 09:47:08 +0000 (UTC) Since I am about to leave the country and will be on an extended road trip with limited access to the internet, I have released a development release of MaraDNS today, the four-year anniversary of the 1.0.00 release of MaraDNS (and the six-month anniversary of the 1.2.00 release). The changes are fairly minor, mainly consisting of documentation touch-ups addressing some minor Debian bugs. I have finally gotten the raw unicode á out of the maradns man page, for example. This will be my last release for a while barring some urgent security matter (not likely, considering MaraDNS' security history). It can be downloaded here: http://www.maradns.org/download/1.2/1.2.10/ Or here: http://sourceforge.net/projects/maradns - Sam From: "Gian Spicuzza" To: Sam Trenholme , list@NOSPAM.org Subject: Re: [MARA] MaraDNS 1.2.10 released (final pre-Mexico release) Date: Wed, 21 Jun 2006 11:48:20 -0500 Sam, Thanks for the heads up. Have a fun and safe trip! Don't drink the water ;-) -Gian > Since I am about to leave the country and will be on an extended road > trip with limited access to the internet, I have released a development > release of MaraDNS today, the four-year anniversary of the 1.0.00 release > of MaraDNS (and the six-month anniversary of the 1.2.00 release). > > The changes are fairly minor, mainly consisting of documentation > touch-ups addressing some minor Debian bugs. I have finally gotten > the raw unicode á out of the maradns man page, for example. > > This will be my last release for a while barring some urgent security > matter (not likely, considering MaraDNS' security history). > > It can be downloaded here: > > http://www.maradns.org/download/1.2/1.2.10/ > > Or here: > > http://sourceforge.net/projects/maradns > > - Sam > > > Warm Regards, Gian G. Spicuzza Co-Founder, GS Enterprises P: +1-401-419-4399 E: GianSpi@NOSPAM.org W: www.GSent.org h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; Date: Thu, 22 Jun 2006 15:29:34 -0300 From: Daniel To: list@NOSPAM.org Subject: Re: [MARA] MaraDNS 1.2.10 released (final pre-Mexico release) Buenas viaje! Daniel Zilli > Since I am about to leave the country and will be on an extended road > trip with limited access to the internet, I have released a development > release of MaraDNS today, the four-year anniversary of the 1.0.00 release > of MaraDNS (and the six-month anniversary of the 1.2.00 release). > > The changes are fairly minor, mainly consisting of documentation > touch-ups addressing some minor Debian bugs. I have finally gotten > the raw unicode á out of the maradns man page, for example. > > This will be my last release for a while barring some urgent security > matter (not likely, considering MaraDNS' security history). > > It can be downloaded here: > > http://www.maradns.org/download/1.2/1.2.10/ > > Or here: > > http://sourceforge.net/projects/maradns > > - Sam > > > From: Casey Bralla To: list@NOSPAM.org Subject: Server Won't Recurse Date: Mon, 26 Jun 2006 21:44:41 -0400 I'm sure that I am doing something very simple that is wrong, but can't figure out the problem. I was hoping someone could offer some assistance. I'm trying to setup an authoritative & recursive name server behind a NAT firewall. I own the domian, and have the registrar's records piointing to my server. I have been using posadis for the past year or so, but it started to give me trouble, and doesn't seem to be maintained much any more. Therefore, I'm trying to move to maradns. I've got maradns servering my domain just fine, but it won't recurse and send along queries for addresses outside my local network. For example: dig www.NerdWorld.org returns correct IP data (71.224.4.252) dig www.IBM.com returns a "not known" I've set the root_servers variables as: root_servers = {} root_servers["."] = "icann" and have verified that the icann.org IP list is accurate (at least the first couple). Posadis (when it wasn't otherwise crashing) would answer this query just fine. Can someone please point me where to look for more troubleshooting? Thanks! -- Casey Bralla Chief Nerd in Residence The NerdWorld Organisation http://www.NerdWorld.org From: Casey Bralla To: list@NOSPAM.org Subject: Re: Server Won't Recurse - Solved Date: Tue, 27 Jun 2006 19:46:41 -0400 I knew it had to be easy I had confused the "recursive_acl" parameter to mean the address to listen *on*, not to listen *from*. It all works fine now. On Monday 26 June 2006 21:44, Casey Bralla wrote: > I'm sure that I am doing something very simple that is wrong, but can't > figure out the problem. I was hoping someone could offer some assistance. > > I'm trying to setup an authoritative & recursive name server behind a NAT > firewall. I own the domian, and have the registrar's records piointing to > my server. I have been using posadis for the past year or so, but it > started to give me trouble, and doesn't seem to be maintained much any > more. Therefore, I'm trying to move to maradns. > > I've got maradns servering my domain just fine, but it won't recurse and > send along queries for addresses outside my local network. > > For example: > > dig www.NerdWorld.org returns correct IP data (71.224.4.252) > dig www.IBM.com returns a "not known" > > I've set the root_servers variables as: > root_servers = {} > root_servers["."] = "icann" > > and have verified that the icann.org IP list is accurate (at least the > first couple). > > Posadis (when it wasn't otherwise crashing) would answer this query just > fine. > > Can someone please point me where to look for more troubleshooting? > Thanks! -- Casey Bralla Chief Nerd in Residence The NerdWorld Organisation http://www.NerdWorld.org From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] I've finished my road trip Date: Tue, 11 Jul 2006 17:57:16 +0000 (UTC) Just letting everyone know that I finished my road trip (I'm now in Mexico), and that I will be able to semi-frequently address MaraDNS concerns. I'm also letting people know that the only support for MaraDNS 1.0 that I will provide is bugfix support; if you send me a "how do I" question and are still using 1.0, I'll ask you to upgrade to 1.2 or reply on the documentation supplied with 1.0 to resolve your problem. If you don't tell me which version of MaraDNS you're using and have a "how do I" question, I'll ask you which version of MaraDNS you're using (and, usually, will ask you for your mararc file and any relevant zone files) before answering your question. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.7 release (very minor bugfix) Date: Wed, 12 Jul 2006 22:15:45 +0000 (UTC) I have released MaraDNS 1.2.07.7 today. This is a very (and I mean very) minor bugfix release. Basically, I have backported the 1.2.10 fix with there being hi-bit characters in man pages to the stable branch. Basically, Perl is rather annoying. In order to set things up so Perl 5.8.0 can correctly have hi-bit characters, you have to use syntax that breaks Perl 5.8.8's handling of hi-bit characters. Personally, I feel that Perl's release process is very unprofessional; something as basic as hi-bit character support should not have its syntax changed in such a way that it is impossible to have the same script handle hi-bit characters with both Perl 5.8.0 and Perl 5.8.8. My workaround is to have the Perl script in question die if you try to run it with Perl 5.8.0; this result in me having to compile and install Perl 5.8.8 on my CentOS 3 system before I can build MaraDNS. Perl's a hack. I think a business is silly to have their enterprise depend on it. Python, on the other hand, is a lot more professional about not making changes which break scripts unless at least the minor version number changes. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Current work being done on MaraDNS Date: Thu, 13 Jul 2006 15:05:34 +0000 (UTC) Right now, I'm working on adding a number of obscure RR types to the CSV2 zone parser. An RR type is the name of a DNS record, such as "A", "MX", or "SRV". DNS has been around for over 23 years; in that time, a lot of weird RR types that no one uses have been proposed. So far, I've added most of the obscure RFC1035 RR types. This work can be seen here: http://www.maradns.org/download/1.2/snap/200607/ Disclaimer: These are "bleding edge" releases not guaranteed to compile, much less do anything useful. The plan is to eventually have BIND zone file support. This is an open source project: "plan" is very much the operative word here and I'm not making any promises. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.11 released (zone files now support many more RRs) Date: Tue, 18 Jul 2006 20:13:49 +0000 (UTC) I have just release MaraDNS 1.2.11. I have added support for a lot of obscure RRs in CSV2 zone files: HINFO, WKS, MD, MF, MB, MG, MINFO, MR, AFSDB, RP, X25, ISDN, RT, NSAP, NSAP-PTR, PX, GPOS, and LOC [1]. I have also made it so the email address in the SOA email field doesn't need an @ (you can use a '.' instead). Basically, with all of these RRs added to csv2 zone files, we're a lot closer to having BIND zone file support. I'm not sure how I'm going to split up the CSV2 parsing code to also support BIND zone files; I can either hack things up so that the same code has a "BIND zone file" and a "CSV2 zone file" mode, or I can just copy all of the code. The first solution seems better. Also, Vlatko Kosturjak from Croatia has kindly provided me a patch to add chkconfig support to MaraDNS's RPM spec file; alas, by the time I got the patch, the MaraDNS 1.2.11 packages were already built. 1.2.12's RPM spec file will have chkconfig support. Additionally, I have been told of a "quick and dirty" way to make any 32-bit .exe file a bona fide Windows service. The trick doesn't seem to work with MaraDNS 1.2.11, alas--but I may be able to make some changes to the source code of MaraDNS to make it work. If so, MaraDNS 1.2.12 will have this support. - Sam [1] OK, LOC is an RR that I have seen "in the wild"; all of the other RRs only seem to exist in dusty RFCs. From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.07.8 release (important bugfix) Date: Mon, 24 Jul 2006 03:24:53 +0000 (UTC) I have a new release of the stable branch of MaraDNS, 1.2.07.8, that fixes a fairly important memory leak. Basically, MaraDNS would leak about 300 bytes of memory every time someone asked for a PTR (reverse DNS lookup) record, the PTR pointed to a CNAME, and the CNAME did not point to a valid PTR record. Fairly rare, but 300 bytes leaked whenever it happened. I encourage all distributions to upgrade MaraDNS to 1.2.07.8 at their soonest convenience. This leak is also in the 1.0 code; I will release a 1.0.39 in the next few days with this memory leak fix backported. 1.2.07.8 also has some other bugfixes from the testing/development branch backported: * Backport of adding infomation about dangling CNAMEs to FAQ from testing branch (see Debian bug #373781) * Backport of explicit exit 0 added to MaraDNS start/stop script (Debian bug #374655) * Backport of 1.2.11 bugfix: We can now have email addresses without @ (using . instead) * Vlatko Kosturjak from Croatia has added chkconfig support to the RPM spec file. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.0.39 release (backport of 1.2.07.8 fix) Date: Mon, 24 Jul 2006 19:25:03 +0000 (UTC) First of all, I looked at older releases of MaraDNS and verified that this memory leak was introduced in the 1.0.33 and 1.1.50 releases of MaraDNS. Basically, when I fixed a compression error bug in those releases of MaraDNS, I accidently introduced a slow memory leak. The reason why the SQA process didn't catch this leak is because the stress test scripts don't make the kinds of queries that caused the leak. Sometimes bug fixes introduce their own bugs. Needless to say, I'm not going to make any changes to the recursive code until I make revisions to MaraDNS' entire SQA process. The SQA process needs an overhaul. Anyway, I have backported the fix to the 1.0 branch, and have released MaraDNS 1.0.39. People stillusing the 1.0 branch are encouraged to update to 1.0.39. It is available here: http://www.maradns.org/download.html - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.12.01 release (testing release) Date: Wed, 26 Jul 2006 19:11:09 +0000 (UTC) At this point, a csv2 zone file has all of the features that a RFC1035-compliant "master file" has, albeit in a slightly different syntax. Now that I have done this, I am releasing a maradns-1.2.12.01 release of MaraDNS. Basically, going from a BIND zone file to a MaraDNS csv2 zone file is now a matter of writing a good Python script. This is a testing release; the reason for the four-part numbering scheme is to remind myself not to add new features to MaraDNS until this release is well tested. Here is the change log: * Memory leak plugged: MaraDNS' resolver was leaking about 300 bytes whenever someone asked for a PTR that pointed to a CNAME that didn't point to a legitimate PTR. * Vlatko Kosturjak from Croatia has added chkconfig support to the RPM spec file. * Documentation on making MaraDNS a Win32 service added. * Truncation of records too long to fit in a 512-byte packet now done in a RFC2181-compliant manner. * Slash commands added to csv2 zone files: '/serial', which allows the serial for a zone file to be automatically updated whenever the zone file is edited; '/ttl', which allows the default TTL to be changed; '/origin', which allows the origin to be changed; '/opush' and '/opop' which allow the origin's values to be put on a stack; and '/read', which allows another file to be included in a zonefile. * Some tidying of the Csv2 parsing code to deallocate unneeded memory resources; this should lower MaraDNS memory usage when a large number of csv2 zone files exist. * Records stored in the authoritative half are now always marked "authoritative" in the DNS header; records not in a zone will simply not have NS records in the NS/AR section of the answer. * Download page revamped to be faster and easier to use. My future plans for MaraDNS: Write that Python script to convert to and from BIND zone files. Improve the SQA process so I can have automated regressions which cover most of MaraDNS' features. Add a FAQ about the importance of using dig's +norecurse option when troubleshooting NS delegation problems. Have read BIND zone file support. Have real Notify/IXFR/AXFR support. This list will probably take five years to do. In the meantime, there is 1.2.07.8 for most people, and 1.2.12.01 for testers. - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] A new look at djbdns for 2006 Date: Sat, 5 Aug 2006 18:25:36 +0000 (UTC) Hello, everyone, I'm letting everyone know that, among other things, I'm working on some advocacy documents for MaraDNS. The only document that I have finished is the one that is critical of DjbDNS. I will include a draft version of the document here; if anyone feels it is inaccurate or has any other comments about the document, let me know. It is my goal to have this document point out the very real issues with djbdns without coming off as trolling nor posting flamebait. - Sam Here is the document: ------8<-----8<-----8<-----8<------8<-----8<-----8<-----8<----- It is very difficult for me to be critical of djbdns. Djbdns came out at a time when the only other viable name server was the very insecure BIND8. It allowed people who needed a DNS server to have a secure solution at a time when BIND had security patches released almost monthly. I myself have used it to keep installations I administered at the time secure. In addition, Dr. Bernstein, djbdns' author, has written a number of documents about keeping DNS secure which were very valuable during the design phase of MaraDNS, and have undoubtably improved MaraDNS' security. I have a good deal of respect for Dr. Bernstein's coding abilities. That said, djbdns has a number of issues which make it not practical to deploy on new installations. Djbdns has not changed one iota for over five years. In addition, it is not legal to distribute a changed version of djbdns. This is the number one problem with djbdns: Djbdns is *not* open source. Its license is not compatible with one fundamental pillar of open source: The right to distribute modified versions of a program. This is a very practical problem: There are high profile internet sites that djbdns' recursive resolver plain simply can not resolve. In order to make djbdns' recursive resolver resolve these sites, after downloading djbdns, you need to find the patch that fixes the broken recursive resolver, apply the patch, and hope the patch doesn't break anything. This isn't the only problem with djbdns' recursive resolver. Its list of root servers is out of date by five years; two root servers have changed since then. This makes the recursive server less reliable; fixing this requires changing the configuration by hand, or by applying yet another third-party patch. Installing djbdns is non-trivial; you need to download and install no less than three different packages. Djbdns will not compile on a modern Linux system; you need to find the secret incantation to make it compile. Compare this to MaraDNS, where installing is as simple as downloading one package and typing in "make; make install". Once djbdns is installed, you will find some directories in the root of your filesystem that weren't there before. This breaks UNIX and Linux standards on how the filesystem can be organized. All of these issues could be fixed if Dr. Bernstein had release djbdns under an open-source compatible license. I understand that such modified versions of djbdns may introduce security problems that Dr. Bernstein's code does not have. The solution is simple: Distribute djbdns under a LaTeX license, which is open source compatible and would require modified versions of djbdns to be called something besides djbdns. There are a number of programs which are still being actively maintained long after the original author stopped contributing to the project. The fvwm project is still thriving even though Rob Nation stopped working on the project over 12 years ago. When Atheos development stopped, its users forked the code and started the Syllable project. Both Perl and Python are no longer being actively worked on by their primary developers; most, if not all, code changes now come from other people. djbdns has a good security record; however, it is not the only dns server with good security. No stable version of MaraDNS on a non-Linux system has ever had an exploitable security problem. The one and only denial-of-service problem was caused by Linux's broken TCP/IP stack and not by MaraDNS, and has long since been fixed. Djbdns users are not the most polite people out there. The very first email I got when I publically announced MaraDNS was a very rude message from a djbdns advocate who told me it wasn't worth my time to write a DNS server, since djbdns works fine. I replied that, yes djbdns is an excellent name server, but is under a restrictive license, and that I would not develop MaraDNS had djbdns been released under a more open license. He knew I was right, and didn't reply back. I'm not the only person to be treated rudely by djbdns' users. When one person pointed out yet another bug with djbdns' recursive resolver, he was told that people who have this problem that it was "their own fault". In more detail, if someone has a domain with an provider and, for whatever reason, wants to change providers with their current provider's help, djbdns' cache will incorrectly point to the old provider until the cache program is restarted. Dr. Bernstein, as far as I can tell, has no intention to fix this issue, nor any other issue with djbdns. He acts too arrogantly to acknowledge that his programs have bugs, much less fix his bugs--I have never seen him admit his program has a bug. This goes back to the djbdns license; the person who blamed the user for a djbdns problem really had no other choice. He could not patch djbdns and distribute a modified djbdns to fix the issue. While he could made a patch available, the number of djbdns users who would actually apply the patch is next-to-zero. Since Dr. Bernstein has abadoned djbdns, there is no system in place to allow people to fix issues with djbdns. Djbdns was the best DNS option available when it came out. That was over five years ago. Since then, the internet has changed and djbdns has not kept up. Now that BIND9, MaraDNS, and PowerDNS have a proven security record, and are both under an open-source license and being actively maintained, there is no longer any reason to use djbdns. From: Remco =?utf-8?q?R=C4=B3nders?= To: list@NOSPAM.org Subject: Re: [MARA] A new look at djbdns for 2006 Date: Sun, 6 Aug 2006 10:05:31 +0200 --nextPart230994831.vTB9HKRqaU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Op Saturday 05 August 2006 20:25, schreef Sam Trenholme: > Hello, everyone, > > I'm letting everyone know that, among other things, I'm working on > some advocacy documents for MaraDNS. The only document that I have > finished is the one that is critical of DjbDNS. I will include a draft > version of the document here; if anyone feels it is inaccurate or > has any other comments about the document, let me know. > > It is my goal to have this document point out the very real issues with > djbdns without coming off as trolling nor posting flamebait. > > - Sam Hi Sam, The document seems good to me. That said, it will draw reactions sooner or= =20 later, no matter how you word things as some will always feel attacked when= =20 you have (valid) criticism on their $package_of_choice. That said, I have a few minor comments to make: > Djbdns users are not the most polite people out there. The very first > email I got when I publically announced MaraDNS was a very rude message > from a djbdns advocate who told me it wasn't worth my time to write a > DNS server, since djbdns works fine. I replied that, yes djbdns is an > excellent name server, but is under a restrictive license, and that I > would not develop MaraDNS had djbdns been released under a more open > license. He knew I was right, and didn't reply back. > > I'm not the only person to be treated rudely by djbdns' users. When one > person pointed out yet another bug with djbdns' recursive resolver, he > was told that people who have this problem that it was "their own fault". > In more detail, if someone has a domain with an provider and, for whatever > reason, wants to change providers with their current provider's help, > djbdns' cache will incorrectly point to the old provider until the cache > program is restarted. I don't think the djbdns user community should be painted this black. Yes,= =20 some of them might be rude, just as some on the bind list can be a bit cros= s=20 at times. I think this is one of the few times where you should be happy th= at=20 maradns doesn't have as big an uptake yet as bind or djbdns as there will=20 always be rude people. The more people you get together, the bigger the odd= s=20 you'll have a few rude ones amongst them; And they tend to be the more voca= l=20 ones too! > This goes back to the djbdns license; the person who blamed the user > for a djbdns problem really had no other choice. He could not patch > djbdns and distribute a modified djbdns to fix the issue. Perhaps you can substantiate this a bit more or rework it some more into th= e=20 previous paragraphs, maybe turn around the order? State that because the=20 license is like this and that, that at times people on the userlist get a b= it=20 short with others when the 10th person in a month shows up with a question= =20 that could have been fixed in the software if only ... > Now that BIND9, MaraDNS, and PowerDNS have a proven > security record, and are both under an open-source license and being > actively maintained, there is no longer any reason to use djbdns. You name three, but refer to them as 'both'. =3D=3D=3D I think it's great that you are working on some advocay documents. As you k= now=20 I really like mara, and at times have wondered why it didn't receive more=20 uptake than it has. Over the years you have added quite a few features and= =20 mara has really gone quite some lenghts from being a 'simple' nameserver to= =20 one that comes with a wide variety of features and uses. Thank you for your work on it! Kind regards, Remco --nextPart230994831.vTB9HKRqaU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE1aLpP0wYCuTizasRAlq6AJ44UtmnArHYpK8keO8H6Il/VMW0aQCdEamJ FwUIunG3DCFwwcLWTVd0Oqg= =VpGU -----END PGP SIGNATURE----- --nextPart230994831.vTB9HKRqaU-- Date: Sun, 06 Aug 2006 10:31:06 +0200 From: Peter Randow To: list@NOSPAM.org Subject: Re: [MARA] A new look at djbdns for 2006 Hi Sam Trenholme softly whispered: * No stable version of MaraDNS on a non-Linux * system has ever had an exploitable security problem. Is this a typo? Or were there especially on Linux systems security problems? Greetings Peter From: Remco =?utf-8?q?R=C4=B3nders?= To: list@NOSPAM.org Subject: Re: [MARA] A new look at djbdns for 2006 Date: Sun, 6 Aug 2006 10:46:06 +0200 --nextPart2492155.IRYllqIGAc Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Op Sunday 06 August 2006 10:31, schreef Peter Randow: > * No stable version of MaraDNS on a non-Linux > * system has ever had an exploitable security problem. > > Is this a typo? > Or were there especially on Linux systems security problems? Peter, There once was a problem that only affected systems running Linux. See http://www.maradns.org/security.html for all known security issues that= =20 have affected / impacted mara over time. The one Sam referred to is #3, and= =20 could cause mara to freeze.=20 See also=20 http://marc.10east.com/?l=3Dmaradns-list&m=3D111543365524290&w=3D2 and http://marc.10east.com/?l=3Dmaradns-list&m=3D111543639932692&w=3D2 for a little more info on this. Sincerely, Remco R=C4=B3nders --nextPart2492155.IRYllqIGAc Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE1axVP0wYCuTizasRAovoAJ4sb12I+yk553b5mFlrH+eSV8y2dACdEhS5 gJYp27xdy4KAyDGZpF0zb3A= =hAWQ -----END PGP SIGNATURE----- --nextPart2492155.IRYllqIGAc-- From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] Another advocacy document written Date: Sun, 6 Aug 2006 17:27:32 +0000 (UTC) First of all, I would like to thank Remmy and everyone else for their feedback on my djbdns advocacy page. I will incorporate this feedback in to the document. As for MaraDNS' security: Yes, there was an issue caused by the Linux kernel which allowed a malformed packet to freeze MaraDNS. This is the only real security issue that a stable release of MaraDNS has had; there have also been academic attacks like "you may be able to obtain the key used for the query id/port number if you send 20,000,000 special packets" and what not which I have also addressed. Second of all, I wrote a similar document for BIND yesterday, which I will include at the end of this message. Third of all, I know I'm behind on personal mail. I will catch as soon as my job search calms down. - Sam Here is the document: ------8<-----8<-----8<-----8<------8<-----8<-----8<-----8<----- BIND9 is the emacs of DNS servers: It includes everything but the kitchen sink. This results in a full-featured DNS server that has about 5,000 features you will never use. This results in BIND being a very large application. On my system, a stripped BIND 9.2.6 binary is some 1,117,348 bytes in size. The maradns binary is only 150,432 bytes in size. The zoneserver binary, if needed, is only 107,360 bytes in size--resulting in a combined size of 257,792 bytes. This is a fraction of the size of BIND, making MaraDNS more suitable for embedded applications or on systems with limited resources (such as heavily loaded web servers). BIND's configuration is somewhat cryptic. For example, here a BIND setup that uses a custom root server; this shell scipt will set up all the files needed to start up BIND9 and run named in the current directory: cat > named.conf << EOF options { directory "$( pwd )"; pid-file "named.pid"; allow-query { 127.0.0.1/8; }; }; zone "." { type hint; file "root.hint"; }; EOF cat > root.hint << EOF \$TTL 86400 . IN NS a.root.bogus. a.root.bogus. IN A 127.0.3.1 EOF chown root:root . named -c named.conf Note that this basic configuration needs two different files with two different syntaxes. Compare this to MaraDNS, which needs just one simple four-line file: cat > mararc << EOF chroot_dir = "$( pwd )" ipv4_bind_addresses = "127.0.0.1" recursive_acl = "127.0.0.1/8" root_servers["."] = "127.0.3.1" EOF maradns -f mararc One key difference between this simple MaraDNS configuration and the corresponding simplified named configuration is that the named server will run as root with full access to the filesystem; the corresponding simple MaraDNS confiuration will run as "nobody" in a limited-access chroot() environment. While it is possible to run BIND as an unprivileged user in a chroot() environment, this configuration is non-trivial and not fully described in BIND's documentation. Indeed, BIND9 has had one remotely exploitable buffer overflow. Basically, older versions of BIND9 linked to the OpenSSL library, which had the offending buffer overflow. This is why MaraDNS has a strong "not invented here" policy; the only external libraries that MaraDNS uses are the libc library and the pthreads library. The reason for this is to minimize security problems that external libraries may cause--a problem that bit BIND9. BIND, to its credit, does have a number of features which I haven't yet implemented in MaraDNS. BIND supports standard RFC-compliant zone files. While MaraDNS' csv2 zone file format is mostly BIND-like, there are differences that make the two zone files incompatible. I plan on writing a converter in the near future and eventually having full RFC zone file support. BIND, of course, also has full support for being a DNS slave, including NOTIFY and IXFR support--features which I may eventually add to MaraDNS. In conclusion, while BIND9 has better RFC compliance and more features, it is a far bigger program that is more difficult to configure than MaraDNS. It is a bigger binary that uses up more memory than MaraDNS. Its security history is not as good as MaraDNS' security history. The two DNS servers have different compromises between code size, features, ease of use, and security. Date: Sun, 06 Aug 2006 12:55:45 -0700 From: RC Subject: Re: [MARA] A new look at djbdns for 2006 To: list@NOSPAM.org On Sat, 5 Aug 2006 18:25:36 +0000 (UTC) Sam Trenholme wrote: > This is a very practical problem: There are high profile internet > sites that djbdns' recursive resolver plain simply can not resolve. "plain simply" Choose one. From: Sam Trenholme To: list@NOSPAM.org Subject: Re: [MARA] A new look at djbdns for 2006 Date: Mon, 7 Aug 2006 15:31:49 +0000 (UTC) >> This is a very practical problem: There are high profile internet >> sites that djbdns' recursive resolver plain simply can not resolve. > Choose one. This last January, www.edmunds.com and www.infiniti.com. They may or may not work today; djbdns certainly hasn't fixed the issue which caused the problem. Reference: http://marc.theaimsgroup.com/?l=djbdns&m=113733374006571 - Sam P.S. And, yes, I'll be nicer to the djbdns community when the final version of the advocacy document is finished. From: Remco =?utf-8?q?R=C4=B3nders?= To: list@NOSPAM.org Subject: Re: [MARA] Another advocacy document written Date: Mon, 7 Aug 2006 18:42:04 +0200 --nextPart1567185.MDQdGA41V5 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Sam, Some small comments on your 2nd text: > This results in a full-featured DNS server that has > about 5,000 features you will never use. > > This results in BIND being a very large application. =20 One "this results" too many, it doesn't sound good when read out loud, so y= ou=20 might want to rephrase either one of them. > BIND, to its credit, does have a number of features which I haven't > yet implemented in MaraDNS. BIND supports standard RFC-compliant zone > files. While MaraDNS' csv2 zone file format is mostly BIND-like, there > are differences that make the two zone files incompatible. I plan on > writing a converter in the near future and eventually having full RFC > zone file support. BIND, of course, also has full support for being > a DNS slave, including NOTIFY and IXFR support--features which I may > eventually add to MaraDNS. > > In conclusion, while BIND9 has better RFC compliance and more features, What I find missing in your text, and that could quite well be because I am= =20 mistaken or that you disagree on this, is the reason that BIND is more RFC= =20 compliant than Mara is and has all these exotic features. Could it be becau= se=20 there is such a tight link / overlap between the people who write bind and= =20 those who write (some of) the RFC's? I remember reading criticisms on thing= s=20 being made a standard that only served as a marginally useful feature for=20 bind servers. Or, on the other hand, things not being made into a standard= =20 because it didn't fit into the way that the bind codebase is organised? I=20 don't have any links to any of that at hand here, so it's not impossible th= at=20 I might have a wrong picture of all this, but what's your take on this? Other than that, the text reads fine to me and seems to address some good=20 points. Kind regards, Remco --nextPart1567185.MDQdGA41V5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBE1216P0wYCuTizasRAvVrAJwKQ13S5UopmBSivl1WW10DYe4lsgCgrYwn ElCOixKSZXbzc+ggT0inzBg= =7+8O -----END PGP SIGNATURE----- --nextPart1567185.MDQdGA41V5-- Date: Tue, 08 Aug 2006 00:44:01 -0700 From: RC Subject: Re: [MARA] A new look at djbdns for 2006 To: list@NOSPAM.org On Mon, 7 Aug 2006 15:31:49 +0000 (UTC) Sam Trenholme wrote: > > Choose one. > > This last January, www.edmunds.com and www.infiniti.com. They may or > may not work today; djbdns certainly hasn't fixed the issue which > caused the problem. I wasn't asking for examples, actually, I was just trying to offer a grammar correction. "plain simply" is redundant repetitious reiterating, if you get my drift gist. And now I've spent WAY too much time on the issue... Date: Tue, 8 Aug 2006 09:54:27 +0200 (CEST) Subject: Re: [MARA] A new look at djbdns for 2006 From: "Remco Rijnders" To: list@NOSPAM.org > I wasn't asking for examples, actually, I was just trying to offer a > grammar correction. "plain simply" is redundant repetitious > reiterating, if you get my drift gist. > > And now I've spent WAY too much time on the issue... Ah well, I think the inclusion of these examples and the relevant links to the mailinglists do make a useful addition to Sam's text though, so it's a good amendment none the less :) (As was your grammar fix) Kind regards, Remco From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS 1.2.12.02 release (stable release) Date: Mon, 14 Aug 2006 20:52:04 +0000 (UTC) I have just released MaraDNS 1.2.12.02, which is a stable release of MaraDNS that is suitable for including with distributions. I have done a lot of testing in preparing this release. The most notable testing is that I finally have run MaraDNS through the very useful Valgrind tool (http://valgrind.org) Valgrind found only one error in the code: There was an off-by-one error in the ipv6 address parsing code. Fortunatly, MaraDNS' string library has measures in place to protect against these kinds of errors; the error was in no way exploitable. There were also a number of memory leaks, none of which were critical. A critical memory leak is one that happens while MaraDNS is serving DNS records, since the leak can potentially leak memory again and again until memory runs out. All of the leaks found by Valgrind are ones that just make MaraDNS use more memory than should be used while loading zone files. With one notable exception, I plugged all of these leaks for the 1.2.12.02 release. The one notable exception is one where I will have to make some fairly significant changes to the recursive code to plug; I will work on this leak in the up-and-coming post-1.2.12 branch of MaraDNS. I have also done a lot of DNS stress testing, both "dry" offline testing and real-world online testing. No memory leaks nor crashes were found. Daniel Zilli has also contributed a shell script to help people configure MaraDNS. A number of other bugs were fixed in the 1.2.12.02 release; details are in the changelog: http://www.maradns.org/changelog.html Now I have to decide whether it's more important to write the Bind zone file conversion Python script, or plug the one last leak that Valgrind reports. The advantage of writing the Python script first is that I don't have to maintain two branches of MaraDNS, since it doesn't have the potential make the C code any less stable. If people are a little reluctant to jump from 1.2.07 to 1.2.12, I can make a 1.2.07.9 release available which incorporates most of the 1.2.12.02 bugfixes in to the 1.2.07 branch. Let me know. - Sam Date: Thu, 17 Aug 2006 10:20:52 -0400 To: list@NOSPAM.org Subject: Re: [MARA] Another advocacy document written From: Rich Felker On Mon, Aug 07, 2006 at 06:42:04PM +0200, Remco Rijnders wrote: > What I find missing in your text, and that could quite well be because I am > mistaken or that you disagree on this, is the reason that BIND is more RFC > compliant than Mara is and has all these exotic features. Could it be because > there is such a tight link / overlap between the people who write bind and > those who write (some of) the RFC's? I agree that this is probably the reason. Any standard based on a single implementation (as opposed to the implementation being based on a standard, or the standard being based on the common features of a multitude of existing implementations) is automatically suspect. Rich From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS: Volunteers needed Date: Wed, 23 Aug 2006 17:33:00 +0000 (UTC) Hello, everyone, Someone sent me an email pointing out that MaraDSN no longer has French documtation. The reason why I have dropped the French documentation is because it was out of date--the documentation was for MaraDNS 1.0 and a lot of new features have been added to 1.2 that I would like to see French-speaking users take advantage of. At times, I do remove older user-contributed material. My rule is that I remove material that hasn't been updated for over two years and hasn't been updated since that last major release of MaraDNS. I, so far, have removed two items that were in MaraDNS 1.0 in the 1.2 tree: * The maragen m4 macros. I will reinstates these if they ever get updated to make csv2 zone files. * The French documentation. Hasn't been updated since before the 1.0 release. If people want to see MaraDNS documented in French, download the last 1.2.07 or 1.0 release of MaraDNS and update the documentation to be current with 1.2. The disadvantage of an open-source project is that I can't spend thousands of dollars getting all of the translated documents updated with each new release of MaraDNS. The advantage is that you don't have to indirectly pay for said translation. - Sam Date: Mon, 28 Aug 2006 10:23:17 +0100 From: Kai Hendry To: Boris =?iso-8859-1?Q?Dor=E8s?= , Subject: Re: Bug#384943: start/stop zoneserver Thank you for the report. I don't use the zoneserver feature myself, so this is difficult for me to test. The /etc/init.d/zoneserver is a Debian addition and I've being doing a poor job maintaining it. It's also a little complex as it is supposed to handle multiple separate servers and their configurations. I've since prepared a package with your patch: http://hendry.iki.fi/debian/unstable/maradns_1.2.12.02-2_i386.changes ¿Could you please test it? Best wishes! On 2006-08-28T08:09+0200 Boris Dorès wrote: > Package: maradns > Version: 1.2.12.02-1 > Tags: patch > > Hi everyone, > > I think I found three bugs related to the init.d script of the zoneserver of > maradns package : > > 1) zoneserver doesn't start if there are more than one configuration > file mentionned in /etc/default/maradns ($SERVERS is used on the > command line instead of $rcfile, which zoneserver doesn't > understand). > > 2) zoneserver isn't started unless "zone_transfer_acl" is defined in the > configuration file, even if it is (only) used to serve DNS records > over TCP (with the "tcp_convert_server" option). > > 3) when zoneserver is stopped with "/etc/init.d/zoneserver stop", only > the parent process of each server is killed : children processes keep > running in the background and must be killed manually. > > > > For 1) and 2), here is a patch proposal : > > --- /etc/init.d/zoneserver 2006-08-28 07:42:00.094624092 +0200 > +++ /etc/init.d/zoneserver2 2006-08-28 05:57:15.210295564 +0200 > @@ -33,11 +33,11 @@ > start) > echo -n "Starting $DESC: " > for rcfile in $SERVERS ; do > - if grep -q -i "^zone_transfer_acl" $rcfile; then > + if grep -q -i "^\(zone_transfer_acl\|tcp_convert_server\)" $rcfile; then > SERVERNAME=`echo $rcfile | sed 's/\//_/g;s/^_*//;' | awk -F. '{print $NF}'` > SERVERNAME=zoneserver.$SERVERNAME > start-stop-daemon --start -m --pidfile /var/run/$SERVERNAME.pid \ > - --exec $DAEMON -- -f $SERVERS &1 | logger -p daemon.notice -t $SERVERNAME 2>/dev/null & > + --exec $DAEMON -- -f $rcfile &1 | logger -p daemon.notice -t $SERVERNAME 2>/dev/null & > else > echo "No zone ACL's configured for $rcfile -- not starting zoneserver for it." > fi > @@ -47,7 +47,7 @@ > stop) > echo -n "Stopping $DESC: " > for rcfile in $SERVERS ; do > - if grep -q -i "^zone_transfer_acl" $rcfile; then > + if grep -q -i "^\(zone_transfer_acl\|tcp_convert_server\)" $rcfile; then > SERVERNAME=`echo $rcfile | sed 's/\//_/g;s/^_*//;' | awk -F. '{print $NF}'` > SERVERNAME=zoneserver.$SERVERNAME > start-stop-daemon --stop -m --quiet --pidfile /var/run/$SERVERNAME.pid \ > > > > As for 3), I guess it's more like an upstream issue. > > Thanks. > > -- > Boris Dores > Date: Mon, 28 Aug 2006 20:54:03 +0200 From: Boris =?iso-8859-15?Q?Dor=E8s?= To: Kai Hendry Subject: Re: Bug#384943: start/stop zoneserver On Mon, Aug 28, 2006 at 10:23:17AM (GMT+0100), Kai Hendry wrote: > I've since prepared a package with your patch: > http://hendry.iki.fi/debian/unstable/maradns_1.2.12.02-2_i386.changes > > ¿Could you please test it? It works fine (but I have only tested the corresponding source package since I am backporting it to sarge actually). This only leaves 3) open (children processes are not killed). Thank you very much ! -- Boris Dorès Date: Tue, 29 Aug 2006 12:08:07 +0200 From: Boris =?iso-8859-15?Q?Dor=E8s?= To: list@NOSPAM.org Subject: Re: Bug#384943: start/stop zoneserver --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit > > 3) when zoneserver is stopped with "/etc/init.d/zoneserver stop", only > > the parent process of each server is killed : children processes keep > > running in the background and must be killed manually. > > As for 3), I guess it's more like an upstream issue. Here is a patch proposal for this issue, made against maradns-1.2.12.02. I hope you will find it useful. Best regards. -- Boris Dorès --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="maradns-1.2.12.02.diff" diff -ruN maradns-1.2.12.02/tcp/zoneserver.c maradns-1.2.12.02-kill/tcp/zoneserver.c --- maradns-1.2.12.02/tcp/zoneserver.c 2006-07-18 05:50:44.000000000 +0200 +++ maradns-1.2.12.02-kill/tcp/zoneserver.c 2006-08-29 12:00:05.000000000 +0200 @@ -77,6 +77,12 @@ num_children--; } +/* Signal handler for termination of the root process */ +void handle_term() { + killpg(getpgrp(), SIGTERM); + exit(0); +} + /* Print out log messages Input: Null-terminated string with the message to log Output: JS_SUCCESS on success, JS_ERROR on error @@ -98,6 +104,7 @@ void harderror(char *why) { printf("%s%s%s",L_FATAL,why,LF); /* "Fatal error: ", why, "\n" */ + killpg(getpgrp(), SIGTERM); /* Don't leave orphaned children */ exit(3); } @@ -992,6 +999,13 @@ int synth_soa_serial; js_string *synth_soa_origin; + /* Kill children processes when we are signaled */ + if(setpgrp()) { + printf(strerror(errno)); /* harderror() would kill the group which may not be correct yet */ + return 3; + } + signal(SIGTERM,handle_term); + /* Initialize the strings (allocate memory for them, etc.) */ if((mararc_loc = js_create(256,1)) == 0) harderror(L_MLC); /* "Could not create mararc_loc string" */ @@ -1156,7 +1170,9 @@ if(pipe(stream1) != 0) harderror("Pipe()'s broken"); /* if((child[bind_address_iterate] = fork())) { * Parent */ - if((pid = fork())) { /* Parent */ + if((pid = fork())) { /* Parent or error */ + if(pid < 0) + harderror("Could not fork"); close(stream1[1]); fcntl(stream1[0],F_SETFL,O_NONBLOCK); /* The following might not be portable */ --cNdxnHkX5QqsyA0e-- From: Sam Trenholme To: list@NOSPAM.org Subject: Re: Bug#384943: start/stop zoneserver Date: Thu, 7 Sep 2006 23:43:46 +0000 (UTC) Upstream here, finally. Sorry about the delay replying to this issue, I've been juggling no less than three different jobs and have been spending my free time this last week playing with Greg Strong's excellent ChessV program (http://sourceforge.net/projects/chessv) to help research a Chess variant that I've "invented" (Schoolbook Chess). Anyway, enough of the excuses and let me look at this issue. All zoneserver processes are correctly killed when using the upstream zoneserver process killer. The script in question has this bit of code: ps -ef | awk '{print $2":"$8}' | grep zoneserver | grep -v $$ | \ cut -f1 -d: | xargs kill > /dev/null 2>&1 English translation: Send a term signal to all processes running on the machine with the name zoneserver This is followed by: ps -e | awk '{print $1":"$NF}' | grep zoneserver | grep -v $$ | \ cut -f1 -d: | xargs kill -9 > /dev/null 2>&1 So my script doesn't have this issue. Now, in terms of the patch for the zoneserver that has the zoneserver also be able to kill its own children, I agree this is a good idea. However, the patch is too big a change for the current stable branch, 1.2.12. I don't know if getpgrp(), setpgrp(), and killpg() exist on all systems MaraDNS' zoneserver is supposed to compile on (Mac OS X, the *BSDs--though Adam Montage has given me an account I can do OpenBSD testing on, Solaris, etc). What I will do is make this a change for the 1.2.13 release of MaraDNS which will come out one of these days. I appreciate Boris submitting this patch to MaraDNS. Now, in terms of MaraDNS progress, I'm slowly but surely working on the BIND to CSV2 converython script. You can see my progress here: http://www.maradns.org/download/1.2/snap/200609/ Anyway, thanks guys for your interest in MaraDNS. This is, from where I am sitting, WONTFIX for the 1.2.12 branch, but the patch will be applied in 1.2.13. - Sam Date: Mon, 11 Sep 2006 11:35:32 -0300 From: Leon Waldman To: list@NOSPAM.org Subject: Problems to compiling Hi... I'm having some problems to compile the source from maradns-1.2.12.02... Can be dependences problems ??? What libraries i need to compile it ??? What version/packages ?? My best regards !!! Leon From: Remco =?utf-8?q?R=C4=B3nders?= To: list@NOSPAM.org Subject: Re: Problems to compiling Date: Tue, 12 Sep 2006 05:38:50 +0200 --nextPart1317728.8VJIKMa14s Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Op Monday 11 September 2006 16:35, schreef Leon Waldman: > Hi... > > I'm having some problems to compile the source from maradns-1.2.12.02... > > Can be dependences problems ??? > > What libraries i need to compile it ??? > > What version/packages ?? Leon, As always when asking for help can you describe: 1) Steps you've taken? 2) Include any (error) output? Without any of that it could be anything and there is no way we could know= =20 where it is failing. Kind regards, Remco --nextPart1317728.8VJIKMa14s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBFBivVP0wYCuTizasRAhVgAKCj2AGwEprY8ajnCPzRZ+3dqJZQQgCfa0zL OhokgYWiJdW8tCFFYw/YjLU= =TXn3 -----END PGP SIGNATURE----- --nextPart1317728.8VJIKMa14s-- From: Sam Trenholme To: list@NOSPAM.org Subject: Re: Problems to compiling Date: Thu, 14 Sep 2006 14:18:50 +0000 (UTC) [Note to self: Teach my advanced English students that "problems" can only be followed by a gerund, not an infinitive] >What libraries do I need to compile MaraDNS? [Excuse me for correcting the English. I'm an English teacher these days.] The only libraries you need which are special are the pthreads libraries, which every Linux distribution I know about includes with a base install. Basically, if you can compile this program: main(){printf("Hello, world!\n");} You should be able to compile MaraDNS. All of the libraries that MaraDNS uses are standard. Here is the output of "ldd maradns": libpthread.so.0 => /lib/tls/libpthread.so.0 (0x004e0000) libc.so.6 => /lib/tls/libc.so.6 (0x00372000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00780000) As an aside, MaraDNS 1.2.12.02 is part of Debian; if you can't find the .deb, ask for help on a Debian list for information on changing the repository you use. Reference: http://groups.google.com/group/linux.debian.changes.devel/msg/9f4ff86b3f6b5005?dmode=source&output=gplain - Sam From: Sam Trenholme To: list@NOSPAM.org Subject: [MARA] MaraDNS statius report Date: Sun, 1 Oct 2006 02:41:59 +0000 (UTC) While I am working three different jobs, I am still able to make time here and there to work on MaraDNS. What I have been working on is the Python script to convert BIND zone files in to MaraDNS-compatible csv2 zone files. This script is a lot of work; the BIND zone file format assumes a state machine that is fairly complicated to implement. Right now, the BIND zone file parser can convert A, AAAA, SOA, NS, MX, SRV, and some obscure record types. In particular, I haven't done the code to convert TXT and SPF records yet. The parser also hasn't been really tested. People can see my progress here: http://www.maradns.org/download/1.2/snap/200609/ My next update will be uploaded here: http://www.maradns.org/download/1.2/snap/200610/ My goal is to have a working BIND zone file format converter by the end of the year; ideally by the end of October. Once this is done, I'll make a 1.2.12.03 release. After that, I'll improve memory usage and add AAAA support to the recursive resolver. As always, I am answering support email sent to me. It may take up to a week to answer an email; faster help is probably available on the list. - Sam To: list@NOSPAM.org From: Peter Wyss Subject: Bad query received Date: Tue, 3 Oct 2006 20:56:43 +1000 Hi I have set up MaraDNS (1.2.12.02) on my server as recursive server. (Nice and easy btw.) With verbose_level = 3 I can see the messages below in my log. Name resolution still works but I get a lot of these bad query messages. Looks like there is one every time MaraDNS needs to resolve a new hostname. If MaraDNS already has the name in the cache, there are no bad query messages. Any idea what this means? Thanks Peter Oct 3 20:25:26 localhost maradns.etc_maradns_mararc: Query from: 192.168.1.4 Awww.apple.com. Oct 3 20:25:26 localhost maradns.etc_maradns_mararc: Log: Bad query received: \032\317 Oct 3 20:25:26 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 3 20:25:26 localhost maradns.etc_maradns_mararc: Log: Bad query received: \032\317 Oct 3 20:25:26 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 3 20:25:26 localhost maradns.etc_maradns_mararc: Log: Message received, processing Oct 3 20:25:27 localhost maradns.etc_maradns_mararc: Query from: 192.168.1.4 Awww.washingtonpost.com. Oct 3 20:25:27 localhost maradns.etc_maradns_mararc: Log: Bad query received: \233\374 Oct 3 20:25:27 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 3 20:25:27 localhost maradns.etc_maradns_mararc: Log: Bad query received: \233\374 Oct 3 20:25:27 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 3 20:25:27 localhost maradns.etc_maradns_mararc: Log: Message received, processing Oct 3 20:25:28 localhost maradns.etc_maradns_mararc: Query from: 192.168.1.4 Awww.nytimes.com. Oct 3 20:25:28 localhost maradns.etc_maradns_mararc: Log: Bad query received: \305& Oct 3 20:25:28 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 3 20:25:28 localhost maradns.etc_maradns_mararc: Log: Bad query received: \305& Oct 3 20:25:28 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 3 20:25:28 localhost maradns.etc_maradns_mararc: Log: Message received, processing From: Sam Trenholme To: list@NOSPAM.org Subject: Re: Bad query received Date: Wed, 4 Oct 2006 19:43:48 +0000 (UTC) I have just uploaded a new version of MaraDNS here: http://www.maradns.org/download/1.2/snap/200610/ Basically, I can't tell you why you are getting those messages. The most likely reason is because the remote server sent a bad packet. What I have done is revise the relevant code to log the IP the bad query came from. This will help me better troubleshoot this issue. Personally, I don't think there is a real problem. A remote server sends Mara an invalid packet, and Mara happily rejects it. :-) - Sam From: Peter Wyss Subject: Re: Bad query received Date: Thu, 5 Oct 2006 17:33:47 +1000 To: list@NOSPAM.org Installed the new version. Result was that MaraDNS crashed every time after the "Log: Bad query received" message. Looks like the new log code could use some improvement ;-) Peter On 05/10/2006, at 5:43 AM, Sam Trenholme wrote: > I have just uploaded a new version of MaraDNS here: > > http://www.maradns.org/download/1.2/snap/200610/ > > Basically, I can't tell you why you are getting those messages. The > most likely reason is because the remote server sent a bad packet. > > What I have done is revise the relevant code to log the IP the bad > query came from. This will help me better troubleshoot this issue. > > Personally, I don't think there is a real problem. A remote server > sends Mara an invalid packet, and Mara happily rejects it. :-) > > - Sam > From: Sam Trenholme To: list@NOSPAM.org Subject: Re: Bad query received Date: Thu, 5 Oct 2006 16:40:26 +0000 (UTC) A54D74F8F@NOSPAM.literati.org> In-Reply-To: OK, I have fixed the bug that makes MaraDNS crash, and have deleted the offending daily snapshot from the MaraDNS server. Keep in mind guys that anything in http://www.maradns.org/download/1.2/snap/ is a snapshot, and is not guaranteed to run, be secure, or even compile. >Result was that MaraDNS crashed every time after the "Log: Bad query >received" message. - Sam From: Peter Wyss Subject: Re: Bad query received Date: Fri, 6 Oct 2006 19:09:35 +1000 To: list@NOSPAM.org The latest snapshot is better - no crashes anymore. The log shows for the bad query the IP of the local machine initiating the query. There seems to be no difference if the query comes from a Linux PC or a Mac. There is always a similar "bad query" logged. Does this help Sam? Do you want me to run specific tests? Cheers Peter ----- Some log messages... Oct 6 19:05:17 localhost maradns.etc_maradns_mararc: Query from: 192.168.1.4 Awww.google-analytics.com. Oct 6 19:05:17 localhost maradns.etc_maradns_mararc: Log: Bad query received: \026\302 Oct 6 19:05:17 localhost maradns.etc_maradns_mararc: From IP: 192.168.1.4 Oct 6 19:05:17 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 6 19:05:17 localhost maradns.etc_maradns_mararc: Log: Bad query received: \026\302 Oct 6 19:05:17 localhost maradns.etc_maradns_mararc: From IP: 192.168.1.4 Oct 6 19:05:17 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 6 19:05:19 localhost maradns.etc_maradns_mararc: Log: Message received, processing Oct 6 19:05:20 localhost maradns.etc_maradns_mararc: Query from: 192.168.1.4 Adata.as-us.falkag.net. Oct 6 19:05:20 localhost maradns.etc_maradns_mararc: Log: Bad query received: \222\245 Oct 6 19:05:20 localhost maradns.etc_maradns_mararc: From IP: 192.168.1.4 Oct 6 19:05:20 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 6 19:05:21 localhost maradns.etc_maradns_mararc: Log: Message received, processing Oct 6 19:05:22 localhost maradns.etc_maradns_mararc: Query from: 127.0.0.1 Awww.iinet.net.au. Oct 6 19:05:22 localhost maradns.etc_maradns_mararc: Log: Message received, processing Oct 6 19:05:23 localhost maradns.etc_maradns_mararc: Query from: 192.168.1.4 Aa.tribalfusion.com. Oct 6 19:05:23 localhost maradns.etc_maradns_mararc: Log: Bad query received: \002\360 Oct 6 19:05:23 localhost maradns.etc_maradns_mararc: From IP: 192.168.1.4 Oct 6 19:05:23 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers Oct 6 19:05:23 localhost maradns.etc_maradns_mararc: Log: Bad query received: \002\360 Oct 6 19:05:23 localhost maradns.etc_maradns_mararc: From IP: 192.168.1.4 Oct 6 19:05:23 localhost maradns.etc_maradns_mararc: Log: No reply from remote servers On 06/10/2006, at 2:40 AM, Sam Trenholme wrote: > A54D74F8F@NOSPAM.literati.org> > > In-Reply-To: > > OK, I have fixed the bug that makes MaraDNS crash, and have deleted > the > offending daily snapshot from the MaraDNS server. Keep in mind guys > that anything in http://www.maradns.org/download/1.2/snap/ is a > snapshot, and is not guaranteed to run, be secure, or even compile. > >> Result was that MaraDNS crashed every time after the "Log: Bad query >> received" message. > > - Sam > From: Sam Trenholme To: list@NOSPAM.org Subject: Re: Bad query received Date: Sat, 7 Oct 2006 23:24:29 +0000 (UTC) OK, Peter, I think I've found the problem. Basically, I have recently modified MaraDNS to use the udperror() routine to inform DNS clients that MaraDNS can not contact any remote DNS servers when trying to recursively resolve a given name. Since udperror() used to only be called when there was some fairly serious error in the processing of a DNS request, the udperror() routine always logs a "bad query received" message when called. This, obviously, is not the case when MaraDNS is unable to contact any remote servers in the routine processing of a domain name. I have fixed this issue. Make sure this is fixed. Download the 20061007 (October 7, 2006) snapshot of MaraDNS here: http://www.maradns.org/download/1.2/snap/200610/ It has the filename maradns-Q.20