From m.ferlitsch at gmail.com Fri Sep 4 17:27:37 2009 From: m.ferlitsch at gmail.com (Markus Ferlitsch) Date: Fri, 4 Sep 2009 23:27:37 +0200 Subject: zoneserver logfile question Message-ID: <1900c9640909041427s435b3c81h4401e22dd69718c1@mail.gmail.com> Hi, I took a look at my logfile. There I can find a lot of entries like this: ... /usr/sbin/zoneserver: Log: Root directory changed ... /usr/sbin/zoneserver: Log: Socket opened on TCP port 53 ... /usr/sbin/zoneserver: Log: Root privileges dropped ... /usr/sbin/zoneserver: Log: Awaiting data on port 53 ... /usr/sbin/zoneserver: Log: Message received, processing What does it mean that root privileges are dropped? greetings, Markus From remco at webconquest.com Sat Sep 5 01:20:22 2009 From: remco at webconquest.com (Remco Rijnders) Date: Sat, 5 Sep 2009 07:20:22 +0200 Subject: zoneserver logfile question In-Reply-To: <1900c9640909041427s435b3c81h4401e22dd69718c1@mail.gmail.com> References: <1900c9640909041427s435b3c81h4401e22dd69718c1@mail.gmail.com> Message-ID: <0a335a7d2d81fec7f5adfa87b554be5f.squirrel@webmail.xs4all.nl> > I took a look at my logfile. There I can find a lot of entries like this: > > ... /usr/sbin/zoneserver: Log: Root directory changed > ... /usr/sbin/zoneserver: Log: Socket opened on TCP port 53 > ... /usr/sbin/zoneserver: Log: Root privileges dropped > ... /usr/sbin/zoneserver: Log: Awaiting data on port 53 > ... /usr/sbin/zoneserver: Log: Message received, processing > > What does it mean that root privileges are dropped? On most unix systems port numbers under 1024 are privileged. This means that you have to be the root user in order to be allowed to make use of them, a normal user is not allowed to 'bind' to those ports. While there are reasons for this limitation on multi user systems, it does mean that programs bind to those ports are running as the root user. Should someone be able to find an exploit in the code for a server listening on one of those ports, it means they can execute code as the root user and have full access to everything on your system. You'll appreciate that this is a security concern. What maradns (and many server programs like it) do is to start as root user, bind to one of those privileged ports, then once that socket is acquired, switch to a normal user (dropping root privileges) and continue running like that. In the event that someone find an exploit in the code now, they only have access to the files and processes that the maradns user has access to and can do far less harm than someone with root privileges. I hope this clarifies. Kind regards, Remco Rijnders From m.ferlitsch at gmail.com Mon Sep 7 13:41:37 2009 From: m.ferlitsch at gmail.com (Markus Ferlitsch) Date: Mon, 7 Sep 2009 19:41:37 +0200 Subject: zoneserver logfile question In-Reply-To: <0a335a7d2d81fec7f5adfa87b554be5f.squirrel@webmail.xs4all.nl> References: <1900c9640909041427s435b3c81h4401e22dd69718c1@mail.gmail.com> <0a335a7d2d81fec7f5adfa87b554be5f.squirrel@webmail.xs4all.nl> Message-ID: <1900c9640909071041t5ba259c0n399feed4e46abe87@mail.gmail.com> ok thanks! It sound logical! :-) 2009/9/5, Remco Rijnders : > >> I took a look at my logfile. There I can find a lot of entries like this: >> >> ... /usr/sbin/zoneserver: Log: Root directory changed >> ... /usr/sbin/zoneserver: Log: Socket opened on TCP port 53 >> ... /usr/sbin/zoneserver: Log: Root privileges dropped >> ... /usr/sbin/zoneserver: Log: Awaiting data on port 53 >> ... /usr/sbin/zoneserver: Log: Message received, processing >> >> What does it mean that root privileges are dropped? > > On most unix systems port numbers under 1024 are privileged. This means > that you have to be the root user in order to be allowed to make use of > them, a normal user is not allowed to 'bind' to those ports. > > While there are reasons for this limitation on multi user systems, it does > mean that programs bind to those ports are running as the root user. > Should someone be able to find an exploit in the code for a server > listening on one of those ports, it means they can execute code as the > root user and have full access to everything on your system. You'll > appreciate that this is a security concern. > > What maradns (and many server programs like it) do is to start as root > user, bind to one of those privileged ports, then once that socket is > acquired, switch to a normal user (dropping root privileges) and continue > running like that. In the event that someone find an exploit in the code > now, they only have access to the files and processes that the maradns > user has access to and can do far less harm than someone with root > privileges. > > I hope this clarifies. > > Kind regards, > > Remco Rijnders > > From strenholme.usenet at gmail.com Tue Sep 8 13:54:24 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 8 Sep 2009 12:54:24 -0500 Subject: zoneserver logfile question In-Reply-To: <0a335a7d2d81fec7f5adfa87b554be5f.squirrel@webmail.xs4all.nl> References: <1900c9640909041427s435b3c81h4401e22dd69718c1@mail.gmail.com> <0a335a7d2d81fec7f5adfa87b554be5f.squirrel@webmail.xs4all.nl> Message-ID: <7bd685720909081054k6f48d9caw47c14f6961a12217@mail.gmail.com> >What maradns (and many server programs like it) do is to start as root >user, bind to one of those privileged ports, then once that socket is >acquired, switch to a normal user (dropping root privileges) and continue >running like that. In the event that someone find an exploit in the code >now, they only have access to the files and processes that the maradns >user has access to and can do far less harm than someone with root >privileges. To expand on what Remco has pointed out, on *NIX systems MaraDNS does two things to minimize the chance of an exploit in the program allowing control of the full system: * MaraDNS drops superuser (root) privileges * MaraDNS uses a *NIX feature called chroot() to minimize accesses to the file system. Note also, that in the over eight years of MaraDNS existence, no attack vector against MaraDNS' code worse than denial of service has been discovered, and no attacks have been discovered since 2007. Programmers have learned a lot since the 1990s, and skilled programmers know how to make code that doesn't allow anyone on the internet full root control with a daemon (the days of things like Sendmail's 'WIZ' backdoor are long-gone). - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From brad-maradns at fewerhassles.com Sun Sep 13 14:51:18 2009 From: brad-maradns at fewerhassles.com (Brad Fritz) Date: Sun, 13 Sep 2009 14:51:18 -0400 Subject: NS subdomain delegation problems with 1.3.07.09 Message-ID: <20090913185117.GD23843@t61.fewerhassles.com> I am using Debian Lenny's MaraDNS 1.3.07.09-2 package and having trouble with NS delegation for select subdomains. Any pointers would be appreciated. My intent is for MaraDNS to be authoritative for localserver.fewerhassles.com but delegate to ns1.easydns.com for remoteserver.fewerhassles.com lookups: $ grep server db.fewerhassles.com localserver.% A 172.17.2.121 remoteserver.% NS ns1.easydns.com. The localserver lookup is working as expected: $ askmara Alocalserver.fewerhassles.com. # Querying the server with the IP 127.0.0.1 # Question: Alocalserver.fewerhassles.com. localserver.fewerhassles.com. +86400 a 172.17.2.121 # NS replies: #fewerhassles.com. +86400 ns synth-ip-7f000001.fewerhassles.com. # AR replies: #synth-ip-7f000001.fewerhassles.com. +86400 a 127.0.0.1 But lookups for remoteserver are only returning the NS record, not the A record for remoteserver: $ askmara Aremoteserver.fewerhassles.com. # Querying the server with the IP 127.0.0.1 # Question: Aremoteserver.fewerhassles.com. # NS replies: remoteserver.fewerhassles.com. +86400 ns ns1.easydns.com. # AR replies: Asking ns1.easydns.com directly works: $ askmara Aremoteserver.fewerhassles.com. 66.225.199.10 \ | grep remoteserver # Question: Aremoteserver.fewerhassles.com. remoteserver.fewerhassles.com. +1200 a 67.23.22.179 Full configuration attached. I am probably missing something simple, but I haven't been able to figure out what so far. --Brad -------------- next part -------------- hide_disclaimer = "YES" csv1 = {} bind_address = "127.0.0.1" chroot_dir = "/etc/maradns" maradns_uid = 106 maradns_gid = 109 maxprocs = 96 no_fingerprint = 0 default_rrany_set = 3 max_chain = 8 max_ar_chain = 1 max_total = 20 verbose_level = 2 ipv4_alias = {} ipv4_alias["osrc"] = "199.166.24.1,205.189.73.102,199.166.24.3,207.126.103.16,195.117.6.10,205.189.73.10,204.57.55.100,213.196.2.97" ipv4_alias["localhost"] = "127.0.0.0/8" ipv4_alias["lan"] = "172.17.1.0/24" ipv4_alias["dmz"] = "172.17.2.0/24" recursive_acl = "localhost,lan,dmz" root_servers = {} root_servers["."] = "osrc" csv2 = {} csv2["2.17.172.in-addr.arpa."] = "db.2.17.172" csv2["colo.fewerhassles.com."] = "db.colo.fewerhassles.com" csv2["fewerhassles.com."] = "db.fewerhassles.com" From strenholme.usenet at gmail.com Mon Sep 14 10:38:29 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 14 Sep 2009 09:38:29 -0500 Subject: NS subdomain delegation problems with 1.3.07.09 In-Reply-To: <20090913185117.GD23843@t61.fewerhassles.com> References: <20090913185117.GD23843@t61.fewerhassles.com> Message-ID: <7bd685720909140738h469ba226w73909d4271f6888a@mail.gmail.com> > I am using Debian Lenny's MaraDNS 1.3.07.09-2 package and having > trouble with NS delegation for select subdomains. [...] > ?$ askmara Aremoteserver.fewerhassles.com. > ?# Querying the server with the IP 127.0.0.1 > ?# Question: Aremoteserver.fewerhassles.com. > ?# NS replies: > ?remoteserver.fewerhassles.com. +86400 ns ns1.easydns.com. > ?# AR replies: MaraDNS authoritative code creates DNS packets intended for other recursive DNS resolvers to resolve; packets for stub resolvers are not created. The above output is the output one should get when getting a NS referral. If you want MaraDNS to have packets with the complete answer resolved, the procedure for making these kinds of packets is identical for the procedure for resolving dangling CNAME records: (Note, if you are reading the archives and can not see the following link, please read the same message in another archive of the mailing list) http://www.maradns.org/tutorial/dangling.html I really need to add a FAQ about this; I think this is the second time I have had to answer this question. - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From brad-maradns at fewerhassles.com Tue Sep 15 14:51:49 2009 From: brad-maradns at fewerhassles.com (Brad Fritz) Date: Tue, 15 Sep 2009 14:51:49 -0400 Subject: NS subdomain delegation problems with 1.3.07.09 In-Reply-To: <7bd685720909140738h469ba226w73909d4271f6888a@mail.gmail.com> References: <20090913185117.GD23843@t61.fewerhassles.com> <7bd685720909140738h469ba226w73909d4271f6888a@mail.gmail.com> Message-ID: <20090915185148.GA30969@t61.fewerhassles.com> Sam, On Mon, Sep 14, 2009 at 09:38:29AM -0500, Sam Trenholme wrote: > > I am using Debian Lenny's MaraDNS 1.3.07.09-2 package and having > > trouble with NS delegation for select subdomains. > [...] > > ?$ askmara Aremoteserver.fewerhassles.com. > > ?# Querying the server with the IP 127.0.0.1 > > ?# Question: Aremoteserver.fewerhassles.com. > > ?# NS replies: > > ?remoteserver.fewerhassles.com. +86400 ns ns1.easydns.com. > > ?# AR replies: [..] > If you want MaraDNS to have packets with the complete answer resolved, > the procedure for making these kinds of packets is identical for the > procedure for resolving dangling CNAME records: [..] > http://www.maradns.org/tutorial/dangling.html Thanks for the pointer. In hindsight, I probably should have recognized the similarity to the dangling CNAME problem while reading that FAQ entry prior to posting. Did that behavior change between MaraDNS 1.2.12.06 and 1.3.07.09 ? I ask because the "dangling NS" issue does not present itself on my old OpenWRT router running 1.2.12.06 with a similar split DNS setup. FWIW, since I already run dnsmasq in front of maradns, I chose to add: server=/remoteserver.fewerhassles.com/66.225.199.10 entries in dnsmasq.conf rather than run a second instance of maradns. The trade-off is now I have host data spread between two locations. Perhaps a third, albeit more complicated, solution would have been to do scheduled zone transfers from the upstream (public) DNS provider and somehow merge the public addresses with the private IPs that maradns is authoritative for using a script. Thanks for your help and for your work on MaraDNS, Sam. --Brad From dnspod at gmail.com Fri Sep 18 04:58:46 2009 From: dnspod at gmail.com (DNSPod) Date: Fri, 18 Sep 2009 16:58:46 +0800 Subject: problem with dig +trace Message-ID: <265412FD-6CD0-4BA5-B723-018F23851A14@gmail.com> hi all, I found a problem with recursion when I try to use dig +trace domain.com, I got a refuse reply like this Sam at Sam:~$ dig +trace google.com ; <<>> DiG 9.6.0-APPLE-P2 <<>> +trace google.com ;; global options: +cmd ;; Received 12 bytes from 221.130.12.61#53(221.130.12.61) in 53 ms tcpdump result 16:16:23.190391 IP (tos 0x80, ttl 49, id 0, offset 0, flags [DF], proto UDP (17), length 40) dnspod.newhua.domain > 10.0.1.2.52317: [udp sum ok] 58277 Refused- [0q] 0/0/0 (12) 0x0000: 001e c2bd aefc 001e 52f6 8e12 0800 4580 ........R.....E. 0x0010: 0028 0000 4000 3111 5484 dd82 0c3d 0a00 .(.. at .1.T....=.. 0x0020: 0102 0035 cc5d 0014 dac6 e3a5 8005 0000 ...5.].......... 0x0030: 0000 0000 0000 ...... and the server's log Sep 18 16:45:42 newhua /usr/local/sbin/maradns: Log: Message received, processing Sep 18 16:45:42 newhua /usr/local/sbin/maradns: Query from: 61.179.151.106 N. Sep 18 16:45:42 newhua /usr/local/sbin/maradns: Log: Bad query received: \373\316\000\000\000\001\000\000\000\000\000\000\000\000\002\000\001 Sep 18 16:45:42 newhua /usr/local/sbin/maradns: From IP: 61.179.151.106 Sep 18 16:45:42 newhua /usr/local/sbin/maradns: Log: I'm sorry Dave (recurse attempt) any ideas? From remco at webconquest.com Fri Sep 18 05:36:21 2009 From: remco at webconquest.com (Remco Rijnders) Date: Fri, 18 Sep 2009 11:36:21 +0200 (CEST) Subject: problem with dig +trace In-Reply-To: <265412FD-6CD0-4BA5-B723-018F23851A14@gmail.com> References: <265412FD-6CD0-4BA5-B723-018F23851A14@gmail.com> Message-ID: <43fe7f695519568d31abe44a9216e0c2.squirrel@milkzilla.webconquest.com> On Fri, September 18, 2009 10:58, DNSPod wrote: > hi all, > > I found a problem with recursion > > when I try to use dig +trace domain.com, I got a refuse reply > Sep 18 16:45:42 newhua /usr/local/sbin/maradns: Log: Message > received, processing > Sep 18 16:45:42 newhua /usr/local/sbin/maradns: Query from: > 61.179.151.106 N. > Sep 18 16:45:42 newhua /usr/local/sbin/maradns: Log: Bad query > received: > \373\316\000\000\000\001\000\000\000\000\000\000\000\000\002\000\001 > Sep 18 16:45:42 newhua /usr/local/sbin/maradns: From IP: 61.179.151.106 > Sep 18 16:45:42 newhua /usr/local/sbin/maradns: Log: I'm sorry Dave > (recurse attempt) > > any ideas? Hi, You should check that: 1) MaraDNS is compiled as a recursive server (that is the default) and not as authorative only. 2) That your IP address (61.179.151.106) is allowed to use your server for recursive queries. Do you have 'recursive_acl' set in your mara configuration to allow queries from this address? See http://www.maradns.org/tutorial/man.mararc.html for information on how to set this. I think #2 is probably the reason why you see this log message. After fixing your config, restart maradns and see if you get the desired result. Kind regards, Remco Rijnders From sean.thorne at gmail.com Fri Sep 18 17:03:23 2009 From: sean.thorne at gmail.com (Sean Thorne) Date: Fri, 18 Sep 2009 17:03:23 -0400 Subject: Zoneserver Error Message-ID: Hi, I get this error when trying to start zoneserver on RHEL 5: Fatal error: inetd is not zero; this is a fatal error. Complain loudly on the MaraDNS mailing list. Can someone please help? Thanks, Sean From strenholme.usenet at gmail.com Fri Sep 18 19:15:30 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 18 Sep 2009 18:15:30 -0500 Subject: Zoneserver Error In-Reply-To: References: Message-ID: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> > ? ? ? ? ? ? ? ?Fatal error: inetd is not zero; this is a fatal error. > ?Complain loudly on the MaraDNS mailing list. You should never see this error? Which version of MaraDNS are you using? - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From sean.thorne at gmail.com Fri Sep 18 19:27:33 2009 From: sean.thorne at gmail.com (Sean Thorne) Date: Fri, 18 Sep 2009 19:27:33 -0400 Subject: Zoneserver Error In-Reply-To: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> Message-ID: The latest. I just downloaded it a week ago and I tried to start up the zoneserver today, which spit out this message. On Sep 18, 2009, at 7:15 PM, Sam Trenholme wrote: >> Fatal error: inetd is not zero; this is a fatal error. >> Complain loudly on the MaraDNS mailing list. > > You should never see this error? Which version of MaraDNS are you > using? > > - Sam > > Note: I do not answer MaraDNS support requests sent by private email > without being compensated for my time. I will discuss rates if you > want this kind of support. Thank you for your understanding. From strenholme.usenet at gmail.com Fri Sep 18 19:31:41 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 18 Sep 2009 18:31:41 -0500 Subject: Zoneserver Error In-Reply-To: References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> Message-ID: <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> [Top quoting because that's the old 1990s USENET tradition back in the days when it was not possible to get postings over 30 days old or so] > The latest. I just downloaded it a week ago and I tried to start up the > zoneserver today, which spit out this message. Yes, I looked at the source code for 1.3.14 and you shouldn't see this. Did you use 1.3.14, the latest snapshot, 1.3.07.09, or 1.2.12.10? What is the output of "maradns --version" (without the quotes)? - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From sean.thorne at gmail.com Fri Sep 18 20:23:59 2009 From: sean.thorne at gmail.com (Sean Thorne) Date: Fri, 18 Sep 2009 20:23:59 -0400 Subject: Zoneserver Error In-Reply-To: <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> Message-ID: 1.3.07.09 is the output. On Sep 18, 2009, at 7:31 PM, Sam Trenholme wrote: > [Top quoting because that's the old 1990s USENET tradition back in the > days when it was not possible to get postings over 30 days old or so] > >> The latest. I just downloaded it a week ago and I tried to start up >> the >> zoneserver today, which spit out this message. > > Yes, I looked at the source code for 1.3.14 and you shouldn't see > this. Did you use 1.3.14, the latest snapshot, 1.3.07.09, or > 1.2.12.10? What is the output of "maradns --version" (without the > quotes)? > > - Sam > > Note: I do not answer MaraDNS support requests sent by private email > without being compensated for my time. I will discuss rates if you > want this kind of support. Thank you for your understanding. From strenholme.usenet at gmail.com Fri Sep 18 20:51:06 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 18 Sep 2009 19:51:06 -0500 Subject: Zoneserver Error In-Reply-To: References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> Message-ID: <7bd685720909181751v18765b83id56013086ea46a13@mail.gmail.com> Hmmm...looking at the 1.3.07.09 source, the only way this can happen appears to be if someone played around with the source code before compiling MaraDNS. Did you compile it yourself, or did you use a precompiled RPM? The "inetd" variable is set to 0 and is never changed. - Sam >> Note: I do not answer MaraDNS support requests sent by private email >> without being compensated for my time. I will discuss rates if you >> want this kind of support. Thank you for your understanding. From sean.thorne at gmail.com Fri Sep 18 21:07:48 2009 From: sean.thorne at gmail.com (Sean Thorne) Date: Fri, 18 Sep 2009 21:07:48 -0400 Subject: Zoneserver Error In-Reply-To: <7bd685720909181751v18765b83id56013086ea46a13@mail.gmail.com> References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> <7bd685720909181751v18765b83id56013086ea46a13@mail.gmail.com> Message-ID: Strange. I just untar'd and ran ./configure and make. On Sep 18, 2009, at 8:51 PM, Sam Trenholme wrote: > Hmmm...looking at the 1.3.07.09 source, the only way this can happen > appears to be if someone played around with the source code before > compiling MaraDNS. > > Did you compile it yourself, or did you use a precompiled RPM? > > The "inetd" variable is set to 0 and is never changed. > > - Sam > >>> Note: I do not answer MaraDNS support requests sent by private email >>> without being compensated for my time. I will discuss rates if you >>> want this kind of support. Thank you for your understanding. From strenholme.usenet at gmail.com Fri Sep 18 22:11:05 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 18 Sep 2009 21:11:05 -0500 Subject: Zoneserver Error In-Reply-To: References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> <7bd685720909181751v18765b83id56013086ea46a13@mail.gmail.com> Message-ID: <7bd685720909181911t6fd3b48bp9f24182a9e069f56@mail.gmail.com> OK, try this: Just make your mararc file be one that is four lines long, like this: ipv4_bind_addresses = "10.3.28.79" chroot_dir = "/etc/maradns" csv2 = {} csv2["example.com."] = "db.example.com" And see if the zoneserver still gives you the same error. - Sam >>>> Note: I do not answer MaraDNS support requests sent by private email >>>> without being compensated for my time. I will discuss rates if you >>>> want this kind of support. Thank you for your understanding. From sean.thorne at gmail.com Fri Sep 18 22:41:34 2009 From: sean.thorne at gmail.com (Sean Thorne) Date: Fri, 18 Sep 2009 22:41:34 -0400 Subject: Zoneserver Error In-Reply-To: <7bd685720909181911t6fd3b48bp9f24182a9e069f56@mail.gmail.com> References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> <7bd685720909181751v18765b83id56013086ea46a13@mail.gmail.com> <7bd685720909181911t6fd3b48bp9f24182a9e069f56@mail.gmail.com> Message-ID: Then I get this: [sthorne at 244446-web01 maradns]$ sudo /sandvine/apps/maradns/zoneserver -f /sandvine/conf/maradns/mararc Log: Root directory changed Log: Socket opened on TCP port 53 Log: Root privileges dropped Log: Socket opened on TCP port 53 Log: Root privileges dropped Log: Socket opened on TCP port 53 Log: Root privileges dropped On Sep 18, 2009, at 10:11 PM, Sam Trenholme wrote: > OK, try this: > > Just make your mararc file be one that is four lines long, like this: > > ipv4_bind_addresses = "10.3.28.79" > chroot_dir = "/etc/maradns" > csv2 = {} > csv2["example.com."] = "db.example.com" > > And see if the zoneserver still gives you the same error. > > - Sam > >>>>> Note: I do not answer MaraDNS support requests sent by private >>>>> email >>>>> without being compensated for my time. I will discuss rates if you >>>>> want this kind of support. Thank you for your understanding. From strenholme.usenet at gmail.com Sat Sep 19 11:18:24 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 19 Sep 2009 10:18:24 -0500 Subject: Zoneserver Error In-Reply-To: References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> <7bd685720909181751v18765b83id56013086ea46a13@mail.gmail.com> <7bd685720909181911t6fd3b48bp9f24182a9e069f56@mail.gmail.com> Message-ID: <7bd685720909190818p7036d352gd60587e9129bcd94@mail.gmail.com> Congratulations, you found a bug in MaraDNS. Here is what I'm going to ask you to do next: Take your mararc, change any information you consider personal (make all IPs 192.168.x.x, domain names example.com and what not) and post it to the list. I'll then see if I can reproduce your bug. Since I use CentOS 5 and you use RHEL 5, we're pretty much on the same page. Indeed, please also post to the list the output of the following commands: cc --version md5sum /sandvine/apps/maradns/zoneserver - Sam 2009/9/18, Sean Thorne : > > Then I get this: > > [sthorne at 244446-web01 maradns]$ sudo /sandvine/apps/maradns/zoneserver > -f /sandvine/conf/maradns/mararc > Log: Root directory changed > Log: Socket opened on TCP port 53 > Log: Root privileges dropped > Log: Socket opened on TCP port 53 > Log: Root privileges dropped > Log: Socket opened on TCP port 53 > Log: Root privileges dropped > > > > On Sep 18, 2009, at 10:11 PM, Sam Trenholme wrote: > >> OK, try this: >> >> Just make your mararc file be one that is four lines long, like this: >> >> ipv4_bind_addresses = "10.3.28.79" >> chroot_dir = "/etc/maradns" >> csv2 = {} >> csv2["example.com."] = "db.example.com" >> >> And see if the zoneserver still gives you the same error. >> >> - Sam >> >>>>>> Note: I do not answer MaraDNS support requests sent by private >>>>>> email >>>>>> without being compensated for my time. I will discuss rates if you >>>>>> want this kind of support. Thank you for your understanding. > > From gabberstudio at mail.ru Thu Sep 24 10:52:56 2009 From: gabberstudio at mail.ru (Uncle Gabber) Date: Thu, 24 Sep 2009 18:52:56 +0400 Subject: problem zone transfer Message-ID: <200909241852558283543@mail.ru> Hello. I ask to excuse me for bad English. There was a problem, problem zone transfer. maradns does not transfer a zone on secondary a server That to me to do I do not know, I try to understand 3 weeks what not so Where there can be a reason? ------------------------------ # Server start, step 1, 2 # step 1 zoneserver -f /etc/mararc >/var/log/maradnszone & # step 2 maradns -f /etc/mararc >/var/log/maradns & # ipv4_bind_addresses = "127.0.0.1,192.168.110.23,???.???.???.???" tcp_convert_server = "127.0.0.1,192.168.110.23,???.???.???.???" tcp_convert_acl = "0.0.0.0/0" chroot_dir = "/etc/maradns" csv2 = {} csv2["mybase."] = "db.mybase" zone_transfer_acl = "193.232.130.14, 194.226.96.8" recursive_acl = "127.0.0.1,192.168.110.0/24" hide_disclaimer = "YES" chroot_dir = "/etc/maradns" random_seed_file="/dev/urandom" maradns_uid = xxxx maradns_gid = xxxx maxprocs = 70 no_fingerprint = 1 default_rrany_set = 3 max_chain = 8 max_ar_chain = 1 max_total = 20 verbose_level = 3 debug_msg_level = 0 dns_port = 53 maximum_cache_elements = 1024 min_ttl_cname = 900 min_ttl = 300 # -------------------------------------------- In advance thanks From gabberstudio at mail.ru Thu Sep 24 10:54:25 2009 From: gabberstudio at mail.ru (Uncle Gabber) Date: Thu, 24 Sep 2009 18:54:25 +0400 Subject: problem zone transfer Message-ID: <200909241854243591806@mail.ru> Hello. I ask to excuse me for bad English. There was a problem, problem zone transfer. maradns does not transfer a zone on secondary a server That to me to do I do not know, I try to understand 3 weeks what not so Where there can be a reason? ------------------------------ # Server start, step 1, 2 # step 1 zoneserver -f /etc/mararc >/var/log/maradnszone & # step 2 maradns -f /etc/mararc >/var/log/maradns & # ipv4_bind_addresses = "127.0.0.1,192.168.110.23,???.???.???.???" tcp_convert_server = "127.0.0.1,192.168.110.23,???.???.???.???" tcp_convert_acl = "0.0.0.0/0" chroot_dir = "/etc/maradns" csv2 = {} csv2["mybase."] = "db.mybase" zone_transfer_acl = "193.232.130.14, 194.226.96.8" recursive_acl = "127.0.0.1,192.168.110.0/24" hide_disclaimer = "YES" chroot_dir = "/etc/maradns" random_seed_file="/dev/urandom" maradns_uid = xxxx maradns_gid = xxxx maxprocs = 70 no_fingerprint = 1 default_rrany_set = 3 max_chain = 8 max_ar_chain = 1 max_total = 20 verbose_level = 3 debug_msg_level = 0 dns_port = 53 maximum_cache_elements = 1024 min_ttl_cname = 900 min_ttl = 300 # -------------------------------------------- In advance thanks From duff0097 at gmail.com Thu Sep 24 17:08:23 2009 From: duff0097 at gmail.com (Bryan Duff) Date: Thu, 24 Sep 2009 16:08:23 -0500 Subject: problem zone transfer In-Reply-To: <200909241854243591806@mail.ru> References: <200909241854243591806@mail.ru> Message-ID: Is the zone transfer to a windows box (where windows is the client)? Because that doesn't work for me (using maradns stable - not sure about the development branch). I know that maradns uses an older format for it's zone transfers (from a previous draft) which may be part of the problem. -Bryan 2009/9/24 Uncle Gabber > > Hello. > I ask to excuse me for bad English. > There was a problem, problem zone transfer. > maradns does not transfer a zone on secondary a server > That to me to do I do not know, I try to understand 3 weeks what not so > Where there can be a reason? > ------------------------------ > # Server start, step 1, 2 > # step 1 zoneserver -f /etc/mararc >/var/log/maradnszone & > # step 2 maradns -f /etc/mararc >/var/log/maradns & > # > ipv4_bind_addresses = "127.0.0.1,192.168.110.23,???.???.???.???" > tcp_convert_server = "127.0.0.1,192.168.110.23,???.???.???.???" > tcp_convert_acl = "0.0.0.0/0" > chroot_dir = "/etc/maradns" > csv2 = {} > csv2["mybase."] = "db.mybase" > zone_transfer_acl = "193.232.130.14, 194.226.96.8" > recursive_acl = "127.0.0.1,192.168.110.0/24" > hide_disclaimer = "YES" > chroot_dir = "/etc/maradns" > random_seed_file="/dev/urandom" > maradns_uid = xxxx > maradns_gid = xxxx > maxprocs = 70 > no_fingerprint = 1 > default_rrany_set = 3 > max_chain = 8 > max_ar_chain = 1 > max_total = 20 > verbose_level = 3 > debug_msg_level = 0 > dns_port = 53 > maximum_cache_elements = 1024 > min_ttl_cname = 900 > min_ttl = 300 > # > -------------------------------------------- > In advance thanks > From strenholme.usenet at gmail.com Thu Sep 24 18:01:50 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 24 Sep 2009 17:01:50 -0500 Subject: problem zone transfer In-Reply-To: References: <200909241854243591806@mail.ru> Message-ID: <7bd685720909241501l6d2b151bjac77b4cb801adc74@mail.gmail.com> To address the original poster, it works for me. Using MaraDNS 1.3.14 (zoneserver, actually), and the following mararc file: ipv4_bind_addresses = "127.0.0.1" tcp_convert_server = "127.0.0.1" tcp_convert_acl = "0.0.0.0/0" chroot_dir = "/etc/maradns" csv2 = {} csv2["example.com."] = "db.example.com" zone_transfer_acl = "127.0.0.1" recursive_acl = "127.0.0.1,192.168.110.0/24" hide_disclaimer = "YES" chroot_dir = "/etc/maradns" random_seed_file="/dev/urandom" maxprocs = 70 no_fingerprint = 1 default_rrany_set = 3 max_chain = 8 max_ar_chain = 1 max_total = 20 verbose_level = 3 debug_msg_level = 0 dns_port = 53 maximum_cache_elements = 1024 min_ttl_cname = 900 min_ttl = 300 And the following db.example.com file: example.com. +1 SOA z.% y@% 1 1 1 1 1 example.com. +3600 NS ns1.example.net. example.com. +3600 NS ns2.example.net. example.com. +3600 NS ns3.example.net. example.com. +3600 MX 10 mail.example.net. example.com. +3600 MX 20 mail2.example.net. example.com. TXT 'dns.' example.com. +3600 A 10.1.2.3 www.example.com. +3600 A 10.1.2.4 xx.example.com. +3600 A 10.1.2.6 #*.example.com. +3600 A 10.1.2.5 I am able to use zoneserver to transfer a zone: $ ./fetchzone example.com 127.0.0.1 example.com. +1 soa z.example.com. y at example.com. 1 1 1 1 1 ~ example.com. +3600 ns ns1.example.net. ~ example.com. +3600 ns ns2.example.net. ~ example.com. +3600 ns ns3.example.net. ~ example.com. +3600 mx 10 mail.example.net. ~ example.com. +3600 mx 20 mail2.example.net. ~ example.com. +86400 txt 'dns.' ~ example.com. +3600 a 10.1.2.3 ~ www.example.com. +3600 a 10.1.2.4 ~ xx.example.com. +3600 a 10.1.2.6 ~ # Second SOA received, exiting So, the next questions are: * Which DNS server are you trying to transfer to? * Does this DNS server have an IP in zone_transfer_acl? * Which version of MaraDNS are you running? * Are you running both the 'maradns' and 'zoneserver' daemons? > Is the zone transfer to a windows box (where windows is the client)? > Because that doesn't work for me (using maradns stable - not sure about the > development branch). It could be a compatibility issue. It could also be a configuration issue (are you running 'zoneserver'? Does this DNS server have an IP in zone_transfer_acl?) > I know that maradns uses an older format for it's zone transfers (from a > previous draft) which may be part of the problem. We don't know what the problem is until we get more information. DNS really hasn't changed since 2001 when I first wrote MaraDNS; don't think DNS is like HTML+CSS or Javascript. Because it's not. It's pretty static and they haven't really changed how Zone transfers are done since Regan was president of the US. - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From gabberstudio at mail.ru Fri Sep 25 17:49:40 2009 From: gabberstudio at mail.ru (Uncle Gabber) Date: Sat, 26 Sep 2009 00:49:40 +0300 Subject: problem zone transfer References: <200909241854243591806@mail.ru>, Message-ID: <200909260049396403338@mail.ru> Hello! re....... So, the next questions are: * Which DNS server are you trying to transfer to? Secondary * Does this DNS server have an IP in zone_transfer_acl? Yes * Which version of MaraDNS are you running? 1.3.07.09 * Are you running both the 'maradns' and 'zoneserver' daemons? Yes ------------------------------mararc # Server start, step 1, 2 # step 1 zoneserver -f /etc/mararc >/var/log/maradnszone & # step 2 maradns -f /etc/mararc >/var/log/maradns & # ipv4_bind_addresses = "127.0.0.1,192.168.110.23,xxx.xxx.xxx.xxx" tcp_convert_server = "127.0.0.1,192.168.110.23,xxx.xxx.xxx.xxx" tcp_convert_acl = "0.0.0.0/0" chroot_dir = "/etc/maradns" csv2 = {} csv2["mybase."] = "db.mybase" zone_transfer_acl = "193.232.130.14, 194.226.96.8" recursive_acl = "127.0.0.1,192.168.110.0/24" hide_disclaimer = "YES" chroot_dir = "/etc/maradns" random_seed_file="/dev/urandom" maradns_uid = xxxx maradns_gid = xxxx maxprocs = 70 no_fingerprint = 1 default_rrany_set = 3 max_chain = 8 max_ar_chain = 1 max_total = 20 verbose_level = 3 debug_msg_level = 0 dns_port = 53 maximum_cache_elements = 1024 min_ttl_cname = 900 min_ttl = 300 # --------------------------------------------db.mybase # SOA example.net. +86400 SOA ns1.example.net. admin at brigar.ru. 65012784 #serial 14400 #refresh 3600 #retry 2592000 # expire 600 #minimum ttl ~ # NS example.net. +86400 NS ns1.example.net. ~ example.net. +86400 NS ns8.example.com. ~ #MXs example.net. +86400 MX 10 example.net. ~ # A example.net. +86400 A xxx.xxx.xxx.xxx. ~ www.example.net. +86400 A xxx.xxx.xxx.xxx ~ ns1.example.net. +86400 A xxx.xxx.xxx.xxx ~ ------------------------------------------------ DiG result $ dig @ns1.example.net example.net axfr ;; communications error to xxx.xxx.xxx.xxx#53: end of file ------------------------------------------------ In advance thanks From strenholme.usenet at gmail.com Fri Sep 25 19:32:50 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 25 Sep 2009 18:32:50 -0500 Subject: problem zone transfer In-Reply-To: <200909260049396403338@mail.ru> References: <200909241854243591806@mail.ru> <200909260049396403338@mail.ru> Message-ID: <7bd685720909251632u2b61f3cataac4e536bace90ba@mail.gmail.com> > * Which DNS server are you trying to transfer to? > Secondary You misunderstood the question. What DNS server is the secondary DNS server using? Is it using MaraDNS, BIND, DjbDNS, NSD, Microsoft DNS, or another DNS server? - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From gabberstudio at mail.ru Fri Sep 25 21:30:18 2009 From: gabberstudio at mail.ru (Uncle Gabber) Date: Sat, 26 Sep 2009 05:30:18 +0400 Subject: problem zone transfer References: <200909241854243591806@mail.ru>, , <200909260049396403338@mail.ru> Message-ID: <200909260530167817623@mail.ru> I ask to excuse for my bad English. I have written the letter to the logger of names with a question what server they use, I look forward to hearing. ------------------------------ The result of the utility dig (end of file), it concerns maradns, is an error? $ dig @ns1.example.net example.net axfr ;; communications error to xxx.xxx.xxx.xxx#53: end of file From strenholme.usenet at gmail.com Sat Sep 26 06:45:31 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 26 Sep 2009 05:45:31 -0500 Subject: problem zone transfer In-Reply-To: <200909260530167817623@mail.ru> References: <200909241854243591806@mail.ru> <200909260049396403338@mail.ru> <200909260530167817623@mail.ru> Message-ID: <7bd685720909260345j6dd91ea3nd295302684217ef2@mail.gmail.com> > I ask to excuse for my bad English. > I have written the letter to the logger of names with a question what server they use, I look forward to hearing. Post to the list when you get an answer from them. In the meantime, you can post here the response to the following query: dig @{xxx.xxx.xxx.xxx} version.bind chaos txt Replace {xxx.xxx.xxx.xxx} with the IP of the secondary server; for example: dig @192.168.1.254 version.bind chaos txt - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From gabberstudio at mail.ru Sat Sep 26 07:16:30 2009 From: gabberstudio at mail.ru (Uncle Gabber) Date: Sat, 26 Sep 2009 15:16:30 +0400 Subject: problem zone transfer References: <200909241854243591806@mail.ru>, , <200909260049396403338@mail.ru>, <200909260530167817623@mail.ru> Message-ID: <200909261516296406967@mail.ru> Hello --------------------------------------- registrator name ns $ dig @ns8.nic.ru version.bind chaos txt ; <<>> DiG 9.4.2-P2 <<>> @ns8.nic.ru version.bind chaos txt ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9891 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;version.bind. CH TXT ;; ANSWER SECTION: version.bind. 0 CH TXT "" ;; AUTHORITY SECTION: version.bind. 0 CH NS version.bind. ;; Query time: 47 msec ;; SERVER: 193.232.130.14#53(193.232.130.14) ;; WHEN: Sat Sep 26 15:15:33 2009 ;; MSG SIZE rcvd: 57 From strenholme.usenet at gmail.com Sat Sep 26 07:48:08 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 26 Sep 2009 06:48:08 -0500 Subject: problem zone transfer In-Reply-To: <200909261516296406967@mail.ru> References: <200909241854243591806@mail.ru> <200909260049396403338@mail.ru> <200909260530167817623@mail.ru> <200909261516296406967@mail.ru> Message-ID: <7bd685720909260448j71b642d4m58d4cea69b5b8be2@mail.gmail.com> OK, they're not telling us which DNS server they use, so we'll have to ask them. - Sam From strenholme.usenet at gmail.com Sun Sep 27 16:25:17 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sun, 27 Sep 2009 15:25:17 -0500 Subject: Zoneserver Error In-Reply-To: <7bd685720909190818p7036d352gd60587e9129bcd94@mail.gmail.com> References: <7bd685720909181615g7e8175e6q64fa704c3c9ddcdf@mail.gmail.com> <7bd685720909181631i333e75fxbc6acb1d8290eabf@mail.gmail.com> <7bd685720909181751v18765b83id56013086ea46a13@mail.gmail.com> <7bd685720909181911t6fd3b48bp9f24182a9e069f56@mail.gmail.com> <7bd685720909190818p7036d352gd60587e9129bcd94@mail.gmail.com> Message-ID: <7bd685720909271325h6bd4888ej312c222c244ab40@mail.gmail.com> > Congratulations, you found a bug in MaraDNS. ?Here is what I'm going > to ask you to do next: Take your mararc, change any information you > consider personal (make all IPs 192.168.x.x, domain names example.com > and what not) and post it to the list. ?I'll then see if I can > reproduce your bug. Sean never followed-up on this issue, and it has been over a week. I'm closing this issue as "unreproducible". - Sam From duff0097 at gmail.com Mon Sep 28 12:38:43 2009 From: duff0097 at gmail.com (Bryan Duff) Date: Mon, 28 Sep 2009 11:38:43 -0500 Subject: problem zone transfer In-Reply-To: <7bd685720909260448j71b642d4m58d4cea69b5b8be2@mail.gmail.com> References: <200909241854243591806@mail.ru> <200909260049396403338@mail.ru> <200909260530167817623@mail.ru> <200909261516296406967@mail.ru> <7bd685720909260448j71b642d4m58d4cea69b5b8be2@mail.gmail.com> Message-ID: Windows Server 2003: "Invalid response from master DNS server at 20.20.20.18 during attempted zone transfer of zone dns.coop. Check the DNS server at 20.20.20.18 and ensure that it is authoritative for this zone. This can be done by viewing or updating the list of authoritative servers for the zone. When using the DNS console, select zone dns.coop Properties at server 20.20.20.18 and click the Name Servers tab. If needed, you can add or update this server in the list there. As an alternative solution, you could also modify settings in the Zone Transfer tab to allow transfer of the zone to this and other DNS servers." This is with MaraDNS 1.3.14 (same thing happens on 1.3.07.08). Windows pulling a zone transfer from Bind works (bind seems to use a different format than MaraDNS - one that appears to coincide with the more recent draft of the AXFR rfc). In this case all the answers come back in one DNS message (as opposed to one message per record [or one answer per DNS response], like MaraDNS appears to do). Thanks. -Bryan 2009/9/26 Sam Trenholme > OK, they're not telling us which DNS server they use, so we'll have to ask > them. > > - Sam > From strenholme.usenet at gmail.com Mon Sep 28 13:13:16 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 28 Sep 2009 12:13:16 -0500 Subject: problem zone transfer In-Reply-To: References: <200909241854243591806@mail.ru> <200909260049396403338@mail.ru> <200909260530167817623@mail.ru> <200909261516296406967@mail.ru> <7bd685720909260448j71b642d4m58d4cea69b5b8be2@mail.gmail.com> Message-ID: <7bd685720909281013k3e70263dgc85110d6d59aa6f5@mail.gmail.com> > Windows Server 2003: > > "Invalid response from master DNS server at 20.20.20.18 during attempted > zone transfer of zone dns.coop. ?Check the DNS server at 20.20.20.18 and > ensure that it is authoritative for this zone. ?This can be done by viewing > or updating the list of authoritative servers for the zone. ?When using the > DNS console, select zone dns.coop Properties at server 20.20.20.18 and click > the Name Servers tab. ?If needed, you can add or update this server in the > list there. ?As an alternative solution, you could also modify settings in > the Zone Transfer tab to allow transfer of the zone to this and other DNS > servers." To be honest, I'm sure this is a legitimate bug. And, you know, if I was selling MaraDNS licenses for, say, $300 a pop, I would have no problem paying the $400 to $600 Windows Server 2003 costs to install a copy so I can look at this issue. I can not even look at this issue unless someone is willing to sponsor me to do so. Their sponsorship will need to cover the cost of me legally having a copy of Windows Server 2003, in addition to covering my time to revise zoneserver.c to fix this bug. No, I will not download an illegal copy of Windows Server 2003 from The Pirate Bay (or wherever people get illegal media these days) just to fix this bug. Yes, if Microsoft offers some kind of developer's program, I will fix this bug as soon as someone is willing to pay for me to join said program and get a copy of Server 2003 via this program. Bottom line: People, by and large, don't pay me for MaraDNS development. I also haven't gotten enough goodwill and fame developing MaraDNS to get my dream job in Silicon Valley (I did get an interview with Google, but they never hired me). So, alas, fixing Windows Server 2003 issues is a little beyond my budget right now. :( Is there a free way to get this DNS server running in Windows XP Home Edition (Service pack 3 with all updates, Spanish-language)? Because that is the copy of Windows I have a license for (two, actually; a VMware machine also runs XP Home in Spanish). Another option is to find an ancient version of BIND with this issue (however, as I recall, MaraDNS was able to transfer zones to both BIND 8 and BIND 9 when I tested this back in 2001) Another solution is to run a packet dump and compare the packets BIND sends Microsoft DNS with the packets MaraDNS sends Microsoft DNS. This will require us to work very closely together on the mailing list. Are you willing to do that? Thank you for your bug report and your interest in MaraDNS. I hope you understand why this issue is probably not practical for me to fix right now. - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From duff0097 at gmail.com Mon Sep 28 19:10:54 2009 From: duff0097 at gmail.com (Bryan Duff) Date: Mon, 28 Sep 2009 18:10:54 -0500 Subject: problem zone transfer In-Reply-To: <7bd685720909281013k3e70263dgc85110d6d59aa6f5@mail.gmail.com> References: <200909241854243591806@mail.ru> <200909260049396403338@mail.ru> <200909260530167817623@mail.ru> <200909261516296406967@mail.ru> <7bd685720909260448j71b642d4m58d4cea69b5b8be2@mail.gmail.com> <7bd685720909281013k3e70263dgc85110d6d59aa6f5@mail.gmail.com> Message-ID: I made a brief attempt at a "proof of concept" (look at the patch). But it never succeeded (even with only 3 records). The count_tmp is probably an incorrect size (it was going off of the specific SOA, NS, A, SOA message I was trying to send (for 'test.com'). I'll see about some other packet captures (like what bind does when pulled from Windows). As for your costs, give me a final number $200? $500? All I know is I'll need a flat fee (there's no way I can do hours). Thanks. -Bryan On Mon, Sep 28, 2009 at 12:13 PM, Sam Trenholme wrote: > > Windows Server 2003: > > > > "Invalid response from master DNS server at 20.20.20.18 during attempted > > zone transfer of zone dns.coop. Check the DNS server at 20.20.20.18 and > > ensure that it is authoritative for this zone. This can be done by > viewing > > or updating the list of authoritative servers for the zone. When using > the > > DNS console, select zone dns.coop Properties at server 20.20.20.18 and > click > > the Name Servers tab. If needed, you can add or update this server in > the > > list there. As an alternative solution, you could also modify settings > in > > the Zone Transfer tab to allow transfer of the zone to this and other DNS > > servers." > > To be honest, I'm sure this is a legitimate bug. And, you know, if I > was selling MaraDNS licenses for, say, $300 a pop, I would have no > problem paying the $400 to $600 Windows Server 2003 costs to install a > copy so I can look at this issue. > > I can not even look at this issue unless someone is willing to sponsor > me to do so. Their sponsorship will need to cover the cost of me > legally having a copy of Windows Server 2003, in addition to covering > my time to revise zoneserver.c to fix this bug. > > No, I will not download an illegal copy of Windows Server 2003 from > The Pirate Bay (or wherever people get illegal media these days) just > to fix this bug. Yes, if Microsoft offers some kind of developer's > program, I will fix this bug as soon as someone is willing to pay for > me to join said program and get a copy of Server 2003 via this > program. > > Bottom line: People, by and large, don't pay me for MaraDNS > development. I also haven't gotten enough goodwill and fame > developing MaraDNS to get my dream job in Silicon Valley (I did get an > interview with Google, but they never hired me). So, alas, fixing > Windows Server 2003 issues is a little beyond my budget right now. :( > > Is there a free way to get this DNS server running in Windows XP Home > Edition (Service pack 3 with all updates, Spanish-language)? Because > that is the copy of Windows I have a license for (two, actually; a > VMware machine also runs XP Home in Spanish). Another option is to > find an ancient version of BIND with this issue (however, as I recall, > MaraDNS was able to transfer zones to both BIND 8 and BIND 9 when I > tested this back in 2001) > > Another solution is to run a packet dump and compare the packets BIND > sends Microsoft DNS with the packets MaraDNS sends Microsoft DNS. > This will require us to work very closely together on the mailing > list. Are you willing to do that? > > Thank you for your bug report and your interest in MaraDNS. I hope > you understand why this issue is probably not practical for me to fix > right now. > > - Sam > > Note: I do not answer MaraDNS support requests sent by private email > without being compensated for my time. I will discuss rates if you > want this kind of support. Thank you for your understanding. > From strenholme.usenet at gmail.com Mon Sep 28 21:59:48 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 28 Sep 2009 20:59:48 -0500 Subject: problem zone transfer In-Reply-To: References: <200909241854243591806@mail.ru> <200909260049396403338@mail.ru> <200909260530167817623@mail.ru> <200909261516296406967@mail.ru> <7bd685720909260448j71b642d4m58d4cea69b5b8be2@mail.gmail.com> <7bd685720909281013k3e70263dgc85110d6d59aa6f5@mail.gmail.com> Message-ID: <7bd685720909281859l8436d6dl4f499f7b813a1170@mail.gmail.com> > As for your costs, give me a final number $200? ?$500? ?All I know is I'll > need a flat fee (there's no way I can do hours). OK, a MSDN subscription to buy any and all OSes Microsoft has made will cost me $700. Add another $200 to fix this bug (and to cover PayPal overhead) and I can do it for $900. As I understand it, this MSDN subscription allows me to download and use any and all versions of Windows http://msdn.microsoft.com/en-us/subscriptions/buy.aspx If you want to do it on the cheap, you'll have to wait until around the new year for me to get the fix done. I can purchase Windows Server 2003 from Newegg.com for $420 and pick it up around Christmas time with I'm with my family for the holidays. Add $150 for my time (since you'll be waiting so long for me to do it), and that gives you a price of $570: http://www.newegg.com/Product/Product.aspx?Item=N82E16832116435&nm_mc=OTC-Froogle&cm_mmc=OTC-Froogle-_-Software+-+Servers-_-Microsoft-_-32116435 So, those are your quotes: $900 now, or $570 if you can wait until January. Thanks for your interest in helping sponsor MaraDNS! From bogus@does.not.exist.com Sun Sep 13 14:51:27 2009 From: bogus@does.not.exist.com () Date: Sun, 13 Sep 2009 18:51:27 -0000 Subject: No subject Message-ID: > $ dig volltreffer.de > > ; <<>> DiG 9.7.0-P1 <<>> volltreffer.de > ;; global options: +cmd > ;; connection timed out; no servers could be reached deadwood log: > Got DNS query for \013volltreffer\002de\000\000\001 > Sending reply for query \013volltreffer\002de\000\000\001 > Sending reply for query \013volltreffer\002de\000\000\001 > Got DNS query for \013volltreffer\002de\000\000\001 > Sending reply for query \013volltreffer\002de\000\000\001 > Processing NS refer for \013volltreffer\002de\000\000\001 > Processing NS refer for \003ns\061\010first\055ns\002de\000\000\001 > Processing NS refer for \002ns\011second\055ns\003com\000\000\001 > Got DNS query for \013volltreffer\002de\000\000\001 > Sending reply for query \013volltreffer\002de\000\000\001 > Sending reply for query \013volltreffer\002de\000\000\001 > Processing NS refer for \010robotns\062\011second\055ns\002de\000\000\001 > Caching direct answer at \010robotns\062\011second\055ns\002de\000\000\001 > Processing NS refer for \003ns\061\013your\055server\002de\000\000\001 > Caching direct answer at \003ns\061\013your\055server\002de\000\000\001 > Caching direct answer at \003ns\063\011second\055ns\002de\000\000\001 > Caching direct answer at \003ns\061\010first\055ns\002de\000\000\001 > Caching direct answer at \013volltreffer\002de\000\000\001 > Sending reply for query \013volltreffer\002de\000\000\001 > Fetching \013volltreffer\002de\000\000\001 from cache digging a second time: > $ dig volltreffer.de > > ; <<>> DiG 9.7.0-P1 <<>> volltreffer.de > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55948 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;volltreffer.de. IN A > > ;; ANSWER SECTION: > volltreffer.de. 3284 IN A 88.198.209.2 > > ;; Query time: 1 msec > ;; SERVER: 192.168.1.1#53(192.168.1.1) > ;; WHEN: Mon Jul 26 11:54:36 2010 > ;; MSG SIZE rcvd: 48 query time 1msec -> Oh wonder, it's cached by dnsmasq. To get it more visual what I mean, I use nslookup. > C:\>nslookup clubber.de > Server: router.lan > Address: 192.168.1.1 > > Nicht autorisierende Antwort: > DNS request timed out. > timeout was 2 seconds. > Name: clubber.de > Address: 88.198.34.48 deadwood logs: > Got DNS query for \007clubber\002de\000\000\001 > Sending reply for query \007clubber\002de\000\000\001 > Caching direct answer at \007clubber\002de\000\000\001 > Sending reply for query \007clubber\002de\000\000\001 > Fetching \007clubber\002de\000\000\001 from cache > Got DNS query for \007clubber\002de\000\000\034 > Sending reply for query \007clubber\002de\000\000\034 > Sending reply for query \007clubber\002de\000\000\034 I can't tell you much more since it's happening by random. Another one: > C:\>nslookup mueller.de > Server: router.lan > Address: 192.168.1.1 > > DNS request timed out. > timeout was 2 seconds. > DNS request timed out. > timeout was 2 seconds. > *** Zeit??berschreitung bei Anforderung an router.lan. > C:\>nslookup mueller.de > Server: router.lan > Address: 192.168.1.1 > > Nicht autorisierende Antwort: > DNS request timed out. > timeout was 2 seconds. > Name: mueller.de > Address: 80.148.9.139 > Got DNS query for \007mueller\002de\000\000\001 > Sending reply for query \007mueller\002de\000\000\001 > Sending reply for query \007mueller\002de\000\000\001 > Got DNS query for \007mueller\002de\000\000\034 > Sending reply for query \007mueller\002de\000\000\034 > Processing NS refer for \007mueller\002de\000\000\034 > Got DNS query for \007mueller\002de\000\000\001 > Sending reply for query \007mueller\002de\000\000\001 > Caching direct answer at \007mueller\002de\000\000\001 > Sending reply for query \007mueller\002de\000\000\001 > Fetching \007mueller\002de\000\000\001 from cache > Got DNS query for \007mueller\002de\000\000\034 > Sending reply for query \007mueller\002de\000\000\034 > Sending reply for query \007mueller\002de\000\000\034 > Processing NS refer for \014secondary\060\060\066\004dtag\003net\000\000\001 > Processing NS refer for \003pns\004dtag\002de\000\000\001 > Caching direct answer at \003pns\004dtag\002de\000\000\001 > Caching direct answer at \014secondary\060\060\066\004dtag\003net\000\000\001 > Processing NS refer for \014secondary\060\060\066\004dtag\003net\000\000\001 > Caching direct answer at \014secondary\060\060\066\004dtag\003net\000\000\001 > Sending SERVER FAIL for query \007mueller\002de\000\000\034 Using nslookup on linux. > $ nslookup ochsen.de > ;; connection timed out; no servers could be reached > > $ nslookup ochsen.de > Server: 192.168.1.1 > Address: 192.168.1.1#53 > > Non-authoritative answer: > Name: ochsen.de > Address: 85.199.129.66 > Got DNS query for \006ochsen\002de\000\000\001 > Sending reply for query \006ochsen\002de\000\000\001 > Sending reply for query \006ochsen\002de\000\000\001 > Got DNS query for \006ochsen\002de\000\000\001 > Sending reply for query \006ochsen\002de\000\000\001 > Sending reply for query \006ochsen\002de\000\000\001 > Got DNS query for \006ochsen\002de\000\000\001 > Sending reply for query \006ochsen\002de\000\000\001 > Sending reply for query \006ochsen\002de\000\000\001 > Got DNS query for \006ochsen\002de\000\000\001 > Sending reply for query \006ochsen\002de\000\000\001 > Processing NS refer for \006ochsen\002de\000\000\001 > Processing NS refer for \003ns\063\013dnsmittwald\002de\000\000\001 > Caching direct answer at \004ns\061\060\004ns\061\064\002de\000\000\001 > Caching direct answer at \003ns\063\013dnsmittwald\002de\000\000\001 > Caching direct answer at \006ochsen\002de\000\000\001 > Sending reply for query \006ochsen\002de\000\000\001 > Fetching \006ochsen\002de\000\000\001 from cache Cheers, Sebastian