From strenholme.usenet at gmail.com Fri Aug 5 08:24:57 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 5 Aug 2011 08:24:57 -0400 Subject: [MaraDNS list] MaraDNS 2.0.03 released Message-ID: I have released MaraDNS 2.0.03 today. This incorporates six months' worth of bugfixes: * ANY queries that do not fit in 512 bytes are now properly truncated * RFC2317 hostnames with slash characters ('/') are now supported * MaraDNS is now fully installed when 'make install' is invoked (at least on CentOS 5) * DDIP MX problem records now show hostname * Correctly handle IXFR and AXFR requests sent over UDP (the UDP server now always marks these as being truncated) * Documentation updates * Give information on how to RTFM (correct manpage pointed out) if a csv2 file doesn't parse * Added support for --pid=/path/to/file to Duende (courtesy Yarin) * ipv6 fixes applied * Duende bugfix courtesy Nicholas Bamber: Deadwood should now reap all children (as long as they don't need a KILL/9 signal to exit) * Updates to the SQA regressions * MaraDNS 2.0 tarball is now xz compressed; MaraDNS 2.0 Windows binary is now provided. Some notes on the contributions made to Duende by Yarin and Nicholas Bamber: * I had to add an "#include " to get Yarin's strncasecmp call to compile w/o warnings. * Nicholas: Thank you for fixing the issue with reaping children in Deadwood. I have backported that fix * The reason why Duende doesn't actually chroot() is because this breaks syslogging (at least on CentOS 5). Nicholas: Make sure your version of Duende correctly syslogs all of MaraDNS' messages; maybe Debian uses a different syslog daemon. * Since Nicholas Bamber's duende has added some new features that may break compiling on some (albeit unsupported) systems, I am including his binary, but with the name "duende-ng.c" in the tools/ directory Now that I have released MaraDNS 2.0.03 (as well as the companion Deadwood 3.0.03), I am going to phase back how much unpaid support I give MaraDNS. Instead of working on MaraDNS once every two weeks without compensation, I will now work on MaraDNS once a month. Since today is August 5, my next scheduled day for unpaid MaraDNS work is going to be a month from today: Monday, September 5. The only exceptions to this will be the occasional comment on this mailing list, or any work needed to fix a critical security problem with MaraDNS. That said, since JFC Morfin has very generously contributed to the MaraDNS cause every month, I plan on doing the following work with MaraDNS before September 5: * I will write up an essay on how to compile the older 1.4 branch of MaraDNS and post it here on the mailing list. * I will make sure "make install" does the right thing in Ubuntu 10.04 (their most recent long-term-support release), albeit in /usr/local - Sam From strenholme.usenet at gmail.com Fri Aug 5 08:26:20 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 5 Aug 2011 08:26:20 -0400 Subject: [MaraDNS list] MaraDNS 2.0.03 released In-Reply-To: References: Message-ID: > I have released MaraDNS 2.0.03 today. Which can be downloaded at the usual place: http://maradns.org/download.html - Sam From compconsultant at yahoo.com Fri Aug 5 16:54:39 2011 From: compconsultant at yahoo.com (Steve Fatula) Date: Fri, 5 Aug 2011 13:54:39 -0700 (PDT) Subject: [MaraDNS list] Deadwood timing out on lookup Message-ID: <1312577679.12702.YahooMailNeo@web39420.mail.mud.yahoo.com> I have Deadwood 3.0.03 on Centos. I key in the following command: dig?-t txt 84.211.52.72.list.dnswl.org And I get, after 30 seconds or so: ;; connection timed out; no servers could be reached I am using deadwood as a caching nameserver. So, using upstream_servers as follows: upstream_servers = {} upstream_servers["."] = "8.8.8.8, 4.2.2.2" If I dig @8.8.8.8??-t txt 84.211.52.72.list.dnswl.org, I get a response. Same for the other server. So... it's not the upstream servers. All our other servers that do not use deadwood work just fine with this dig. So, not sure what the issue is. In this case, there is no txt record for the query. When there is a txt record, it works fine (for other IPs). So, why would it take so very long and then timeout?? ? Steve From strenholme.usenet at gmail.com Fri Aug 5 18:41:16 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 5 Aug 2011 18:41:16 -0400 Subject: [MaraDNS list] Deadwood timing out on lookup In-Reply-To: <1312577679.12702.YahooMailNeo@web39420.mail.mud.yahoo.com> References: <1312577679.12702.YahooMailNeo@web39420.mail.mud.yahoo.com> Message-ID: Works for me: [root at cartomancy etc]# cat /etc/dwood3rc.upstream bind_address="0.0.0.0" # IP we bind to chroot_dir = "/etc/maradns" # Directory we run program from (not used in Win32) upstream_servers = {} upstream_servers["."]="8.8.8.8, 4.2.2.2" recursive_acl = "127.0.0.1/16" [root at cartomancy etc]# /usr/local/sbin/Deadwood -f dwood3rc.upstream Deadwood version 3.0.03 Deadwood: A DNS UDP non-recursive cache (IPv4-only) We bound to 1 addresses Then, in another window: [set at cartomancy ~]$ dig @127.0.0.1 -t txt 84.211.52.72.list.dnswl.org ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @127.0.0.1 -t txt 84.211.52.72.list.dnswl.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59100 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;84.211.52.72.list.dnswl.org. IN TXT ;; AUTHORITY SECTION: list.dnswl.org. 900 IN SOA ns0.dnswl.org. admins.dnswl.org. 1312582870 3600 300 432000 43200 ;; Query time: 125 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Aug 5 17:36:47 2011 ;; MSG SIZE rcvd: 92 Conclusion: Look elsewhere for the problem. I would start with /etc/resolv.conf and go from there. Another thing: Check your recursive_acl to make sure the IP in question has permission to contact Deadwood. Deadwood will act like it never got the query if the IP isn't in recursive_acl. Yes, this is a little paranoid, and sometimes makes it hard to troubleshoot problems, but I'm not getting enough sponsorship right now to make it worth my time to add the ability to return a "REFUSED" to IPs not in the recursive_acl. - Sam 2011/8/5 Steve Fatula : > I have Deadwood 3.0.03 on Centos. I key in the following command: > > dig?-t txt 84.211.52.72.list.dnswl.org > > And I get, after 30 seconds or so: > > ;; connection timed out; no servers could be reached > > > I am using deadwood as a caching nameserver. So, using upstream_servers as follows: > > upstream_servers = {} > upstream_servers["."] = "8.8.8.8, 4.2.2.2" > > If I dig @8.8.8.8??-t txt 84.211.52.72.list.dnswl.org, I get a response. Same for the other server. So... it's not the upstream servers. > > All our other servers that do not use deadwood work just fine with this dig. So, not sure what the issue is. In this case, there is no txt record for the query. When there is a txt record, it works fine (for other IPs). > > So, why would it take so very long and then timeout? > > Steve > From compconsultant at yahoo.com Sat Aug 6 01:42:46 2011 From: compconsultant at yahoo.com (Steve Fatula) Date: Fri, 5 Aug 2011 22:42:46 -0700 (PDT) Subject: [MaraDNS list] Deadwood timing out on lookup In-Reply-To: References: <1312577679.12702.YahooMailNeo@web39420.mail.mud.yahoo.com> Message-ID: <1312609366.71833.YahooMailNeo@web39403.mail.mud.yahoo.com> Didn't work for me. dwood3rc: ipv4_bind_addresses = "127.0.0.1" chroot_dir = "/etc/maradns" recursive_acl = "127.0.0.1" timeout_seconds = 10 maximum_cache_elements=1024 reject_mx=0 filter_rfc1918=0 upstream_servers = {} upstream_servers["."] = "8.8.8.8, 4.2.2.2" resolv.conf: nameserver 127.0.0.1 I tried all sorts of things. It was taking around 40 seconds for milter-greylist to use deadwood to resolv the stuff it needed to (and never resolved dnswl). So, I replaced deadwood with dnsmasq, and, it takes < 2 seconds now. Works perfectly, though, uses a little more memory. So, not sure why dnsmasq is 20 times faster, but it is on this system which is openvz Centos 5.6 ? Steve From strenholme.usenet at gmail.com Sat Aug 6 02:35:05 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 6 Aug 2011 02:35:05 -0400 Subject: [MaraDNS list] Deadwood timing out on lookup In-Reply-To: <1312609366.71833.YahooMailNeo@web39403.mail.mud.yahoo.com> References: <1312577679.12702.YahooMailNeo@web39420.mail.mud.yahoo.com> <1312609366.71833.YahooMailNeo@web39403.mail.mud.yahoo.com> Message-ID: Your exact same configuration, on a nearly identical system (a 32-bit CentOS 5 OpenVZ container with a 64-bit Scientific Linux 6 host using a custom kernel based off of 042test013) works for me. e.g.: [set at cartomancy ~]$ ls -l /proc/user_beancounters -r-------- 1 root root 0 Aug 6 01:18 /proc/user_beancounters [set at cartomancy ~]$ cat /etc/redhat-release CentOS release 5.6 (Final) [set at cartomancy ~]$ su Password: [root at cartomancy set]# cat > /etc/dwood3rc.steve ipv4_bind_addresses = "127.0.0.1" chroot_dir = "/etc/maradns" recursive_acl = "127.0.0.1" timeout_seconds = 10 maximum_cache_elements=1024 reject_mx=0 filter_rfc1918=0 upstream_servers = {} upstream_servers["."] = "8.8.8.8, 4.2.2.2" [root at cartomancy set]# cat /etc/resolv.conf nameserver 127.0.0.1 [root at cartomancy set]# Deadwood -f /etc/dwood3rc.steve Deadwood version 3.0.03 Deadwood: A DNS UDP non-recursive cache (IPv4-only) We bound to 1 addresses And then, in another window: [set at cartomancy ~]$ ping www.yahoo.com PING any-fp3-real.wa1.b.yahoo.com (209.191.122.70) 56(84) bytes of data. 64 bytes from ir1.fp.vip.mud.yahoo.com (209.191.122.70): icmp_seq=1 ttl=50 time=35.5 ms 64 bytes from ir1.fp.vip.mud.yahoo.com (209.191.122.70): icmp_seq=2 ttl=50 time=38.3 ms 64 bytes from ir1.fp.vip.mud.yahoo.com (209.191.122.70): icmp_seq=3 ttl=50 time=34.0 ms ^C --- any-fp3-real.wa1.b.yahoo.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 34.041/35.986/38.370/1.800 ms [set at cartomancy ~]$ dig @127.0.0.1 www.yahoo.com ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @127.0.0.1 www.yahoo.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52289 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.yahoo.com. IN A ;; ANSWER SECTION: www.yahoo.com. 49 IN CNAME fp3.wg1.b.yahoo.com. fp3.wg1.b.yahoo.com. 49 IN CNAME any-fp3-lfb.wa1.b.yahoo.com. any-fp3-lfb.wa1.b.yahoo.com. 49 IN CNAME any-fp3-real.wa1.b.yahoo.com. any-fp3-real.wa1.b.yahoo.com. 49 IN A 67.195.160.76 any-fp3-real.wa1.b.yahoo.com. 49 IN A 69.147.125.65 any-fp3-real.wa1.b.yahoo.com. 49 IN A 209.191.122.70 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Aug 6 01:20:19 2011 ;; MSG SIZE rcvd: 160 Is your OpenVZ account a hosting account with a SolusVM (or other) control panel, or do you control the server running OpenVZ? In other words, can you get at /etc/vz/conf/{container number}.conf on the host? What does "ifconfig" give you? What messages do you get if you add the following to your dwood3rc: verbose_level = 1000 Are you using Deadwood 3.0.03? Here is what I get on my working system after adding the verbose_level=1000 line: [root at cartomancy set]# Deadwood -f /etc/dwood3rc.steve Deadwood version 3.0.03 Deadwood: A DNS UDP non-recursive cache (IPv4-only) Verbose_level set to 1000 We bound to 1 addresses add_constant is set to 0x3a548f35 Got DNS query for \003www\005yahoo\003com\000\000\001 Looking in cache for query \003www\005yahoo\003com\000\000\001 Nothing found for \003www\005yahoo\003com\000\000\001 Making connection to IP 8.8.8.8 Caching a reply for query \003www\005yahoo\003com\000\000\001 Caching direct answer at \003www\005yahoo\003com\000\000\001 Looking in cache for query \003www\005yahoo\003com\000\000\001 Fetching \003www\005yahoo\003com\000\000\001 from cache - Sam 2011/8/6 Steve Fatula : > Didn't work for me. > > dwood3rc: > > ipv4_bind_addresses = "127.0.0.1" > chroot_dir = "/etc/maradns" > recursive_acl = "127.0.0.1" > timeout_seconds = 10 > maximum_cache_elements=1024 > reject_mx=0 > filter_rfc1918=0 > upstream_servers = {} > upstream_servers["."] = "8.8.8.8, 4.2.2.2" > > resolv.conf: > > nameserver 127.0.0.1 > > > I tried all sorts of things. It was taking around 40 seconds for milter-greylist to use deadwood to resolv the stuff it needed to (and never resolved dnswl). So, I replaced deadwood with dnsmasq, and, it takes < 2 seconds now. Works perfectly, though, uses a little more memory. So, not sure why dnsmasq is 20 times faster, but it is on this system which is openvz Centos 5.6 > > Steve > From strenholme.usenet at gmail.com Sat Aug 6 03:05:46 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 6 Aug 2011 03:05:46 -0400 Subject: [MaraDNS list] Deadwood timing out on lookup In-Reply-To: <1312613684.57272.YahooMailNeo@web39409.mail.mud.yahoo.com> References: <1312577679.12702.YahooMailNeo@web39420.mail.mud.yahoo.com> <1312609366.71833.YahooMailNeo@web39403.mail.mud.yahoo.com> <1312613684.57272.YahooMailNeo@web39409.mail.mud.yahoo.com> Message-ID: [Messages sent to me by accident are forwarded to the list] What messages do you get if you add the following to your dwood3rc: verbose_level = 1000 To add this line, use an editor: nano -w /etc/dwood3rc Or, more simply: echo verbose_level=1000 >> /etc/dwood3rc You can then either run Deadwood via Duende and see all the messages in /var/log/messages, or just run Deadwood directly from the shell and see all of the messages on stdout. Both the yahoo example works for me, as well as the TXT record for 84.211.52.72.list.dnswl.org. Again, I am not, repeat not seeing this problem, even on a nearly identical OpenVZ system. Unfortunately, until I can reproduce it on my setup, I will have to mark this bug as "works for me, unreproducible" Everything works fine even when using Deadwood as a fully recursive resolver: [set at cartomancy ~]$ dig @127.0.0.1 -t txt 84.211.52.72.list.dnswl.org ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @127.0.0.1 -t txt 84.211.52.72.list.dnswl.org ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33156 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;84.211.52.72.list.dnswl.org. IN TXT ;; AUTHORITY SECTION: list.dnswl.org. 43200 IN SOA ns0.dnswl.org. admins.dnswl.org. 1312582870 3600 300 432000 43200 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Aug 6 01:59:31 2011 ;; MSG SIZE rcvd: 92 - Sam 2011/8/6 Steve Fatula : > Mine worked fine for yahoo.com, I had tried to say that as far as I know, the problem was something with dnswl in the example quoted. I do not control this machine, I am just in a container. Yes, it was Deadwood 3.0.03, which I upgraded today since it was not working on the previous version, thought it might fix the issue. > > Steve > > > ----- Original Message ----- > From: Sam Trenholme > To: Steve Fatula > Cc: > Sent: Saturday, August 6, 2011 1:30 AM > Subject: Re: [MaraDNS list] Deadwood timing out on lookup > > Your exact same configuration, on a nearly identical system (a 32-bit > CentOS 5 OpenVZ container with a 64-bit Scientific Linux 6 host using > a custom kernel based off of 042test013) works for me. e.g.: > > [set at cartomancy ~]$ ls -l /proc/user_beancounters > -r-------- 1 root root 0 Aug? 6 01:18 /proc/user_beancounters > [set at cartomancy ~]$ cat /etc/redhat-release > CentOS release 5.6 (Final) > [set at cartomancy ~]$ su > Password: > [root at cartomancy set]# cat > /etc/dwood3rc.steve > ipv4_bind_addresses = "127.0.0.1" > chroot_dir = "/etc/maradns" > recursive_acl = "127.0.0.1" > timeout_seconds = 10 > maximum_cache_elements=1024 > reject_mx=0 > filter_rfc1918=0 > upstream_servers = {} > upstream_servers["."] = "8.8.8.8, 4.2.2.2" > [root at cartomancy set]# cat /etc/resolv.conf > nameserver 127.0.0.1 > [root at cartomancy set]# Deadwood -f /etc/dwood3rc.steve > Deadwood version 3.0.03 > Deadwood: A DNS UDP non-recursive cache (IPv4-only) > We bound to 1 addresses > > And then, in another window: > > [set at cartomancy ~]$ ping www.yahoo.com > PING any-fp3-real.wa1.b.yahoo.com (209.191.122.70) 56(84) bytes of data. > 64 bytes from ir1.fp.vip.mud.yahoo.com (209.191.122.70): icmp_seq=1 > ttl=50 time=35.5 ms > 64 bytes from ir1.fp.vip.mud.yahoo.com (209.191.122.70): icmp_seq=2 > ttl=50 time=38.3 ms > 64 bytes from ir1.fp.vip.mud.yahoo.com (209.191.122.70): icmp_seq=3 > ttl=50 time=34.0 ms > ^C > --- any-fp3-real.wa1.b.yahoo.com ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms > rtt min/avg/max/mdev = 34.041/35.986/38.370/1.800 ms > [set at cartomancy ~]$ dig @127.0.0.1 www.yahoo.com > > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @127.0.0.1 www.yahoo.com > ; (1 server found) > ;; global options:? printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52289 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.yahoo.com.? ? ? ? ? ? ? ? ?IN? ? ? A > > ;; ANSWER SECTION: > www.yahoo.com.? ? ? ? ? 49? ? ? IN? ? ? CNAME? ?fp3.wg1.b.yahoo.com. > fp3.wg1.b.yahoo.com.? ? 49? ? ? IN? ? ? CNAME? ?any-fp3-lfb.wa1.b.yahoo.com. > any-fp3-lfb.wa1.b.yahoo.com. 49 IN? ? ? CNAME? ?any-fp3-real.wa1.b.yahoo.com. > any-fp3-real.wa1.b.yahoo.com. 49 IN? ? ?A? ? ? ?67.195.160.76 > any-fp3-real.wa1.b.yahoo.com. 49 IN? ? ?A? ? ? ?69.147.125.65 > any-fp3-real.wa1.b.yahoo.com. 49 IN? ? ?A? ? ? ?209.191.122.70 > > ;; Query time: 1 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Aug? 6 01:20:19 2011 > ;; MSG SIZE? rcvd: 160 > > Is your OpenVZ account a hosting account with a SolusVM (or other) > control panel, or do you control the server running OpenVZ?? In other > words, can you get at /etc/vz/conf/{container number}.conf on the > host? > > What does "ifconfig" give you? > > What messages do you get if you add the following to your dwood3rc: > > verbose_level = 1000 > > Are you using Deadwood 3.0.03? > > Here is what I get on my working system after adding the > verbose_level=1000 line: > > [root at cartomancy set]# Deadwood -f /etc/dwood3rc.steve > Deadwood version 3.0.03 > Deadwood: A DNS UDP non-recursive cache (IPv4-only) > Verbose_level set to 1000 > We bound to 1 addresses > add_constant is set to 0x3a548f35 > Got DNS query for \003www\005yahoo\003com\000\000\001 > Looking in cache for query \003www\005yahoo\003com\000\000\001 > Nothing found for \003www\005yahoo\003com\000\000\001 > Making connection to IP 8.8.8.8 > Caching a reply for query \003www\005yahoo\003com\000\000\001 > Caching direct answer at \003www\005yahoo\003com\000\000\001 > Looking in cache for query \003www\005yahoo\003com\000\000\001 > Fetching \003www\005yahoo\003com\000\000\001 from cache > > - Sam > From compconsultant at yahoo.com Sat Aug 6 03:17:44 2011 From: compconsultant at yahoo.com (Steve Fatula) Date: Sat, 6 Aug 2011 00:17:44 -0700 (PDT) Subject: [MaraDNS list] Deadwood timing out on lookup In-Reply-To: References: <1312577679.12702.YahooMailNeo@web39420.mail.mud.yahoo.com> <1312609366.71833.YahooMailNeo@web39403.mail.mud.yahoo.com> <1312613684.57272.YahooMailNeo@web39409.mail.mud.yahoo.com> Message-ID: <1312615064.7797.YahooMailNeo@web39407.mail.mud.yahoo.com> Of course, your example is incomplete since you are querying the cache (0 msec). For any tests that you do, you need to clear the cache so it goes out of your network. My other email might shed some light on a potential explanation. At least a guess! ? Steve ----- Original Message ----- From: Sam Trenholme To: maradns list Cc: Sent: Saturday, August 6, 2011 2:05 AM Subject: Re: [MaraDNS list] Deadwood timing out on lookup [Messages sent to me by accident are forwarded to the list] What messages do you get if you add the following to your dwood3rc: verbose_level = 1000 To add this line, use an editor: nano -w /etc/dwood3rc Or, more simply: echo verbose_level=1000 >> /etc/dwood3rc You can then either run Deadwood via Duende and see all the messages in /var/log/messages, or just run Deadwood directly from the shell and see all of the messages on stdout. Both the yahoo example works for me, as well as the TXT record for 84.211.52.72.list.dnswl.org.? Again, I am not, repeat not seeing this problem, even on a nearly identical OpenVZ system.? Unfortunately, until I can reproduce it on my setup, I will have to mark this bug as "works for me, unreproducible"? Everything works fine even when using Deadwood as a fully recursive resolver: [set at cartomancy ~]$ dig @127.0.0.1 -t txt 84.211.52.72.list.dnswl.org ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5 <<>> @127.0.0.1 -t txt 84.211.52.72.list.dnswl.org ; (1 server found) ;; global options:? printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33156 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;84.211.52.72.list.dnswl.org.? IN? ? ? TXT ;; AUTHORITY SECTION: list.dnswl.org.? ? ? ? 43200? IN? ? ? SOA? ? ns0.dnswl.org. admins.dnswl.org. 1312582870 3600 300 432000 43200 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Aug? 6 01:59:31 2011 ;; MSG SIZE? rcvd: 92 - Sam From strenholme.usenet at gmail.com Sat Aug 6 03:33:14 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 6 Aug 2011 03:33:14 -0400 Subject: [MaraDNS list] 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: OK, so the issue is that we're sometimes getting a server fail upstream when using upstream_servers (instead of root_servers) and Deadwood doesn't appear to be handling these kinds of packets well. Very good. This gives me enough information to play around with some tests and start trying to fix that. That's the good news. The bad news is that, as I pointed out earlier today here on the mailing list, because I'm not getting the necessary sponsorship for my MaraDNS/Deadwood work, the next day I'm going to look at the code is on September 5, 2011--one month from today (I just released MaraDNS 2.0.03 today and, at my current level of sponsorship, only work on MaraDNS/Deadwood once a month). In the meantime, some ideas: * If you want to just cache what comes upstream, try using Deadwood 2.3.07, the supported "tiny" non-recursive version of Deadwood: http://maradns.org/deadwood/tiny/ In particular, this release has a parameter called "deliver_all" which may work with your network and its issues. * Do full recursion with Deadwood. This is most easily done by simply commenting out the upstream_servers lines in the dwood3rc; Deadwood will then contact the root nameservers and follow the referrals until it gets a usable answer to send to the client. While I do a lot of SQA tests with upstream_servers before releasing Deadwood, I don't have one which recreates this particular network condition. I can write code to simulate this condition (or something similar such as a DNS server which always returns "SERVER FAIL") and see how Deadwood handles it. Thank you for your detailed bug report and I apologize that I'm just not getting the sponsorship needed right now to justify immediately looking at and fixing this issue. And, yes, I do fix issues like this once I allocate time to look at them; for example: http://afj2.vk.tj/ Here, I fixed an issue on June 10, 2011 which was reported on June 2, 2011 (this was back when I worked on MaraDNS/Deadwood one day every two weeks) - Sam 2011/8/6 Steve Fatula : > 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 compconsultant at yahoo.com Sat Aug 6 03:43:08 2011 From: compconsultant at yahoo.com (Steve Fatula) Date: Sat, 6 Aug 2011 00:43:08 -0700 (PDT) Subject: [MaraDNS list] Deadwood timing out on lookup In-Reply-To: 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: <1312616588.82716.YahooMailNeo@web39409.mail.mud.yahoo.com> Query works fine with full recursion. FWIW. Though, I had hoped to rely on the cache of THEIR DNS server. Oh well, it does work at least. ? Steve ----- Original Message ----- From: Sam Trenholme To: maradns list Cc: Sent: Saturday, August 6, 2011 2:33 AM Subject: Re: [MaraDNS list] Deadwood timing out on lookup * Do full recursion with Deadwood.? This is most easily done by simply commenting out the? upstream_servers lines in the dwood3rc; Deadwood will then contact the root nameservers and follow the referrals until it gets a usable answer to send to the client. From strenholme.usenet at gmail.com Sat Aug 6 04:48:05 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 6 Aug 2011 04:48:05 -0400 Subject: [MaraDNS list] Deadwood timing out on lookup In-Reply-To: <1312616588.82716.YahooMailNeo@web39409.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> <1312616588.82716.YahooMailNeo@web39409.mail.mud.yahoo.com> Message-ID: It should also work fine with Deadwood 2.3.07; Jakob Blomer of CERN laboratories (yes, the same CERN the invented the world wide web and HTTP, and yes the same CERN that helps make my current Linux distribution of choice, Scientific Linux) added a feature called deliver_all which fixes the exact same issue you saw with a non-recursive configuration of Deadwood: http://woodlane.webconquest.com/pipermail/list/2009-October/000458.html http://maradns.org/deadwood/tiny/deadwood-2.3.07.tar.bz2 Alas, I had to disable this feature in Deadwood. But, yes, I'll see what I can do to fix this--a month from now. - Sam > Query works fine with full recursion. FWIW. Though, I had hoped to rely on the cache of THEIR DNS server. Oh well, it does work at least. > > Steve > > > ----- Original Message ----- > From: Sam Trenholme > To: maradns list > Cc: > Sent: Saturday, August 6, 2011 2:33 AM > Subject: Re: [MaraDNS list] Deadwood timing out on lookup > > > > * Do full recursion with Deadwood.? This is most easily done by simply > commenting out the? ?upstream_servers lines in the dwood3rc; Deadwood > will then contact the root nameservers and follow the referrals until > it gets a usable answer to send to the client. > From MSands at EPLUS.com Tue Aug 9 10:36:57 2011 From: MSands at EPLUS.com (Mike Sands) Date: Tue, 9 Aug 2011 10:36:57 -0400 Subject: [MaraDNS list] bug with spf records? In-Reply-To: <4DE02107.4070000@shlrm.org> References: <4DE00FE6.5060708@shlrm.org> <4DE01CBE.4020101@datafaber.net> <4DE01FDA.2030002@shlrm.org> <4DE02107.4070000@shlrm.org> Message-ID: <2688766582E16041AFB400DD06CDCB79196117BFA9@EPEXMB02.epgpdom.com> I've been trying to add a spf record with a soft fail and maradns won't load the cvs2 file. So for example this works just fine. example.com. TXT 'v=spf1 +mx include:examplemail.com -all' ~ and this does not example.com. TXT 'v=spf1 +mx include:examplemail.com ~all' ~ Is this a bug or just my syntax? From strenholme.usenet at gmail.com Tue Aug 9 10:47:44 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 9 Aug 2011 10:47:44 -0400 Subject: [MaraDNS list] bug with spf records? In-Reply-To: <2688766582E16041AFB400DD06CDCB79196117BFA9@EPEXMB02.epgpdom.com> References: <4DE00FE6.5060708@shlrm.org> <4DE01CBE.4020101@datafaber.net> <4DE01FDA.2030002@shlrm.org> <4DE02107.4070000@shlrm.org> <2688766582E16041AFB400DD06CDCB79196117BFA9@EPEXMB02.epgpdom.com> Message-ID: If you upgrade to 2.0.03, it will tell you the following whenever you try to put a ~ in a TXT (or SPF--yes, MaraDNS has native SPF record support) record: man csv2_txt for more information (You're not the first person to have this issue) The reason why the ~ is not allowed is to make it possible to parse zone files using awk and an RS of ~; this make automation with scripts that much easier. - Sam 2011/8/9 Mike Sands : > > I've been trying to add a spf record with a soft fail and maradns won't load the cvs2 file. > > So for example this works just fine. > > example.com. ?TXT 'v=spf1 ?+mx ?include:examplemail.com ?-all' ~ > > and this does not > > example.com. ?TXT 'v=spf1 ?+mx ?include:examplemail.com ?~all' ~ > > Is this a bug or just my syntax? > From strenholme.usenet at gmail.com Thu Aug 11 17:59:58 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 11 Aug 2011 17:59:58 -0400 Subject: [MaraDNS list] How to compile MaraDNS 1 in Windows Message-ID: Because I am getting sponsorship for MaraDNS (thank you very much JFC Morfin), I am proving this document which details how to compile MaraDNS 1 for Windows. The way I compile this program in Windows 7 is with MinGW-3.4.2 and MSYS-1.0.10, as well as the pthreads library that MaraDNS 1 needs. These programs are available at the following locations: ftp://ftp.trolltech.com/misc/ (MinGW 3.4.2) http://prdownloads.sourceforge.net/mingw/MSYS-1.0.10.exe?download ftp://sourceware.org/pub/pthreads-win32/pthreads-w32-2-8-0-release.exe The order of installation is as follows: MinGW 3.4.2 MSYS 1.0.10 Pthreads 2.8.0 The first two are simple "I agree", "Next", "I agree", "Install"-type click-to-install packages. Install MinGW *before* installing MSYS so the MSYS installer can find MinGW; be sure to put MinGW in C:\ so the MSYS installer can find it. Once MinGW and MSYS are installed, one can install Pthreads. - Run the pthreads exe file to install it. The program will create three folders; the only one we care about is Pre-built.2 - Put lib\libpthreadGC2.a and lib\pthreadGC2.dll in mingw\lib (where mingw is the location mingw is installed on the computer, usually c:\mingw) - Put the contents of Pre-built.2\include in mingw\include Once this is done, it should be possible to download and compile MaraDNS 1: 1. Download the latest MaraDNS 1.4.XX version of MaraDNS. 2. Put MaraDNS-1.4.XX.tar.bz2 in your MSYS home directory (which is something like C:\MSYS\1.0\Home\User name\) 3. Enter MSYS by double-clicking on the blue "M" icon which should be on your desktop. 3. Then enter these UNIX commands: tar xvjf MaraDNS-1.4.XX.tar.bz2 cd MaraDNS-1.4.XX/ ./configure; make At this point you should have a server/maradns.exe and a tools/askmara.exe If these directions do not work, please let me know. From D.Rotondi at Computer.Org Tue Aug 23 12:48:29 2011 From: D.Rotondi at Computer.Org (Domenico Rotondi) Date: Tue, 23 Aug 2011 18:48:29 +0200 Subject: [MaraDNS list] MaraDNS authoritative and recursive config issue Message-ID: <4E53D9DD.14048.1E82841@D.Rotondi.Computer.Org> Hi, I'm trying to use MaraDNS-2-0-03 to solve the following problem: on my intranet I want to manage the mapping of a few FQDN belonging to the "example.org" domain to IP addresses on my intranet and, at the same time, assure reolution for FQDN in other domains (including the intranet one). My intranet has its how DNS servers, which also manages resolutions for Internet domains. I found an How-to blog (http://blog.mixu.net/2009/10/14/how-to-setup-a-lan-dns- server-using-maradns-under-windows-7/) on how to set MaraDNS to act at the same time as an authoritative DNS for example.org and as a recursive DNS server. The instructions in that blog seems to refer to a previous version of MaraDNS; anyway as a first attempt I followed that how-to and I performed the following actions: 1) download the last Windows MaraDNS stable version 2) unzip the package into a suitable directory. So I got the MaraDNS-2-0-03 files and the Deadwood subfolder 3) in the MaraDNS main folder I executed mkSecretTxt.exe so that I got the secret.txt file 4) I edited the mararc file as follows: # # Bind MaraDNS to my laptop IP Address # # N.B.: this IP address has to be changed according to the IP address of the machine on which MaraDNS is running # ipv4_bind_addresses = "127.0.0.1" timestamp_type = 2 random_seed_file = "secret.txt" # # This section states where the data for the authoritative zone are held # csv2 = {} csv2["example.org."] = "db.example.org.txt" # # # This section instructs MaraDNS to redirect DNS queries for non- authoritative zones to other DNS servers # # N.B.: the IP addresses in this section must be set according to the DNS configuration of your local Net # upstream_servers = {} upstream_servers["."] = "192.168.152.5, 192.168.152.8, 192.168.210.33" The upstream_servers IP addresses are our intranet DNS servers through which we also resolve Internet domains. BTW: I'm using Windows 7 Enterprise Edition 64-bits 5) I open an Administrator Command window 6) execute run_maradns.bat 7) a new window opens and MaraDNS confirms it has loaded the example.org file and it's ready to work. >From another command window I start the askmara.exe program and submit requests like: * askmara Aexample.org. obtaining the correct answer. while if I submit the request: * askmara Awww.google.com. I get a "REFUSED" answer. I've also tried to configure the Deadwood service (correctly installed and started as Windows service) setting it in a way compatible with the MaraDNS service (e.g. allocating it on my intranet IP address 192.168.152.67 while MaraDNS is allocated on 127.0.0.1 so that they don't conmflict on the same UDP port), but with no useful result. This is my dwood3rc.txt config: # # # This section instructs "Deadwood" to redirect DNS queries for non- authoritative zones to other DNS servers # # N.B.: the IP addresses in this section must be set according to the DNS configuration of your local Net # upstream_servers = {} upstream_servers["."] = "192.168.152.5, 192.168.152.8, 192.168.210.33" # root_servers = {} root_servers["example.org."] = "127.0.0.1" # # Bind "Deadwood" to my laptop TXT BA IP Address # # N.B.: this IP address has to be changed according to the IP address of the machine on which "Deadwood" is installed # bind_address="192.168.152.67" # # The IPs allowed to connect and use the cache # N.B.: this value must be updated as requested recursive_acl = "192.168.152.0/24" # The file containing a hard-to-guess secret random_seed_file = "secret.txt" # This is the file Deadwood uses to read the cache to and from disk cache_file = "dw_cache_bin" The 2 services starts and coexist, but I'm not able to resolve names in example.org and other domains. Requests like: * askmara Aexample.org. 192.168.152.67 provides the answer I'll get submitting the reques to a DNS server on Internet and not the answer I was expecting. I tried different configs (including removing the "upstream_servers" lines in mararc file) for MaraDNS and Deadwood without any result. Any suggestions? Thanks in advance. Regards Domenico From strenholme.usenet at gmail.com Tue Aug 23 15:17:01 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 23 Aug 2011 15:17:01 -0400 Subject: [MaraDNS list] MaraDNS authoritative and recursive config issue In-Reply-To: <4E53D9DD.14048.1E82841@D.Rotondi.Computer.Org> References: <4E53D9DD.14048.1E82841@D.Rotondi.Computer.Org> Message-ID: > I got the MaraDNS-2-0-03 files and the Deadwood subfolder [...] > ? ?upstream_servers = {} > ? ?upstream_servers["."] = "192.168.152.5, 192.168.152.8, 192.168.210.33" upstream_servers doesn't work in MaraDNS 2.0; the maradns daemon in MaraDNS 2.0 *only* returns data from zone files. > * ? askmara Awww.google.com. > > I get a "REFUSED" answer. When you want to resolve a query which you are not in control of, such as "maradns.org" or "google.com", Deadwood is the program to use. > I've also tried to configure the Deadwood service (correctly installed and started as > Windows service) setting it in a way compatible with the MaraDNS service (e.g. > allocating it on my intranet IP address 192.168.152.67 while MaraDNS is allocated > on 127.0.0.1 so that they don't conmflict on the same UDP port), but with no useful > result. Deadwood will only do recursive (or upstream) queries; MaraDNS will only do authoritative queries. > This is my dwood3rc.txt config: > ? ?upstream_servers = {} > ? ?upstream_servers["."] = "192.168.152.5, 192.168.152.8, 192.168.210.33" > ? ?root_servers = {} > ? ?root_servers["example.org."] = "127.0.0.1" While I believe complex setups with both root_servers and upstream_servers are set are possible, they haven't been tested in Deadwood. Try using upstream_servers["example.org."] = "127.0.0.1" instead of root_servers and see if that resolves your issue (since the server at 127.0.0.1 is MaraDNS 2.0, there is no condition whatsoever that will result in the reply causing a query loop). > ? ?bind_address="192.168.152.67" bind_address="0.0.0.0" works if you just want to use every IP your computer happens to have. Anyway, you may or may not have found a bug. I will work with you on the list to see if the issue is a configuration (or documentation) issue or an honest-to-God bug in Deadwood. If we do determine it is a bug, the next day I have scheduled for working on Deadwood is September 5; I already have an issue with upstream_servers that returns a SERVER FAIL to fix. If this issue is important enough that it needs to be fixed more quickly, I'm willing to talk if there's money on the table. - Sam From sebastiano at datafaber.net Wed Aug 24 03:11:30 2011 From: sebastiano at datafaber.net (sebastiano at datafaber.net) Date: Wed, 24 Aug 2011 09:11:30 +0200 Subject: [MaraDNS list] MaraDNS authoritative and recursive config issue In-Reply-To: <4E53D9DD.14048.1E82841@D.Rotondi.Computer.Org> References: <4E53D9DD.14048.1E82841@D.Rotondi.Computer.Org> Message-ID: <8f697b35f1b45c8327cb545fc685ca7d@datafaber.net> On Tue, 23 Aug 2011 18:48:29 +0200, Domenico Rotondi wrote: > Hi, > I'm trying to use MaraDNS-2-0-03 to solve the following problem: > on my intranet I want to manage the mapping of a few FQDN belonging > to the > "example.org" domain to IP addresses on my intranet and, at the same > time, assure > reolution for FQDN in other domains (including the intranet one). > My intranet has its how DNS servers, which also manages resolutions > for Internet > domains. I'm on Linux rather than Windows, but I have a setup similar to yours. On one box I have MaraDNS set up as an authoritative DNS for the home.lan zone (i.e. the intranet), and on the same box I also have Deadwood listening on another IP address set as recursive nameserver for the intranet and for the Internet. My MaraDNS configuration file is: ipv4_bind_addresses = "192.168.88.4" tcp_convert_acl = "0.0.0.0/0" tcp_convert_server = "192.168.88.4" long_packet_ipv4 = "192.168.88.4" chroot_dir = "/etc/maradns" csv2 = {} csv2["home.lan."] = "db.home.lan.conf" verbose_level = 1 My Deadwood configuration file is: bind_address="127.0.0.1, 192.168.88.3" chroot_dir="/var/run/deadwood" dns_port=53 filter_rfc1918=0 maximum_cache_elements=1024 recursive_acl="127.0.0.1/8, 192.168.88.1/16" reject_mx=0 root_servers={} root_servers["home.lan."]="192.168.88.4" root_servers["."]="198.41.0.4," root_servers["."]+="192.228.79.201," root_servers["."]+="192.33.4.12," root_servers["."]+="128.8.10.90," root_servers["."]+="192.203.230.10," root_servers["."]+="192.5.5.241," root_servers["."]+="192.112.36.4," root_servers["."]+="128.63.2.53," root_servers["."]+="192.36.148.17," root_servers["."]+="192.58.128.30," root_servers["."]+="193.0.14.129," root_servers["."]+="199.7.83.42," root_servers["."]+="202.12.27.33" tcp_listen=1 timeout_seconds=60 timeout_seconds_tcp=60 upstream_servers={} verbose_level=3 I also have a DHCP configuration which specifies 192.168.88.3 as the DNS to use to all other boxes. Try adapting this configuration to your environment and tell us what happens. Best regards Sebastiano Pilla From strenholme.usenet at gmail.com Wed Aug 24 10:42:10 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 24 Aug 2011 10:42:10 -0400 Subject: [MaraDNS list] MaraDNS authoritative and recursive config issue In-Reply-To: <8f697b35f1b45c8327cb545fc685ca7d@datafaber.net> References: <4E53D9DD.14048.1E82841@D.Rotondi.Computer.Org> <8f697b35f1b45c8327cb545fc685ca7d@datafaber.net> Message-ID: > My Deadwood configuration file is: > [snip] > bind_address="127.0.0.1, 192.168.88.3" > root_servers={} > root_servers["home.lan."]="192.168.88.4" > root_servers["."]="198.41.0.4," [snip rest of ICANN root servers] > upstream_servers={} [Note: no other use of upstream_servers] Thanks for the report. The issue here may be that combinations of root_servers and upstream_servers have some issues. What may also work for Domenico is to use Deadwood 2.3 (which has really good upstream_servers support, but no root_servers support) instead of Deadwood 3.0. There appear to be two different bugs with Deadwood 3's upstream_servers: * upstream_servers has issues if one of the upstream servers gives us a SERVER FAIL * There may be problems in Deadwood configurations where both upstream_servers and root_servers are used. I will look in to these issues on September 5 (sooner if I can get sponsorship to fix these bugs). - Sam From D.Rotondi at Computer.Org Wed Aug 24 11:35:45 2011 From: D.Rotondi at Computer.Org (Domenico Rotondi) Date: Wed, 24 Aug 2011 17:35:45 +0200 Subject: [MaraDNS list] MaraDNS authoritative and recursive config issue In-Reply-To: References: <4E53D9DD.14048.1E82841@D.Rotondi.Computer.Org>, <8f697b35f1b45c8327cb545fc685ca7d@datafaber.net>, Message-ID: <4E551A51.22891.1AF3BFF@D.Rotondi.Computer.Org> On 24 Aug 2011 at 10:42, Sam Trenholme wrote: Hi, thanks to Sebastiano and Sam. I finally was able to set up the configuration for MaraDNS 2-0-3 and Deeawood 3.0. I report the detials here for the benefit of MaraDNS users. My problem was to be able to support on my intranet (which has its own DNS servers that support both management of the intranet domain/subdomains and resolution for Internet domains) resolution for names belonging to the "example.org" domain to IP addresses of machines on our intranet (these machines are not altered in any way; so they still are part of the intranet domain. Our environment is Windows based!). I installed MaraDNS and Deadwood on my laptop (a Windows 7 Enterprise 64-bits) following the instructions provided within the MaraDNS zip file. I've not installed MaraDNS as a Windows service beacause I don't need a permanent support for the "example.org" domain-2-IP resolution! Deadwood is, instead, installed as a Windows service even if I changes its properties so that it doesn't start automatically. Having performed all the above instalaltion I've configured MaraDNS to bind on the 127.0.0.1 IP address, so that it cannot be directly accessed from other machines, while Deadwood is bound to my laptop IP address (192.168.152.67 as indicated in the config file below). The MaraDNS config is the following: # # Bind MaraDNS to my laptop IP Address # # N.B.: this IP address has to be changed according to the IP address of the machine on which MaraDNS is running # ipv4_bind_addresses = "127.0.0.1" timestamp_type = 2 random_seed_file = "secret.txt" ## # verbose_level: The number of messages we log to stdout. It can have five values: # 0 No messages except for the legal disclaimer and fatal parsing errors # 1 Only startup messages logged (Default level) # 2 Error queries logged # 3 All queries logged # 4 All actions adding and removing records from the cache logged # verbose_level = 1 # # ## hide_disclaimer = "YES" # # # This section states where the data for the authoritative zone are held # csv2 = {} csv2["example.org."] = "db.example.org.txt" as you can see I simply specify that MaraDNS has to manage the example.org domain and be bound to the specified IP address. The Deadwood config file instead is this one: # # This section instructs "Deadwood" to redirect DNS queries for non- authoritative zones to other DNS servers # # N.B.: the IP addresses in this section must be set according to the DNS configuration of your local Net # root_servers = {} root_servers["example.org."] = "127.0.0.1" root_servers["."] = "192.168.152.5," root_servers["."] += "192.168.152.8," root_servers["."] += "192.168.210.33" # # Bind "Deadwood" to my laptop IP Address # # N.B.: this IP address has to be changed according to the IP address of the machine on which "Deadwood" is installed # bind_address="192.168.152.67" # # Enable the provision of private IP addresses in DNS replies # filter_rfc1918=0 # # The IPs allowed to connect and use the cache # N.B.: this value must be updated as requested recursive_acl = "192.168.152.0/24" # The file containing a hard-to-guess secret random_seed_file = "secret.txt" # This is the file Deadwood uses to read the cache to and from disk cache_file = "dw_cache_bin" as you can see I've instructed Deadwood to redirect any example.org query to the MaraDNS active on the 127.0.0.1 IP address and all other DNS queries to our internal DNS servers (see root_servers["."] lines above). Additionally I've instructed Deaddwood to bind to my laptop IP address and accept DNS queries from all machines in our intranet. All this is not sufficient if you don't specify the filter_rfc1918=0 line, instrcting Deadwood to return IP private address in DNS replies. Indeed if you leave the filter_rfc1918 default value (1), Deadwood will correctly pass example.org queries to MaraDNS but will not return any IP address (if, as normal, you are using private IP addresses for the example.org domain). That' all. Thanks again to the people who provided hints to me. Regards Domenico > > My Deadwood configuration file is: > > > [snip] > > bind_address="127.0.0.1, 192.168.88.3" > > root_servers={} > > root_servers["home.lan."]="192.168.88.4" > > root_servers["."]="198.41.0.4," > [snip rest of ICANN root servers] > > upstream_servers={} > [Note: no other use of upstream_servers] > > Thanks for the report. The issue here may be that combinations of > root_servers and upstream_servers have some issues. What may also > work for Domenico is to use Deadwood 2.3 (which has really good > upstream_servers support, but no root_servers support) instead of > Deadwood 3.0. > > There appear to be two different bugs with Deadwood 3's upstream_servers: > > * upstream_servers has issues if one of the upstream servers gives us > a SERVER FAIL > > * There may be problems in Deadwood configurations where both > upstream_servers and root_servers are used. > > I will look in to these issues on September 5 (sooner if I can get > sponsorship to fix these bugs). > > - Sam > From angeld at froga.net Sat Aug 27 09:41:30 2011 From: angeld at froga.net (AngelD) Date: Sat, 27 Aug 2011 15:41:30 +0200 (CEST) Subject: [MaraDNS list] [zoneserver] Missing registers Message-ID: I have this test zone file: % SOA % dns at dns.net. /serial 1800 1800 604800 1800 ~ /ttl 1800 ~ 0.% FQDN4 192.168.1. ~ 1.% FQDN4 192.168.1.1 ~ 2.% FQDN4 192.168.1.2 ~ 3.% FQDN4 192.168.1.3 ~ 4.% FQDN4 192.168.1.4 ~ 5.% FQDN4 192.168.1.5 ~ 6.% FQDN4 192.168.1.6 ~ 7.% FQDN4 192.168.1.7 ~ 8.% FQDN4 192.168.1.8 ~ 9.% FQDN4 192.168.1.9 ~ 10.% FQDN4 192.168.1.10 ~ 11.% FQDN4 192.168.1.11 ~ 12.% FQDN4 192.168.1.12 ~ 13.% FQDN4 192.168.1.13 ~ 14.% FQDN4 192.168.1.14 ~ 15.% FQDN4 192.168.1.15 ~ 16.% FQDN4 192.168.1.16 ~ 17.% FQDN4 192.168.1.17 ~ 18.% FQDN4 192.168.1.18 ~ 19.% FQDN4 192.168.1.19 ~ 20.% FQDN4 192.168.1.20 ~ 21.% FQDN4 192.168.1.21 ~ The server resolv all registries OK, but the fetchzone mising some registers (17, 18, 19 and 20): # Disabled out-of-bailiwick record follows # 0.1.168.192.in-addr.arpa. +1800 ptr 0.doo.dns.net. ~ 0.doo.dns.net. +1800 a 192.168.1.0 ~ # Disabled out-of-bailiwick record follows # 1.1.168.192.in-addr.arpa. +1800 ptr 1.doo.dns.net. ~ 1.doo.dns.net. +1800 a 192.168.1.1 ~ # Disabled out-of-bailiwick record follows # 2.1.168.192.in-addr.arpa. +1800 ptr 2.doo.dns.net. ~ 2.doo.dns.net. +1800 a 192.168.1.2 ~ # Disabled out-of-bailiwick record follows # 3.1.168.192.in-addr.arpa. +1800 ptr 3.doo.dns.net. ~ 3.doo.dns.net. +1800 a 192.168.1.3 ~ # Disabled out-of-bailiwick record follows # 4.1.168.192.in-addr.arpa. +1800 ptr 4.doo.dns.net. ~ 4.doo.dns.net. +1800 a 192.168.1.4 ~ # Disabled out-of-bailiwick record follows # 5.1.168.192.in-addr.arpa. +1800 ptr 5.doo.dns.net. ~ 5.doo.dns.net. +1800 a 192.168.1.5 ~ # Disabled out-of-bailiwick record follows # 6.1.168.192.in-addr.arpa. +1800 ptr 6.doo.dns.net. ~ 6.doo.dns.net. +1800 a 192.168.1.6 ~ # Disabled out-of-bailiwick record follows # 7.1.168.192.in-addr.arpa. +1800 ptr 7.doo.dns.net. ~ 7.doo.dns.net. +1800 a 192.168.1.7 ~ # Disabled out-of-bailiwick record follows # 8.1.168.192.in-addr.arpa. +1800 ptr 8.doo.dns.net. ~ 8.doo.dns.net. +1800 a 192.168.1.8 ~ # Disabled out-of-bailiwick record follows # 9.1.168.192.in-addr.arpa. +1800 ptr 9.doo.dns.net. ~ 9.doo.dns.net. +1800 a 192.168.1.9 ~ # Disabled out-of-bailiwick record follows # 10.1.168.192.in-addr.arpa. +1800 ptr 10.doo.dns.net. ~ 10.doo.dns.net. +1800 a 192.168.1.10 ~ # Disabled out-of-bailiwick record follows # 11.1.168.192.in-addr.arpa. +1800 ptr 11.doo.dns.net. ~ 11.doo.dns.net. +1800 a 192.168.1.11 ~ # Disabled out-of-bailiwick record follows # 12.1.168.192.in-addr.arpa. +1800 ptr 12.doo.dns.net. ~ 12.doo.dns.net. +1800 a 192.168.1.12 ~ # Disabled out-of-bailiwick record follows # 13.1.168.192.in-addr.arpa. +1800 ptr 13.doo.dns.net. ~ 13.doo.dns.net. +1800 a 192.168.1.13 ~ # Disabled out-of-bailiwick record follows # 14.1.168.192.in-addr.arpa. +1800 ptr 14.doo.dns.net. ~ 14.doo.dns.net. +1800 a 192.168.1.14 ~ # Disabled out-of-bailiwick record follows # 15.1.168.192.in-addr.arpa. +1800 ptr 15.doo.dns.net. ~ 15.doo.dns.net. +1800 a 192.168.1.15 ~ # Disabled out-of-bailiwick record follows # 16.1.168.192.in-addr.arpa. +1800 ptr 16.doo.dns.net. ~ 16.doo.dns.net. +1800 a 192.168.1.16 ~ # Disabled out-of-bailiwick record follows # 21.1.168.192.in-addr.arpa. +1800 ptr 21.doo.dns.net. ~ 21.doo.dns.net. +1800 a 192.168.1.21 ~ Is a misconfiguration?, Is a bug?. -- Saludos --- Angel From strenholme.usenet at gmail.com Sat Aug 27 12:49:28 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 27 Aug 2011 12:49:28 -0400 Subject: [MaraDNS list] [zoneserver] Missing registers In-Reply-To: References: Message-ID: > ? ? ? ?The server resolv all registries OK, but the fetchzone mising some > registers (17, 18, 19 and 20): > ? ? ? ?Is a misconfiguration?, Is a bug?. It looks to be a bug. Right now, the next day I have scheduled to look at bugs is September 5 (I'm not getting enough sponsorship to look at bugs any sooner). However, there are already a number of Deadwood bugs which I need to look at on this day. That in mind, I probably won't be able to look at this bug until October 5. Thank you for the bug report; please be patient until I get some more sponsorship or wait a couple of months before I have allocated unpaid time to look at this bug. If anyone else wishes to look at this bug and submit a patch, be my guest. If someone wishes to sponsor me fixing this bug, the rates are very very reasonable and we can discuss them in private email. - Sam