From remco at webconquest.com Mon Feb 1 00:35:56 2010 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 01 Feb 2010 06:35:56 +0100 Subject: MaraDNS on OpenWRT In-Reply-To: <4B66493F.6090202@messageme.de> References: <4B66493F.6090202@messageme.de> Message-ID: <4B66683C.5020908@webconquest.com> Sebastian M?ller schreef: > Hi, > > I am running OpenWRT 8.09 with MaraDNS 1.3.07.08-1 > > Since I didn't find any bug-reports or alike I am posting here. Maybe > it's even not a bug. And I can solve my problem with your assistance. > > > In my network there is a windows 7, a windows xp and a debian sid box. > All traffic is routed through a Linksys Router with OpenWRT. > > Both windows systems are never having any problems in resolving dns from > the openwrt router. > > But the debian box got. > When typing "dig somedomain.com", the maradns is resolving. "ping > somedomain.com" is working fine, too. > But a "telnet somedomain.com XY" prints "telnet: could not resolve > somedomain.com/XY: Name or service not known" > The same happens with ssh and ftp and so on too. > When I type "telnet -4 somedomain.com XY" the resolving works. > > First I thought that this is some kind of strange IPv6 problem - but my > router doesn't have IPv6, the debian box and the windows boxes neigther. > > So I tried a server running maradns, placed outside of my LAN. > Everything works, the debian box is resolving everything without any > problems. "telnet somedomain.com XY" is working just fine. > The server doesn't got ipv6. > > So I replaced maradns on openwrt router by bind9 package. And everything > is working, too. > > Is it a bug in maradns? Hi Sebastian, To be honest I don't have the faintest idea what could be the issue here. Can you try it using a more recent version of maradns and see if you still have the observed issue? The version that's currently on your OpenWRT box is from late 2007 and there have been a few stable releases since then. Sorry that I can't be of further help with your problem here. Kind regards, Remco Rijnders From strenholme.usenet at gmail.com Mon Feb 1 02:25:55 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 1 Feb 2010 01:25:55 -0600 Subject: MaraDNS on OpenWRT In-Reply-To: <4B66493F.6090202@messageme.de> References: <4B66493F.6090202@messageme.de> Message-ID: <7bd685721001312325w7006b91dtba215a41460a794b@mail.gmail.com> > But the debian box got. > When typing "dig somedomain.com", the maradns is resolving. "ping > somedomain.com" is working fine, too. > But a "telnet somedomain.com XY" prints "telnet: could not resolve > somedomain.com/XY: Name or service not known" > The same happens with ssh and ftp and so on too. > When I type "telnet -4 somedomain.com XY" the resolving works. It would help more if you could us a real-world example of this problem. > Is it a bug in maradns? Who knows? It could be anything, and we don't have enough information to even begin troubleshooting. My wild ass guess, since you haven't given us any real information, is that this is the CNAME-and-AAAA bug which is, like all non-security MaraDNS 1.0 recursive bugs, won't be fixed unless: 1) You pay me to fix it 2) You can show how this bug results in a security problem 3) This bug causes an A or MX query for an Alexa top 500 site to not resolve at all. Again, and I've posted this to the list before: I'm working on MaraDNS 2.0 so am no longer fixing non-critical MaraDNS 1.0 recursive bugs. If you read my blog at http://maradns.blogspot.com you can see I finally got over the burnout I had last September and am working on the recursive core for MaraDNS 2.0 again. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From spamcatch-maradns.org at messageme.de Mon Feb 1 08:07:12 2010 From: spamcatch-maradns.org at messageme.de (=?ISO-8859-15?Q?Sebastian_M=FCller?=) Date: Mon, 01 Feb 2010 14:07:12 +0100 Subject: MaraDNS on OpenWRT In-Reply-To: <4B66683C.5020908@webconquest.com> References: <4B66493F.6090202@messageme.de> <4B66683C.5020908@webconquest.com> Message-ID: <4B66D200.5080600@messageme.de> Am 01.02.2010 06:35, schrieb Remco Rijnders: > Sebastian M?ller schreef: >> >> > > Hi Sebastian, > > To be honest I don't have the faintest idea what could be the issue > here. Can you try it using a more recent version of maradns and see if > you still have the observed issue? The version that's currently on your > OpenWRT box is from late 2007 and there have been a few stable releases > since then. Sorry that I can't be of further help with your problem here. > > Kind regards, > > Remco Rijnders > > I will try to compile the latest version of maradns for openwrt. It could take a little. Thanks for this hint. From spamcatch-maradns.org at messageme.de Mon Feb 1 10:02:57 2010 From: spamcatch-maradns.org at messageme.de (=?ISO-8859-1?Q?Sebastian_M=FCller?=) Date: Mon, 01 Feb 2010 16:02:57 +0100 Subject: MaraDNS on OpenWRT In-Reply-To: <7bd685721001312325w7006b91dtba215a41460a794b@mail.gmail.com> References: <4B66493F.6090202@messageme.de> <7bd685721001312325w7006b91dtba215a41460a794b@mail.gmail.com> Message-ID: <4B66ED21.8030605@messageme.de> Am 01.02.2010 08:25, schrieb Sam Trenholme: > > It would help more if you could us a real-world example of this problem. > Ok, OpenWRT Router = 192.168.2.1 debian sid = 192.168.2.101 Windows XP = 192.168.2.103 Windows 7 = 192.168.2.102 Gateway at 192.168.2.2 MaraDNS outside the LAN 85.93.18.63 MaraDNS inside the LAN 192.168.2.1 using 192.168.2.1 as DNS Server Win7: no problems WinXP: no problems debian sid: dig pop3.web.de -> working ping pop3.web.de -> working telnet pop3.web.de 110 -> not resolving telnet -4 pop3.web.de 110 -> working using 85.93.18.63 as DNS Server Win7: no problems WinXP: no problems debian sid: dig pop3.web.de -> working ping pop3.web.de -> working telnet pop3.web.de 110 -> working telnet -4 pop3.web.de 110 -> working > Who knows? It could be anything, and we don't have enough information > to even begin troubleshooting. > I turned logging on (4) on both dns servers an attached both query results. Nevertheless I will now investigate in building latest stable maradns for openwrt. Cheers, Sebastian -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: telnet google.de 85.93.18.63.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: telnet google.de 192.168.2.1.txt URL: From strenholme.usenet at gmail.com Mon Feb 1 11:26:35 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 1 Feb 2010 10:26:35 -0600 Subject: MaraDNS on OpenWRT In-Reply-To: <4B66ED21.8030605@messageme.de> References: <4B66493F.6090202@messageme.de> <7bd685721001312325w7006b91dtba215a41460a794b@mail.gmail.com> <4B66ED21.8030605@messageme.de> Message-ID: <7bd685721002010826w9c8c226y26dd47ce5d40df78@mail.gmail.com> > I turned logging on (4) on both dns servers an attached both query > results. Nevertheless I will now investigate in building latest stable > maradns for openwrt. Thanks a lot for the logs. I am seeing some AAAA queries there, so you may be able to resolve the issue by adding the following to your mararc file: reject_aaaa = 1 Note to self: Document this parameter, as well as reject_ptr. Let us know if this resolves your concern, and thank you for your bug report. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From spamcatch-maradns.org at messageme.de Mon Feb 1 11:43:59 2010 From: spamcatch-maradns.org at messageme.de (=?ISO-8859-1?Q?Sebastian_M=FCller?=) Date: Mon, 01 Feb 2010 17:43:59 +0100 Subject: MaraDNS on OpenWRT In-Reply-To: <7bd685721002010826w9c8c226y26dd47ce5d40df78@mail.gmail.com> References: <4B66493F.6090202@messageme.de> <7bd685721001312325w7006b91dtba215a41460a794b@mail.gmail.com> <4B66ED21.8030605@messageme.de> <7bd685721002010826w9c8c226y26dd47ce5d40df78@mail.gmail.com> Message-ID: <4B6704CF.70705@messageme.de> Am 01.02.2010 17:26, schrieb Sam Trenholme: >> I turned logging on (4) on both dns servers an attached both query >> results. Nevertheless I will now investigate in building latest stable >> maradns for openwrt. > > Thanks a lot for the logs. I am seeing some AAAA queries there, so > you may be able to resolve the issue by adding the following to your > mararc file: > > reject_aaaa = 1 > > Note to self: Document this parameter, as well as reject_ptr. > > Let us know if this resolves your concern, and thank you for your bug report. > Everything is working now on the OpenWRT Router. Thank you for your help! reject_aaaa = 1 did the job. :) Cheers, Sebastian From strenholme.usenet at gmail.com Mon Feb 1 12:39:22 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 1 Feb 2010 11:39:22 -0600 Subject: MaraDNS on OpenWRT In-Reply-To: <4B6704CF.70705@messageme.de> References: <4B66493F.6090202@messageme.de> <7bd685721001312325w7006b91dtba215a41460a794b@mail.gmail.com> <4B66ED21.8030605@messageme.de> <7bd685721002010826w9c8c226y26dd47ce5d40df78@mail.gmail.com> <4B6704CF.70705@messageme.de> Message-ID: <7bd685721002010939i3f0438d4hf94342a1faeaaeb5@mail.gmail.com> > Everything is working now on the OpenWRT Router. > Thank you for your help! reject_aaaa = 1 did the job. :) I will add a FAQ entry about this tonight and make sure reject_aaaa and reject_ptr are documented in the next 1.4 MaraDNS release. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Mon Feb 1 23:59:48 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 1 Feb 2010 22:59:48 -0600 Subject: MaraDNS on OpenWRT In-Reply-To: <7bd685721002010939i3f0438d4hf94342a1faeaaeb5@mail.gmail.com> References: <4B66493F.6090202@messageme.de> <7bd685721001312325w7006b91dtba215a41460a794b@mail.gmail.com> <4B66ED21.8030605@messageme.de> <7bd685721002010826w9c8c226y26dd47ce5d40df78@mail.gmail.com> <4B6704CF.70705@messageme.de> <7bd685721002010939i3f0438d4hf94342a1faeaaeb5@mail.gmail.com> Message-ID: <7bd685721002012059x6e7521abn9212410227120678@mail.gmail.com> > I will add a FAQ entry about this tonight and make sure reject_aaaa > and reject_ptr are documented in the next 1.4 MaraDNS release. Done: http://www.maradns.org/faq.html#reject http://www.maradns.org/tutorial/man.mararc.html - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Tue Feb 2 13:00:36 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 2 Feb 2010 12:00:36 -0600 Subject: MaraDNS minor security update Message-ID: <7bd685721002021000o76eb3290la9b0d0c562f8cbbb@mail.gmail.com> I have released MaraDNS 1.4.03 and 1.3.07.10 today. This fixes a minor security issue; MaraDNS' first known security problem since 2007. There was a bug introduced in MaraDNS 1.3.03 (January 2007): Hostnames that incorrectly not end with a dot result in a string being deallocated then used. MaraDNS 1.2 does not have this issue. This issue can not be exploited from zones loaded using DNS's zone transfer mechanism; fetchzone filters data obtained this way. This issue can only be exploited in the unusual case of an attacker having control of the contents of a csv2 zone file to be parsed by MaraDNS. This issue, on Linux systems, results in a null pointer dereference that terminates that MaraDNS process. Impact: Denial of service This issue is now fixed in MaraDNS 1.4.03 and 1.3.07.10, released February 2, 2010. I have already talked with the relevant people at Debian, who feel this bug is not serious enough to warrant a new stable release of MaraDNS in the Debian repositories. The updated files can be downloaded here: http://www.maradns.org/download.html http://sourceforge.net/projects/maradns/ Note also that MaraDNS 1.4.03 documents the reject_aaaa/ptr parameters, as per this weekend's discussion on the list. Personal note: There is a possibility that some hard core DJB advocate will say "Look at how buggy MaraDNS is; you should use DJBdns instead". May I point out, to this imaginary annoying advocate (I love making up people who are the worst of the types of twits the internet has), that DJBdns has three security problems, including a remote denial of service and a way to spoof records with DJBdns. May I also point out this bug was added during the process of adding a feature users want: BIND zone file support. If I had kept with MaraDNS 1.0's ugly zone file format, I would not have had this bug. There is a balance between security and features; it is not good to make a program with almost no features then proclaim "I'm more secure than everyone else!". Security is a process; there is no such thing as a perfectly secure program. The only way to keep a program secure is to be honest about the program's security problems and patch them in a timely manner. DJBdns is still insecure because DJB walked away from this program a decade ago, and has since made no updates (except finally making the license reasonable in 2007). - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited.