From strenholme.usenet at gmail.com Mon Sep 5 22:51:11 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 5 Sep 2011 22:51:11 -0400 Subject: [MaraDNS list] Deadwood update Message-ID: I am slowly but surely going through the bugs people have been reporting on the list: * Steve Fatula reported that Deadwood was returning SERVER FAILs on his system. I was and still am unable to reproduce this bug. In an attempt to reproduce this concern, I have created a SQA test that simulates one of the two upstream servers giving out a SERVER FAIL error; this test did not reproduce the condition Steve reported. I am closing this bug as "unreproducible". * Domenico Rotondi reported having issues when both root_servers and upstream_servers are set in a dwood3rc file. I have created a SQA test to use both of these settings in the same Deadwood configuration file; the tests appear to be able to reproduce this problem; I will investigate further in a month. * Angel reported that some records were lost when transferring a zone. I have not had a chance to look at this yet. Hopefully next month. It can be downloaded here: http://www.maradns.org/deadwood/snap/ The next day I plan to work on MaraDNS/Deadwood is one month from today: October 5, 2011. - Sam From strenholme.usenet at gmail.com Tue Sep 6 09:32:54 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 6 Sep 2011 09:32:54 -0400 Subject: [MaraDNS list] Fwd: Deadwood timing out on lookup In-Reply-To: <1312614918.67919.YahooMailNeo@web39422.mail.mud.yahoo.com> References: <1312577679.12702.YahooMailNeo@web39420.mail.mud.yahoo.com> <1312609366.71833.YahooMailNeo@web39403.mail.mud.yahoo.com> <1312614918.67919.YahooMailNeo@web39422.mail.mud.yahoo.com> Message-ID: This message never got posted to the mailing list, so I'm forwarding it here so people understand why it is I did a "one server returns server fail" SQA test for Deadwood. ---------- Forwarded message ---------- From: Steve Fatula Date: 2011/8/6 Subject: Re: [MaraDNS list] Deadwood timing out on lookup To: Sam Trenholme Here's something really weird.... When I add the verbose_level = 1000, it worked just fine for the original dig I gave you. When I remove the verbose_level line, it failed again. Both times I did a service restart. So, I repeated the experiment. I added the line again, restarted the service, and, it worked again. So, I deleted the line from dwood3rc, restarted the service, and, it failed again. However, the third time, it failed again even with the line. So, different starts give different results. That is very strange! Here's is the verbose_level = 1000 query that failed: Aug ?6 02:07:42 host2 /usr/local/sbin/Deadwood: Got DNS query for \002\070\062\003\061\063\066\003\062\063\062\003\062\060\064\004list\005dnswl\003org\000\000\020 Aug ?6 02:07:42 host2 /usr/local/sbin/Deadwood: Looking in cache for query \002\070\062\003\061\063\066\003\062\063\062\003\062\060\064\004list\005dnswl\003org\000\000\020 Aug ?6 02:07:42 host2 /usr/local/sbin/Deadwood: Nothing found for \002\070\062\003\061\063\066\003\062\063\062\003\062\060\064\004list\005dnswl\003org\000\000\020 Aug ?6 02:07:42 host2 /usr/local/sbin/Deadwood: Making connection to IP 8.8.8.8 And it ends there. If I change the query to specifically go to 8.8.8.8 as follows: dig @8.8.8.8 -t txt 82.136.232.204.list.dnswl.org I get this: ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @8.8.8.8 -t txt 82.136.232.204.list.dnswl.org ; (1 server found) ;; global options: ?printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24969 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;82.136.232.204.list.dnswl.org.INTXT ;; Query time: 1308 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sat Aug ?6 02:09:46 2011 ;; MSG SIZE ?rcvd: 47 Note the servfail.... Perhaps Deadwood is not handling that properly as a guess? 4.2.2.2 is working fine, perhaps there is some sort of problem with 8.8.8.8 right now. HOWEVER, I suspect that the servfail is causing trouble for Deadwood. Not sure where I got this, but the init file I am using is as follows: #!/bin/bash # MaraDNSThis shell script takes care of starting and stopping MaraDNS # chkconfig: - 55 45 # description: MaraDNS is secure Domain Name Server (DNS) # probe: true # Copyright 2005-2006 Sam Trenholme # TERMS # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # ? ?notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # ? ?notice, this list of conditions and the following disclaimer in the # ? ?documentation and/or other materials provided with the distribution. # This software is provided 'as is' with no guarantees of correctness or # fitness for purpose. # This is a script which stops and starts the MaraDNS process # The first line points to bash because I don't have a true Solaris /bin/sh # to test this against. # The following is a pointer to the MaraDNS program if [ -x "/usr/sbin/Deadwood" ] ; then MARADNS="/usr/sbin/Deadwood" elif [ -x "/usr/sbin/Deadwood.authonly" ] ; then MARADNS="/usr/sbin/Deadwood.authonly" elif [ -x "/usr/local/sbin/Deadwood" ] ; then MARADNS="/usr/local/sbin/Deadwood" elif [ -x "/usr/local/sbin/Deadwood.authonly" ] ; then MARADNS="/usr/local/sbin/Deadwood.authonly" else echo unable to find Deadwood exit 1 fi # The following is a pointer to the duende daemonizer if [ -x "/usr/sbin/duende" ] ; then DUENDE="/usr/sbin/duende" elif [ -x "/usr/local/sbin/duende" ] ; then DUENDE="/usr/local/sbin/duende" elif [ -x "/usr/local/bin/duende" ] ; then DUENDE="/usr/local/bin/duende" elif [ -x "/usr/bin/duende" ] ; then DUENDE="/usr/bin/duende" else echo unable to find duende exit 1 fi # The following is the directory we place MaraDNS log entries in LOGDIR="/var/log" # The following is a list of all dwood3rc files which we will load or # unload; # Simple case: Only one MaraDNS process, using the /etc/dwood3rc file MARARCS="/etc/dwood3rc" # Case two: Three MaraDNS processes, one using /etc/dwood3rc.1, the second one # using /etc/dwood3rc.2, and the third one using /etc/dwood3rc.3 # (this is not as essential as it was in the 1.0 days; MaraDNS can now bind # ?to multiple IPs) #MARARCS="/etc/dwood3rc.1 /etc/dwood3rc.2 /etc/dwood3rc.3" # Show usage information if this script is invoked with no arguments if [ $# -lt 1 ] ; then ? ? echo Usage: $0 \(start\|stop\|restart\) ? ? exit 1 fi # If invoked as stop or restart, kill *all* MaraDNS processes if [ $1 = "stop" -o $1 = "restart" ] ; then ? ? echo Sending all MaraDNS processes the TERM signal ? ? ps -ef | awk '{print $2":"$8}' | grep Deadwood | grep -v $$ | \ ? ? ? cut -f1 -d: | xargs kill > /dev/null 2>&1 ? ? echo waiting 1 second ? ? sleep 1 ? ? echo Sending all MaraDNS processes the KILL signal ? ? ps -e | awk '{print $1":"$NF}' | grep Deadwood | grep -v $$ | \ ? ? ? cut -f1 -d: | xargs kill -9 > /dev/null 2>&1 ? ? echo MaraDNS should have been stopped ? ? if [ $1 = "stop" ] ; then ? ? exit 0 ? ? fi fi # If invoked as start or restart, start the MaraDNS processes if [ $1 = "start" -o $1 = "restart" ] ; then ? ? echo Starting all Deadwood processes ? ? for a in $MARARCS ; do ? ? ? ? echo Starting Deadwood process which uses Mararc file $a # Duende syslogs MaraDNS' output messages and daemonizes MaraDNS ? ? ? ? $DUENDE $MARADNS -f $a ? ? done ? ? exit 0 fi Steve From nicholas at periapt.co.uk Sat Sep 10 02:10:55 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Sat, 10 Sep 2011 07:10:55 +0100 Subject: [MaraDNS list] two little questions Message-ID: <4E6AFF6F.1080807@periapt.co.uk> Sam, I have found some time to start looking at MaraDNS 2.0. I am puzzled by two documentational questions: 1.) CHANGELOG seems to be out of date, similarly doc/en/chagelog.txt. 2.) The contents of 0Quickstart are very different and baffling. -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From strenholme.usenet at gmail.com Sat Sep 10 10:43:55 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 10 Sep 2011 10:43:55 -0400 Subject: [MaraDNS list] I have gotten sponsorship for this month...so people won't have to wait until October 5 Message-ID: I'm letting everyone know that I have gotten enough sponsorship to work on MaraDNS one more day out of the month. That in mind, people won't have to wait until October 5 for me to look at and fix bug reports. Namely: * Domenico Rotondi reported having issues when both root_servers and upstream_servers are set in a dwood3rc file. I have created a SQA test to use both of these settings in the same Deadwood configuration file; the tests appear to be able to reproduce this problem. * Angel reported that some records were lost when transferring a zone. I have not had a chance to look at this yet. * Nicholas Bamber has reported some issues with MaraDNS' documentation. - Sam From strenholme.usenet at gmail.com Sat Sep 10 13:00:47 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 10 Sep 2011 13:00:47 -0400 Subject: [MaraDNS list] Deadwood updates Message-ID: Investigating the bug that Domenico Rotondi reported, I discovered that there have been some issues with RD (recursion desired) being correctly set when both upstream_servers and root_servers are set. I have updated the code and hopefully RD will now always have the correct value in DNS queries sent upstream. In addition, I am updating the Deadwood's parser: * I consider it a bug if any valid dwood3rc file does not parse in Python 2. That in mind, I have updated the dwood3rc parser to not allow parameters to have any leading whitespace (since whitespace is significant in Python) * It is no longer allowed to set a given root_servers or upstream_servers node more than once. In other words, a configuration like this will now raise an error: upstream_servers["example.com."] = "127.0.0.1" upstream_servers["example.com."] = "10.1.2.3" or upstream_servers["example.net."] = "192.168.1.1" root_servers["example.net."] = "192.168.1.1" The updated code can be downloaded here: http://maradns.org/deadwood/snap/ - Sam From strenholme.usenet at gmail.com Mon Sep 12 01:50:16 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 12 Sep 2011 01:50:16 -0400 Subject: [MaraDNS list] Deadwood update Message-ID: I have finished up all of the work I am going to do for MaraDNS and Deadwood for September 2011 (barring receiving more sponsorship). The work I have done this weekend was made possible by a fairly modest (but much appreciated) financial contribution. Investigating the bug that Domenico Rotondi reported, I discovered that there have been some issues with RD (recursion desired) being incorrectly set when both upstream_servers and root_servers are set. I have updated the code and hopefully RD will now always have the correct value in DNS queries sent upstream. In addition, I have updated Deadwood's parser: * I consider it a bug if any valid dwood3rc file does not parse in Python 2. That in mind, I have updated the dwood3rc parser to not allow parameters to have any leading whitespace (since whitespace is significant in Python). This is OK: recursive_acl = "127.0.0.1/16, 192.168.1.1/24" But this will raise an error: recursive_acl = "127.0.0.1/16, 192.168.1.1/24" (Observe the extra space in the left of the second example) * It is no longer allowed to set both root_servers or upstream_servers for a given name. In other words, a configuration like this will now raise an error: upstream_servers = {} upstream_servers["example.com."] = "127.0.0.1" root_servers = {} root_servers["example.com."] = "192.168.1.1" * Deadwood now raises a warning when the same name is set more than once. This will now trigger a warning: upstream_servers = {} upstream_servers["example.net."] = "10.1.2.3" upstream_servers["example.net."] = "192.168.1.1" I was tempted to make this fatal, but decided not to because making this fatal would make it more difficult to manage large anti-phish/malware blacklists. * It is no longer permitted to initialize root_servers or upstream_servers more than once. This will now raise an error: upstream_servers = {} upstream_servers["example.net."] = "10.1.2.3" upstream_servers = {} upstream_servers["example.com."] = "192.168.1.1" * Deadwood will now raise an error for invalid lists of root or upstream servers. This is now fatal: root_servers = {} root_servers["."] = "foo" Yes, I am making the parser more anal. This is to help protect the user from typos and other errors causing problems with Deadwood, giving them a detailed description of the exact cause of a potential problem before Deadwood starts to resolve queries, so that they find and fix it before coming to the mailing list and complaining about the issue. In addition, I want to ensure that any valid dwood3rc file is also a valid Python 2 script to make it much easier to use Deadwood configuration files in Python scripts. I have also updated the SQA tests; they now run in both Scientific Linux 6 and in CentOS 5. Two new tests have been added: sqa_server_fail and sqa_root_upstream Whew! This was a lot of work; I spent most of Saturday and a couple of hours this morning making all of these improvements. This will be all of the work I do with MaraDNS/Deadwood this month unless I can get more sponsorship. It can be downloaded here: http://www.maradns.org/deadwood/snap/ The next day I plan to work on MaraDNS/Deadwood without being compensated for my time is on October 5, 2011. From wayne.kroncke at tiscali.co.uk Mon Sep 12 04:44:40 2011 From: wayne.kroncke at tiscali.co.uk (wayne at tiscali) Date: Mon, 12 Sep 2011 09:44:40 +0100 Subject: [MaraDNS list] Deadwood update Message-ID: <4E6DC678.40508@tiscali.co.uk> thanks, sam (& your sponsor) for the updated deadwood program... -- Best Regards, Wayne Kroncke