From maradns at gmail.com Thu Dec 1 12:40:45 2011 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 1 Dec 2011 09:40:45 -0800 Subject: [MaraDNS list] MaraDNS funding update Message-ID: Last month's funding drive gave me enough money to devote my time off during the Thanksgiving week to improve Deadwood's handling of CNAME records, as well as allowing Deadwood's to accurately wait less before giving up on an unresponsive DNS server. Right now, I have enough funds left over to be able to provide basic bug-fix support for MaraDNS and Deadwood on the mailing list for three and a half months. In other words, if I get non-security bug reports or other significant support requests every month, my funding will dry out in mid-March. I currently do not have enough funding to implement split horizon or any other new features. If these features are desirable, please send me a private email and we can discuss rates. - Sam From nicholas at periapt.co.uk Mon Dec 5 16:11:35 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Mon, 05 Dec 2011 21:11:35 +0000 Subject: [MaraDNS list] not fixed upstream after all Message-ID: <4EDD3387.7050101@periapt.co.uk> tags 573970 -fixed-upstream unblock 573970 by 612229 thanks Sam, I don't think include functionality in deadwood addresses the user's issue since he clearly needs it in the authoritative server. In any case the "execfile" documentation is quite hard to follow. Chris, This need not necessarily be an upstream issue. If your processing can handle running dpkg-reconfigure after updating the include file, then this could be accomplished with debconf. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Wed Dec 7 12:54:00 2011 From: maradns at gmail.com (Sam Trenholme) Date: Wed, 7 Dec 2011 09:54:00 -0800 Subject: [MaraDNS list] not fixed upstream after all In-Reply-To: <4EDD3387.7050101@periapt.co.uk> References: <4EDD3387.7050101@periapt.co.uk> Message-ID: > I don't think include functionality in deadwood addresses the user's > issue since he clearly needs it in the authoritative server. In any case > the "execfile" documentation is quite hard to follow. I will add more documentation for "execfile" in Deadwood over the next few days. It's been really hectic the last week; I had one job interview Friday and am flying out today for another interview tomorrow. I should be able to make time to document "execfile" better this weekend. In terms of adding "execfile" support to the authoritative server, my answer before I began accepting donations was "No, because UNIX [1] already has a program called 'bash' that can do this. 'man bash' for details." or "No, because MaraDNS has the /read directive that can do this for zone files.". Now that MaraDNS' continued development and support is user-funded, the answer is "No, because I currently don't have enough funding to implement new features." (Note: I do manage to get a job offer, I may no longer be able to implement new MaraDNS features for reasonable sums of money. I will let the list know when this happens). > This need not necessarily be an upstream issue. If your processing > can handle running dpkg-reconfigure after updating the include file, > then this could be accomplished with debconf. UNIX has a program called 'bash' that can combine multiple files in to a single file. 'man bash' for details. :) - Sam [1] I understand that POSIX does not require that Bash be included with a UNIX system. However, I can not think of a recent implementation of UNIX that doesn't come with BASH (AIX and HP-UX are legacy implementations, not recent implementations. I *believe* Solaris comes with Bash these days; I *know* most Linux distros, BSD, and Mac OS X do come with Bash). If you want to be pedantic about it, just do a s/bash/sh/ig while reading this email. From nicholas at periapt.co.uk Wed Dec 7 14:27:14 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Wed, 07 Dec 2011 19:27:14 +0000 Subject: [MaraDNS list] not fixed upstream after all In-Reply-To: References: <4EDD3387.7050101@periapt.co.uk> Message-ID: <4EDFBE12.7080105@periapt.co.uk> Sam, Good luck with the job interview. On 07/12/11 17:54, Sam Trenholme wrote: >> I don't think include functionality in deadwood addresses the user's >> issue since he clearly needs it in the authoritative server. In any case >> the "execfile" documentation is quite hard to follow. > > I will add more documentation for "execfile" in Deadwood over the next > few days. It's been really hectic the last week; I had one job > interview Friday and am flying out today for another interview > tomorrow. I should be able to make time to document "execfile" better > this weekend. > > In terms of adding "execfile" support to the authoritative server, my > answer before I began accepting donations was "No, because UNIX [1] > already has a program called 'bash' that can do this. 'man bash' for > details." or "No, because MaraDNS has the /read directive that can do > this for zone files.". Now that MaraDNS' continued development and > support is user-funded, the answer is "No, because I currently don't > have enough funding to implement new features." (Note: I do manage to > get a job offer, I may no longer be able to implement new MaraDNS > features for reasonable sums of money. I will let the list know when > this happens). > >> This need not necessarily be an upstream issue. If your processing >> can handle running dpkg-reconfigure after updating the include file, >> then this could be accomplished with debconf. > > UNIX has a program called 'bash' that can combine multiple files in to > a single file. 'man bash' for details. :) > > - Sam > > [1] I understand that POSIX does not require that Bash be included > with a UNIX system. However, I can not think of a recent > implementation of UNIX that doesn't come with BASH (AIX and HP-UX are > legacy implementations, not recent implementations. I *believe* > Solaris comes with Bash these days; I *know* most Linux distros, BSD, > and Mac OS X do come with Bash). If you want to be pedantic about it, > just do a s/bash/sh/ig while reading this email. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Sat Dec 10 23:15:56 2011 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 10 Dec 2011 20:15:56 -0800 Subject: [MaraDNS list] How to use execfile("filename") in Deadwood Message-ID: Also at http://maradns.org/deadwood/doc/execfile-HOWTO.html The execfile mechanism allows one to have Deadwood include another file in the dwood3rc configuration file. For example, let us suppose we want to have a file with a list of domains to be solved by a name server for the Open NIC project. We want to make this an external file, since this information will probably have to be updated more frequently than other configuration data in our dwood3rc file. First, Deadwood requires that the directory /etc/deadwood/execfile exists: $ mkdir /etc/deadwood/ $ mkdir /etc/deadwood/execfile/ This directory should be owned by root. Now, let's take a simple dwood3rc file: bind_address = "127.0.0.1,192.168.42.101" recursive_acl = "127.0.0.0/16,192.168.42.0/24" chroot_dir = "/etc/deadwood" root_servers = {} root_servers["."]="198.41.0.4, 192.228.79.201, 192.33.4.12, 128.8.10.90," root_servers["."]+="192.203.230.10, 192.5.5.241, 192.112.36.4, 128.63.2.53, " root_servers["."]+="192.36.148.17, 192.58.128.30, 193.0.14.129, 199.7.83.42, " root_servers["."]+="202.12.27.33" upstream_servers = {} We now make a file pointing to a recursive server used by the Open NIC project: $ cat > /etc/deadwood/execfile/opennicproject upstream_servers["bit."] = "178.32.31.41" upstream_servers["glue."] = "178.32.31.41" upstream_servers["geek."] = "178.32.31.41" upstream_servers["free."] = "178.32.31.41" upstream_servers["indy."] = "178.32.31.41" upstream_servers["parody."] = "178.32.31.41" upstream_servers["bbs."] = "178.32.31.41" upstream_servers["fur."] = "178.32.31.41" upstream_servers["null."] = "178.32.31.41" upstream_servers["oss."] = "178.32.31.41" upstream_servers["ing."] = "178.32.31.41" upstream_servers["dyn."] = "178.32.31.41" upstream_servers["gopher."] = "178.32.31.41" upstream_servers["micro."] = "178.32.31.41" (At this point hit Ctrl + D at the beginning of a blank line to end the file) This file needs to be referred to by Deadwood, so let's edit the dwood3rc file to refer to it: bind_address = "127.0.0.1,192.168.42.101" recursive_acl = "127.0.0.0/16,192.168.42.0/24" chroot_dir = "/etc/deadwood" root_servers = {} root_servers["."]="198.41.0.4, 192.228.79.201, 192.33.4.12, 128.8.10.90," root_servers["."]+="192.203.230.10, 192.5.5.241, 192.112.36.4, 128.63.2.53, " root_servers["."]+="192.36.148.17, 192.58.128.30, 193.0.14.129, 199.7.83.42, " root_servers["."]+="202.12.27.33" upstream_servers = {} execfile("opennicproject") That's all there is to it. Now, Deadwood will read the contents of the /etc/deadwood/execfile/opennicproject file as if it were part of the dwood3rc file. From maradns at gmail.com Fri Dec 23 13:16:17 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 23 Dec 2011 10:16:17 -0800 Subject: [MaraDNS list] Merry Christmas everyone Message-ID: I would like to thank the whole community of MaraDNS users a very merry Christmas as we wrap up 2011 and move on to 2012. I have made a lot of improvements to MaraDNS and its recursive resolver Deadwood in 2011. Not only have I fixed a number of bugs, but I have also greatly improved Deadwood's speed resolving domains, both by not having it slow down when getting certain problematic packets, and by adding features to speed up resolution. One last thought as 2001 comes to an end: > Deadwood has support for having up to 1,000 different IPs in one's > results black-listed; if we get a DNS reply with a black-listed IP, > the reply is not sent to us. ?For example, the malware authors are > currently using the IP 64.111.199.250 to host these unwanted > redirects. ?To blacklist this, one can add this to one's dwood3rc > file: I would like people to know that the owner of this IP has contacted me and now has a zero-tolerance policy for malware and other click fraud: http://64.111.199.250/ Happy new year 2012! - Sam From Bradley at NorthTech.US Fri Dec 23 20:30:51 2011 From: Bradley at NorthTech.US (Bradley D. Thornton) Date: Fri, 23 Dec 2011 17:30:51 -0800 Subject: [MaraDNS list] Merry Christmas everyone In-Reply-To: References: Message-ID: <4EF52B4B.2010703@NorthTech.US> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 12/23/2011 10:16 AM, Sam Trenholme wrote: > I would like to thank the whole community of MaraDNS users a very > merry Christmas as we wrap up 2011 and move on to 2012. Merry Christmas to you too Sam! And a hearty thanks for your continued support of such a great software suite. > I would like people to know that the owner of this IP has contacted me > and now has a zero-tolerance policy for malware and other click fraud: > http://64.111.199.250/ No doubt an indication of the marketshare MaraDNS enjoys ;) Kindest regards, - -- Bradley D. Thornton Manager Network Services NorthTech Computer TEL: +1.760.666.2703 (US) TEL: +44.203.318.2755 (UK) http://NorthTech.US -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Find this cert at x-hkp://pool.sks-keyservers.net iQEcBAEBAwAGBQJO9StKAAoJEE1wgkIhr9j3pNQH/1cJpQWLDO1V/HGhgwdAGGXY J1i5bya20O3PCAOJHsPyBBJQhTeBd5w+Pi1hGI3gHkHWJJToXc51SiDcUBINPdsF EVgWK+FlWi3u6pqVQKDy5SRfc86GpZVk+94BdHvmr/9Lt3T1ioQ7xuMH/pU01wvX 2A+SZT7w2PL7w5yEJxUMI1BygzWk5icMuQF4911TdvADPrZFsie602X6m7352Awa R+ATHRmEyrNEY23QZDrFNXbPOwUz/h8IXUI0WT4CgTNBhYakID9rfb2VGLeR/6zd g8f9RkVj+hyJgP8/CtmZai77oAkrOi5qA5G8XByXVHl0jFvmIKClJz+F+Q8fhzc= =1SyR -----END PGP SIGNATURE----- From jefsey at jefsey.com Sat Dec 24 20:32:54 2011 From: jefsey at jefsey.com (JFC Morfin) Date: Sun, 25 Dec 2011 02:32:54 +0100 Subject: [MaraDNS list] Merry Christmas everyone In-Reply-To: <4EF52B4B.2010703@NorthTech.US> References: <4EF52B4B.2010703@NorthTech.US> Message-ID: <7.0.1.0.2.20111225022700.05d29d18@jefsey.com> Merry Xmas to you Sam and to your spouse. Thank you for maraDNS and all. jfc At 02:30 24/12/2011, Bradley D. Thornton wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: RIPEMD160 > > > >On 12/23/2011 10:16 AM, Sam Trenholme wrote: > > I would like to thank the whole community of MaraDNS users a very > > merry Christmas as we wrap up 2011 and move on to 2012. > >Merry Christmas to you too Sam! > >And a hearty thanks for your continued support of such a great software >suite. > > > > I would like people to know that the owner of this IP has contacted me > > and now has a zero-tolerance policy for malware and other click fraud: > > http://64.111.199.250/ > >No doubt an indication of the marketshare MaraDNS enjoys ;) > >Kindest regards, > > >- -- >Bradley D. Thornton >Manager Network Services >NorthTech Computer >TEL: +1.760.666.2703 (US) >TEL: +44.203.318.2755 (UK) >http://NorthTech.US > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.10 (GNU/Linux) >Comment: Find this cert at x-hkp://pool.sks-keyservers.net > >iQEcBAEBAwAGBQJO9StKAAoJEE1wgkIhr9j3pNQH/1cJpQWLDO1V/HGhgwdAGGXY >J1i5bya20O3PCAOJHsPyBBJQhTeBd5w+Pi1hGI3gHkHWJJToXc51SiDcUBINPdsF >EVgWK+FlWi3u6pqVQKDy5SRfc86GpZVk+94BdHvmr/9Lt3T1ioQ7xuMH/pU01wvX >2A+SZT7w2PL7w5yEJxUMI1BygzWk5icMuQF4911TdvADPrZFsie602X6m7352Awa >R+ATHRmEyrNEY23QZDrFNXbPOwUz/h8IXUI0WT4CgTNBhYakID9rfb2VGLeR/6zd >g8f9RkVj+hyJgP8/CtmZai77oAkrOi5qA5G8XByXVHl0jFvmIKClJz+F+Q8fhzc= >=1SyR >-----END PGP SIGNATURE----- From vaebris at 0xeb.info Wed Dec 28 19:06:06 2011 From: vaebris at 0xeb.info (William) Date: Wed, 28 Dec 2011 17:06:06 -0700 Subject: [MaraDNS list] Csv2 delimiters Message-ID: <4EFBAEEE.2070006@0xeb.info> Hello, Is there a reason that , isn't a valid delimiter in csv2 zone files? I'm new to MaraDNS and I figure there's probably a reason that was omitted I just don't know it. If it won't screw anything up I'll give you my patch to add it if anyone is interested. Best Regards, William From vaebris at 0xeb.info Thu Dec 29 01:07:10 2011 From: vaebris at 0xeb.info (William) Date: Wed, 28 Dec 2011 23:07:10 -0700 Subject: [MaraDNS list] Limiting DNS requests Message-ID: <4EFC038E.4040306@0xeb.info> Hello, I'm wondering if there's a way to limit dns responses by IP. For example csv2["example.net."] = "example.net" csv2["test.net."] = "test.net" ipv4_bind_addresses = "10.0.0.2, 10.0.0.3, 10.0.0.4, 10.0.0.5" example.net has name servers pointed at 10.0.0.2 and 10.0.0.3 test.net has name servers pointed at 10.0.0.4 and 10.0.0.5 If I query 10.0.0.4 for example.net it will return the queries. Is it possible for it to return not found? Best Regards, William From maradns at gmail.com Thu Dec 29 05:16:33 2011 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 29 Dec 2011 02:16:33 -0800 Subject: [MaraDNS list] Csv2 delimiters In-Reply-To: <4EFBAEEE.2070006@0xeb.info> References: <4EFBAEEE.2070006@0xeb.info> Message-ID: It makes the parser a little simpler, and I prefer using the pipe (|) as a delimiter because it's less common than a comma. While I'll happily host a patch to change this, I actually won't merge a patch to make the , a delimiter, since I would then be the one responsible for any bugs introduced by said patch. - Sam On Wed, Dec 28, 2011 at 4:06 PM, William wrote: > Hello, > > Is there a reason that , isn't a valid delimiter in csv2 zone files? I'm new > to MaraDNS and I figure there's probably a reason that was omitted I just > don't know it. If it won't screw anything up I'll give you my patch to add > it if anyone is interested. > > Best Regards, > William From maradns at gmail.com Thu Dec 29 05:21:18 2011 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 29 Dec 2011 02:21:18 -0800 Subject: [MaraDNS list] Limiting DNS requests In-Reply-To: <4EFC038E.4040306@0xeb.info> References: <4EFC038E.4040306@0xeb.info> Message-ID: This is called "split horizon" and no, MaraDNS doesn't implement it. While my tip jar is full enough to answer this email, it's not quite full enough for me to bother implementing this. Also, there's some issues with how the hash of DNS records is indexed by MaraDNS to make this a little tricky to shoehorn in to the current code. The workaround, of course, is to run multiple copies of MaraDNS. MaraDNS is small enough that this is not unreasonable. - Sam On Wed, Dec 28, 2011 at 10:07 PM, William wrote: > Hello, > > I'm wondering if there's a way to limit dns responses by IP. For example > > csv2["example.net."] = "example.net" > csv2["test.net."] = "test.net" > > ipv4_bind_addresses = "10.0.0.2, 10.0.0.3, 10.0.0.4, 10.0.0.5" > > example.net has name servers pointed at 10.0.0.2 and 10.0.0.3 > test.net has name servers pointed at 10.0.0.4 and 10.0.0.5 > > If I query 10.0.0.4 for example.net it will return the queries. Is it > possible for it to return not found? > > Best Regards, > William From maradns at gmail.com Thu Dec 29 12:16:30 2011 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 29 Dec 2011 09:16:30 -0800 Subject: [MaraDNS list] Hash compression function attacks: Deadwood is immune Message-ID: There has been a lot of noise being made about programs being vulnerable to denial of service attacks because attacksers can find collisions in their hash compression function. MaraDNS 2.0 is immune to these kinds of attack; I knew about these attacks back in 2007 when designing Deadwood's hash compression function, and further hardened Deadwood against them in September of 2010. From the Deadwood man page: To protect Deadwood from certain possible denial-of-service attacks, it is best if Deadwood's prime number used for hashing elements in the cache is a random 31-bit prime number. The program RandomPrime.c generates a random prime that is placed in the file DwRandPrime.h that is regenerated whenever either the program is compiled or things are cleaned up with make clean. This program uses /dev/urandom for its entropy; the file DwRandPrime.h will not be regenerated on systems without /dev/urandom. [...] If using a precompiled binary of Deadwood, please ensure that the system has /dev/urandom support (on Windows system, please ensure that the file with the name secret.txt is generated by the included mkSecretTxt.exe program); Deadwood, at runtime, uses /dev/urandom (secret.txt in Windows) as a hardcoded path to get entropy (along with the timestamp) for the hash algorithm. I haven't had a chance to see if MaraDNS 1.0's recursive code is vulnerable to this attack; it might be and if it is, I will release a patch. But Deadwood users don't need to worry about this attack, because I already was worrying about it four years ago. - Sam From maradns at gmail.com Thu Dec 29 14:35:12 2011 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 29 Dec 2011 11:35:12 -0800 Subject: [MaraDNS list] MaraDNS 1.4.08 and MaraDNS 1.3.07.12 released Message-ID: One issue with making software is that a responsible programmer takes responsibility for his mistakes. Even if the mistakes were made years ago. MaraDNS is a lot of code dating back to 2001; even though a good deal of the code has been completely rewritten, I still take responsibility for code I wrote in 2001 and 2002. I very strongly encourage people still using MaraDNS 1.x's recursive code to upgrade to MaraDNS 2, and use Deadwood to process recursive queries. I have completely rewritten the code from the ground up -- Deadwood shares no code whatsoever with MaraDNS -- and did a better job of it the second time around. The new Deadwood recursive resolver, for example, has been using randomized hashes since 2007, and today's hash randomization attack making the rounds has never affected Deadwood. The older MaraDNS 1.x recursive code, however, did not use a randomized hash. While people really should be using Deadwood for recursive queries, I have released MaraDNS 1.4.08 and MaraDNS 1.3.07.12 with an updated randomized hash. For anyone who is still using MaraDNS 1, it is important to upgrade to this version in order so that hashes are randomized and not vulnerable to hash collision denial of service attacks. Or better yet, upgrade to MaraDNS 2. Note that a randomized hash needs a source of entropy; that in mind, the *NIX version of MaraDNS 1.4.08/1.3.07.12 requires /dev/urandom and the Windows version of MaraDNS needs "secret.txt" in the same directory as "maradns.exe". People running MaraDNS 1 on *NIX systems without /dev/urandom are on their own -- I do not support MaraDNS on anything besides CentOS, Scientific Linux, and Windows. Note that this security bug only affects you if: 1) You are using MaraDNS 1, *not* MaraDNS 2 2) recursive_acl is set in MaraDNS 1 3) Untrusted potential attackers can perform recursive queries with MaraDNS 1. For example, if using MaraDNS 1 as described in http://samiam.org/blog/20111128.html, one is safe as long as one's mararc file recursive_acl line looks like this: recursive_acl = "127.0.0.1/8" The tarballs files can be found here: http://maradns.org/download/1.3 http://maradns.org/download/1.4 (also has Windows binary) The patch is here: http://maradns.org/download/patches/maradns-1.3-secret_hash.patch - Sam From vaebris at 0xeb.info Thu Dec 29 16:26:22 2011 From: vaebris at 0xeb.info (William) Date: Thu, 29 Dec 2011 14:26:22 -0700 Subject: [MaraDNS list] Limiting DNS requests In-Reply-To: References: <4EFC038E.4040306@0xeb.info> Message-ID: <4EFCDAFE.8000908@0xeb.info> On 12/29/2011 3:21 AM, Sam Trenholme wrote: > This is called "split horizon" and no, MaraDNS doesn't implement it. > While my tip jar is full enough to answer this email, it's not quite > full enough for me to bother implementing this. Also, there's some > issues with how the hash of DNS records is indexed by MaraDNS to make > this a little tricky to shoehorn in to the current code. > > The workaround, of course, is to run multiple copies of MaraDNS. > MaraDNS is small enough that this is not unreasonable. > > - Sam I guess it's a good thing I wasn't asking or expecting you to implement it then :-). Running multiple instances is what I plan to do. Best Regards, William From vaebris at 0xeb.info Thu Dec 29 17:02:25 2011 From: vaebris at 0xeb.info (William) Date: Thu, 29 Dec 2011 15:02:25 -0700 Subject: [MaraDNS list] Csv2 delimiters In-Reply-To: References: <4EFBAEEE.2070006@0xeb.info> Message-ID: <4EFCE371.5090204@0xeb.info> On 12/29/2011 3:16 AM, Sam Trenholme wrote: > It makes the parser a little simpler, and I prefer using the pipe (|) > as a delimiter because it's less common than a comma. While I'll > happily host a patch to change this, I actually won't merge a patch to > make the , a delimiter, since I would then be the one responsible for > any bugs introduced by said patch. > > - Sam > > On Wed, Dec 28, 2011 at 4:06 PM, William wrote: >> Hello, >> >> Is there a reason that , isn't a valid delimiter in csv2 zone files? I'm new >> to MaraDNS and I figure there's probably a reason that was omitted I just >> don't know it. If it won't screw anything up I'll give you my patch to add >> it if anyone is interested. >> >> Best Regards, >> William That's a good point. I'll send the patch in a little bit if you want to put it up. So far I'm pretty impressed with MaraDNS good job. From nicholas at periapt.co.uk Fri Dec 30 14:13:26 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Fri, 30 Dec 2011 19:13:26 +0000 Subject: [MaraDNS list] MaraDNS 1.4.08 and MaraDNS 1.3.07.12 released In-Reply-To: References: Message-ID: <4EFE0D56.20908@periapt.co.uk> Sam, Thanks for staying on top of security. I notice that the online changelog has not been updated. On 29/12/11 19:35, Sam Trenholme wrote: > One issue with making software is that a responsible programmer takes > responsibility for his mistakes. Even if the mistakes were made years > ago. MaraDNS is a lot of code dating back to 2001; even though a good > deal of the code has been completely rewritten, I still take > responsibility for code I wrote in 2001 and 2002. > > I very strongly encourage people still using MaraDNS 1.x's recursive > code to upgrade to MaraDNS 2, and use Deadwood to process recursive > queries. I have completely rewritten the code from the ground up -- > Deadwood shares no code whatsoever with MaraDNS -- and did a better > job of it the second time around. > > The new Deadwood recursive resolver, for example, has been using > randomized hashes since 2007, and today's hash randomization attack > making the rounds has never affected Deadwood. The older MaraDNS 1.x > recursive code, however, did not use a randomized hash. While people > really should be using Deadwood for recursive queries, I have released > MaraDNS 1.4.08 and MaraDNS 1.3.07.12 with an updated randomized hash. > > For anyone who is still using MaraDNS 1, it is important to upgrade to > this version in order so that hashes are randomized and not vulnerable > to hash collision denial of service attacks. Or better yet, upgrade > to MaraDNS 2. > > Note that a randomized hash needs a source of entropy; that in mind, > the *NIX version of MaraDNS 1.4.08/1.3.07.12 requires /dev/urandom and > the Windows version of MaraDNS needs "secret.txt" in the same > directory as "maradns.exe". People running MaraDNS 1 on *NIX systems > without /dev/urandom are on their own -- I do not support MaraDNS on > anything besides CentOS, Scientific Linux, and Windows. > > Note that this security bug only affects you if: > > 1) You are using MaraDNS 1, *not* MaraDNS 2 > > 2) recursive_acl is set in MaraDNS 1 > > 3) Untrusted potential attackers can perform recursive queries with MaraDNS 1. > > For example, if using MaraDNS 1 as described in > http://samiam.org/blog/20111128.html, one is safe as long as one's > mararc file recursive_acl line looks like this: > > recursive_acl = "127.0.0.1/8" > > The tarballs files can be found here: > > http://maradns.org/download/1.3 > > http://maradns.org/download/1.4 (also has Windows binary) > > The patch is here: > > http://maradns.org/download/patches/maradns-1.3-secret_hash.patch > > - Sam -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Fri Dec 30 16:11:48 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 30 Dec 2011 13:11:48 -0800 Subject: [MaraDNS list] MaraDNS 1.4.08 and MaraDNS 1.3.07.12 released In-Reply-To: <4EFE0D56.20908@periapt.co.uk> References: <4EFE0D56.20908@periapt.co.uk> Message-ID: > ? ? ? ?Thanks for staying on top of security. I notice that the online > changelog has not been updated. Done. Yesterday, I updated MaraDNS 1, posted to the mailing list the update, updated the Sourceforge version of MaraDNS, and posted a blog about the issue. Today, I have updated the relevant MaraDNS web pages: http://maradns.org/security.html http://maradns.org/changelog.html Again, Deadwood (MaraDNS 2) has never had this problem; it only impacts users of MaraDNS 1's recursive resolver. - Sam From maradns at gmail.com Fri Dec 30 16:17:45 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 30 Dec 2011 13:17:45 -0800 Subject: [MaraDNS list] MaraDNS 1.4.08 and MaraDNS 1.3.07.12 released In-Reply-To: <4EFE0D56.20908@periapt.co.uk> References: <4EFE0D56.20908@periapt.co.uk> Message-ID: In terms of issuing a Debian security update: MaraDNS 2 is not affected and does not need to be patched. I have a minimal patch fixing only this security issue: http://maradns.org/download/patches/maradns-1.3-secret_hash.patch The patch requires /dev/urnadom; Debian has this. [1] While there isn't a CVE for this issue in relation to MaraDNS, the problem is covered by CERT VU#903934 [2] - Sam [1] There really isn't much out there besides DOS and Windows that doesn't have /dev/urandom these days. [2] This will hopefully preclude Debian's bureaucratic hoop of needing a vulnerability number before patching MaraDNS From maradns at gmail.com Fri Dec 30 16:20:26 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 30 Dec 2011 13:20:26 -0800 Subject: [MaraDNS list] Csv2 delimiters In-Reply-To: <4EFCE371.5090204@0xeb.info> References: <4EFBAEEE.2070006@0xeb.info> <4EFCE371.5090204@0xeb.info> Message-ID: Let me know when the patch is ready. I will add it to http://maradns.org/download/patches/ When sending attachments, please CC this email address, since the listserv scrubs attachments. - Sam On Thu, Dec 29, 2011 at 2:02 PM, William wrote: > On 12/29/2011 3:16 AM, Sam Trenholme wrote: >> >> It makes the parser a little simpler, and I prefer using the pipe (|) >> as a delimiter because it's less common than a comma. ?While I'll >> happily host a patch to change this, I actually won't merge a patch to >> make the , a delimiter, since I would then be the one responsible for >> any bugs introduced by said patch. >> >> - Sam >> >> On Wed, Dec 28, 2011 at 4:06 PM, William ?wrote: >>> >>> Hello, >>> >>> Is there a reason that , isn't a valid delimiter in csv2 zone files? I'm >>> new >>> to MaraDNS and I figure there's probably a reason that was omitted I just >>> don't know it. If it won't screw anything up I'll give you my patch to >>> add >>> it if anyone is interested. >>> >>> Best Regards, >>> William > > That's a good point. ?I'll send the patch in a little bit if you want to put > it up. So far I'm pretty impressed with MaraDNS good job. From maradns at gmail.com Fri Dec 30 16:26:51 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 30 Dec 2011 13:26:51 -0800 Subject: [MaraDNS list] Limiting DNS requests In-Reply-To: <4EFCDAFE.8000908@0xeb.info> References: <4EFC038E.4040306@0xeb.info> <4EFCDAFE.8000908@0xeb.info> Message-ID: >> While my tip jar is full enough to answer this email, it's not quite >> full enough for me to bother implementing this. > I guess it's a good thing I wasn't asking or expecting you to implement it > then :-) I would love to be paid enough money to work on MaraDNS full time. If I were, I could have a working DNSSEC prototype going in six months and have stable code with DNSSEC done by the end of the year. I could then merge the authoritative code with the recursive code again, along with a stand-alone recursive daemon for people who need just recursion (just as there is a non-recursive caching-only version of Deadwood for people who do not need full DNS recursion). If I could find an employer willing to have me work on MaraDNS every other Friday, I probably wouldn't be able to implement DNSSEC nor full merging of the two code bases, but I could implement features people have been asking for, such a split horizon, including other files in one's mararc, and so on. - Sam From maradns at gmail.com Fri Dec 30 17:41:33 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 30 Dec 2011 14:41:33 -0800 Subject: [MaraDNS list] MaraDNS 1.3.07.13 and MaraDNS 1.4.09 released Message-ID: Looking closely at the patch I applied yesterday, I realized that it has a couple of problems: * Instead of the hash randomization having 24 bits of entropy, it only had 2 to 5 bits of entropy * The hash randomization would sometimes not do a good job of randomizing the hash buckets chosen, slowing down MaraDNS' performance This in mind, I have release MaraDNS 1.3.07.13 and MaraDNS 1.4.09 today with both of these issues fixed. The hash randomization now has 31 bits of entropy, and the hash does a fairly good job of choosing a random hash bucket again. Done: * I have replaced the secret_hash patch with a better "better_hash" patch: http://maradns.org/download/patches/maradns-1.3-better_hash.patch * I have replaced 1.3.07.12 and 1.4.08 with 1.3.07.13 and 1.4.09 * I am informing the mailing list of this update Still to do (later on tonight or tomorrow): * Make the Windows version of MaraDNS 1.4.09 * Upload 1.4.09 to Sourceforge * Update the MaraDNS security page * Update the MaraDNS blog - Sam From nicholas at periapt.co.uk Fri Dec 30 18:45:44 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Fri, 30 Dec 2011 23:45:44 +0000 Subject: [MaraDNS list] MaraDNS 1.4.08 and MaraDNS 1.3.07.12 released In-Reply-To: References: <4EFE0D56.20908@periapt.co.uk> Message-ID: <4EFE4D28.5080405@periapt.co.uk> Sam, 1.4.08-1 is in preparation whatever the bureaucracy. I have asked the Debian security team what they want to do with the old releases. On 30/12/11 21:17, Sam Trenholme wrote: > In terms of issuing a Debian security update: > > MaraDNS 2 is not affected and does not need to be patched. > > I have a minimal patch fixing only this security issue: > > http://maradns.org/download/patches/maradns-1.3-secret_hash.patch > > The patch requires /dev/urnadom; Debian has this. [1] > > While there isn't a CVE for this issue in relation to MaraDNS, the > problem is covered by CERT VU#903934 [2] > > - Sam > > [1] There really isn't much out there besides DOS and Windows that > doesn't have /dev/urandom these days. > > [2] This will hopefully preclude Debian's bureaucratic hoop of needing > a vulnerability number before patching MaraDNS -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Fri Dec 30 22:39:40 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 30 Dec 2011 19:39:40 -0800 Subject: [MaraDNS list] MaraDNS 1.3.07.13 and MaraDNS 1.4.09 released In-Reply-To: References: Message-ID: > Still to do (later on tonight or tomorrow): > > * Make the Windows version of MaraDNS 1.4.09 > > * Upload 1.4.09 to Sourceforge > > * Update the MaraDNS security page > > * Update the MaraDNS blog Done. I've also updated the MaraDNS changelog. http://maradns.org/download/1.4 http://maradns.org/download/1.3 Also: MaraDNS' 1.3 EOL is December 12, 2012, so anyone still using it needs to update MaraDNS soon. - Sam From maradns at gmail.com Fri Dec 30 23:00:55 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 30 Dec 2011 20:00:55 -0800 Subject: [MaraDNS list] MaraDNS 1.4.08 and MaraDNS 1.3.07.12 released In-Reply-To: <4EFE4D28.5080405@periapt.co.uk> References: <4EFE0D56.20908@periapt.co.uk> <4EFE4D28.5080405@periapt.co.uk> Message-ID: > 1.4.08-1 is in preparation whatever the bureaucracy. I have asked the > Debian security team what they want to do with the old releases. If reasonably easy to do, it's probably better to upload 1.4.09; I kinda-sorta borked the hash compression function in 1.4.08. Also, the backport patch for older MaraDNS releases has been replaced: http://ns1.maradns.org/download/patches/maradns-1.3-better_hash.patch - Sam