From dave at teamunify.com Wed Jun 5 12:50:32 2013 From: dave at teamunify.com (Dave Owens) Date: Wed, 5 Jun 2013 09:50:32 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: Hi Sam and list members, I have a mararc.base like this: ipv4_bind_addresses = "192.168.50.250" synth_soa_origin = "ns1.teamunify.net" maradns_uid = 65500 maradns_gid = 65500 chroot_dir = "/etc/maradns" default_rrany_set = 15 verbose_level = 2 hide_disclaimer = "yes" tcp_convert_acl = "0.0.0.0/0" tcp_convert_server = "192.168.50.250" recursive_acl = "192.168.50.0/24, 10.10.0.0/16, 127.0.0.1" csv2 = {} I have added a record to the teamunify.com.zone file like this: topica.% 192.168.50.141 ~ I am able to get the A record returned when I query the server from the local subnet. I am not able to get the A record returned when I query the server remotely. Logging at verbose_level = 3 shows that MaraDNS does receive the query: Query from: $PUBLIC_IP Atopica.teamunify.com. ...but there are no errors in the log related to the query. We have other private IP A records in that zone file, and all can return A records when queried remotely. None of the working addresses are in the 192.168.50.0/24 subnet, however. Dave Owens TeamUnify, LLC From remco at webconquest.com Wed Jun 5 13:47:35 2013 From: remco at webconquest.com (Remco Rijnders) Date: Wed, 5 Jun 2013 19:47:35 +0200 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: <16b.Nwc@r78.nl> On Wed, Jun 05, 2013 at 09:50:32AM -0700, Dave wrote in : >Hi Sam and list members, > >I have a mararc.base like this: > >ipv4_bind_addresses = "192.168.50.250" >synth_soa_origin = "ns1.teamunify.net" >maradns_uid = 65500 >maradns_gid = 65500 >chroot_dir = "/etc/maradns" >default_rrany_set = 15 >verbose_level = 2 >hide_disclaimer = "yes" >tcp_convert_acl = "0.0.0.0/0" >tcp_convert_server = "192.168.50.250" >recursive_acl = "192.168.50.0/24, 10.10.0.0/16, 127.0.0.1" >csv2 = {} > >I have added a record to the teamunify.com.zone file like this: > >topica.% 192.168.50.141 ~ > >I am able to get the A record returned when I query the server from the >local subnet. I am not able to get the A record returned when I query the >server remotely. > >Logging at verbose_level = 3 shows that MaraDNS does receive the query: >Query from: $PUBLIC_IP Atopica.teamunify.com. >...but there are no errors in the log related to the query. > >We have other private IP A records in that zone file, and all can return A >records when queried remotely. None of the working addresses are in the >192.168.50.0/24 subnet, however. Hi Dave, While I don't know the answer to your query right now... am I correct in understanding that remotely querying for an address with an A record in the 10.10 range for example works? What version of maradns are you using? Then, I notice the use of both teamunify.net and teamunify.com domains in your example. Is that not causing any issues / explain the difference between the internal and external set up? [remmy at silvertown ~ (master)]$ askmara Atopica.teamunify.com. 208.100.130.99 # Querying the server with the IP 208.100.130.99 # Hard Error: Timeout [remmy at silvertown ~ (master)]$ askmara Atopica.teamunify.net. 208.100.130.99 # Querying the server with the IP 208.100.130.99 # Remote server said: NAME ERROR # Question: Atopica.teamunify.net. # NS replies: #teamunify.net. +86400 soa ns1.teamunify.net. hostmaster at teamunify.net. 176478890 7200 3600 604800 3600 # AR replies: The timeout in the first commands makes me ask: Any firewalling in place? Remmy From dave at teamunify.com Wed Jun 5 14:29:06 2013 From: dave at teamunify.com (Dave Owens) Date: Wed, 5 Jun 2013 11:29:06 -0700 Subject: [MaraDNS list] Fwd: Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: <16b.Nwc@r78.nl> Message-ID: Hi Remmy, We are using maradns-2.0.06. You are correct that remote queries for the A record of jenkins.teamunify.com (10.11.13/24) are returned with no problem. The same is true for queries against the many other domains for which we are authoritative... such as acswimteam.org. However, queries for the A record tensub.teamunify.com (10.10/16) also fail. I also tested adding the topica A record to the teamunify.net zone, and A records queries are not returned. We are running stateless firewalls on both the server and at the edge of our network. Should be able to rule the firewalls out as other A record queries succeed, just this specific one fails. We use the teamunify.net domain for infrastructure-related things, and the teamunify.com domain for public services. This configuration has not previously been a problem (we've been running MaraDNS for at least three years). Dave Owens TeamUnify, LLC On Wed, Jun 5, 2013 at 10:47 AM, Remco Rijnders wrote: > On Wed, Jun 05, 2013 at 09:50:32AM -0700, Dave wrote in > > >: > > Hi Sam and list members, >> >> I have a mararc.base like this: >> >> ipv4_bind_addresses = "192.168.50.250" >> synth_soa_origin = "ns1.teamunify.net" >> maradns_uid = 65500 >> maradns_gid = 65500 >> chroot_dir = "/etc/maradns" >> default_rrany_set = 15 >> verbose_level = 2 >> hide_disclaimer = "yes" >> tcp_convert_acl = "0.0.0.0/0" >> tcp_convert_server = "192.168.50.250" >> recursive_acl = "192.168.50.0/24, 10.10.0.0/16, 127.0.0.1" >> csv2 = {} >> >> I have added a record to the teamunify.com.zone file like this: >> >> topica.% 192.168.50.141 ~ >> >> I am able to get the A record returned when I query the server from the >> local subnet. I am not able to get the A record returned when I query the >> server remotely. >> >> Logging at verbose_level = 3 shows that MaraDNS does receive the query: >> Query from: $PUBLIC_IP Atopica.teamunify.com. >> ...but there are no errors in the log related to the query. >> >> We have other private IP A records in that zone file, and all can return A >> records when queried remotely. None of the working addresses are in the >> 192.168.50.0/24 subnet, however. >> > > Hi Dave, > > While I don't know the answer to your query right now... am I correct in > understanding that remotely querying for an address with an A record in the > 10.10 range for example works? > > What version of maradns are you using? > > Then, I notice the use of both teamunify.net and teamunify.com domains in > your example. Is that not causing any issues / explain the difference > between the internal and external set up? > > [remmy at silvertown ~ (master)]$ askmara Atopica.teamunify.com. > 208.100.130.99 > # Querying the server with the IP 208.100.130.99 > # Hard Error: Timeout > [remmy at silvertown ~ (master)]$ askmara Atopica.teamunify.net. > 208.100.130.99 > # Querying the server with the IP 208.100.130.99 > # Remote server said: NAME ERROR > # Question: Atopica.teamunify.net. > # NS replies: > #teamunify.net. +86400 soa ns1.teamunify.net. hostmaster at teamunify.net. > 176478890 7200 3600 604800 3600 > # AR replies: > > The timeout in the first commands makes me ask: Any firewalling in place? > > Remmy > From wc-tmp at useunix.net Wed Jun 5 14:50:52 2013 From: wc-tmp at useunix.net (wc-tmp at useunix.net) Date: Wed, 5 Jun 2013 14:50:52 -0400 Subject: [MaraDNS list] CNAME chaining Message-ID: <20130605185052.GK6525@slacker.ja10629.home> We're running Deadwood 3.2.01 and I've got users complaining that they cannot resolve www.spireon.com. Indeed when I test this it sometimes works and sometimes doesn't. I've tested against my ISPs resolver and Google's public resolvers (8.8.8.8) and it works reliably everytime. In ths case www.spireon.com is a CNAME to another CNAME. Here is the dig output (also note, that I've tested with dig and nslookup, both have problems when resolving this against Deadwood): ------------------------------------------------------------------------ <<>> DiG 9.9.2-P2 <<>> @10.203.11.39 www.spireon.com. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9954 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.spireon.com. IN A ;; ANSWER SECTION: www.spireon.com. 60 IN CNAME global.spireon.com. global.spireon.com. 60 IN CNAME marketing-elb-spireon1-290371133.us-east-1.elb.amazonaws.com. marketing-elb-spireon1-290371133.us-east-1.elb.amazonaws.com. 60 IN A 23.23.215.69 ;; Query time: 111 msec ;; SERVER: 10.203.11.39#53(10.203.11.39) ;; WHEN: Wed Jun 5 14:42:40 2013 ;; MSG SIZE rcvd: 141 ------------------------------------------------------------------------ I've seen that many recommend against CNAME chaining, while bad practice it doesn't appear to violate the RFC, so I think Dw should handle this. Can anyone else test this resolution and see if they experience the same problem? Thanks in advance, Wayne From sebastiano at datafaber.net Wed Jun 5 15:06:01 2013 From: sebastiano at datafaber.net (Sebastiano Pilla) Date: Wed, 05 Jun 2013 21:06:01 +0200 Subject: [MaraDNS list] CNAME chaining In-Reply-To: <20130605185052.GK6525@slacker.ja10629.home> References: <20130605185052.GK6525@slacker.ja10629.home> Message-ID: <51AF8C19.8020702@datafaber.net> wc-tmp at useunix.net wrote: > We're running Deadwood 3.2.01 and I've got users complaining that they > cannot resolve www.spireon.com. ... > I've seen that many recommend against CNAME chaining, while bad practice > it doesn't appear to violate the RFC, so I think Dw should handle this. > Can anyone else test this resolution and see if they experience the same > problem? Using Deadwood 3.2.03, it worked for me: [admin at picard ~]$ dig @192.168.88.21 www.spireon.com ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> @192.168.88.21 www.spireon.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37809 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.spireon.com. IN A ;; ANSWER SECTION: www.spireon.com. 60 IN CNAME global.spireon.com. global.spireon.com. 60 IN CNAME marketing-elb-spireon1-290371133.us-east-1.elb.amazonaws.com. marketing-elb-spireon1-290371133.us-east-1.elb.amazonaws.com. 60 IN A 23.23.215.69 ;; Query time: 845 msec ;; SERVER: 192.168.88.21#53(192.168.88.21) ;; WHEN: Wed Jun 5 21:05:47 2013 ;; MSG SIZE rcvd: 141 From wc-tmp at useunix.net Wed Jun 5 15:46:25 2013 From: wc-tmp at useunix.net (wc-tmp at useunix.net) Date: Wed, 5 Jun 2013 15:46:25 -0400 Subject: [MaraDNS list] CNAME chaining In-Reply-To: <51AF8C19.8020702@datafaber.net> References: <20130605185052.GK6525@slacker.ja10629.home> <51AF8C19.8020702@datafaber.net> Message-ID: <20130605194625.GL6525@slacker.ja10629.home> Thank you for testing Sebastiano! We have multiple connections to the internet and when I test using one it works. From the other, our corporate connection, we receive no replies ns78.worldnic.com nor ns77.worldnic.com which are the authoritative NS for the spireon.com zone. I don't know whether they are not receiving my queries or I'm not receive their responses but I clearly see using Dw's verbose logging that requests are being sent to both of their NSs and no response arriving. I don't think this is something that I can fix and I hate trying to explain something like this to my clients. Thanks again for the response. Wayne On Wed, Jun 05, 2013 at 09:06:01PM +0200, Sebastiano Pilla wrote: > wc-tmp at useunix.net wrote: > >We're running Deadwood 3.2.01 and I've got users complaining that they > >cannot resolve www.spireon.com. > > ... > > >I've seen that many recommend against CNAME chaining, while bad practice > >it doesn't appear to violate the RFC, so I think Dw should handle this. > >Can anyone else test this resolution and see if they experience the same > >problem? > > Using Deadwood 3.2.03, it worked for me: > > [admin at picard ~]$ dig @192.168.88.21 www.spireon.com > > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.17.rc1.el6_4.4 <<>> @192.168.88.21 > www.spireon.com > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37809 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.spireon.com. IN A > > ;; ANSWER SECTION: > www.spireon.com. 60 IN CNAME global.spireon.com. > global.spireon.com. 60 IN CNAME > marketing-elb-spireon1-290371133.us-east-1.elb.amazonaws.com. > marketing-elb-spireon1-290371133.us-east-1.elb.amazonaws.com. 60 IN A > 23.23.215.69 > > ;; Query time: 845 msec > ;; SERVER: 192.168.88.21#53(192.168.88.21) > ;; WHEN: Wed Jun 5 21:05:47 2013 > ;; MSG SIZE rcvd: 141 > > From ozgurkazancci at gmail.com Sat Jun 8 22:20:38 2013 From: ozgurkazancci at gmail.com (=?ISO-8859-9?B?1npn/HIgS2F6YW7n5/0=?=) Date: Sun, 9 Jun 2013 05:20:38 +0300 Subject: [MaraDNS list] Memory allocation limits on OpenBSD Message-ID: Hello everyone. I've installed MaraDNS today, by fetching maradns-1.4.12.tar.gz, then doing a make, and make install. The setup went fine. However MaraDNS always reports the following warning: "Jun 9 05:14:17 tstusr maradns: WARNING: Your system does not allow setting memory allocation limits! Log: All RRs have been loaded" How can I stop that warning? # maradns -v This is MaraDNS version 1.4.12 Compiled on a OpenBSD system at Sun Jun 9 05:06:48 EEST 2013 For usage information, 'man maradns' OS: OpenBSD 5.3 2nd question: The MaraDNS package in OpenBSD pkgs seems quite old; maradns-1.3.07.15. There's now 1.4.12, even 2.0.07, I wonder is there any "license issue" that it doesn't get updated anymore in OpenBSD? Thanks. From remco at webconquest.com Mon Jun 10 02:10:01 2013 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 10 Jun 2013 08:10:01 +0200 Subject: [MaraDNS list] Memory allocation limits on OpenBSD In-Reply-To: References: Message-ID: <16*.^l0@r78.nl> On Sun, Jun 09, 2013 at 05:20:38AM +0300, ?zg?r wrote in : > >OS: OpenBSD 5.3 > >2nd question: The MaraDNS package in OpenBSD pkgs seems quite old; >maradns-1.3.07.15. There's now 1.4.12, even 2.0.07, I wonder >is there any "license issue" that it doesn't get updated anymore in OpenBSD? Hi ?zg?r, No, there is not any license issue to blame for this. If anything, I fear "lack of interest" is the reason for this. Best, Remmy From maradns at gmail.com Mon Jun 10 04:35:22 2013 From: maradns at gmail.com (Sam Trenholme) Date: Mon, 10 Jun 2013 01:35:22 -0700 Subject: [MaraDNS list] CNAME chaining In-Reply-To: <20130605185052.GK6525@slacker.ja10629.home> References: <20130605185052.GK6525@slacker.ja10629.home> Message-ID: Deadwood works just fine with CNAME chains...I went to a lot of effort to get CNAMEs right. Recently, I fixed an obscure once-in-a-blue-moon Deadwood resolving bug in Deadwood 3.2.03a. Make sure to use this version of Deadwood, which is available here: http://maradns.org/deadwood/stable/ I am able to resolve the A record for both spireon.com and www.spireon.com without problem in Deadwood 3.2.03a. I assume this is the same bug I saw with whatever.scalzi.com a couple of months ago: http://samiam.org/blog/20130320.html If, after upgrading to 3.2.03a, anyone has any problems resolving any host name that 8.8.8.8/8.8.4.4 can resolve, please post a bug report here. - Sam On Wed, Jun 5, 2013 at 11:50 AM, wrote: > We're running Deadwood 3.2.01 and I've got users complaining that they > cannot resolve www.spireon.com. > > Indeed when I test this it sometimes works and sometimes doesn't. I've > tested against my ISPs resolver and Google's public resolvers (8.8.8.8) > and it works reliably everytime. > > In ths case www.spireon.com is a CNAME to another CNAME. Here is the dig > output (also note, that I've tested with dig and nslookup, both have > problems when resolving this against Deadwood): > > ------------------------------------------------------------------------ > <<>> DiG 9.9.2-P2 <<>> @10.203.11.39 www.spireon.com. > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9954 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;www.spireon.com. IN A > > ;; ANSWER SECTION: > www.spireon.com. 60 IN CNAME global.spireon.com. > global.spireon.com. 60 IN CNAME marketing-elb-spireon1-290371133.us-east-1.elb.amazonaws.com. > marketing-elb-spireon1-290371133.us-east-1.elb.amazonaws.com. 60 IN A 23.23.215.69 > > ;; Query time: 111 msec > ;; SERVER: 10.203.11.39#53(10.203.11.39) > ;; WHEN: Wed Jun 5 14:42:40 2013 > ;; MSG SIZE rcvd: 141 > ------------------------------------------------------------------------ > > I've seen that many recommend against CNAME chaining, while bad practice > it doesn't appear to violate the RFC, so I think Dw should handle this. > Can anyone else test this resolution and see if they experience the same > problem? > > Thanks in advance, > Wayne From maradns at gmail.com Mon Jun 10 04:42:39 2013 From: maradns at gmail.com (Sam Trenholme) Date: Mon, 10 Jun 2013 01:42:39 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: Looking at this configuration file, recursive_acl doesn't do much in MaraDNS 2.0.06...make sure you're using Deadwood to resolve anything remotely. Also, if you're using Deadwood as the recursive name server, there's a gotcha with IPs that resolve to 127.x.x.x, 172.[16-31].x.x, 10.x.x.x, or 192.168.x.x. Make sure to have filter_rfc1918 set to 0: http://maradns.org/deadwood/browse-source/head/doc/Deadwood-HOWTO Note to self: Add filter_rfc1918 note to Deadwood FAQ. This isn't the first time Deadwood's built-in DNSwall has confused people. - Sam On Wed, Jun 5, 2013 at 9:50 AM, Dave Owens wrote: > Hi Sam and list members, > > I have a mararc.base like this: > > ipv4_bind_addresses = "192.168.50.250" > synth_soa_origin = "ns1.teamunify.net" > maradns_uid = 65500 > maradns_gid = 65500 > chroot_dir = "/etc/maradns" > default_rrany_set = 15 > verbose_level = 2 > hide_disclaimer = "yes" > tcp_convert_acl = "0.0.0.0/0" > tcp_convert_server = "192.168.50.250" > recursive_acl = "192.168.50.0/24, 10.10.0.0/16, 127.0.0.1" > csv2 = {} > > I have added a record to the teamunify.com.zone file like this: > > topica.% 192.168.50.141 ~ > > I am able to get the A record returned when I query the server from the > local subnet. I am not able to get the A record returned when I query the > server remotely. > > Logging at verbose_level = 3 shows that MaraDNS does receive the query: > Query from: $PUBLIC_IP Atopica.teamunify.com. > ...but there are no errors in the log related to the query. > > We have other private IP A records in that zone file, and all can return A > records when queried remotely. None of the working addresses are in the > 192.168.50.0/24 subnet, however. > > Dave Owens > TeamUnify, LLC From ozgurkazancci at gmail.com Mon Jun 10 04:42:53 2013 From: ozgurkazancci at gmail.com (=?ISO-8859-9?B?1npn/HIgS2F6YW7n5/0=?=) Date: Mon, 10 Jun 2013 11:42:53 +0300 Subject: [MaraDNS list] Memory allocation limits on OpenBSD In-Reply-To: <16*.^l0@r78.nl> References: <16*.^l0@r78.nl> Message-ID: Mr. Remmy, thanks for your reply. And how about the error of "not allowing setting memory allocation limits" for OpenBSD? Would there be any fix to solve this? My last question; Is there any solution for the following error when compiling MaraDNS 2.0.7 on OpenBSD 5.3? ; "MaraDNS.c: In function 'main': MaraDNS.c:3724: warning: unused variable 'thread_overhead'" Thanks once again, Regards. On Mon, Jun 10, 2013 at 9:10 AM, Remco Rijnders wrote: > On Sun, Jun 09, 2013 at 05:20:38AM +0300, ?zg?r wrote in < > CA+GnASdecQ-YxSoSp6RMt+**VoyNtLo_m4KXpK2tqEHbpqSY0PZg@**mail.gmail.com > >: > > >> OS: OpenBSD 5.3 >> >> 2nd question: The MaraDNS package in OpenBSD pkgs seems quite old; >> maradns-1.3.07.15. There's now 1.4.12, even 2.0.07, I wonder >> is there any "license issue" that it doesn't get updated anymore in >> OpenBSD? >> > > Hi ?zg?r, > > No, there is not any license issue to blame for this. If anything, I fear > "lack of interest" is the reason for this. > > Best, > > Remmy > From maradns at gmail.com Mon Jun 10 04:43:38 2013 From: maradns at gmail.com (Sam Trenholme) Date: Mon, 10 Jun 2013 01:43:38 -0700 Subject: [MaraDNS list] Memory allocation limits on OpenBSD In-Reply-To: References: Message-ID: > 2nd question: The MaraDNS package in OpenBSD pkgs seems quite old; > maradns-1.3.07.15. There's now 1.4.12, even 2.0.07, I wonder > is there any "license issue" that it doesn't get updated anymore in OpenBSD? No license issue. Every single MaraDNS release since 1.1 has been released under the same 2-clause BSD license. - Sam From ozgurkazancci at gmail.com Mon Jun 10 05:38:05 2013 From: ozgurkazancci at gmail.com (=?ISO-8859-9?B?1npn/HIgS2F6YW7n5/0=?=) Date: Mon, 10 Jun 2013 12:38:05 +0300 Subject: [MaraDNS list] uucp user, and the logger folder. Message-ID: I use MaraDNS 2.0.7 as authoritative name server. My "ps auwx" output shows; uucp 29449 0.0 0.5 408 708 C0- I 12:33PM 0:00.00 duende-log-helper /usr/local/sbin/maradns (duende) _maradns 23602 0.0 0.8 728 1000 C0- S 12:33PM 0:00.02 /usr/local/sbin/maradns root 26374 0.0 0.3 336 360 C0- S 12:33PM 0:00.00 /usr/local/bin/duende /usr/local/sbin/maradns What does duende-log-helper do with the user uucp? Shouldn't it run as _maradns? Additionally, /etc/maradns/logger/ folder is always empty, and I wonder what does MaraDNS do with that logger folder? Is it possible to redirect MaraDNS's logs from general /var/log/daemon log file, into /etc/maradns/logger/maralogs ? Thanks. From maradns at gmail.com Mon Jun 10 11:53:14 2013 From: maradns at gmail.com (Sam Trenholme) Date: Mon, 10 Jun 2013 08:53:14 -0700 Subject: [MaraDNS list] uucp user, and the logger folder. In-Reply-To: References: Message-ID: > My "ps auwx" output shows; > > uucp 29449 0.0 0.5 408 708 C0- I 12:33PM 0:00.00 > duende-log-helper /usr/local/sbin/maradns (duende) > > What does duende-log-helper do with the user uucp? Shouldn't it run as > _maradns? Duende uses UID 66 for the logger process. That is a simple numeric UID in CentOS/RedHat, but appears to be the user-id for the obsolete UUCP protocol in OpenBSD. Changing this UID requires a patch. I am willing to host to do not make patches for OSes besides Windows 7 and CentOS 6. > Additionally, /etc/maradns/logger/ folder is always empty, and I wonder > what does MaraDNS do with that logger folder? It?s a chroot() jail to sandbox the process. > Is it possible to redirect MaraDNS's logs from general /var/log/daemon log > file, into /etc/maradns/logger/maralogs ? Probably, but I am not familiar enough with OpenBSD's syslog to answer this question. > Thanks. From dave at teamunify.com Tue Jun 11 15:06:44 2013 From: dave at teamunify.com (Dave Owens) Date: Tue, 11 Jun 2013 12:06:44 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: Hi Sam, Thank you for the reply. I removed the recursive_acl config. We don't want to offer recursive DNS for queries against our NS, so need for Deadwood... I'm still running up against the problem... rfc1918 addresses within the server's connected subnets will not resolve, other rfc1918 adresses resolve with no issue. The logs show normal 'processing query' message, but no response is sent... client that sent the query eventually times out. I'd be happy to help test this if you'd like. I plan to work around this such that I will advertise rfc1918 addresses that MaraDNS *can* resolve for these new hosts. This turns out to be the Right Thing with regard to our topology anyway... Thank you, Dave Owens TeamUnify, LLC On Mon, Jun 10, 2013 at 1:42 AM, Sam Trenholme wrote: > Looking at this configuration file, recursive_acl doesn't do much in > MaraDNS 2.0.06...make sure you're using Deadwood to resolve anything > remotely. > > Also, if you're using Deadwood as the recursive name server, there's a > gotcha with IPs that resolve to 127.x.x.x, 172.[16-31].x.x, 10.x.x.x, > or 192.168.x.x. Make sure to have filter_rfc1918 set to 0: > > http://maradns.org/deadwood/browse-source/head/doc/Deadwood-HOWTO > > Note to self: Add filter_rfc1918 note to Deadwood FAQ. This isn't the > first time Deadwood's built-in DNSwall has confused people. > > - Sam > > On Wed, Jun 5, 2013 at 9:50 AM, Dave Owens wrote: > > Hi Sam and list members, > > > > I have a mararc.base like this: > > > > ipv4_bind_addresses = "192.168.50.250" > > synth_soa_origin = "ns1.teamunify.net" > > maradns_uid = 65500 > > maradns_gid = 65500 > > chroot_dir = "/etc/maradns" > > default_rrany_set = 15 > > verbose_level = 2 > > hide_disclaimer = "yes" > > tcp_convert_acl = "0.0.0.0/0" > > tcp_convert_server = "192.168.50.250" > > recursive_acl = "192.168.50.0/24, 10.10.0.0/16, 127.0.0.1" > > csv2 = {} > > > > I have added a record to the teamunify.com.zone file like this: > > > > topica.% 192.168.50.141 ~ > > > > I am able to get the A record returned when I query the server from the > > local subnet. I am not able to get the A record returned when I query > the > > server remotely. > > > > Logging at verbose_level = 3 shows that MaraDNS does receive the query: > > Query from: $PUBLIC_IP Atopica.teamunify.com. > > ...but there are no errors in the log related to the query. > > > > We have other private IP A records in that zone file, and all can return > A > > records when queried remotely. None of the working addresses are in the > > 192.168.50.0/24 subnet, however. > > > > Dave Owens > > TeamUnify, LLC > From ozgurkazancci at gmail.com Wed Jun 12 15:59:00 2013 From: ozgurkazancci at gmail.com (=?ISO-8859-9?B?1npn/HIgU3VwaGkgS2F6YW7n5/0=?=) Date: Wed, 12 Jun 2013 22:59:00 +0300 Subject: [MaraDNS list] Bad queries Message-ID: Hello everyone. I get a lot of, I mean A LOT of "Bad query received" messages from MaraDNS inside the log file; Jun 12 21:56:41 ns2 /usr/local/sbin/maradns: Log: I'm sorry Dave (recurse attempt) Jun 12 21:56:41 ns2 /usr/local/sbin/maradns: Log: Message received, processing Jun 12 21:56:41 ns2 /usr/local/sbin/maradns: Query from: 81.23.12.44 Uns2.mydomain.com. Jun 12 21:56:41 ns2 /usr/local/sbin/maradns: Log: Bad query received: \\011\\336\\000\\020\\000\\001\\000\\000\\000\\000\\000\\001\\003ns2\\014mydomain\\003com\\000\\000\\034\\000\\001\\000\\000)\\020\\000\\000\\000\\200\\000\\000\\000 Jun 12 21:56:41 ns2 /usr/local/sbin/maradns: From IP: 81.23.12.44 Jun 12 21:56:41 ns2 /usr/local/sbin/maradns: Log: I'm sorry Dave (recurse attempt) Any idea on reducing such annoying messages? I'm using the latest stable version; # maradns -v This is MaraDNS version 2.0.07 Thanks. From maradns at gmail.com Thu Jun 13 22:04:58 2013 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 13 Jun 2013 19:04:58 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: > I am able to get the A record returned when I query the server from the > local subnet. I am not able to get the A record returned when I query the > server remotely. If you run Wireshark or another network analyzer against the server running MaraDNS, do you see the DNS packet which doesn?t get a reply hit the MaraDNS server? Do you see MaraDNS sending a reply to the DNS packet? I have a sense this issue isn't with Mara; but Wireshark will help us confirm things. DNS replies with RFC1918 addresses in them are considered a bad thing, so there could very well be a firewall dropping the packets. http://wireshark.org/ - Sam From maradns at gmail.com Thu Jun 13 22:07:01 2013 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 13 Jun 2013 19:07:01 -0700 Subject: [MaraDNS list] Bad queries In-Reply-To: References: Message-ID: > Any idea on reducing such annoying messages? RTFM. http://www.maradns.org/tutorial/man.mararc.html Look for "verbose_level" - Sam From dave at teamunify.com Fri Jun 14 09:40:15 2013 From: dave at teamunify.com (Dave Owens) Date: Fri, 14 Jun 2013 06:40:15 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: Hi Sam, Yesterday I ran captures both on our DNS node (it indeed sends the reply) and on the other side of our edge router (no reply is seen). Our colo provider says they aren't doing any deep packet inspection around this... I'll be on the phone with Cisco today, I fear... just very strange that certain A records with 1918 addresses work well. Thank you for all your help. Dave Owens TeamUnify, LLC On Thu, Jun 13, 2013 at 7:04 PM, Sam Trenholme wrote: > > I am able to get the A record returned when I query the server from the > > local subnet. I am not able to get the A record returned when I query > the > > server remotely. > > If you run Wireshark or another network analyzer against the server > running MaraDNS, do you see the DNS packet which doesn?t get a reply > hit the MaraDNS server? > > Do you see MaraDNS sending a reply to the DNS packet? > > I have a sense this issue isn't with Mara; but Wireshark will help us > confirm things. DNS replies with RFC1918 addresses in them are > considered a bad thing, so there could very well be a firewall > dropping the packets. > > http://wireshark.org/ > > - Sam > From maradns at gmail.com Fri Jun 14 14:13:57 2013 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 14 Jun 2013 11:13:57 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: > Yesterday I ran captures both on our DNS node (it indeed sends the reply) > and on the other side of our edge router (no reply is seen). Our colo > provider says they aren't doing any deep packet inspection around this... I want to know how this gets resolved--so I can add this information to the MaraDNS FAQ (which is horribly outdated and needs a serious revamp). There is a small chance it?s a case of ?MaraDNS makes a weird DNS packet which this route doesn?t like?. One way to normalize against that is to have another computer whose packets go through the same route use a different DNS server to send out the 192.168.50.141 DNS reply. For example, here?s a DNS server I wrote a few years ago: $ cat > nanodns.c /*Placed in the public domain by Sam Trenholme*/ #include #include #include #define Z struct sockaddr #define Y sizeof(d) int main(int a,char **b){uint32_t i;char q[512] ,p[17]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a> 1){struct sockaddr_in d;socklen_t f=511;bzero(& d,Y);a=socket(AF_INET,SOCK_DGRAM,0);*((uint32_t *)(p+12))=inet_addr(b[1]);d.sin_family=AF_INET; d.sin_port=htons(53);bind(a,(Z*)&d,Y);for(;;){i =recvfrom(a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0) {q[2]|=128;q[11]?q[3]|=4:1;q[7]++;memcpy(q+i,p, 16);sendto(a,q,i+16,0,(Z*)&d,Y);}}}return 0;} // Hit control-D to end this file here $ gcc -g -O nanodns nanodns.c $ su Password: # ./nanodns 192.168.50.141 At this point, the machine is running a tiny little DNS server which will reply to all DNS queries with the IP 192.168.50.141. I have a more readable version of that DNS server here: http://samiam.org/software/microdns.html - Sam From dave at teamunify.com Fri Jun 14 17:12:45 2013 From: dave at teamunify.com (Dave Owens) Date: Fri, 14 Jun 2013 14:12:45 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: Hi Sam, I tried this with your lightweight DNS server, on a different machine (same route), still no luck. Testing a non-connected rfc1918 returns a response, testing a connected rfc1918 address does not work. An enhanced packet capture shows that when the reply for the 'special' A record is sent to the router, the router replies with an icmp-host-unreachable packet indicating the that the destination IP is unreachable.... I must be hitting a bug or possibly hidden configuration in the router OS. Attached is a .pcapng file that illustrates the behavior... first request succeeds, subsequent three requests fail. Dave Owens TeamUnify, LLC On Fri, Jun 14, 2013 at 11:13 AM, Sam Trenholme wrote: > > Yesterday I ran captures both on our DNS node (it indeed sends the reply) > > and on the other side of our edge router (no reply is seen). Our colo > > provider says they aren't doing any deep packet inspection around this... > > I want to know how this gets resolved--so I can add this information > to the MaraDNS FAQ (which is horribly outdated and needs a serious > revamp). There is a small chance it?s a case of ?MaraDNS makes a > weird DNS packet which this route doesn?t like?. One way to normalize > against that is to have another computer whose packets go through the > same route use a different DNS server to send out the 192.168.50.141 > DNS reply. > > For example, here?s a DNS server I wrote a few years ago: > > $ cat > nanodns.c > /*Placed in the public domain by Sam Trenholme*/ > #include > #include > #include > #define Z struct sockaddr > #define Y sizeof(d) > int main(int a,char **b){uint32_t i;char q[512] > ,p[17]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a> > 1){struct sockaddr_in d;socklen_t f=511;bzero(& > d,Y);a=socket(AF_INET,SOCK_DGRAM,0);*((uint32_t > *)(p+12))=inet_addr(b[1]);d.sin_family=AF_INET; > d.sin_port=htons(53);bind(a,(Z*)&d,Y);for(;;){i > =recvfrom(a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0) > {q[2]|=128;q[11]?q[3]|=4:1;q[7]++;memcpy(q+i,p, > 16);sendto(a,q,i+16,0,(Z*)&d,Y);}}}return 0;} > // Hit control-D to end this file here > $ gcc -g -O nanodns nanodns.c > $ su > Password: > # ./nanodns 192.168.50.141 > > At this point, the machine is running a tiny little DNS server which > will reply to all DNS queries with the IP 192.168.50.141. > > I have a more readable version of that DNS server here: > > http://samiam.org/software/microdns.html > > - Sam > From dave at teamunify.com Mon Jun 17 16:53:28 2013 From: dave at teamunify.com (Dave Owens) Date: Mon, 17 Jun 2013 13:53:28 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: Hi Sam et. al, Wanted to share how this turned out: http://serverfault.com/questions/513608/maradns-does-not-respond-to-a-record-queries-of-locally-connected-rfc1918-addres/516464#516464 Moral of the story is: "Capture traffic early, capture traffic often." Especially when NAT is involved :-) Thanks to everyone for listening. Very happy to learn that MaraDNS is not the culprit. Dave Owens TeamUnify, LLC On Fri, Jun 14, 2013 at 2:12 PM, Dave Owens wrote: > Hi Sam, > > I tried this with your lightweight DNS server, on a different machine > (same route), still no luck. Testing a non-connected rfc1918 returns a > response, testing a connected rfc1918 address does not work. > > An enhanced packet capture shows that when the reply for the 'special' A > record is sent to the router, the router replies with an > icmp-host-unreachable packet indicating the that the destination IP is > unreachable.... I must be hitting a bug or possibly hidden configuration in > the router OS. > > Attached is a .pcapng file that illustrates the behavior... first request > succeeds, subsequent three requests fail. > > Dave Owens > TeamUnify, LLC > > > > > > On Fri, Jun 14, 2013 at 11:13 AM, Sam Trenholme wrote: > >> > Yesterday I ran captures both on our DNS node (it indeed sends the >> reply) >> > and on the other side of our edge router (no reply is seen). Our colo >> > provider says they aren't doing any deep packet inspection around >> this... >> >> I want to know how this gets resolved--so I can add this information >> to the MaraDNS FAQ (which is horribly outdated and needs a serious >> revamp). There is a small chance it?s a case of ?MaraDNS makes a >> weird DNS packet which this route doesn?t like?. One way to normalize >> against that is to have another computer whose packets go through the >> same route use a different DNS server to send out the 192.168.50.141 >> DNS reply. >> >> For example, here?s a DNS server I wrote a few years ago: >> >> $ cat > nanodns.c >> /*Placed in the public domain by Sam Trenholme*/ >> #include >> #include >> #include >> #define Z struct sockaddr >> #define Y sizeof(d) >> int main(int a,char **b){uint32_t i;char q[512] >> ,p[17]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a> >> 1){struct sockaddr_in d;socklen_t f=511;bzero(& >> d,Y);a=socket(AF_INET,SOCK_DGRAM,0);*((uint32_t >> *)(p+12))=inet_addr(b[1]);d.sin_family=AF_INET; >> d.sin_port=htons(53);bind(a,(Z*)&d,Y);for(;;){i >> =recvfrom(a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0) >> {q[2]|=128;q[11]?q[3]|=4:1;q[7]++;memcpy(q+i,p, >> 16);sendto(a,q,i+16,0,(Z*)&d,Y);}}}return 0;} >> // Hit control-D to end this file here >> $ gcc -g -O nanodns nanodns.c >> $ su >> Password: >> # ./nanodns 192.168.50.141 >> >> At this point, the machine is running a tiny little DNS server which >> will reply to all DNS queries with the IP 192.168.50.141. >> >> I have a more readable version of that DNS server here: >> >> http://samiam.org/software/microdns.html >> >> - Sam >> > > From maradns at gmail.com Tue Jun 18 05:08:05 2013 From: maradns at gmail.com (Sam Trenholme) Date: Tue, 18 Jun 2013 02:08:05 -0700 Subject: [MaraDNS list] Fwd: MaraDNS doesn't respond to queries from the bind addr subnet In-Reply-To: References: Message-ID: Thank you so much for this information. Since Deadwood also, by default, drops replies with RFC1918 addresses in it, when I add a FAQ about RFC1918 addresses to Deadwood later on this week or this weekend, I will add a link to your ServerFault posting telling people that routers sometimes also drop RFC1918 addresses. - Sam On Mon, Jun 17, 2013 at 1:53 PM, Dave Owens wrote: > Hi Sam et. al, > > Wanted to share how this turned out: > > http://serverfault.com/questions/513608/maradns-does-not-respond-to-a-record-queries-of-locally-connected-rfc1918-addres/516464#516464 > > Moral of the story is: "Capture traffic early, capture traffic often." > Especially when NAT is involved :-) > > Thanks to everyone for listening. Very happy to learn that MaraDNS is not > the culprit. > > Dave Owens > TeamUnify, LLC > > > > > > On Fri, Jun 14, 2013 at 2:12 PM, Dave Owens wrote: > >> Hi Sam, >> >> I tried this with your lightweight DNS server, on a different machine >> (same route), still no luck. Testing a non-connected rfc1918 returns a >> response, testing a connected rfc1918 address does not work. >> >> An enhanced packet capture shows that when the reply for the 'special' A >> record is sent to the router, the router replies with an >> icmp-host-unreachable packet indicating the that the destination IP is >> unreachable.... I must be hitting a bug or possibly hidden configuration in >> the router OS. >> >> Attached is a .pcapng file that illustrates the behavior... first request >> succeeds, subsequent three requests fail. >> >> Dave Owens >> TeamUnify, LLC >> >> >> >> >> >> On Fri, Jun 14, 2013 at 11:13 AM, Sam Trenholme wrote: >> >>> > Yesterday I ran captures both on our DNS node (it indeed sends the >>> reply) >>> > and on the other side of our edge router (no reply is seen). Our colo >>> > provider says they aren't doing any deep packet inspection around >>> this... >>> >>> I want to know how this gets resolved--so I can add this information >>> to the MaraDNS FAQ (which is horribly outdated and needs a serious >>> revamp). There is a small chance it?s a case of ?MaraDNS makes a >>> weird DNS packet which this route doesn?t like?. One way to normalize >>> against that is to have another computer whose packets go through the >>> same route use a different DNS server to send out the 192.168.50.141 >>> DNS reply. >>> >>> For example, here?s a DNS server I wrote a few years ago: >>> >>> $ cat > nanodns.c >>> /*Placed in the public domain by Sam Trenholme*/ >>> #include >>> #include >>> #include >>> #define Z struct sockaddr >>> #define Y sizeof(d) >>> int main(int a,char **b){uint32_t i;char q[512] >>> ,p[17]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a> >>> 1){struct sockaddr_in d;socklen_t f=511;bzero(& >>> d,Y);a=socket(AF_INET,SOCK_DGRAM,0);*((uint32_t >>> *)(p+12))=inet_addr(b[1]);d.sin_family=AF_INET; >>> d.sin_port=htons(53);bind(a,(Z*)&d,Y);for(;;){i >>> =recvfrom(a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0) >>> {q[2]|=128;q[11]?q[3]|=4:1;q[7]++;memcpy(q+i,p, >>> 16);sendto(a,q,i+16,0,(Z*)&d,Y);}}}return 0;} >>> // Hit control-D to end this file here >>> $ gcc -g -O nanodns nanodns.c >>> $ su >>> Password: >>> # ./nanodns 192.168.50.141 >>> >>> At this point, the machine is running a tiny little DNS server which >>> will reply to all DNS queries with the IP 192.168.50.141. >>> >>> I have a more readable version of that DNS server here: >>> >>> http://samiam.org/software/microdns.html >>> >>> - Sam >>> >> >> From maradns at gmail.com Fri Jun 21 17:35:35 2013 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 21 Jun 2013 14:35:35 -0700 Subject: [MaraDNS list] Deadwood update; Deadwood 2 and MaraDNS 1 end-of-life Message-ID: 11 years ago today, I released MaraDNS 1.0 to the world. Today, I have updated Deadwood and am announcing another end-of-life. ==Deadwood update== I have added a FAQ entry about using Deadwood with RFC1918 addresses. It can be downloaded here: http://www.maradns.org/deadwood/snap/ The updated FAQ: http://maradns.org/deadwood/doc/FAQ.html#11 ==Deadwood 2.0 end-of-life== I have dropped most support for the older, more compact Deadwood 2.0 release. The only thing I update in this branch of Deadwood is security holes with CVE numbers. The last update to Deadwood 2.0 was Deadwood 2.3.08, which addressed CVE-2012-1570. I am now placing an end of life on Deadwood 2.0: June 21, 2016. This gives users three years to update to Deadwood 3.0. With Deadwood out for over two years, it?s time to upgrade. ==MaraDNS 1 end-of-life== Please remember that all MaraDNS 1 releases are only supported for CVE security holes, and that this branch of MaraDNS will no longer be supported two years from today (June 21, 2015): http://samiam.org/blog/20120621.html ==Current MaraDNS plans== Unless a CVE security hole comes up, my present plan is to release Deadwood 3.2.04 and MaraDNS 2.0.08 sometime around the end of the year. While not a hard-and-fast rule (for example, I answered a lot of email on the list this month), my plan is to work on MaraDNS or Deadwood again one day in a couple of months unless a critical security bug with a CVE number is found. From maradns at gmail.com Sat Jun 22 21:43:34 2013 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 22 Jun 2013 18:43:34 -0700 Subject: [MaraDNS list] MaraDNS update (Happy Summer Solstice 2013) Message-ID: Happy Summer Solstice everyone! The long sunny days have inspired me to make a second MaraDNS update in the same month, even though I am not getting paid to do so. I have updated MaraDNS to incorporate a one-line bugfix with Deadwood (MaraDNS?s recursive resolver) in to the codebase. The name of this release is MaraDNS 2.0.07b (for more details on the unusual naming patterns, read the May 23 blog entry at http://samiam.org/blog/20130523.html ) I actually made this release in April, but have waited until now to make it the latest release on Sourceforge and MaraDNS' web page...so it has had two months of testing. This will hopefully stop complaints of being unable to resolve some domain names that occasionally pop up on the mailing list, such as this complaint: http://woodlane.webconquest.com/pipermail/list/2013-June/001172.html It can be downloaded here: http://www.maradns.org/download.html While not a hard-and-fast rule, my plan is to work on MaraDNS or Deadwood again one day in a couple of months unless a critical security bug with a CVE number is found. - Sam From tomek at pipebreaker.pl Sun Jun 23 07:19:11 2013 From: tomek at pipebreaker.pl (Tomasz Torcz) Date: Sun, 23 Jun 2013 13:19:11 +0200 Subject: [MaraDNS list] MaraDNS update (Happy Summer Solstice 2013) Message-ID: Sam, Does it mean you will release 2.0.07 _after_ releasing 2.0.07b? From the viewpoint of a packager (I maintain MaraDNS in Fedora) I strongly ask you not to. Please keep numbering monotonically increasing, it makes upgrades straight forward. Why not just bump minor number to 8? -------- Original message -------- Subject:[MaraDNS list] MaraDNS update (Happy Summer Solstice 2013) From:Sam Trenholme To:MaraDNS support mailing list Cc:wc-tmp at useunix.net Happy Summer Solstice everyone!? The long sunny days have inspired me to make a second MaraDNS update in the same month, even though I am not getting paid to do so. I have updated MaraDNS to incorporate a one-line bugfix with Deadwood (MaraDNS?s recursive resolver) in to the codebase. The name of this release is MaraDNS 2.0.07b (for more details on the unusual naming patterns, read the May 23 blog entry at http://samiam.org/blog/20130523.html )? I actually made this release in April, but have waited until now to make it the latest release on Sourceforge and MaraDNS' web page...so it has had two months of testing. This will hopefully stop complaints of being unable to resolve some domain names that occasionally pop up on the mailing list, such as this complaint: http://woodlane.webconquest.com/pipermail/list/2013-June/001172.html It can be downloaded here: http://www.maradns.org/download.html While not a hard-and-fast rule, my plan is to work on MaraDNS or Deadwood again one day in a couple of months unless a critical security bug with a CVE number is found. - Sam From maradns at gmail.com Fri Jun 28 12:26:03 2013 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 28 Jun 2013 09:26:03 -0700 Subject: [MaraDNS list] MaraDNS update (Happy Summer Solstice 2013) In-Reply-To: References: Message-ID: > Does it mean you will release 2.0.07 _after_ releasing 2.0.07b? From the >viewpoint of a packager (I maintain MaraDNS in Fedora) I strongly ask you >not to. Please keep numbering monotonically increasing, it makes upgrades >straight forward. > Why not just bump minor number to 8? MaraDNS 2.0.07b is MaraDNS 2.0.07 with the one-line Deadwood patch, as well as having the Windows Deadwood binary stripped (to keep it under 65,536 bytes?64k?in size) If nothing else, in early 2014 I will release MaraDNS 2.0.08 and Deadwood 3.2.04 with this patch. - Sam