From volker.jaenisch at inqbus.de Fri Aug 1 10:51:36 2008 From: volker.jaenisch at inqbus.de (Dr. Volker Jaenisch) Date: Fri, 01 Aug 2008 16:51:36 +0200 Subject: wrong RD/RA flags cause exim4 to fail if no MX Record for a domain is set Message-ID: <489322F8.6080107@inqbus.de> Hi Maradns-list! We use maradns on large exim mail-server-clusters and we like it. The stabe version on Debian 1.2.12.04 as well as the sourcecode for 1.3.11 shows the same behavior: MaraDNS does not return the RD and sets does not set RA Flag in case of a RECORD NOT FOUND case. (See attached maradns and bind output of such a case, below) In general the reflection of the RD/RA flags have been fixed with the last patches in the stable and developement branch. For this seldom case the existing bugfix should be extended by the following patch (against 1.3.11). --- MaraDNS.c~ 2008-03-24 16:52:28.000000000 +0100 +++ MaraDNS.c 2008-08-01 15:49:05.000000000 +0200 @@ -1892,8 +1892,8 @@ header.qr = 1; header.opcode = 0; header.tc = 0; /* To do: truncation handling */ - header.rd = 0; /* RDBUG udpnotfound */ - header.ra = 0; + header.rd = rd_val; /* RDBUG udpnotfound */ + header.ra = rd_val; header.z = 0; /* Code that verifies that this host does not exist in any class. If so, then we give them a rcode of NXDOMAIN_RCODE. This patch cures the exim problem. But I am pretty sure that it is not complete. Also there may be a conflict with the RDBUG udpnotfound bugfix. Background: If a domain has no MX entry exim decides to use the IP of the A entry. But exim have to be resonable sure that no other DNS error has ocurred. Since maradns does not return the RD and RA flags properly exim supposes an dns malfunction: I did send a recursive MX question and get a nonrecursive answer > the DNS may be broken and tries again and again to get a recursive answer. The bitter consequence is that emails to domains without MX records will completely fail on exim systems. It is no RFC violation not to set an MX record for a maildomain. Let's take a look at what RFC 2821 says: - Once the domain is identified SMTP must perform a DNS lookup and first attempt to locate an MX record. - If no MX records are found but an A record is found, it is treated as if it was associated with an implicit MX record with a preference of 0 pointing to that host - also known as the "implicit MX" rule. With maradns the following happens: skylla:~/maradns-1.3.11# dig @10.1.0.8 -tmx +recurse mail.tropos.de ; <<>> DiG 9.3.4-P1.1 <<>> @10.1.0.8 -tmx +recurse mail.tropos.de ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24702 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;mail.tropos.de. IN MX ;; AUTHORITY SECTION: mail.tropos.de. 85665 IN SOA sana.tropos.de. jagemann.tropos.de. 200807312 86400 3600 3600000 86400 Compared to a bind DNS-server: skylla:~/maradns-1.3.11# dig @193.239.30.4 -tmx +recurse mail.tropos.de ; <<>> DiG 9.3.4-P1.1 <<>> @193.239.30.4 -tmx +recurse mail.tropos.de ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61493 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;mail.tropos.de. IN MX ;; AUTHORITY SECTION: tropos.de. 10800 IN SOA sana.tropos.de. jagemann.tropos.de. 200807312 86400 3600 3600000 86400 Best regards Volker -- ==================================================== inqbus it-consulting +49 ( 341 ) 5643800 Dr. Volker Jaenisch http://www.inqbus.de Herlo?sohnstr. 12 0 4 1 5 5 Leipzig N O T - F ? L L E +49 ( 170 ) 3113748 ==================================================== From strenholme.usenet at gmail.com Fri Aug 1 11:03:00 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 1 Aug 2008 10:03:00 -0500 Subject: wrong RD/RA flags cause exim4 to fail if no MX Record for a domain is set In-Reply-To: <489322F8.6080107@inqbus.de> References: <489322F8.6080107@inqbus.de> Message-ID: <7bd685720808010803rec3edd2k748315a44d41c5a1@mail.gmail.com> Thanks for the bug report; I will verify this fix is OK and hopefully release new versions of MaraDNS next week sometime. As an aside, RA serves *no* purpose in the DNS header. There is no good reason why clients should look at or care how this bit is set. IMHO, Exim is broken because it cares how this bit is set. I mostly fixed this last fall (as you observed); however I didn't cover all of the corner cases. I wonder if this merits a 1.2.12.10 release. Probably, since, among other things, it has been months since the last MaraDNS release. Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. Note that I am aware of the July 2008 cache poison attack, and that MaraDNS is immune, and has been immune since 2001. - Sam 2008/8/1 Dr. Volker Jaenisch : > Hi Maradns-list! > > We use maradns on large exim mail-server-clusters and we like it. > > The stabe version on Debian 1.2.12.04 as well as the > sourcecode for 1.3.11 shows the same behavior: > MaraDNS does not return the RD and sets does not set RA Flag in case > of a RECORD NOT FOUND case. (See attached maradns and bind output of > such a case, below) > > In general the reflection of the RD/RA flags have been fixed with the > last patches in the stable and developement branch. > For this seldom case the existing bugfix should be extended by the > following patch (against 1.3.11). > > --- MaraDNS.c~ 2008-03-24 16:52:28.000000000 +0100 > +++ MaraDNS.c 2008-08-01 15:49:05.000000000 +0200 > @@ -1892,8 +1892,8 @@ > header.qr = 1; > header.opcode = 0; > header.tc = 0; /* To do: truncation handling */ > - header.rd = 0; /* RDBUG udpnotfound */ > - header.ra = 0; > + header.rd = rd_val; /* RDBUG udpnotfound */ > + header.ra = rd_val; > header.z = 0; > /* Code that verifies that this host does not exist in > any class. If so, then we give them a rcode of NXDOMAIN_RCODE. > > This patch cures the exim problem. But I am pretty sure that it is not > complete. Also there may be a conflict with > the RDBUG udpnotfound bugfix. > > Background: > If a domain has no MX entry exim decides to use the IP of the A entry. > But exim have to be resonable sure that no other DNS error has ocurred. > Since maradns does not return the RD and RA flags properly exim supposes > an dns malfunction: > > I did send a recursive MX question and get a nonrecursive answer > the > DNS may be broken > > and tries again and again to get a recursive answer. The bitter > consequence is that emails to domains without MX records > will completely fail on exim systems. > > It is no RFC violation not to set an MX record for a maildomain. > Let's take a look at what RFC 2821 says: > - Once the domain is identified SMTP must perform a DNS lookup and first > attempt to locate an MX record. > - If no MX records are found but an A record is found, it is treated as > if it was associated with an implicit MX record with a preference of 0 > pointing to that host - also known as the "implicit MX" rule. > > With maradns the following happens: > > skylla:~/maradns-1.3.11# dig @10.1.0.8 -tmx +recurse mail.tropos.de > ; <<>> DiG 9.3.4-P1.1 <<>> @10.1.0.8 -tmx +recurse mail.tropos.de > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24702 > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;mail.tropos.de. IN MX > > ;; AUTHORITY SECTION: > mail.tropos.de. 85665 IN SOA sana.tropos.de. > jagemann.tropos.de. 200807312 86400 3600 3600000 86400 > > Compared to a bind DNS-server: > > skylla:~/maradns-1.3.11# dig @193.239.30.4 -tmx +recurse mail.tropos.de > > ; <<>> DiG 9.3.4-P1.1 <<>> @193.239.30.4 -tmx +recurse mail.tropos.de > ; (1 server found) > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61493 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;mail.tropos.de. IN MX > > ;; AUTHORITY SECTION: > tropos.de. 10800 IN SOA sana.tropos.de. > jagemann.tropos.de. 200807312 86400 3600 3600000 86400 > > Best regards > > Volker > > -- > ==================================================== > inqbus it-consulting +49 ( 341 ) 5643800 > Dr. Volker Jaenisch http://www.inqbus.de > Herlo?sohnstr. 12 0 4 1 5 5 Leipzig > N O T - F ? L L E +49 ( 170 ) 3113748 > ==================================================== > > From volker.jaenisch at inqbus.de Fri Aug 1 12:29:13 2008 From: volker.jaenisch at inqbus.de (Dr. Volker Jaenisch) Date: Fri, 01 Aug 2008 18:29:13 +0200 Subject: wrong RD/RA flags cause exim4 to fail if no MX Record for a domain is set In-Reply-To: <7bd685720808010803rec3edd2k748315a44d41c5a1@mail.gmail.com> References: <489322F8.6080107@inqbus.de> <7bd685720808010803rec3edd2k748315a44d41c5a1@mail.gmail.com> Message-ID: <489339D9.5000109@inqbus.de> Hello Sam! Thank you for this fast reply. Sam Trenholme wrote: > As an aside, RA serves *no* purpose in the DNS header. There is no > good reason why clients should look at or care how this bit is set. > IMHO, Exim is broken because it cares how this bit is set. I mostly > fixed this last fall (as you observed); however I didn't cover all of > the corner cases. > I agree with you that the behavior of exim has to be questioned. But I disagree with your first point. RFC 1035 reads: RA Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server. So RA seems of value if one likes to know wether or not the query has undergone recursive treatment or if the DNS-Server supports recursive queries. I think it is very important to implement the RFC as exakt as possible. Or lets say the other way around: If an application differs in behavior from the reference implementation (Bind) this deviation should be explicitly allowed in the RFC. RFC 2929 is of no great help : The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful only in queries or only in responses, depending on the bit. However, many DNS implementations copy the query header as the initial value of the response header without clearing bits. Thus any attempt to use a "query" bit with a different meaning in a response or to define a query meaning for a "response" bit is dangerous given existing implementation. Such meanings may only be assigned by an IETF Standards Action. In summary it states: There are differences in the implementation of flags in different DNS servers. This also promotes my point to implement RFC1035 word by word. :-) Please do not take this as criticism on maradns. I like to use and promote maradns. Lets make a better world with better DNS servers. :-) Best regards, Volker -- ==================================================== inqbus it-consulting +49 ( 341 ) 5643800 Dr. Volker Jaenisch http://www.inqbus.de Herlo?sohnstr. 12 0 4 1 5 5 Leipzig N O T - F ? L L E +49 ( 170 ) 3113748 ==================================================== From strenholme.usenet at gmail.com Fri Aug 1 13:11:59 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 1 Aug 2008 12:11:59 -0500 Subject: wrong RD/RA flags cause exim4 to fail if no MX Record for a domain is set In-Reply-To: <489339D9.5000109@inqbus.de> References: <489322F8.6080107@inqbus.de> <7bd685720808010803rec3edd2k748315a44d41c5a1@mail.gmail.com> <489339D9.5000109@inqbus.de> Message-ID: <7bd685720808011011j383c2e0dr6e33127d5ea71799@mail.gmail.com> > RA Recursion Available - this be is set or cleared in a > response, and denotes whether recursive query support is > available in the name server. > > So RA seems of value if one likes to know whether or not the query has > undergone recursive treatment or if the DNS-Server supports recursive queries. OK, first of all, I have noted this bug and I do have a "I will fix RFC violations that you can demonstrate real-world problems with" policy with MaraDNS bug fixes (However, I won't change things to follow the RFC exactly just for the sake of following the RFCs). RA won't tell you if a given query is one where recursion was used. All it will tell you is whether you can perform recursion with a given DNS server. This is useless information; a user using a DNS server not allowing recursion will quickly find this out when they can't go to google.com, hi5.com, or whatever social networking site is popular in their region. Most DNS clients happily ignore this bit (which is why I didn't see this issue at all until late 2007, over five years after the first stable release of MaraDNS); it's only a few corner cases with some minority clients that are needlessly pedantic about the DNS spec. Don't get me started on RFC1912 section 2.2, where the serial number is supposed to be in a format that is only meaningful if you edit the SOA serial by hand. Yes, this would be a useful bit in the header if it was, say RP (recursion performed) telling you that the query in question was one processed recursively, and not coming from the local DNS server. I also feel RD is handled wrong in BIND. BIND's handling of RD has privacy implications: BIND simply doesn't recurse to process a given query, but if the query is already in the cache, BIND will give you the query from the cache. In MaraDNS, if RD is cleared, MaraDNS will not ever give you any information from the cache, but will only answer authoritative queries. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From volker.jaenisch at inqbus.de Fri Aug 1 13:59:44 2008 From: volker.jaenisch at inqbus.de (Dr. Volker Jaenisch) Date: Fri, 01 Aug 2008 19:59:44 +0200 Subject: wrong RD/RA flags cause exim4 to fail if no MX Record for a domain is set In-Reply-To: <7bd685720808011011j383c2e0dr6e33127d5ea71799@mail.gmail.com> References: <489322F8.6080107@inqbus.de> <7bd685720808010803rec3edd2k748315a44d41c5a1@mail.gmail.com> <489339D9.5000109@inqbus.de> <7bd685720808011011j383c2e0dr6e33127d5ea71799@mail.gmail.com> Message-ID: <48934F10.8060906@inqbus.de> Hello Sam! Sam Trenholme wrote: >> RA Recursion Available - this be is set or cleared in a >> response, and denotes whether recursive query support is >> available in the name server. >> >> So RA seems of value if one likes to know whether or not the query has >> undergone recursive treatment or if the DNS-Server supports recursive queries. >> > > OK, first of all, I have noted this bug and I do have a "I will fix > RFC violations that you can demonstrate real-world problems with" > policy with MaraDNS bug fixes (However, I won't change things to > follow the RFC exactly just for the sake of following the RFCs). > I agree absolutly with that. > RA won't tell you if a given query is one where recursion was used. > All it will tell you is whether you can perform recursion with a given > DNS server. This is useless information; a user using a DNS server > not allowing recursion will quickly find this out when they can't go > to google.com, hi5.com, or whatever social networking site is popular > in their region. That's true from the perspective of a user maintaining his small home-office. From ruskie at codemages.net Sat Aug 2 11:22:27 2008 From: ruskie at codemages.net (=?UTF-8?B?IkFuZHJhxb4gJ3J1c2tpZScgTGV2c3RpayI=?=) Date: Sat, 02 Aug 2008 17:22:27 +0200 Subject: Building 1.3.07.08 on openbsd Message-ID: I had 2 probs building maradns on openbsd and had to create two patches. I'm attaching them in hopes of them being the right fixes... -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From GregPlatt at ix.netcom.com Mon Aug 4 11:02:19 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 09:02:19 -0600 Subject: New MaraDNS install & New user getting Unexpected character errors on load. Message-ID: <011501c8f643$17e7d450$0200a8c0@gregsrocket> I'm a new Mara User but a 40 year IT vet. I'm also new to DNS Servers. I've struggled with the Mara setup for days without success. I have a single high-speed server with 2 IP addresses assigned (e.g. 219.180.18.68, 219.180.18.69). I bought a new domain name (e.g. mydnshost.com) which will host my DNS Servers. mydnshost.com will reside on my server along with the other domains it acts as authoritative name server for. mydnshost.com has been defined to its registrar as a domain name server using the following (fictitious) IPs ns1.mydnshost.com 219.180.18.68 ns2.mydnshost.com 219.180.18.69 To repeat, mydnshost.com resides on the same physical hardware (server) as the domains it acts as authoritative name server for. I've tried to configure mydnshost.com as BOTH a recursive and authoritative name server. For testing, I've created a single mararc file that reads as follows: [code]ipv4_bind_addresses = "219.18.180.68, 219.18.180.69" chroot_dir = "/etc/maradns" csv2 = {} csv2["mydnshost.com."] = "db.mydnshost.com" csv2["homeontherange.com."] = "db.homeontherange.com" recursive_acl = "219.18.180.68, 219.18.180.69" upstream_servers = {} upstream_servers["."] = "219.239.219.33, 219.239.219.32, 219.239.219.10, 219.239.219.11" hide_disclaimer = "YES" [/code] Here are the two zone files I'm using: [code]# This is the zone file for the domain mydnshost.com. # We have two records which handle the serving of web pages. These # are simple name-to-ip translations. In other words, we have one # record which states "The IP for mydnshost.com. is 219.18.180.68" and # another that states "The IP for www.mydnshost.com. is 219.18.180.69" # example.com. 10.10.10.12 ~ mydnshost.com. NS ns1.mydnshost.com. ~ mydnshost.com. NS ns2.mydnshost.com. ~ ns1.mydnshost.com. 219.18.180.68. ~ ns2.mydnshost.com. 219.18.180.69. ~ mydnshost.com. 219.18.180.69 ~ www.mydnshost.com. 219.18.180.69 ~ mydnshost.com. MX 10 mail1.mydnshost.com. ~ mail1.mydnshost.com. 219.18.180.69 ~ [/code] [code] # This is the sample zone file for the domain homeontherange.com. # We have two records which handle the serving of web pages. These # are simple name-to-ip translations. In other words, we have one # record which states "The IP for homeontherange.com. is 219.18.180.68" and # another that states "The IP for www.homeontherange.com. is 219.18.180.68" # example.com. 10.10.10.12 ~ homeontherange.com. NS ns1.mydnshost.com. ~ ns1.mydnshost.com 219.18.180.68 ~ homeontherange.com. NS ns2.mydnshost.com. ~ ns2.mydnshost.com 219.18.180.69 ~ homeontherange.com. 219.18.180.68 ~ www.homeontherange.com. 219.18.180.68 ~ homeontherange.com. MX 10 mail1.homeontherange.com. ~ mail1.homeontherange.com. 219.18.180.68 ~ [/code] I'm testing the setup with just 2 domains. I may eventually host 2 dozen. For testing, the domains are mydnshost.com and homeontherange.com The error messages I'm getting are: [code] myserver:/etc# /usr/sbin/maradns Log: Root directory changed Log: Binding to address 219.18.180.68, 219.18.180.69 Log: Socket opened on UDP port 53 Log: Root privileges dropped Processing zone homeontherange.com. right now. Filename: db.homeontherange.com Error: Unexpected character Error is on line 9 in file db.homeontherange.com context of error: ns1.mydnshost.com. ~ (closing this file) BUG: Don't run csv2_justread on a closed file! BUG: Don't run csv2_justread on a closed file! Error: Unexpected character Error is on line 9 in file db.homeontherange.com context of error: ns1.mydnshost.com. ~ (closing this file) Error: Problem getting hostname Error is on line 9 in file db.homeontherange.com context of error: ns1.mydnshost.com. ~ (closing this file) Processing zone mydnshost.com. right now. Filename: db.mydnshost.com Error: Unexpected character Error is on line 9 in file db.mydnshost.com context of error: ns1.mydnshost.com. ~ (closing this file) BUG: Don't run csv2_justread on a closed file! BUG: Don't run csv2_justread on a closed file! Error: Unexpected character Error is on line 9 in file db.mydnshost.com context of error: ns1.mydnshost.com. ~ (closing this file) Error: Problem getting hostname Error is on line 9 in file db.mydnshost.com context of error: ns1.mydnshost.com. ~ (closing this file) Log: All RRs have been loaded [/code] 1st Question: The server has two IP addresses; but it clearly has just 1 mararc file and 1 maradns directory. The maradns directory is empty except for two zone files and the original sample mararc file (which is unused). The mararc file that IS being used is /etc/mararc. Should we be running TWO copies of maradns to serve the two IP addresses involved? Or, since both IP's are served by the same hardware and software is one running copy of maradns enough? I'm assuming one copy is enough. 2nd Question: WHY is maradns complaining about the reference to ns1.mydnshost.com when that is the name of its Domain Name Server? 3rd Question: WHY is maradns processing the homeontherange zone file BEFORE it processes the mydnshost.com file? That's not the order they're defined in in mararc I'm completely baffled here. What the HECK is an "unexpected character" error and what causes it? What have I done wrong? And how do I fix it? Can someone out there please advise me? Thanks! From remco at webconquest.com Mon Aug 4 11:37:57 2008 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 4 Aug 2008 17:37:57 +0200 (CEST) Subject: New MaraDNS install & New user getting Unexpected character errors on load. Message-ID: <9689.167.202.222.228.1217864277.squirrel@webmail.xs4all.nl> > I'm a new Mara User but a 40 year IT vet. I'm also new to DNS Servers. > I've > struggled with the Mara setup for days without success. Hi Greg, What version of maradns are you trying this with? Kind regards, Remco From GregPlatt at ix.netcom.com Mon Aug 4 11:47:33 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 09:47:33 -0600 Subject: New MaraDNS install & New user getting Unexpected character errors onload. Message-ID: <013101c8f649$6982bb80$0200a8c0@gregsrocket> In addition to the info provided in my earlier message, You may also want to know that: I'm running Debian v4.0r3 (etch) Linux v 2.6.18-6-686 Apache v2.2.3 Maradns v1.2.12.04-1etch2 From GregPlatt at ix.netcom.com Mon Aug 4 11:53:06 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 09:53:06 -0600 Subject: New MaraDNS install & New user getting Unexpected character errors on load. In-Reply-To: <9689.167.202.222.228.1217864277.squirrel@webmail.xs4all.nl> Message-ID: <013701c8f64a$3000c9f0$0200a8c0@gregsrocket> Sorry, I realized shortly after I'd sent it that I'd left out that info as well as linux and apache details. I was reposting it to the list when your follow-up question arrived. Here's what I said: I'm running Debian v4.0r3 (etch) Linux v 2.6.18-6-686 Apache v2.2.3 Maradns v1.2.12.04-1etch2 I'm trying to figure out what patches have been applied to v1.2.12.04 the "1etch2" suffix to the name does, I believe, indicate that some patches released AFTER the original v1.2.12 version have been applied to Maradns since the original February 08 release of Debian 4.0r3; but I'm not sure how to determine exactly WHAT patches have been applied. -----Original Message----- From: Remco Rijnders [mailto:remco at webconquest.com] Sent: Monday, August 04, 2008 9:38 AM To: gregplatt at ix.netcom.com Cc: list at maradns.org Subject: Re: New MaraDNS install & New user getting Unexpected character errors on load. > I'm a new Mara User but a 40 year IT vet. I'm also new to DNS Servers. > I've > struggled with the Mara setup for days without success. Hi Greg, What version of maradns are you trying this with? Kind regards, Remco From remco at webconquest.com Mon Aug 4 11:58:19 2008 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 4 Aug 2008 17:58:19 +0200 (CEST) Subject: New MaraDNS install & New user getting Unexpected character errors on load. Message-ID: <19540.167.202.222.228.1217865499.squirrel@webmail.xs4all.nl> > Sorry, I realized shortly after I'd sent it that I'd left out that info as > well as linux and apache details. I was reposting it to the list when your > follow-up question arrived. Here's what I said: > > I'm running > > Debian v4.0r3 (etch) > > Linux v 2.6.18-6-686 > > Apache v2.2.3 > > Maradns v1.2.12.04-1etch2 > > I'm trying to figure out what patches have been applied to v1.2.12.04 the > "1etch2" suffix to the name does, I believe, indicate that some patches > released AFTER the original v1.2.12 version have been applied to Maradns > since the original February 08 release of Debian 4.0r3; but I'm not sure > how > to determine exactly WHAT patches have been applied. I do not have my "play" maradns server at hand at the moment to try this on, but I think the problem might be related to your records all ending in " ~". Tilde handling was only introduced in maradns v1.3 and I'm not sure how the 1.2 parser likes it. Looking at the zone files you posted, I think you can safely leave off the ~ at the end of each line. Can you try and see it that makes a difference? Remco From GregPlatt at ix.netcom.com Mon Aug 4 12:03:20 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 10:03:20 -0600 Subject: New MaraDNS install & New user getting Unexpected character errors on load. In-Reply-To: <19540.167.202.222.228.1217865499.squirrel@webmail.xs4all.nl> Message-ID: <013901c8f64b$9e5e0100$0200a8c0@gregsrocket> You know, I wondered about the tilde's at the ends of the lines myself since the documentation I had (from the current docs on the MaraDNS site) showed them but did not explain them. So I did try removing the ~ at the ends of the lines BEFORE I posted my original message and it did not seem to make any difference. Sorry... I probably should have explained what troubleshooting I had already tried. But I was trying to keep my post short and to the point. -----Original Message----- From: Remco Rijnders [mailto:remco at webconquest.com] Sent: Monday, August 04, 2008 9:58 AM To: gregplatt at ix.netcom.com Cc: list at maradns.org Subject: RE: New MaraDNS install & New user getting Unexpected character errors on load. > Sorry, I realized shortly after I'd sent it that I'd left out that info as > well as linux and apache details. I was reposting it to the list when your > follow-up question arrived. Here's what I said: > > I'm running > > Debian v4.0r3 (etch) > > Linux v 2.6.18-6-686 > > Apache v2.2.3 > > Maradns v1.2.12.04-1etch2 > > I'm trying to figure out what patches have been applied to v1.2.12.04 the > "1etch2" suffix to the name does, I believe, indicate that some patches > released AFTER the original v1.2.12 version have been applied to Maradns > since the original February 08 release of Debian 4.0r3; but I'm not sure > how > to determine exactly WHAT patches have been applied. I do not have my "play" maradns server at hand at the moment to try this on, but I think the problem might be related to your records all ending in " ~". Tilde handling was only introduced in maradns v1.3 and I'm not sure how the 1.2 parser likes it. Looking at the zone files you posted, I think you can safely leave off the ~ at the end of each line. Can you try and see it that makes a difference? Remco From GregPlatt at ix.netcom.com Mon Aug 4 12:07:01 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 10:07:01 -0600 Subject: New MaraDNS install & New user getting Unexpected character errors on load. In-Reply-To: <19540.167.202.222.228.1217865499.squirrel@webmail.xs4all.nl> Message-ID: <013b01c8f64c$21d05d30$0200a8c0@gregsrocket> Here's a complete list of all patches that have been applied to maradns v1.2.12 in the debian 4.0r3(etch) that release I'm running: maradns (1.2.12.04-1etch2) stable-security; urgency=high * Fix remote DoS -- Moritz Muehlenhoff Wed, 2 Jan 2008 20:05:55 +0000 maradns (1.2.12.04-1etch1) stable-security; urgency=high * Fix memleak DoS [CVE-2007-311[456] -- Moritz Muehlenhoff Thu, 21 Jun 2007 13:52:57 +0200 maradns (1.2.12.04-1) unstable; urgency=low * New upstream release * Source package contains non-free IETF RFC/I-D's (Closes: #393397) -- Kai Hendry Tue, 28 Nov 2006 08:54:23 -0300 maradns (1.2.12.03-1) unstable; urgency=low * New upstream release with many new doc tweaks. Though most of the changes are with the webpages which I have chosen not to distribute as you can read them all rather online at http://maradns.org/ * The diffs in the Makefiles are due to upstream's configure script * Added bind2csv2.py as an example from upstream's tools/ There is a lot of little scripts in tools/ which can probably join this -- Kai Hendry Mon, 9 Oct 2006 17:44:21 -0300 maradns (1.2.12.02-4) unstable; urgency=low * More tweaks to the init. -- Kai Hendry Mon, 9 Oct 2006 16:01:50 -0300 maradns (1.2.12.02-3) unstable; urgency=low * I applied patch in the wrong place. Thanks again to Boris Dor?s -- Kai Hendry Sun, 8 Oct 2006 21:02:33 -0300 maradns (1.2.12.02-2) unstable; urgency=low * start/stop zoneserver (Closes: #384943) Thank you Boris Dor?s for the patch * Need --oknodo in postinst (Closes: #386734) * Start maradns(19) before exim4(20) -- Kai Hendry Sun, 8 Oct 2006 19:32:22 -0300 maradns (1.2.12.02-1) unstable; urgency=low * New upstream release -- Kai Hendry Wed, 23 Aug 2006 21:08:05 +0100 -----Original Message----- From: Remco Rijnders [mailto:remco at webconquest.com] Sent: Monday, August 04, 2008 9:58 AM To: gregplatt at ix.netcom.com Cc: list at maradns.org Subject: RE: New MaraDNS install & New user getting Unexpected character errors on load. > Sorry, I realized shortly after I'd sent it that I'd left out that info as > well as linux and apache details. I was reposting it to the list when your > follow-up question arrived. Here's what I said: > > I'm running > > Debian v4.0r3 (etch) > > Linux v 2.6.18-6-686 > > Apache v2.2.3 > > Maradns v1.2.12.04-1etch2 > > I'm trying to figure out what patches have been applied to v1.2.12.04 the > "1etch2" suffix to the name does, I believe, indicate that some patches > released AFTER the original v1.2.12 version have been applied to Maradns > since the original February 08 release of Debian 4.0r3; but I'm not sure > how > to determine exactly WHAT patches have been applied. I do not have my "play" maradns server at hand at the moment to try this on, but I think the problem might be related to your records all ending in " ~". Tilde handling was only introduced in maradns v1.3 and I'm not sure how the 1.2 parser likes it. Looking at the zone files you posted, I think you can safely leave off the ~ at the end of each line. Can you try and see it that makes a difference? Remco From GregPlatt at ix.netcom.com Mon Aug 4 12:14:12 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 10:14:12 -0600 Subject: New MaraDNS install & New user getting Unexpected character errors on load. In-Reply-To: <19540.167.202.222.228.1217865499.squirrel@webmail.xs4all.nl> Message-ID: <013d01c8f64d$2732e260$0200a8c0@gregsrocket> STOP! Don't waste your time. I took your suggestion and tried the "without tilde's" test again. This time the result without the tildes is different. I'm looking at them now. More shortly. -----Original Message----- From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf Of Remco Rijnders Sent: Monday, August 04, 2008 9:58 AM To: gregplatt at ix.netcom.com Cc: list at maradns.org Subject: RE: New MaraDNS install & New user getting Unexpected character errors on load. > Sorry, I realized shortly after I'd sent it that I'd left out that info as > well as linux and apache details. I was reposting it to the list when your > follow-up question arrived. Here's what I said: > > I'm running > > Debian v4.0r3 (etch) > > Linux v 2.6.18-6-686 > > Apache v2.2.3 > > Maradns v1.2.12.04-1etch2 > > I'm trying to figure out what patches have been applied to v1.2.12.04 the > "1etch2" suffix to the name does, I believe, indicate that some patches > released AFTER the original v1.2.12 version have been applied to Maradns > since the original February 08 release of Debian 4.0r3; but I'm not sure > how > to determine exactly WHAT patches have been applied. I do not have my "play" maradns server at hand at the moment to try this on, but I think the problem might be related to your records all ending in " ~". Tilde handling was only introduced in maradns v1.3 and I'm not sure how the 1.2 parser likes it. Looking at the zone files you posted, I think you can safely leave off the ~ at the end of each line. Can you try and see it that makes a difference? Remco From GregPlatt at ix.netcom.com Mon Aug 4 12:46:05 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 10:46:05 -0600 Subject: New MaraDNS install & New user getting Unexpected character errors on load. In-Reply-To: <19540.167.202.222.228.1217865499.squirrel@webmail.xs4all.nl> Message-ID: <015a01c8f651$96d36780$0200a8c0@gregsrocket> Dear Remco: Thanks a lot for the help. Your one suggestion was enough to help me solve the problem. Following your 'remove the tildes' suggestion, I tried removing the tilde's again. Obviously I did SOMETHING wrong when I tried removing the tilde's earlier because this time the results were different. Here's what I saw: myserver:/etc# /usr/sbin/maradns Log: Root directory changed Log: Binding to address 219.18.180.68, 219.18.180.69 Log: Socket opened on UDP port 53 Log: Root privileges dropped Processing zone homeontherange.com. right now. Filename: db.homeontherange.com Error: Improper termination of label Label must end with '.' or '%' (A '*' is allowed in csv2_default_zonefile) Error is on line 10 in file db.homeontherange.com context of error: ns1.mydnshost.com (closing this file) Error: Problem getting hostname Error is on line 10 in file db.homeontherange.com context of error: ns1.mydnshost.com (closing this file) Processing zone mydnshost.com. right now. Filename: db.mydnshost.com Log: All RRs have been loaded At this point, I looked at line 10 and realized the ns1.mydnshost.com record there was missing a period. (I had nearly forgotten the lessons learned back in my COBOL programming days when a 'missed period' was one of the worst things that could happen in life) I fixed that and tried again. The results of the next test showed: myserver:/etc# /usr/sbin/maradns Log: Root directory changed Log: Binding to address 219.18.180.68, 219.18.180.69 Log: Socket opened on UDP port 53 Log: Root privileges dropped Processing zone homeontherange.com. right now. Filename: db.homeontherange.com Warning: Authoritative NSes must be immediately after SOA Or the first records in the zone Otherwise, the record is ignored Processing zone mydnshost.com. right now. Filename: db.mydnshost.com Log: All RRs have been loaded Again, I looked at the zone file and realized the ns1.mydnshost.com. record occurred between the two NS records. So I moved the second DNS record up above the first one so that the zone file looked like this: # This is the sample zone file for the domain homeontherange.com. # We have two records which handle the serving of web pages. These # are simple name-to-ip translations. In other words, we have one # record which states "The IP for homeontherange.com. is 219.18.180.68" and # another that states "The IP for www.homeontherange.com. is 219.18.180.68" # example.com. 10.10.10.12 ~ homeontherange.com. NS ns1.mydnshost.com. homeontherange.com. NS ns2.mydnshost.com. ns1.mydnshost.com. 219.18.180.68 ns2.mydnshost.com. 219.18.180.69 homeontherange.com. 219.18.180.68 www.homeontherange.com. 219.18.180.68 homeontherange.com. MX 10 mail1.homeontherange.com. mail1.homeontherange.com. 219.18.180.68 And then I ran the test again. This time, it seems to have worked. What I see now, is: myserver:/etc# /usr/sbin/maradns Log: Root directory changed Log: Binding to address 219.18.180.68, 219.18.180.69 Log: Socket opened on UDP port 53 Log: Root privileges dropped Processing zone homeontherange.com. right now. Filename: db.homeontherange.com Processing zone mydnshost.com. right now. Filename: db.mydnshost.com Log: All RRs have been loaded Hurray! Thank You, Remco. You ARE a genius! I see what happened. I obviously wasn't able to 'guess' how to set-up the mararc and zone files but my Debian release didn't seem to include the full docs and tutorials. So, I went to the MaraDNS site and followed the tutorials there. It never dawned on me the version I was following the tutorial for would include config file format changes that might not be backward compatible to the version I was actually INSTALLING. Duhhh! NOW that it's running from the command prompt, I'll try to figure out how to run it as a background process and how to test it to confirm that it's working otherwise. Is there any possibility you can answer the other two questions I asked in my original message? 1st Question: The server has two IP addresses; but it clearly has just 1 mararc file and 1 maradns directory. The maradns directory is empty except for two zone files and the original sample mararc file (which is unused). The mararc file that IS being used is /etc/mararc. Should we be running TWO copies of maradns to serve the two IP addresses involved? Or, since both IP's are served by the same hardware and software is one running copy of maradns enough? I'm assuming one copy is enough. 2nd Question: ANSWERED! :-) 3rd Question: WHY is maradns processing the homeontherange zone file BEFORE it processes the mydnshost.com file? That's not the order they're defined in in mararc. Thanks, Greg -----Original Message----- From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf Of Remco Rijnders Sent: Monday, August 04, 2008 9:58 AM To: gregplatt at ix.netcom.com Cc: list at maradns.org Subject: RE: New MaraDNS install & New user getting Unexpected character errors on load. > Sorry, I realized shortly after I'd sent it that I'd left out that info as > well as linux and apache details. I was reposting it to the list when your > follow-up question arrived. Here's what I said: > > I'm running > > Debian v4.0r3 (etch) > > Linux v 2.6.18-6-686 > > Apache v2.2.3 > > Maradns v1.2.12.04-1etch2 > > I'm trying to figure out what patches have been applied to v1.2.12.04 the > "1etch2" suffix to the name does, I believe, indicate that some patches > released AFTER the original v1.2.12 version have been applied to Maradns > since the original February 08 release of Debian 4.0r3; but I'm not sure > how > to determine exactly WHAT patches have been applied. I do not have my "play" maradns server at hand at the moment to try this on, but I think the problem might be related to your records all ending in " ~". Tilde handling was only introduced in maradns v1.3 and I'm not sure how the 1.2 parser likes it. Looking at the zone files you posted, I think you can safely leave off the ~ at the end of each line. Can you try and see it that makes a difference? Remco From remco at webconquest.com Mon Aug 4 13:03:09 2008 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 4 Aug 2008 19:03:09 +0200 (CEST) Subject: New MaraDNS install & New user getting Unexpected character errors on load. Message-ID: <25360.167.202.222.228.1217869389.squirrel@webmail.xs4all.nl> Hi Greg, > 1st Question: The server has two IP addresses; but it clearly has just 1 > mararc file and 1 maradns directory. The maradns directory is empty except > for two zone files and the original sample mararc file (which is unused). > The mararc file that IS being used is /etc/mararc. Should we be running > TWO > copies of maradns to serve the two IP addresses involved? Or, since both > IP's are served by the same hardware and software is one running copy of > maradns enough? I'm assuming one copy is enough. Yup, one copy is enough. As the log of your now working server shows: myserver:/etc# /usr/sbin/maradns Log: Root directory changed Log: Binding to address 219.18.180.68, 219.18.180.69 Maradns should be listening and answering on both addresses now. > 2nd Question: ANSWERED! :-) Glad to hear that fixed it :) > 3rd Question: WHY is maradns processing the homeontherange zone file > BEFORE > it processes the mydnshost.com file? That's not the order they're defined > in > in mararc. I believe maradns processes the files in alphabetical order based on the filename. It shouldn't make a difference to you though as there are no loading dependencies between the various zone files; In other words it is fine to have a file showing ns.mydnshost.com as the nameserver before the mydnshost.com zone file has been loaded. Kind regards, Remco Rijnders From strenholme.usenet at gmail.com Mon Aug 4 13:07:46 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 4 Aug 2008 12:07:46 -0500 Subject: wrong RD/RA flags cause exim4 to fail if no MX Record for a domain is set In-Reply-To: <7bd685720808011235l6a3db66cxfd477dd934231a4d@mail.gmail.com> References: <489322F8.6080107@inqbus.de> <7bd685720808010803rec3edd2k748315a44d41c5a1@mail.gmail.com> <489339D9.5000109@inqbus.de> <7bd685720808011011j383c2e0dr6e33127d5ea71799@mail.gmail.com> <48934F10.8060906@inqbus.de> <7bd685720808011235l6a3db66cxfd477dd934231a4d@mail.gmail.com> Message-ID: <7bd685720808041007q198c870ck9e8b79bd8dbf50c0@mail.gmail.com> OK, update on this bug: I have fixed the issue in both the 1.2 and 1.3 branches. These fixes should not introduce any new problems. In particular, the 1.3 branch passed all regression tests. With the 1.2 branch, I only fixed this bug. With the 1.3 branch, I also fixed a troublesome regression and removed a compile-time warning. That said, I have uploaded the updated files but won't make them official for a couple of days to make sure no one reports the world coming to an end using a new release. Here are the files: http://www.maradns.org/download/1.2/1.2.12.10/ http://www.maradns.org/download/1.3/1.3.07.09/ An issue I haven't dealt with yet: The !@#$ FreeBSD compile problem caused by zoneserver (The TCP DNS server). - Samuel From gianspi at gsent.org Mon Aug 4 13:11:09 2008 From: gianspi at gsent.org (Gian Spicuzza) Date: Mon, 04 Aug 2008 13:11:09 -0400 Subject: unsubscribe In-Reply-To: <015a01c8f651$96d36780$0200a8c0@gregsrocket> References: <015a01c8f651$96d36780$0200a8c0@gregsrocket> Message-ID: <4897382D.9020106@gsent.org> Greg Platt - Platt Consultants wrote: > Dear Remco: > > Thanks a lot for the help. Your one suggestion was enough to help me solve > the problem. > > Following your 'remove the tildes' suggestion, I tried removing the tilde's > again. Obviously I did SOMETHING wrong when I tried removing the tilde's > earlier because this time the results were different. > > Here's what I saw: > > > > myserver:/etc# /usr/sbin/maradns > Log: Root directory changed > Log: Binding to address 219.18.180.68, 219.18.180.69 > Log: Socket opened on UDP port 53 > Log: Root privileges dropped > Processing zone homeontherange.com. right now. > Filename: db.homeontherange.com > Error: Improper termination of label > Label must end with '.' or '%' (A '*' is allowed in csv2_default_zonefile) > Error is on line 10 in file db.homeontherange.com > context of error: ns1.mydnshost.com (closing this file) > Error: Problem getting hostname > Error is on line 10 in file db.homeontherange.com > context of error: ns1.mydnshost.com (closing this file) > Processing zone mydnshost.com. right now. > Filename: db.mydnshost.com > Log: All RRs have been loaded > > > > At this point, I looked at line 10 and realized the ns1.mydnshost.com record > there was missing a period. (I had nearly forgotten the lessons learned back > in my COBOL programming days when a 'missed period' was one of the worst > things that could happen in life) I fixed that and tried again. > > The results of the next test showed: > > > > myserver:/etc# /usr/sbin/maradns > Log: Root directory changed > Log: Binding to address 219.18.180.68, 219.18.180.69 > Log: Socket opened on UDP port 53 > Log: Root privileges dropped > Processing zone homeontherange.com. right now. > Filename: db.homeontherange.com > Warning: Authoritative NSes must be immediately after SOA > Or the first records in the zone > Otherwise, the record is ignored > Processing zone mydnshost.com. right now. > Filename: db.mydnshost.com > Log: All RRs have been loaded > > > > Again, I looked at the zone file and realized the ns1.mydnshost.com. record > occurred between the two NS records. So I moved the second DNS record up > above the first one so that the zone file looked like this: > > > > # This is the sample zone file for the domain homeontherange.com. > > # We have two records which handle the serving of web pages. These > # are simple name-to-ip translations. In other words, we have one > # record which states "The IP for homeontherange.com. is 219.18.180.68" and > # another that states "The IP for www.homeontherange.com. is 219.18.180.68" > # example.com. 10.10.10.12 ~ > > homeontherange.com. NS ns1.mydnshost.com. > homeontherange.com. NS ns2.mydnshost.com. > ns1.mydnshost.com. 219.18.180.68 > ns2.mydnshost.com. 219.18.180.69 > homeontherange.com. 219.18.180.68 > www.homeontherange.com. 219.18.180.68 > homeontherange.com. MX 10 mail1.homeontherange.com. > mail1.homeontherange.com. 219.18.180.68 > > > > And then I ran the test again. > > This time, it seems to have worked. What I see now, is: > > > > myserver:/etc# /usr/sbin/maradns > Log: Root directory changed > Log: Binding to address 219.18.180.68, 219.18.180.69 > Log: Socket opened on UDP port 53 > Log: Root privileges dropped > Processing zone homeontherange.com. right now. > Filename: db.homeontherange.com > Processing zone mydnshost.com. right now. > Filename: db.mydnshost.com > Log: All RRs have been loaded > > > Hurray! Thank You, Remco. You ARE a genius! I see what happened. I obviously > wasn't able to 'guess' how to set-up the mararc and zone files but my Debian > release didn't seem to include the full docs and tutorials. So, I went to > the MaraDNS site and followed the tutorials there. It never dawned on me the > version I was following the tutorial for would include config file format > changes that might not be backward compatible to the version I was actually > INSTALLING. Duhhh! > > NOW that it's running from the command prompt, I'll try to figure out how to > run it as a background process and how to test it to confirm that it's > working otherwise. > > Is there any possibility you can answer the other two questions I asked in > my original message? > > 1st Question: The server has two IP addresses; but it clearly has just 1 > mararc file and 1 maradns directory. The maradns directory is empty except > for two zone files and the original sample mararc file (which is unused). > The mararc file that IS being used is /etc/mararc. Should we be running TWO > copies of maradns to serve the two IP addresses involved? Or, since both > IP's are served by the same hardware and software is one running copy of > maradns enough? I'm assuming one copy is enough. > > 2nd Question: ANSWERED! :-) > > 3rd Question: WHY is maradns processing the homeontherange zone file BEFORE > it processes the mydnshost.com file? That's not the order they're defined in > in mararc. > > Thanks, > Greg > > -----Original Message----- > From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf > Of Remco Rijnders > Sent: Monday, August 04, 2008 9:58 AM > To: gregplatt at ix.netcom.com > Cc: list at maradns.org > Subject: RE: New MaraDNS install & New user getting Unexpected character > errors on load. > > >> Sorry, I realized shortly after I'd sent it that I'd left out that info as >> well as linux and apache details. I was reposting it to the list when your >> follow-up question arrived. Here's what I said: >> >> I'm running >> >> Debian v4.0r3 (etch) >> >> Linux v 2.6.18-6-686 >> >> Apache v2.2.3 >> >> Maradns v1.2.12.04-1etch2 >> >> I'm trying to figure out what patches have been applied to v1.2.12.04 the >> "1etch2" suffix to the name does, I believe, indicate that some patches >> released AFTER the original v1.2.12 version have been applied to Maradns >> since the original February 08 release of Debian 4.0r3; but I'm not sure >> how >> to determine exactly WHAT patches have been applied. >> > > I do not have my "play" maradns server at hand at the moment to try this > on, but I think the problem might be related to your records all ending in > " ~". Tilde handling was only introduced in maradns v1.3 and I'm not sure > how the 1.2 parser likes it. Looking at the zone files you posted, I think > you can safely leave off the ~ at the end of each line. Can you try and > see it that makes a difference? > > Remco > > > From GregPlatt at ix.netcom.com Mon Aug 4 14:25:24 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 12:25:24 -0600 Subject: Still having issues -- is this an issue with Apache or mardns? Message-ID: <018f01c8f65f$76893a50$0200a8c0@gregsrocket> Okay, the domain name server appears to be working now. At least when I point to a domain that has only ever been defined on our new server, the domain name does resolve to my new server and it forwards the user's request to Apache on the new server. Similarly, when I request a domain whose registrar record has been repointed to this server, the domain also resolves to the new server and the request gets handed to Apache on the new server. However, once the request is handed to the new server, Apache ALWAYS delivers the home page for the default domain on the server no matter what domain was actually requested. Even though I have the new domains defined to Apache and enabled there, Apache doesn't deliver the user to the home directory (and thus the index.html file) for that domain. Instead, it delivers them to whatever is the default domain on the server at the moment. My conclusion is that the issue appears to be caused by Apache on the server and is not being caused by maradns. Is that the same conclusion you come to? Thanks! From remco at webconquest.com Mon Aug 4 14:57:08 2008 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 4 Aug 2008 20:57:08 +0200 Subject: Still having issues -- is this an issue with Apache or mardns? In-Reply-To: <018f01c8f65f$76893a50$0200a8c0@gregsrocket> References: <018f01c8f65f$76893a50$0200a8c0@gregsrocket> Message-ID: Op 4 aug 2008, om 20:25 heeft Greg Platt - Platt Consultants het volgende geschreven: > Okay, the domain name server appears to be working now. At least > when I > point to a domain that has only ever been defined on our new server, > the > domain name does resolve to my new server and it forwards the user's > request > to Apache on the new server. Similarly, when I request a domain whose > registrar record has been repointed to this server, the domain also > resolves > to the new server and the request gets handed to Apache on the new > server. > > However, once the request is handed to the new server, Apache ALWAYS > delivers the home page for the default domain on the server no > matter what > domain was actually requested. Even though I have the new domains > defined to > Apache and enabled there, Apache doesn't deliver the user to the home > directory (and thus the index.html file) for that domain. Instead, it > delivers them to whatever is the default domain on the server at the > moment. > > My conclusion is that the issue appears to be caused by Apache on > the server > and is not being caused by maradns. Is that the same conclusion you > come to? Yup... looks like DNS points to the right server for both domains. Apache should make the distinction based on the URL being requested. You may have to read up on virtual hosting directives and/or see how to add and enable sites on your Debian box. Google should be your friend here :) Also don't forget to restart apache when you changed its configuration. Cheers, Remco From strenholme.usenet at gmail.com Mon Aug 4 15:03:36 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 4 Aug 2008 14:03:36 -0500 Subject: New MaraDNS install & New user getting Unexpected character errors on load. In-Reply-To: <015a01c8f651$96d36780$0200a8c0@gregsrocket> References: <19540.167.202.222.228.1217865499.squirrel@webmail.xs4all.nl> <015a01c8f651$96d36780$0200a8c0@gregsrocket> Message-ID: <7bd685720808041203y32be4fcbx49d6e3790c4d11@mail.gmail.com> > 1st Question: The server has two IP addresses; but it clearly has just 1 > mararc file and 1 maradns directory. MaraDNS has support this since MaraDNS 1.2 e.g. ipv4_bind_addresses = "10.1.2.3, 10.9.8.7" > 3rd Question: WHY is maradns processing the homeontherange zone file BEFORE > it processes the mydnshost.com file? That's not the order they're defined in > in mararc. The names of zones are hashed and then pulled out of the hash in the order they are in the hash. In other words, they are pulled out of the zones in a semi-random fashion. Doesn't make a real-world difference with zone file processing. It's the name reason awk 'BEGIN{a["hello"]="foo";a["world"]="bar";a["foo"]="hello";for(b in a){print b}}' prints out the elements in a semi-random order. From strenholme.usenet at gmail.com Mon Aug 4 15:08:01 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 4 Aug 2008 14:08:01 -0500 Subject: Standard disclaimer Message-ID: <7bd685720808041208g61d08f79t5195661bc80b810a@mail.gmail.com> OK, a co-worker needed something from me so I forgot to put this on my last postings to the list: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. Please not that I'm aware of the "new" cache poisoning attack, and that MaraDNS has always been immune. In other words, if you email telling me you just gave my paypal account $5 and are, as a result, entitled to demand you favorite pet feature RIGHT NOW, don't come back until you have $3,000 or more to give me. From GregPlatt at ix.netcom.com Mon Aug 4 20:29:58 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 18:29:58 -0600 Subject: MaraDNS now runs automatically on reboot but always times out... Message-ID: <020001c8f692$64797a40$0200a8c0@gregsrocket> While I was testing my maradns server today and still using manual starts of myserver #: ~/etc//usr/sbin/maradns to get mara going, I did a system restart. Afterwards, when I tried to start mara with Ess000503:~# /usr/sbin/maradns As I had before, I received: Log: Root directory changed Fatal error: Problem binding to port 53. System said: Cannot assign requested address Since I was suddenly getting this error, I eventually discovered maradns was now starting automatically and was already running as a resident process (therefore, it had port 53 tied up). AFAIK, I had done nothing specific to make the auto-start of maradns happen. It just happened. Ever since then, maradns has refused to respond to queries it did reply to before earlier for domains its supposed to be hosting. For hours I couldn't figure out why. Then an hour ago I looked close at the command line shown by ps for maradns and immediately saw the problem. myserver:~# ps aux |grep maradns nobody 2284 0.0 0.0 1820 592 ? S Aug04 0:00 /usr/sbin/maradns -f /etc/maradns/mararc root 2285 0.0 0.0 1560 500 ? S Aug04 0:00 logger -p daemon.notice -t maradns.etc_maradns_mararc root 2751 0.0 0.0 2856 716 pts/1 S+ 00:07 0:00 grep maradns maradns is auto-starting with the following command line: /usr/sbin/maradns -f /etc/maradns/mararc That's NOT the mararc file I created and was testing with! My test mararc file was actually /etc/mararc and since I was always starting maradns manually, it was consistently using that file because I was always starting maradns from the /etc directory. Once I realized what was wrong, I tried to fix the problem by saving a copy of the original mararc /etc/maradns/mararc file. Then I moved my test copy of mararc into that directory. After I did that, I rebooted the server. But NOW, maradns either fails or refuses to auto-start and when I try to start it manually, I STILL get the port error! Log: Root directory changed Fatal error: Problem binding to port 53. System said: Cannot assign requested address! Bottom line: earlier today when I did: myserver:~# askmara -n -v Zmydnshost.com. 219.18.180.68 I was getting a long and detailed report from the server. But NOW when I do the same thing, the server spins its wheels for a while and I get: myserver:~# askmara -n -v Zmydnshost.com. 219.18.180.68 Querying the server with the IP 219.18.180.68 Hard Error: Timeout The odd thing about this is that what WASN'T working earlier was NameBasedHosting in Apache2. (That's WHY I was still testing mara when the sh*t hit the fan) Now, it appears I've got the NameBasedHosting working okay for my test domain "homeonetherange.com" because I can now go to the browser and type in "homeontherange.com" and I get the correct site displayed -- even when that's not the default site in Apache. But when I try the other domain (mydnshost.com), it never displays in the browser and askmara consistently displays the timeout error. you see above. Clearly the automatic startup process has introduced an error during startup that's preventing maradns from working right. How the heck do I correct this?? HELP!!! Can ANYONE tell me what to do to FIX this problem? Thanks! From GregPlatt at ix.netcom.com Mon Aug 4 23:32:12 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 21:32:12 -0600 Subject: How do I STOP maradns from autostarting? Message-ID: <022f01c8f6ab$d9dc67c0$0200a8c0@gregsrocket> While testing, maradns inserted itself into my autostart process. I don't WANT it autostarting! I'm still trying to TEST the darn thing! If I shut it down using kill -TERM processID, it leaves port 53 locked. That means I can't start it manually to continue my tests! 1. How do I STOP the darned thing from autostarting when the server starts? 2. What do I do later to convince it to start automatically again later? 3. What could the sample autostart process have possibly done that now PREVENTS me from replacing the /etc/maradns/mararc "unabridged" file with the one I was testing with earlier in the day? When I replace the /etc/maradns/mararc with my test version, mara fails to start now even in the autostart mode. What a nightmare this process is. From GregPlatt at ix.netcom.com Tue Aug 5 00:13:29 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 4 Aug 2008 22:13:29 -0600 Subject: rcconf provided partial solution maradns process no longer starts Message-ID: <024101c8f6b1$9e7437c0$0200a8c0@gregsrocket> I dug around and figured out that the tool I needed to stop the maradns autostart was either rcconf or sysv-rc-conf. So, I installed rcconf and ran it and have now stopped maradns from autostarting. However, I'm still having trouble because ether the install of maradns or something else seems to have locked down port 53 so that it shows as "in use" when any process tries to access it. As a result, I can no longer start maradns manually. All I'm trying to do is get back to where I can run the process manually and stop and restart it easily while I'm testing the darn thing. Any suggestions about how I can get back to that point would be VERY MUCH appreciated! From ruskie at codemages.net Tue Aug 5 00:55:32 2008 From: ruskie at codemages.net (=?UTF-8?B?IkFuZHJhxb4gJ3J1c2tpZScgTGV2c3RpayI=?=) Date: Tue, 05 Aug 2008 06:55:32 +0200 Subject: rcconf provided partial solution maradns process no longer starts In-Reply-To: <024101c8f6b1$9e7437c0$0200a8c0@gregsrocket> References: <024101c8f6b1$9e7437c0$0200a8c0@gregsrocket> Message-ID: On 06:13:29 2008-08-05 "Greg Platt - Platt Consultants" wrote: > I dug around and figured out that the tool I needed to stop the maradns > autostart was either rcconf or sysv-rc-conf. So, I installed rcconf and > ran it and have now stopped maradns from autostarting. However, I'm > still having trouble because ether the install of maradns or something > else seems to have locked down port 53 so that it shows as "in use" > when any process tries to access it. As a result, I can no longer start > maradns manually. > > All I'm trying to do is get back to where I can run the process > manually and stop and restart it easily while I'm testing the darn > thing. > > Any suggestions about how I can get back to that point would be VERY > MUCH appreciated! Try 'netstat -Nnlp | grep 53' and see what process is using the port and kill that one :) -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From remco at webconquest.com Tue Aug 5 01:23:59 2008 From: remco at webconquest.com (Remco Rijnders) Date: Tue, 5 Aug 2008 07:23:59 +0200 (CEST) Subject: rcconf provided partial solution maradns process no longer starts Message-ID: <5794.167.202.222.228.1217913839.squirrel@webmail.xs4all.nl> > I dug around and figured out that the tool I needed to stop the maradns > autostart was either rcconf or sysv-rc-conf. So, I installed rcconf and > ran > it and have now stopped maradns from autostarting. However, I'm still > having > trouble because ether the install of maradns or something else seems to > have > locked down port 53 so that it shows as "in use" when any process tries to > access it. As a result, I can no longer start maradns manually. > > All I'm trying to do is get back to where I can run the process manually > and > stop and restart it easily while I'm testing the darn thing. > > Any suggestions about how I can get back to that point would be VERY MUCH > appreciated! I think it is the maradns zoneserver (aptly called zoneserver) which is hanging on to port 53. You may wish to stop the zoneserver permanently as you don't need it unless you want to run a 'slave' server on another machine. You can use a command like '/etc/rc2.d/S20zoneserver stop' for that on your debian machine to stop the current running zoneserver process. Similary, on your debian box you can also issue '/etc/rc2.d/S20maradns stop' to stop maradns, or use the argument start or restart to kick mara back up again. Kind regards, Remco From strenholme.usenet at gmail.com Tue Aug 5 10:53:44 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 5 Aug 2008 09:53:44 -0500 Subject: MaraDNS now runs automatically on reboot but always times out... In-Reply-To: <020001c8f692$64797a40$0200a8c0@gregsrocket> References: <020001c8f692$64797a40$0200a8c0@gregsrocket> Message-ID: <7bd685720808050753q2c6422c3led42d395ab8c2efb@mail.gmail.com> > Since I was suddenly getting this error, I eventually discovered maradns was > now starting automatically and was already running as a resident process > (therefore, it had port 53 tied up). AFAIK, I had done nothing specific to > make the auto-start of maradns happen. It just happened. MaraDNS startup is very system-specific. MaraDNS, when one does a "make install", adds files to /etc/rc.d/init.d, and, as I recall, /etc/rc.d/rc3.d and /etc/rc.d/rc5.d. This is how RedHat and CentOS do things. However, in the tradition of doing things differently just for the sake of being different, each Linux and *BSD version has it own ways of determining how a program is started up at system boot. So, which version of *NIX are you using? Looking at the LSB, it appears that if your distribution is LSB compliant, that init scripts are in /etc/init.d [1]. So, look in /etc/init.d. If your version of *NIX doesn't have an /etc/init.d directory, well I can't help you but maybe the guys who make your Linux or *BSD distribution know what to do. - Sam [1] http://refspecs.linux-foundation.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. No, MaraDNS is not vulnerable to the "new" cache poisoning attack, and was never vulnerable. From strenholme.usenet at gmail.com Tue Aug 5 13:32:09 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 5 Aug 2008 12:32:09 -0500 Subject: FW: MaraDNS now runs automatically on reboot but always times out... In-Reply-To: <031301c8f717$cf612da0$0200a8c0@gregsrocket> References: <031301c8f717$cf612da0$0200a8c0@gregsrocket> Message-ID: <7bd685720808051032m6a4d5c80r86477c483cffe66c@mail.gmail.com> Greg, Just a reminder to send all messages to the list (I know, in Gmail, it's easy to accidentally send the mail to just me). As per my disclaimer, I am CCing this reply to the list. > Log: Root directory changed > Fatal error: Problem binding to port 53. > > System said: Cannot assign requested address OK, to see if something is on port 53, do this as root: netstat -nap | grep 53 These options are Linux-specific, and tell you which process is on a given port. To see what services^H^H^H^H^H^H^H^H daemons are started by your system, look in /etc/init.d, /etc/rc3.d (symlinks to all services started at runlevel 3) and /etc/rc5.d (runlevel 5). As an aside, does anyone here know the default runlevel for init on Debian systems? Also, make sure you have the IP Mara is asking for: ipconfig Since the error looks like one where you don't have the IP Mara is asking for. What is the value of bind_address or ipv4_bind_addresses in your mararc file? MaraDNS *should* use /etc/mararc for the default configuration file; if not look at the appropriate /etc/init.d file (probably /etc/init.d/maradns) to see how MaraDNS is started up. > Thanks for the feedback and the willingness to help, Sam. I know you're very > busy. Obviously, any further thoughts or suggestions you have would be MUCH > appreciated. I'm particularly curious now about how to create a mara error > log. If I can prove the same problem happens during boot-time startup (i.e. > mara is unable to bind port 53) then I'll know where to look next. MaraDNS, if started with duende, will log all messages with syslog(). The Duende man page has all of the ugly details: man duende MaraDNS uses standard output for all logs; duende converts this in to system logs (In /var/log as I recall on Debian systems). I'm a RedHat/CentOS guy, not a Debian guy, so my knowledge doesn't apply 100%. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From GregPlatt at ix.netcom.com Tue Aug 5 15:26:03 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Tue, 5 Aug 2008 13:26:03 -0600 Subject: FW: MaraDNS now runs automatically on reboot but always times out... In-Reply-To: <7bd685720808051032m6a4d5c80r86477c483cffe66c@mail.gmail.com> Message-ID: <03a401c8f731$1a36b430$0200a8c0@gregsrocket> Sorry about the private reply. I know how mailman works, I manage a set of lists myself. But I hit reply rather than reply-all without thinking and overlooked the implications of doing so. Believe it or not, a single request from you helped me find and fix the problem I was having in minutes. I went to lots of trouble last week to determine exactly out how to get the second IP address activated on my server so that I had two IP addresses for maradns to bind to and not just one. In the end, to achieve that, I used: ifconfig eth0 add 208.18.190.69 netmask 255.255.254.0 to activate it. What didn't dawn on me at the time was that ifconfig would completely forget about that IP address when I rebooted the system. That's exactly what happened when I rebooted yesterday after a week had gone by. Since that port was one of the two being used by maradns, it worked flawlessly until I rebooted. But after the reboot, only 1 of the IP addresses was active. So, when I went looking for what you called ipconfig I soon realized you must mean ifconfig. And when I saw that report and realized it ONLY included et0 and not eth0:0, I instantly knew I'd found the cause of my problem. Sure enough when I reactivated eth0:0, maradns started working again without problems. I guess this means I need to put that ifconfig command into my startup scripts, huh? Thanks a lot, Sam... You're a Genius, sir! :-) -----Original Message----- From: Sam Trenholme [mailto:strenholme.usenet at gmail.com] Sent: Tuesday, August 05, 2008 11:32 AM To: gregplatt at ix.netcom.com; list at maradns.org Subject: Re: FW: MaraDNS now runs automatically on reboot but always times out... Greg, Just a reminder to send all messages to the list (I know, in Gmail, it's easy to accidentally send the mail to just me). As per my disclaimer, I am CCing this reply to the list. > Log: Root directory changed > Fatal error: Problem binding to port 53. > > System said: Cannot assign requested address OK, to see if something is on port 53, do this as root: netstat -nap | grep 53 These options are Linux-specific, and tell you which process is on a given port. To see what services^H^H^H^H^H^H^H^H daemons are started by your system, look in /etc/init.d, /etc/rc3.d (symlinks to all services started at runlevel 3) and /etc/rc5.d (runlevel 5). As an aside, does anyone here know the default runlevel for init on Debian systems? Also, make sure you have the IP Mara is asking for: ipconfig Since the error looks like one where you don't have the IP Mara is asking for. What is the value of bind_address or ipv4_bind_addresses in your mararc file? MaraDNS *should* use /etc/mararc for the default configuration file; if not look at the appropriate /etc/init.d file (probably /etc/init.d/maradns) to see how MaraDNS is started up. > Thanks for the feedback and the willingness to help, Sam. I know you're very > busy. Obviously, any further thoughts or suggestions you have would be MUCH > appreciated. I'm particularly curious now about how to create a mara error > log. If I can prove the same problem happens during boot-time startup (i.e. > mara is unable to bind port 53) then I'll know where to look next. MaraDNS, if started with duende, will log all messages with syslog(). The Duende man page has all of the ugly details: man duende MaraDNS uses standard output for all logs; duende converts this in to system logs (In /var/log as I recall on Debian systems). I'm a RedHat/CentOS guy, not a Debian guy, so my knowledge doesn't apply 100%. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From GregPlatt at ix.netcom.com Tue Aug 5 15:46:34 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Tue, 5 Aug 2008 13:46:34 -0600 Subject: FW: MaraDNS now runs automatically on reboot but always times out... Message-ID: <03a601c8f733$f7df52e0$0200a8c0@gregsrocket> For the record, Sam, it was the following remark from you that turned on the light at the end of the tunnel for me... "Since the error looks like one where you don't have the IP Mara is asking for. What is the value of bind_address or ipv4_bind_addresses in your mararc file?" It hadn't dawned on me until you phrased it that way that maradns actually had TWO port 53's to deal with for the authoritative side of the server. And that it was possible that one of them was active while the other was dead. That of course, also explained why one of my test domains worked after the reboot but the other did not. For testing purposes, I had deliberately pointed each domain name to a different primary DNS server (i.e. toward a different IP address) on my server. I guess that explains why after the server reboot one test domain name continued to work but the other didn't. The registrar's primary name server record for the not-working test domain was pointing to an IP address that was no longer alive! One thing I don't understand... once the primary DNS failed due to the IP address having "gone dead", why didn't mara automatically reroute the request to the secondary DNS address and forward the request to Apache that way? Thanks again! Best, Greg -----Original Message----- From: Greg Platt - Platt Consultants [mailto:GregPlatt at ix.netcom.com] Sent: Tuesday, August 05, 2008 1:26 PM To: 'Sam Trenholme'; 'list at maradns.org' Subject: RE: FW: MaraDNS now runs automatically on reboot but always times out... Importance: High Sorry about the private reply. I know how mailman works, I manage a set of lists myself. But I hit reply rather than reply-all without thinking and overlooked the implications of doing so. Believe it or not, a single request from you helped me find and fix the problem I was having in minutes. I went to lots of trouble last week to determine exactly out how to get the second IP address activated on my server so that I had two IP addresses for maradns to bind to and not just one. In the end, to achieve that, I used: ifconfig eth0 add 208.18.190.69 netmask 255.255.254.0 to activate it. What didn't dawn on me at the time was that ifconfig would completely forget about that IP address when I rebooted the system. That's exactly what happened when I rebooted yesterday after a week had gone by. Since that port was one of the two being used by maradns, it worked flawlessly until I rebooted. But after the reboot, only 1 of the IP addresses was active. So, when I went looking for what you called ipconfig I soon realized you must mean ifconfig. And when I saw that report and realized it ONLY included et0 and not eth0:0, I instantly knew I'd found the cause of my problem. Sure enough when I reactivated eth0:0, maradns started working again without problems. I guess this means I need to put that ifconfig command into my startup scripts, huh? Thanks a lot, Sam... You're a Genius, sir! :-) -----Original Message----- From: Sam Trenholme [mailto:strenholme.usenet at gmail.com] Sent: Tuesday, August 05, 2008 11:32 AM To: gregplatt at ix.netcom.com; list at maradns.org Subject: Re: FW: MaraDNS now runs automatically on reboot but always times out... Greg, Just a reminder to send all messages to the list (I know, in Gmail, it's easy to accidentally send the mail to just me). As per my disclaimer, I am CCing this reply to the list. > Log: Root directory changed > Fatal error: Problem binding to port 53. > > System said: Cannot assign requested address OK, to see if something is on port 53, do this as root: netstat -nap | grep 53 These options are Linux-specific, and tell you which process is on a given port. To see what services^H^H^H^H^H^H^H^H daemons are started by your system, look in /etc/init.d, /etc/rc3.d (symlinks to all services started at runlevel 3) and /etc/rc5.d (runlevel 5). As an aside, does anyone here know the default runlevel for init on Debian systems? Also, make sure you have the IP Mara is asking for: ipconfig Since the error looks like one where you don't have the IP Mara is asking for. What is the value of bind_address or ipv4_bind_addresses in your mararc file? MaraDNS *should* use /etc/mararc for the default configuration file; if not look at the appropriate /etc/init.d file (probably /etc/init.d/maradns) to see how MaraDNS is started up. > Thanks for the feedback and the willingness to help, Sam. I know you're very > busy. Obviously, any further thoughts or suggestions you have would be MUCH > appreciated. I'm particularly curious now about how to create a mara error > log. If I can prove the same problem happens during boot-time startup (i.e. > mara is unable to bind port 53) then I'll know where to look next. MaraDNS, if started with duende, will log all messages with syslog(). The Duende man page has all of the ugly details: man duende MaraDNS uses standard output for all logs; duende converts this in to system logs (In /var/log as I recall on Debian systems). I'm a RedHat/CentOS guy, not a Debian guy, so my knowledge doesn't apply 100%. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From marty at supine.com Tue Aug 5 20:21:37 2008 From: marty at supine.com (Martin Barry) Date: Wed, 6 Aug 2008 10:21:37 +1000 Subject: FW: MaraDNS now runs automatically on reboot but always times out... In-Reply-To: <7bd685720808051032m6a4d5c80r86477c483cffe66c@mail.gmail.com> References: <031301c8f717$cf612da0$0200a8c0@gregsrocket> <7bd685720808051032m6a4d5c80r86477c483cffe66c@mail.gmail.com> Message-ID: <20080806002137.GA10190@sprocket.mamista.net> $quoted_author = "Sam Trenholme" ; > > To see what services^H^H^H^H^H^H^H^H daemons are started by your > system, look in /etc/init.d, /etc/rc3.d (symlinks to all services > started at runlevel 3) and /etc/rc5.d (runlevel 5). As an aside, does > anyone here know the default runlevel for init on Debian systems? It's usually runlevel 2 under Debian and it's derivatives. $ grep initdefault /etc/inittab id:2:initdefault: cheers Marty From thebesthorizon at hotmail.com Fri Aug 8 01:08:00 2008 From: thebesthorizon at hotmail.com (. .) Date: Fri, 8 Aug 2008 05:08:00 +0000 Subject: Maradns xp configuration problems Message-ID: Hello maradns users: I am new to web site / mail server hosting. This is my first attempt to setup an authoritative DNS server. I am having a problem configuring something it seems, please let me know if maradns cannot run as an authoritative dns on XP OS ? any help would be greatly appreciated. Details: Windows XP OS Unchanging IP (though not officially in the Static range) Apache running on port 44 Port 53 open in firewall (in/outbound/all the world) Maradns ok?d as exception in firewall (in/out bound/all the world) Firewalls/Routers redirecting port 53 to proper internal ip Connectivity verified AskMara Awww.google.com. (working dns server) ? seemed to work Now my problem: Assuming maradns does work on win xp as an authoritative dns??. I askmara to generate a nameserver for my domain. I use the internal ip of the computer maradns is running on as the dns server in the command line: >askmara Ndomain.com in.ter.nal.ip I get the error: #Remote server said: REFUSED Screenshots of the command line results for askmara and from running maradns.bat, as well as copies of my mararc and db files are all viewable at http://dns.jmarxonline.com Thank you for your help-david _________________________________________________________________ Your PC, mobile phone, and online services work together like never before. http://clk.atdmt.com/MRT/go/108587394/direct/01/ From pd200411vz at verizon.net Wed Aug 13 12:57:07 2008 From: pd200411vz at verizon.net (Paul Dunkley) Date: Wed, 13 Aug 2008 12:57:07 -0400 Subject: List archive url broken Message-ID: <00110646080D0C39079C001002@WINXPSTN> Tried to look at the list archive today at http://woodlane.webconquest.com/pipermail/list/ and got a; Not Found The requested URL /pipermail/list/ was not found on this server." message. Anyone know the correct url for this? From strenholme.usenet at gmail.com Wed Aug 13 13:51:18 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 13 Aug 2008 12:51:18 -0500 Subject: List archive url broken In-Reply-To: <00110646080D0C39079C001002@WINXPSTN> References: <00110646080D0C39079C001002@WINXPSTN> Message-ID: <7bd685720808131051q6c5915a1v27bbbf771f454dea@mail.gmail.com> From rick at linuxmafia.com Wed Aug 13 14:30:44 2008 From: rick at linuxmafia.com (Rick Moen) Date: Wed, 13 Aug 2008 11:30:44 -0700 Subject: List archive url broken In-Reply-To: <7bd685720808131051q6c5915a1v27bbbf771f454dea@mail.gmail.com> References: <00110646080D0C39079C001002@WINXPSTN> <7bd685720808131051q6c5915a1v27bbbf771f454dea@mail.gmail.com> Message-ID: <20080813183043.GB7564@linuxmafia.com> Quoting Sam Trenholme (strenholme.usenet at gmail.com): > >From the MaraDNS home page: > > http://marc.info/?l=maradns-list Sam, FYI, during the process of subscribing, one ends up at the Mailman listinfo page, http://woodlane.webconquest.com/cgi-bin/mailman/listinfo/list , which has a broken "list Archives" hyperlink (going to a missing pipermail archive). You might want to edit that via the Mailman administrative interface[1], to point to the marc.info archive. Also, headers include this pointer directly to the missing pipermail stuff: List-Archive: The Mailman admin interface permits disabling that group of headers if you wish[2], but custom-editing the headers' contents probably requires hacking of Mailman internals, it appears. (HTH.) [1] Entry point should be: http://woodlane.webconquest.com/cgi-bin/mailman/edithtml/list/listinfo.html [2] Entry point should be: http://woodlane.webconquest.com/cgi-bin/mailman/admin/list/general From remco at webconquest.com Wed Aug 13 14:58:08 2008 From: remco at webconquest.com (Remco Rijnders) Date: Wed, 13 Aug 2008 20:58:08 +0200 Subject: List archive url broken In-Reply-To: <20080813183043.GB7564@linuxmafia.com> References: <00110646080D0C39079C001002@WINXPSTN> <7bd685720808131051q6c5915a1v27bbbf771f454dea@mail.gmail.com> <20080813183043.GB7564@linuxmafia.com> Message-ID: <56DBFE1C-F082-4AE1-96AB-9698F06D73FB@webconquest.com> > >>> From the MaraDNS home page: >> >> http://marc.info/?l=maradns-list > > Sam, FYI, during the process of subscribing, one ends up at the > Mailman > listinfo page, > http://woodlane.webconquest.com/cgi-bin/mailman/listinfo/list , which > has a broken "list Archives" hyperlink (going to a missing pipermail > archive). You might want to edit that via the Mailman administrative > interface[1], to point to the marc.info archive. > > Also, headers include this pointer directly to the missing pipermail > stuff: > List-Archive: > > > [1] Entry point should be: > http://woodlane.webconquest.com/cgi-bin/mailman/edithtml/list/listinfo.html Hi Rick, Paul, Sam, all, Thanks for noticing and the constructive feedback. I've edited the apache configuration file and the archives should now be visible and accessible at the indicated URL. Kind regards, Remco From strenholme.usenet at gmail.com Wed Aug 13 15:10:06 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 13 Aug 2008 14:10:06 -0500 Subject: List archive url broken In-Reply-To: <56DBFE1C-F082-4AE1-96AB-9698F06D73FB@webconquest.com> References: <00110646080D0C39079C001002@WINXPSTN> <7bd685720808131051q6c5915a1v27bbbf771f454dea@mail.gmail.com> <20080813183043.GB7564@linuxmafia.com> <56DBFE1C-F082-4AE1-96AB-9698F06D73FB@webconquest.com> Message-ID: <7bd685720808131210j695abf4fjb154b5fc995fbe8f@mail.gmail.com> Rick: Thank you for the kind mail; I am sorry I never replied to it. Remco: Thank you for the donation to MaraDNS. I did not ever accept this donation (it would seem, with PayPal, you have to hit "accept" to get a donation), so if you were charged, complain very loudly to PayPal. I am in the process of verifying my PayPal account so I can get donations. And, since you host MaraDNS.org, I won't accept donations from you. Also, thanks for fixing the list archive. I will update the link on MaraDNS.org if I can this afternoon. I would like to thank the people who are supporting MaraDNS, and I may even get some work on Deadwood done. Such as maybe having more checks on truncated replies. - Sam From strenholme.usenet at gmail.com Wed Aug 13 15:38:20 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 13 Aug 2008 14:38:20 -0500 Subject: List archive url broken In-Reply-To: <7bd685720808131210j695abf4fjb154b5fc995fbe8f@mail.gmail.com> References: <00110646080D0C39079C001002@WINXPSTN> <7bd685720808131051q6c5915a1v27bbbf771f454dea@mail.gmail.com> <20080813183043.GB7564@linuxmafia.com> <56DBFE1C-F082-4AE1-96AB-9698F06D73FB@webconquest.com> <7bd685720808131210j695abf4fjb154b5fc995fbe8f@mail.gmail.com> Message-ID: <7bd685720808131238x51be694aydfbfef5595d852c3@mail.gmail.com> > I am in the process of verifying my PayPal account so I can > get donations. It is done, and I have accepted my first MaraDNS donation from Chicago. Thanks a lot for the MaraDNS support! - Sam (grouchy MaraDNS developer) From GregPlatt at ix.netcom.com Mon Aug 18 02:30:19 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 18 Aug 2008 00:30:19 -0600 Subject: Not sure what broke Mara... Message-ID: <01e801c900fb$e3ba04a0$0200a8c0@gregsrocket> Early this afternoon I finished a reinstall of Maradns on my production server. Using my notes from my first test server build, I'm now in the process of building my production server from scratch. I'm running the latest Debian release on a stable etch 4.0r3 system and brand new server hardware. I completed the install of the second IP address and tested to confirm it was activated. Then I recreated the maradns' config files and tested to confirm they loaded with no problems. Once they were working fine, I started the server and confirmed that maradns was running. Everything looked perfect. I was able to reach both of the 2 production sites I'm testing with without problems. My next step was to use the test sites to get my CGI scripts working so, having finished with mara (or so I naively thought!) I went on to work on getting the CGI scripts to run in the two test sites as well. I got the CGI process working without problems. And I rebooted the server to confirm that all my changes still worked. I was shocked to find that one of my 2 test sites came up fine but the other did not. IN fact, I can't even PING the site. It's as if mara was completely refusing to reply to requests for it. To try to figure out what had happened, I restarted mara manually again and discovered that it is now throwing "fatal errors on line 26" message for all 3 sites my name server site and the 2 test sites). When running in stand alone mode. This worked this afternoon. I KNOW it did. I didn't even TRY to run mara in resident mode until it had started without errors in stand alone mode. Here's what I see from the ifconfig. [code]eth1 Link encap:Ethernet HWaddr 00:1F:C6:76:C1:A2 inet addr:208.19.190.68 Bcast:208.19.191.255 Mask:255.255.254.0 inet6 addr: fe80::21f:c6ff:fe76:c1a2/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1411 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:1 collisions:0 txqueuelen:1000 RX bytes:145501 (142.0 KiB) TX bytes:0 (0.0 b) Memory:febc0000-fec00000 eth1:0 Link encap:Ethernet HWaddr 00:1F:C6:76:C1:A2 inet addr:208.19.190.69 Bcast:208.19.191.255 Mask:255.255.254.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Memory:febc0000-fec00000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:13 errors:0 dropped:0 overruns:0 frame:0 TX packets:13 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:975 (975.0 b) TX bytes:975 (975.0 b)[/code] It tells me both IP addresses are active. Here's what I see when I reboot the server. Maradns seems to be running in resident mode [code]myserver:~# ps aux |grep mara nobody 2342 0.0 0.0 3944 724 ? S 23:04 0:00 /usr/sbin/maradns -f /etc/maradns/mararc root 2343 0.0 0.0 2640 532 ? S 23:04 0:00 logger -p daemon.notice -t maradns.etc_maradns_mararc root 2763 0.0 0.0 3936 692 pts/0 D+ 23:06 0:00 grep mara[/code] But HERE is what I see when I run mara from the command prompt [code]myserver:/etc/maradns# maradns Using default ICANN root servers Log: Root directory changed Log: Binding to address 208.19.190.68, 208.19.190.69 Log: Socket opened on UDP port 53 Log: Root privileges dropped Warning: Fatal error in zone file testsite2.com. (aborting this zone file) on line 26 Warning: Fatal error in zone file testsite1.com. (aborting this zone file) on line 26 Warning: Fatal error in zone file myhost.com. (aborting this zone file) on line 26 Log: All RRs have been loaded[/code] These errors were NOT showing up this afternoon. I swear they were not. I didn't even TRY to put mara into resident mode until all the errors at this level had been eliminated. Here is one of the zone files involved this is the site that DOES still work despite the "fatal error" reported # This is an example zone file for the imaginary domain example.com. # To adapt this file to another zone, we need to make the following changes: # Substitute the name example.com with the name of the domain one wishes to # administer. # Substitute the IP 10.10.10.12 with the IP of the machine running the web # server for the domain. # Substitute the IP 10.10.10.15 with the IP of the machine running the mail # server for the domain. # Note that the chroot_dir mararc variable tells MaraDNS which directory # contains domain zone files. # example.com. NS ns1.example.com. # ns1.example.com. 10.10.10.19 # example.com. 10.10.10.19 # www.example.com. 10.10.10.19 # example.com. MX 10 mail1.example.com. # mail1.example.com. 10.10.10.19 # First we must define the name server for the domain and the name server's # address # example.com. NS ns1.example.com. # ns1.example.com. 10.10.10.19 testsite2.com. NS ns1.myhost.com. <--- Note: this is LINE 26! testsite2.com. NS ns2.myhost.com. ns1.myhost.com. 208.19.190.68 ns2.myhost.com. 208.19.190.69 # We have two records which handle the serving of web pages. These # are simple name-to-ip translations. In other words, we have one # record which states "The IP for example.com. is 10.10.10.12" and # another that states "The IP for www.example.com. is 10.10.10.12" # example.com. 10.10.10.12 # www.example.com. 10.10.10.12 testsite2.com. 208.19.190.68 www.testsite2.com. 208.19.190.68 testsite2.com. 208.19.190.69 www.testsite2.com. 208.19.190.69 # We also need to set up an IP for the machine that serves email for # example.com. Because of how DNS is designed, we both need[/code] Yet, DESPITE the reported fatal errors the test site referenced in THIS file comes up and displays on the web just fine. While the other test site which I ran and tested with for 3 full hours now fails to respond to ping and does not come up on the web at all. delivering what amounts to a 404 error everytime I try to access it. So what the heck is WRONG here? Can somebody give me a clue please? I'm totally baffled. And at the moment it's after midnight so I'm gonna go crash and hope that mara has healed itself in the morning. Thanks! From contato at kurtkraut.net Thu Aug 21 22:41:13 2008 From: contato at kurtkraut.net (Kurt Kraut) Date: Thu, 21 Aug 2008 23:41:13 -0300 Subject: Different DNS replies depending on IP block Message-ID: <26c783fe0808211941t6dc5b3bcy163ce6635666c098@mail.gmail.com> Hi, I own a service that has mirrors all around the world. I'd like to MaraDNS to respond a DNS request of my A ADDRESSes differently, depending on the IP block that made the request For instance, from a computer from an ISP provider would have this: [root at computer1 etc]# host www.maradns.org www.maradns.org has address 209.172.32.214 And another person from another ISP would have: [root at computer2 etc]# host www.maradns.org www.maradns.org has address 74.125.45.83 Anyone has a clue how I could do that ? Thanks in advance From KenL at GraphixWizard.com Fri Aug 22 06:27:59 2008 From: KenL at GraphixWizard.com (Ken Lyons - Graphix Wizard/Data-Forms) Date: Fri, 22 Aug 2008 06:27:59 -0400 Subject: Different DNS replies depending on IP block In-Reply-To: <2008-234-22-4-1219372883-026887@gwizfl.org> References: <2008-234-22-4-1219372883-026887@gwizfl.org> Message-ID: <2008-235-06-2-1219400887-018976@gwizfl.org> I'm not an expert on Mara, but have been using on several clusters for many years. As far as I know, what your asking is not built-in to mara. To achieve your goal, the only work-around I could do is... Run several MARA servers on the same system, each bound to a different port. Using IPtables setup rules based on the Source Address. so port 53 (ips 11.x.x.x/8 - 99.x.x.x/8) forward to maraserver 1 at port 1001 so port 53 (ips 100.x.x.x/8 - 199.x.x.x/8) forward to maraserver 2 at port 1002 so port 53 (ips 200.x.x.x/8 - 254.x.x.x/8) forward to maraserver 3 at port 1003 so, to the client you have a single IP... but using IPTABLES / your firewall, you can control which dns server responds, each having a different answer. I don't know if this is the 'Best' way to do it, but that is what I would do to achieve your goal. I'm sure someone else on the list might have other ideas. Ken Lyons Kurt Kraut wrote: > Hi, > > I own a service that has mirrors all around the world. I'd like to > MaraDNS to respond a DNS request of my A ADDRESSes differently, > depending on the IP block that made the request > > For instance, from a computer from an ISP provider would have this: > > [root at computer1 etc]# host www.maradns.org > www.maradns.org has address 209.172.32.214 > > And another person from another ISP would have: > > [root at computer2 etc]# host www.maradns.org > www.maradns.org has address 74.125.45.83 > > Anyone has a clue how I could do that ? Thanks in advance > > > > From lew.payne at gmail.com Fri Aug 22 14:14:09 2008 From: lew.payne at gmail.com (Lew Payne) Date: Fri, 22 Aug 2008 12:14:09 -0600 Subject: Different DNS replies depending on IP block In-Reply-To: <26c783fe0808211941t6dc5b3bcy163ce6635666c098@mail.gmail.com> References: <26c783fe0808211941t6dc5b3bcy163ce6635666c098@mail.gmail.com> Message-ID: I would suggest using the right tool for the right job, if possible. If your needs are such that you want to geographically route traffic by issuing different DNS responses (on the Internet as opposed to some intra-net), then the organization is likely to be sophisticated enough to own or at least have (SWIP) their own IP block. If that's the case, use the right tool for the job... anycast from your zone routers. Google is your friend (hint: anycast DNS). > I own a service that has mirrors all around the world. I'd like to > MaraDNS to respond a DNS request of my A ADDRESSes > differently, depending on the IP block that made the request > > For instance, from a computer from an ISP provider would have this: > > [root at computer1 etc]# host www.maradns.org > www.maradns.org has address 209.172.32.214 > > And another person from another ISP would have: > > [root at computer2 etc]# host www.maradns.org > www.maradns.org has address 74.125.45.83 > > Anyone has a clue how I could do that ? Thanks in advance > From rick at linuxmafia.com Fri Aug 22 15:50:09 2008 From: rick at linuxmafia.com (Rick Moen) Date: Fri, 22 Aug 2008 12:50:09 -0700 Subject: FYI: Slightly rough MaraDNS default installation on Ubuntu Message-ID: <20080822195009.GA5031@linuxmafia.com> MaraDNS keeps coming up in _Linux Gazette_ magazine's efforts to stay on top of the Kaminsky affair and its ramifications for Linux users. I'm one of the _Gazette's_ editors; Ben Okopnik (cited below) is editor in chief. I kept telling Ben that running a reliable local recursive-resolver nameserver should be essential to all small networks including his, and that setting one up is dead-simple. Right at publication deadline for the August issue, Ben disagreed. The below-cited, hurried e-mail exchange followed, where I test-installed each of MaraDNS, BIND9, and PowerDNS Recursor on an Ubuntu workstation. Ubuntu have not yet acted on the bug I filed for their MaraDNS package (but at lest they didn't close it ;-> ). In case anyone's interested, herewith, my page of rundowns on DNS-related software for Linux: "DNS Servers" on http://linuxmafia.com/kb/Network_Other/ ----- Forwarded message from Rick Moen ----- Date: Sun, 3 Aug 2008 18:31:21 -0700 From: Rick Moen To: Ben Okopnik Subject: MaraDNS default installation (was: pdnsd) Quoting Ben Okopnik (ben at linuxmafia.com): > Rick, I've been researching and experimenting, and that statement of "no > muss, no fuss, no greasy aftertaste" for DNS RR server installation may > have been a bit too optimistic. BIND9, MaraDNS, and PowerDNS all fail > the "turnkey" test; Again, this is a from-scratch package install on Ubuntu Gutsy Gibbon: ~$ sudo apt-get install maradns Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: maradns 0 upgraded, 1 newly installed, 0 to remove and 254 not upgraded. Need to get 479kB of archives. After unpacking 1139kB of additional disk space will be used. [snip package fetch] Fetched 479kB in 0s (9016kB/s) Selecting previously deselected package maradns. (Reading database ... 135280 files and directories currently installed.) Unpacking maradns (from .../maradns_1.2.12.08-1_i386.deb) ... Setting up maradns (1.2.12.08-1) ... creating MaraDNS system user... adduser: Warning: that home directory does not belong to the user you are currently creating. Starting maradns: maradns. Starting zoneserver: No zone ACL's configured for /etc/maradns/mararc -- not starting zoneserver for it. zoneserver. I belive you gave up upon seeing that message about zoneserver ACLs, but ironically _that_ was OK. That merely meant that MaraDNS wasn't going to be able to do authoritative service -- which we don't _want_ it to. However, there were other problems: First, find out the homedir MaraDNS user, since we'll need it later: ~$ grep maradns /etc/passwd maradns:x:113:123::/etc/maradns:/bin/false And what's the ownership of the conffile directory? $ ls -l /etc/maradns/ total 12 -rw-r--r-- 1 root root 10311 2007-09-19 03:11 mararc Last, is the recursive-resolver daemon _working_? $ dig linuxmafia.com @localhost +short ;; connection timed out; no servers could be reached $ So, oops, the recursive service simply doesn't work, out of the box. We then have to find out why, and fix it: /var/log/daemon.log includes: Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: POSSIBILITY OF SUCH DAMAGE. Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: To not display this message, add the follwing to your mararc file: Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: hide_disclaimer = "YES" Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Root directory changed Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Binding to address 127.0.0.3 Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Socket opened on UDP port 53 Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Root privileges dropped Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: All RRs have been loaded ~$ dig linuxmafia.com @127.0.0.3 +short ;; connection timed out; no servers could be reached (My recollection was that all IP addresses in the loopback network were interchangeable, but I just wanted to make sure.) /usr/share/doc/maradns/README.Debian starts out with: maradns for Debian ------------------ This version of MaraDNS works as authoritative or/and recursive server. Below are guides to two typical setups: Recursive: ---------- Usually good enough to: sudo cp /usr/share/doc/maradns/en/examples/example_recursive_mararc.txt /etc/maradns/mararc BUT please use the uid and gid of the default mararc. Look up the maradns uid and gid with `id`. You might want to throw in: hide_disclaimer = "YES" And use icann root servers instead. [...] ~$ id maradns uid=113(maradns) gid=123(maradns) groups=123(maradns) (Actually, we already knew that from when I looked up that user's homedir.) After following the above ("sudo cp") advice, including making sure the following lines were in /etc/maradns/mararc: # The numeric UID MaraDNS will run as maradns_uid = 123 # Recursive ACL: Who is allowd to perform recursive queries. recursive_acl = "127.0.0.0/8" hide_disclaimer = "YES" I did: $ sudo /etc/init.d/maradns start Starting maradns: maradns. $ dig linuxmafia.com @localhost +short 198.144.195.186 Yay, works as intended. (It was not necessary to give the maradns user or group ownership over /etc/maradns/ .) So, indeed it wasn't _quite_ turnkey, and could use a bit of improvement from the package maintainer to optimise for the most common case. The package maintainer might have two objections, if I were to so suggest: 1. "The target audience can take care of such things, because the target audience are sysadmins." Which is where we get the chicken-and-egg problem of regular users never running their own caching nameservers because it's too difficult, and package maintainers never bothering to remove the difficulty because regular users don't use the software. 2. "The MaraDNS package includes two separate daemon processes, the recursiver-resolver daemon and the zoneserver, with separate configuration needs. Some people will need one function but not the other; some will need both. So, there's no such thing as an optimised configuration for the most common case." There would be some justice to that -- but I frankly don't think it'd be difficult to ask the user a few questions, construct a mararc file to suit, and only _then_ start the daemon(s). Not surprisingly, there is not yet an Ubuntu package for "Unbound" -- at least, not in Gutsy Gibbon. (In fact, it appears to be present only in the Intrepid Ibis beta.) That leaves only PowerDNS Recursor and dnscache (from djbdns). Gutsy Gibbon has package "djbdns-installer - Source only package for building djbdns" (reflecting the pre-"public domain" status of the djbdns 1.06 source code at the time the package was put together). To my surprise, there's a pdns-recursor package: Description: PowerDNS recursor PowerDNS is a versatile nameserver which supports a large number of different backends ranging from simple zonefiles to relational databases and load balancing/failover algorithms. PowerDNS tries to emphasize speed and security. . This is the recursive nameserver that goes out to the internet and resolve queries about other domains. I'll try that one, and then probably call it quits -- until the Ubuntu folks catch up with the licence change on djbdns, and re-packages it to get around a number of problems that will suddenly be fixable (if anyone still cares): I hear that among the problems with default djbdns is that it needs an immediate source-level security patch, plus you need to fetch the current named.root file from ftp.internic.net , as the one provided is out of date. And, even after that, it's my understanding that djbdns has problems resolving some domains (such as Akamai). There may or may not be suitable patches, and I can either gamely try to chase down that sort of stuff or just say to myself "Screw it. Nobody should have to go to that sort of trouble, and desktop users sure ain't going to." ----- End forwarded message ----- ----- Forwarded message from Rick Moen ----- Date: Sun, 3 Aug 2008 19:49:59 -0700 From: Rick Moen To: Ben Okopnik Subject: Re: (forw) MaraDNS default installation (was: pdnsd) Quoting Ben Okopnik (ben at linuxmafia.com): > Yes. The target _audience_ may well be sysadmins, but the _target_ is > every user. Unless things are fixed at that level - e.g., the > maintainers getting that point totally clear in their heads - we're > screwed, and Dan K's exposure of this vuln goes for nothing, except > maybe to tell the Blackhats where to look (the author of Metasploit said > that he'd have an exploit for it *that day*.) That'll be Wednesday. I recall reading, in any event, that Metasploit sprouted an attack mode for cache poisoning the same day that the German mathematician posted his blog post. > Yep. Several packages do exactly that - and in the case of an RR DNS > server, the questions would be trivial. It would be _very_ nice if you > could ask "Do you just want a caching server (STRONGLY RECOMMENDED > UNLESS YOU KNOW ENOUGH TO SAY 'NO')?" and then install 'resolvconf' if > the answer is 'yes' - but I've never seen that kind of a setup on any > package before. See, this is where I've been suggesting that the influence of BIND9 has been pernicious: It's conditioned most people to think of server-side DNS as all one big thing. (The Red Hat / Fedora / CentOS people _do_ have, as I mentioned, a specific configuration of BIND9 for just the functionality you speak of as package "caching-nameserver"). And yeah, I cannot recall having even heard of resolvconf before -- though it does ring a distant bell. Anyway, at minimum, BIND9 in its default caching mode, and (more happily) PowerDNS Recursor meet spec -- though that annoying thing that necessitates "resolvconf" does stand in the way. Too bad about the teething problems regarding (at least the Ubuntu package of) MaraDNS: It's the one offering about which I have the best feelings overall. Sam's design is really good, he does his own random number generator and string-handling library for security reasons, he has a history of not making dumb security errors, and he actively maintains it. I actually have more confidence in him than I do in the maintainers of PowerDNS -- who _have_ made a number of hideous security errors in the past. ----- End forwarded message ----- ----- Forwarded message from Rick Moen ----- Date: Tue, 5 Aug 2008 16:17:08 -0700 From: Rick Moen To: Ben Okopnik Subject: Re: (forw) Re: (forw) MaraDNS default installation (was: pdnsd) Quoting Ben Okopnik (ben at linuxmafia.com): > Ya know, I don't want to sound like a broken record, but - a patch > (perhaps consisting of a properly-configured conffile and a list of > directories, etc. that should be created) sent to the maintainer of > MaraDNS Short of that, I've just filed a bug with downstream (Ubuntu): https://bugs.launchpad.net/ubuntu/+source/maradns/+bug/255156 I'll mention that to the upstream author, and see if shameless flattery might motivate him to improve the upstream fit'n'finish. ----- End forwarded message ----- From GregPlatt at ix.netcom.com Sat Aug 23 03:01:27 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Sat, 23 Aug 2008 01:01:27 -0600 Subject: The Saga of my Mara Install ... a success story (or so I hope!) In-Reply-To: <19317.167.202.222.228.1219303190.squirrel@webmail.xs4all.nl> Message-ID: <053e01c904ee$10fc2f60$0200a8c0@gregsrocket> Hi again, Remco (and other mara users too). I appreciated your reply to my Wednesday night inquiry. I was certainly feeling naked, alone and lonely out here on the American Frontier with hostile Apaches around and no word from folks back at the "Mara Fort" at all. Frankly knowing there was someone there who at least cared was enough to give me the courage to tackle my install problems on my own and fix almost all of them with lots of help from my friends on the Debian Forums site (http://forums.debian.net) On Thursday after receiving your note, I gave up on waiting for advice from the mara list and instead decided to dive straight into the lions' den armed with nothing but a wooden sword and a rubber machete. Fortunately, the lions had no idea that I was incapable of injuring a fly and were so shocked to see me jump straight into their midst making so much noise, that they basically turned and ran in all directions! :-) I began by discarding my existing mara configuration and I rebuilt everything from scratch beginning with the installation of the second IP address on my dedicated server, continuing on to the registrar for my DNS domain, then tackling a rebuild of mararc and moving on to setup the mara zone files. I even adjusted the configuration of my Apache VirtualHosts to correctly handle what mara provides. When I encountered a problem, I analyzed and did battle with it until I managed to make it work the way I understood it should. In doing that, I gradually isolated and eliminated the causes of all the problems I'd been having with the old setup and was able to focus on each issue until I conquered it. As a result, it appears I now have a stable mara install that works right for all of my test domains and consistently delivers the visitor to the right web site every time thus producing the results I was expecting in the beginning. Frankly, the errors I had made during my second attempt at DNS server installation and setup were widespread and based on my misunderstandings. They began with the definition of the DNS server at my domain registrar and continued through the mararc and zone file setups. They also involved the setup of virtual hosts in Apache as well. To be honest, the intricate and complex interplay between the Domain Registrar and the Domain Name Server software and the Web Server hardware and Apache server itself are complicated and confusing to sort out on your first or second trip through the forest... especially when you have no guide and no map to follow as you begin the journey. Although I'm generally pretty good at figuring this stuff out, I had a tough time sorting it in my head with no one around to talk to who understood the process and the issues involved even as half well as I did. But in the end, I did solve most of the problems and mara does seem to be working now. The only thing I can't figure out is why I can't SEE maraDNS running among the tasks on my server. I know it IS running, because I can SEE the results, but when I try to SEE the task running using ps aux|grep mara it doesn't show up in the list of active tasks on my Debian Etch 4.0r3 system. The troubling part of this is that sometimes mara starts as it's expected to and at other times it either does NOT do so or it stalls at some point after it started successfully. If you can shed any light on this issue, I would certainly appreciate your advice on what to do about it. Other than that, everything does now seem to be working as it should be. In the immortal words of General Custer, "How much trouble can a few Indians possibly cause?" Thanks again for your help and feedback, Remco. You have NO idea how much they helped! Best Professional Regards, WebSissy -----Original Message----- From: Remco Rijnders [mailto:remco at webconquest.com] Sent: Thursday, August 21, 2008 1:20 AM To: gregplatt at ix.netcom.com Subject: Re: Need some Mara insights please. Hi Greg, You do not need to worry. I don't think you've done anything wrong or said anything that would rub people the wrong way. I'm sorry for not having responded to your enquiry yet, but work has been busy and to be frank, I simply didn't know the answer to your question or didn't have an idea on what it could be. In the past year or so, Sam wanted support mail not to be sent to the list, but when he got a burn out recently, he decided that he did want all support mail to go to the list. No payment or donation is necessary in order to receive an answer from Sam, but he too is limited in the time he has available. I think we still have to work a bit on making the list feel more of a community than it currently is so others may feel more willing to chip in their two cents worth. Other than me and Sam, I don't think too many people are active with answering questions unless they happen to know the answer from the top of their head. Would it be ok if I get back to you over the weekend to see what we can find out? Please note that only one mail you sent to the list on monday made it through; I don't think the second one did, but I'm not sure why; What I do know though that it is nothing personal. Did you receive any sort of bounce mail? Maybe you had an attachment that caused the mail to be dropped, or perhaps you sent from a different address? I can have a look at the mailserver logs to see what went wrong, but that too I won't get to today. Kind regards, Remco From kenl at graphixwizard.com Sat Aug 23 21:32:32 2008 From: kenl at graphixwizard.com (Ken Lyons) Date: Sat, 23 Aug 2008 21:32:32 -0400 Subject: FYI: Slightly rough MaraDNS default installation on Ubuntu In-Reply-To: <2008-235-15-5-1219434636-009524@gwizfl.org> References: <2008-235-15-5-1219434636-009524@gwizfl.org> Message-ID: <2008-236-21-3-1219541589-019703@gwizfl.org> I have used Ubuntu for production machines for 2 years now, we started on RH 5.2, moved to Gentoo then to Ubuntu 6.06 lts, so far Ubuntu has been the best for us. One issue that we had, like many admins, is that apt-get, a great tool, doesn't always have the most recent versions of software. Both MaraDNS and ClamAV have always seemed to be behind... which is why we just install thoses from the source downloads. If you download an OLD version apt-get, your going to have many problems that have already been fixed in newwer versions. --we had this same issue with Gentoo, but support for Ubuntu seems to be much better overall. Ken Lyons -- from a medium ISP in Orlando Rick Moen wrote: > MaraDNS keeps coming up in _Linux Gazette_ magazine's efforts to stay on > top of the Kaminsky affair and its ramifications for Linux users. I'm > one of the _Gazette's_ editors; Ben Okopnik (cited below) is editor in > chief. I kept telling Ben that running a reliable local > recursive-resolver nameserver should be essential to all small networks > including his, and that setting one up is dead-simple. Right at > publication deadline for the August issue, Ben disagreed. The > below-cited, hurried e-mail exchange followed, where I test-installed > each of MaraDNS, BIND9, and PowerDNS Recursor on an Ubuntu workstation. > > Ubuntu have not yet acted on the bug I filed for their MaraDNS package > (but at lest they didn't close it ;-> ). > > In case anyone's interested, herewith, my page of rundowns on > DNS-related software for Linux: > "DNS Servers" on http://linuxmafia.com/kb/Network_Other/ > > > ----- Forwarded message from Rick Moen ----- > > Date: Sun, 3 Aug 2008 18:31:21 -0700 > From: Rick Moen > To: Ben Okopnik > Subject: MaraDNS default installation (was: pdnsd) > > Quoting Ben Okopnik (ben at linuxmafia.com): > > >> Rick, I've been researching and experimenting, and that statement of "no >> muss, no fuss, no greasy aftertaste" for DNS RR server installation may >> have been a bit too optimistic. BIND9, MaraDNS, and PowerDNS all fail >> the "turnkey" test; >> > > > Again, this is a from-scratch package install on Ubuntu Gutsy Gibbon: > > ~$ sudo apt-get install maradns > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following NEW packages will be installed: > maradns > 0 upgraded, 1 newly installed, 0 to remove and 254 not upgraded. > Need to get 479kB of archives. > After unpacking 1139kB of additional disk space will be used. > > [snip package fetch] > > Fetched 479kB in 0s (9016kB/s) > Selecting previously deselected package maradns. > (Reading database ... 135280 files and directories currently installed.) > Unpacking maradns (from .../maradns_1.2.12.08-1_i386.deb) ... > Setting up maradns (1.2.12.08-1) ... > creating MaraDNS system user... > adduser: Warning: that home directory does not belong to the user you > are currently creating. > Starting maradns: maradns. > Starting zoneserver: No zone ACL's configured for /etc/maradns/mararc -- > not starting zoneserver for it. > zoneserver. > > > I belive you gave up upon seeing that message about zoneserver ACLs, but > ironically _that_ was OK. That merely meant that MaraDNS wasn't going > to be able to do authoritative service -- which we don't _want_ it to. > However, there were other problems: > > > First, find out the homedir MaraDNS user, since we'll need it later: > > ~$ grep maradns /etc/passwd > maradns:x:113:123::/etc/maradns:/bin/false > > And what's the ownership of the conffile directory? > > $ ls -l /etc/maradns/ > total 12 > -rw-r--r-- 1 root root 10311 2007-09-19 03:11 mararc > > > Last, is the recursive-resolver daemon _working_? > > $ dig linuxmafia.com @localhost +short > ;; connection timed out; no servers could be reached > $ > > > So, oops, the recursive service simply doesn't work, out of the box. > We then have to find out why, and fix it: > > > /var/log/daemon.log includes: > > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: POSSIBILITY OF SUCH DAMAGE. > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: To not display this message, add the follwing to your mararc file: > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: hide_disclaimer = "YES" > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Root directory changed > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Binding to address 127.0.0.3 > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Socket opened on UDP port 53 > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: Root privileges dropped > Aug 3 17:28:44 WFF593 maradns.etc_maradns_mararc: Log: All RRs have been loaded > > > ~$ dig linuxmafia.com @127.0.0.3 +short > ;; connection timed out; no servers could be reached > > (My recollection was that all IP addresses in the loopback network were > interchangeable, but I just wanted to make sure.) > > > /usr/share/doc/maradns/README.Debian starts out with: > > maradns for Debian > ------------------ > > This version of MaraDNS works as authoritative or/and recursive server. > > Below are guides to two typical setups: > > Recursive: > ---------- > > Usually good enough to: > sudo cp /usr/share/doc/maradns/en/examples/example_recursive_mararc.txt /etc/maradns/mararc > > BUT please use the uid and gid of the default mararc. Look up the > maradns uid and gid with `id`. > > You might want to throw in: > hide_disclaimer = "YES" > And use icann root servers instead. > [...] > > > > ~$ id maradns > uid=113(maradns) gid=123(maradns) groups=123(maradns) > > (Actually, we already knew that from when I looked up that user's > homedir.) > > > After following the above ("sudo cp") advice, including making sure the > following lines were in /etc/maradns/mararc: > > # The numeric UID MaraDNS will run as > maradns_uid = 123 > # Recursive ACL: Who is allowd to perform recursive queries. > recursive_acl = "127.0.0.0/8" > hide_disclaimer = "YES" > > > I did: > > $ sudo /etc/init.d/maradns start > Starting maradns: maradns. > > > $ dig linuxmafia.com @localhost +short > 198.144.195.186 > > > Yay, works as intended. > > > (It was not necessary to give the maradns user or group ownership over > /etc/maradns/ .) > > So, indeed it wasn't _quite_ turnkey, and could use a bit of improvement > from the package maintainer to optimise for the most common case. The > package maintainer might have two objections, if I were to so suggest: > > 1. "The target audience can take care of such things, because the target > audience are sysadmins." Which is where we get the chicken-and-egg > problem of regular users never running their own caching nameservers > because it's too difficult, and package maintainers never bothering to > remove the difficulty because regular users don't use the software. > > 2. "The MaraDNS package includes two separate daemon processes, the > recursiver-resolver daemon and the zoneserver, with separate > configuration needs. Some people will need one function but not the > other; some will need both. So, there's no such thing as an optimised > configuration for the most common case." > > There would be some justice to that -- but I frankly don't think it'd be > difficult to ask the user a few questions, construct a mararc file to > suit, and only _then_ start the daemon(s). > > > > Not surprisingly, there is not yet an Ubuntu package for "Unbound" -- at > least, not in Gutsy Gibbon. (In fact, it appears to be present only in > the Intrepid Ibis beta.) > > > That leaves only PowerDNS Recursor and dnscache (from djbdns). Gutsy > Gibbon has package "djbdns-installer - Source only package for building > djbdns" (reflecting the pre-"public domain" status of the djbdns 1.06 > source code at the time the package was put together). > > To my surprise, there's a pdns-recursor package: > > Description: PowerDNS recursor > PowerDNS is a versatile nameserver which supports a large number > of different backends ranging from simple zonefiles to relational > databases and load balancing/failover algorithms. > PowerDNS tries to emphasize speed and security. > . > This is the recursive nameserver that goes out to the internet and > resolve queries about other domains. > > > I'll try that one, and then probably call it quits -- until the Ubuntu > folks catch up with the licence change on djbdns, and re-packages it to > get around a number of problems that will suddenly be fixable (if anyone > still cares): I hear that among the problems with default djbdns is > that it needs an immediate source-level security patch, plus you need to > fetch the current named.root file from ftp.internic.net , as the one > provided is out of date. > > And, even after that, it's my understanding that djbdns has problems > resolving some domains (such as Akamai). There may or may not be > suitable patches, and I can either gamely try to chase down that sort of > stuff or just say to myself "Screw it. Nobody should have to go to that > sort of trouble, and desktop users sure ain't going to." > > > ----- End forwarded message ----- > ----- Forwarded message from Rick Moen ----- > > Date: Sun, 3 Aug 2008 19:49:59 -0700 > From: Rick Moen > To: Ben Okopnik > Subject: Re: (forw) MaraDNS default installation (was: pdnsd) > > Quoting Ben Okopnik (ben at linuxmafia.com): > > >> Yes. The target _audience_ may well be sysadmins, but the _target_ is >> every user. Unless things are fixed at that level - e.g., the >> maintainers getting that point totally clear in their heads - we're >> screwed, and Dan K's exposure of this vuln goes for nothing, except >> maybe to tell the Blackhats where to look (the author of Metasploit said >> that he'd have an exploit for it *that day*.) >> > > That'll be Wednesday. I recall reading, in any event, that Metasploit > sprouted an attack mode for cache poisoning the same day that the German > mathematician posted his blog post. > > >> Yep. Several packages do exactly that - and in the case of an RR DNS >> server, the questions would be trivial. It would be _very_ nice if you >> could ask "Do you just want a caching server (STRONGLY RECOMMENDED >> UNLESS YOU KNOW ENOUGH TO SAY 'NO')?" and then install 'resolvconf' if >> the answer is 'yes' - but I've never seen that kind of a setup on any >> package before. >> > > See, this is where I've been suggesting that the influence of BIND9 has > been pernicious: It's conditioned most people to think of server-side > DNS as all one big thing. (The Red Hat / Fedora / CentOS people _do_ > have, as I mentioned, a specific configuration of BIND9 for just the > functionality you speak of as package "caching-nameserver"). > > And yeah, I cannot recall having even heard of resolvconf before -- > though it does ring a distant bell. > > > Anyway, at minimum, BIND9 in its default caching mode, and (more > happily) PowerDNS Recursor meet spec -- though that annoying thing that > necessitates "resolvconf" does stand in the way. > > Too bad about the teething problems regarding (at least the Ubuntu > package of) MaraDNS: It's the one offering about which I have the > best feelings overall. Sam's design is really good, he does his own > random number generator and string-handling library for security > reasons, he has a history of not making dumb security errors, and he > actively maintains it. I actually have more confidence in him than I do > in the maintainers of PowerDNS -- who _have_ made a number of hideous > security errors in the past. > > > ----- End forwarded message ----- > ----- Forwarded message from Rick Moen ----- > Date: Tue, 5 Aug 2008 16:17:08 -0700 > From: Rick Moen > To: Ben Okopnik > Subject: Re: (forw) Re: (forw) MaraDNS default installation (was: pdnsd) > > Quoting Ben Okopnik (ben at linuxmafia.com): > > >> Ya know, I don't want to sound like a broken record, but - a patch >> (perhaps consisting of a properly-configured conffile and a list of >> directories, etc. that should be created) sent to the maintainer of >> MaraDNS >> > > Short of that, I've just filed a bug with downstream (Ubuntu): > https://bugs.launchpad.net/ubuntu/+source/maradns/+bug/255156 > > I'll mention that to the upstream author, and see if shameless flattery > might motivate him to improve the upstream fit'n'finish. > > ----- End forwarded message ----- > > > > From dr at kyx.net Sat Aug 23 21:40:37 2008 From: dr at kyx.net (Dragos Ruiu) Date: Sat, 23 Aug 2008 18:40:37 -0700 Subject: The Saga of my Mara Install ... a success story (or so I hope!) In-Reply-To: <053e01c904ee$10fc2f60$0200a8c0@gregsrocket> References: <053e01c904ee$10fc2f60$0200a8c0@gregsrocket> Message-ID: <7E8A202D-BA54-41E5-B611-23AEDE2338D4@kyx.net> On 23-Aug-08, at 12:01 AM, Greg Platt - Platt Consultants wrote: > In the past year or so, Sam wanted support mail not to be sent to the > list, but when he got a burn out recently, he decided that he did > want all > support mail to go to the list. No payment or donation is necessary in > order to receive an answer from Sam, but he too is limited in the > time he > has available. I think we still have to work a bit on making the > list feel > more of a community than it currently is so others may feel more > willing > to chip in their two cents worth. Other than me and Sam, I don't > think too > many people are active with answering questions unless they happen > to know > the answer from the top of their head. The nice thing about answering support mail on the list is that it's archived places and others can learn from the answers... cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Buenos Aires, Argentina Sept. 30 / Oct. 1 - 2008 http://ba-con.com.ar Tokyo, Japan November 12/13 2008 http://pacsec.jp Vancouver, Canada March 16-20 2009 http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From GregPlatt at ix.netcom.com Mon Aug 25 08:11:13 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 25 Aug 2008 06:11:13 -0600 Subject: Still Looking for Help: Why doesn't Maradns start at boot time? Message-ID: <005b01c906ab$abb4fff0$0200a8c0@gregsrocket> In my reinstall of maradns on my Debian 4.0r3 etch system, I had several issues related to errors I'd made during setup. I've gradually worked through and solved all but one of those. But I need help on the issue that's left. The one remaining issue (which is plainly critical in my ultimate ability to use mara) is that for some reason maradns fails to load chroot'ed in resident mode at boot time. If I start maradns manually after boot as the root user, it starts and runs fine. But when I reboot the server, I find maradns did NOT restart during the boot process and I can't figure out why. For the record, if I run the process manually as the root user after startup and leave it running, it does seem to STAY running; but having the DNS server not start at boot time is definitely a BIG problem! A check of rcconf shows maradns is listed and configured to start and a grep of dmesg after boot shows no errors are being produced by maradns at boot time. Yet, after the server has BOOTED, maradns is definitely not running from what I can tell. I'm looking for it using "ps aux | grep mara". And from what I see, it is definitely NOT in the active task list after startup. When maradns is set to start at boot time, but it does NOT do so, I'm at a loss as to how to troubleshoot the boot process. Can SOMEONE here please advise me on how to fix this problem? Thanks! From remco at webconquest.com Mon Aug 25 08:15:28 2008 From: remco at webconquest.com (Remco Rijnders) Date: Mon, 25 Aug 2008 14:15:28 +0200 (CEST) Subject: Still Looking for Help: Why doesn't Maradns start at boot time? Message-ID: <13553.167.202.222.228.1219666528.squirrel@webmail.xs4all.nl> > The one remaining issue (which is plainly critical in my ultimate ability > to > use mara) is that for some reason maradns fails to load chroot'ed in > resident mode at boot time. If I start maradns manually after boot as the > root user, it starts and runs fine. But when I reboot the server, I find > maradns did NOT restart during the boot process and I can't figure out > why. Hi Greg, How do you start maradns manually? As in, what command do you give to kick it off? I imagine that this might be different from how the server itself tries to start maradns at boot time. Remco From ruskie at codemages.net Mon Aug 25 08:25:26 2008 From: ruskie at codemages.net (=?UTF-8?B?IkFuZHJhxb4gJ3J1c2tpZScgTGV2c3RpayI=?=) Date: Mon, 25 Aug 2008 14:25:26 +0200 Subject: Still Looking for Help: Why doesn't Maradns start at boot time? In-Reply-To: <005b01c906ab$abb4fff0$0200a8c0@gregsrocket> References: <005b01c906ab$abb4fff0$0200a8c0@gregsrocket> Message-ID: <3f2b2fe50f7e93ee477f1449c526b544@hastymail.org> On 14:11:13 2008-08-25 "Greg Platt - Platt Consultants" wrote: > In my reinstall of maradns on my Debian 4.0r3 etch system, I had several > issues related to errors I'd made during setup. I've gradually worked > through and solved all but one of those. But I need help on the issue > that's left. > > The one remaining issue (which is plainly critical in my ultimate > ability to use mara) is that for some reason maradns fails to load > chroot'ed in resident mode at boot time. If I start maradns manually > after boot as the root user, it starts and runs fine. But when I reboot > the server, I find maradns did NOT restart during the boot process and > I can't figure out why. So now that all the redundant talk was removed... This would most likely be due to the init scripts of your distribution. If you are using /etc/init.d/maradns start to launch it manualy then there seems to be something odd... if you launch it using maradns fooetc... then that would explain the differences... -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From KenL at GraphixWizard.com Mon Aug 25 08:51:13 2008 From: KenL at GraphixWizard.com (Ken Lyons - Graphix Wizard/Data-Forms) Date: Mon, 25 Aug 2008 08:51:13 -0400 Subject: Still Looking for Help: Why doesn't Maradns start at boot time? In-Reply-To: <2008-238-08-1-1219666554-026352@gwizfl.org> References: <2008-238-08-1-1219666554-026352@gwizfl.org> Message-ID: <2008-238-08-5-1219668685-002833@gwizfl.org> If it helps anyone, this is how we start Mara. (Identical data on several servers around the world, updated 15/min) We use many DNS servers that need to have identical information, so we use the inittab to respawn a perl script that runs mara. A cron tab kills that script every 15 minutes so that it respawns with any new or changed data. The script itself just downloads all the config files, builds a new mara.rc file, then runs runs mara (not deamon/background). Should mara ever die for some unexplained reason, it would just cycle and restart like a normal update. So for us, as long as the data is valid and correct, mara will keep running no matter what. Ken Lyons / e/Solutions / IT Services *GraphixWizard/Data-Forms* */Toll Free/* 800.447.3676 */Direct/* 407.656.9742 */Fax/* 407.656.3353 kenl at graphixwizard.com hosting.graphixwizard.com Remco Rijnders wrote: >> The one remaining issue (which is plainly critical in my ultimate ability >> to >> use mara) is that for some reason maradns fails to load chroot'ed in >> resident mode at boot time. If I start maradns manually after boot as the >> root user, it starts and runs fine. But when I reboot the server, I find >> maradns did NOT restart during the boot process and I can't figure out >> why. >> > > Hi Greg, > > How do you start maradns manually? As in, what command do you give to kick > it off? I imagine that this might be different from how the server itself > tries to start maradns at boot time. > > Remco > > > > From GregPlatt at ix.netcom.com Mon Aug 25 09:31:56 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 25 Aug 2008 07:31:56 -0600 Subject: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: <005b01c906ab$abb4fff0$0200a8c0@gregsrocket> Message-ID: <006101c906b6$f2aae3b0$0200a8c0@gregsrocket> The answer to this turned out to be just as simple as the solutions to my earlier mara problems. And yes, I WAS the unwitting cause of this issue too. As mara works on a Debian system when it is installed, a default mararc file is created in the /etc/maradns directory. However according to the mara docs the NORMAL location of this file is in the /etc directory. So when I worked on building my local mararc file, that's where I put it (in /etc/mararc). Nothing I saw anywhere ever mentioned that a mararc config file should exist in /etc/maradns let alone that it would actually be USED for ANYTHING. However, it turns out that on a Debian system /etc/maradns/mararc actually IS used AND the resident version of mara will NOT start on a Debian system unless that file already exists IN the /etc/maradns directory. In fact, the /etc/init.d/maradns script that starts mara on a Debian system sets an environment variable named DEFAULT that points to that file at the very beginning of the init script. Then it uses that environment later to reference that /etc/maradns/mararc file when it tries to start mara in resident mode. In short, the Debian boot time startup for mara expects the mararc file to be in a non-standard location. As part of my mara installation and setup work on our server, I spotted this undocumented file and wrongly concluded this "un-needed" file was merely an example and renamed it to mararc-sample. The fact that Debian's "default" mara configuration script was missing was causing the boot time startup script to fail. Once I realized what was happening and copied my /etc/mararc script into the /etc/maradns directory, the problem with failing to start at boot time immediately vanished. That also explains why mara started fine for me when I typed maradns at the command prompt. In that case, it was operating in its normal startup mode and looking for mararc in /etc (which was where I had placed it) Credit for helping me find the solution to this problem goes to Andra? "ruskie" Levstik who mentioned the /etc/init.d/maradns script file and thus lead me to the customized version of the Debian startup script for mara. Once I was there, it took less than 5 minutes to spot and solve the cause of the problem. Thanks, "Ruskie"! And very much thanks to Remco and Ken Lyons who also responded as well! Good GRIEF what a saga THIS has been! Best Professional Regards, Greg Platt a.k.a. WebSissy -----Original Message----- From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf Of Greg Platt - Platt Consultants Sent: Monday, August 25, 2008 6:11 AM To: list at maradns.org Subject: Still Looking for Help: Why doesn't Maradns start at boot time? In my reinstall of maradns on my Debian 4.0r3 etch system, I had several issues related to errors I'd made during setup. I've gradually worked through and solved all but one of those. But I need help on the issue that's left. The one remaining issue (which is plainly critical in my ultimate ability to use mara) is that for some reason maradns fails to load chroot'ed in resident mode at boot time. If I start maradns manually after boot as the root user, it starts and runs fine. But when I reboot the server, I find maradns did NOT restart during the boot process and I can't figure out why. For the record, if I run the process manually as the root user after startup and leave it running, it does seem to STAY running; but having the DNS server not start at boot time is definitely a BIG problem! A check of rcconf shows maradns is listed and configured to start and a grep of dmesg after boot shows no errors are being produced by maradns at boot time. Yet, after the server has BOOTED, maradns is definitely not running from what I can tell. I'm looking for it using "ps aux | grep mara". And from what I see, it is definitely NOT in the active task list after startup. When maradns is set to start at boot time, but it does NOT do so, I'm at a loss as to how to troubleshoot the boot process. Can SOMEONE here please advise me on how to fix this problem? Thanks! From strenholme.usenet at gmail.com Mon Aug 25 11:41:36 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 25 Aug 2008 10:41:36 -0500 Subject: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: <006101c906b6$f2aae3b0$0200a8c0@gregsrocket> References: <005b01c906ab$abb4fff0$0200a8c0@gregsrocket> <006101c906b6$f2aae3b0$0200a8c0@gregsrocket> Message-ID: <7bd685720808250841o1aba9a63mf460308a8d8b221f@mail.gmail.com> > As mara works on a Debian system when it is installed, a default mararc file > is created in the /etc/maradns directory. However according to the mara docs > the NORMAL location of this file is in the /etc directory. The issue is that the Debian package needs to revise all of the MaraDNS docs to point out that the default mararc file is in /etc/maradns/, or to have a very prominent README.debian that points out that the mararc file is in /etc/maradns. I am sure Jakko can look at and address this issue; I think, since Mara's online docs say it's in /etc/mararc, but Debian needs it to be in /etc/maradns/mararc, the best thing to do is to have a README.debian pointing this out or to have an additional printf("NOTE: The Debian build of MaraDNS has the mararc file in /etc/maradns/mararc\n"); in the code run when MaraDNS is started up. Don't get me started on how Debian's random hacking of code resulted in OpenSSH having a gaping security hole. Personally, I think CentOS/RHEL (or one of the BSDs) makes a lot more sense on a server. - Sam From hendry at iki.fi Mon Aug 25 11:54:28 2008 From: hendry at iki.fi (Kai Hendry) Date: Mon, 25 Aug 2008 16:54:28 +0100 Subject: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: <7bd685720808250841o1aba9a63mf460308a8d8b221f@mail.gmail.com> References: <005b01c906ab$abb4fff0$0200a8c0@gregsrocket> <006101c906b6$f2aae3b0$0200a8c0@gregsrocket> <7bd685720808250841o1aba9a63mf460308a8d8b221f@mail.gmail.com> Message-ID: On Mon, Aug 25, 2008 at 4:41 PM, Sam Trenholme wrote: > I am sure Jakko can look at and address this issue; I think, since > Mara's online docs say it's in /etc/mararc, but Debian needs it to be > in /etc/maradns/mararc, the best thing to do is to have a > README.debian pointing this out or to have an additional printf("NOTE: > The Debian build of MaraDNS has the mararc file in > /etc/maradns/mararc\n"); in the code run when MaraDNS is started up. I'm the maintainer for maradns. :) http://packages.qa.debian.org/m/maradns.html I can add a note when I also package up 1.3.07.09. Anything else I can do to make the Debian package better, please file a bug or mail me. http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=maradns Kind regards, From GregPlatt at ix.netcom.com Mon Aug 25 12:46:24 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 25 Aug 2008 10:46:24 -0600 Subject: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: <7bd685720808250841o1aba9a63mf460308a8d8b221f@mail.gmail.com> Message-ID: <00e001c906d2$1d4a7ed0$0200a8c0@gregsrocket> For the record, Sam, Debian does have a README.Debian but it is completely silent on this topic... as well as several others that do puzzle me. For instance, I'd love to know why my Debian install of mara starts mara as user 99 but the maradns group and user on my server are 106 and 108 respectively. I've wondered if this has any effect on mara running as a chroot'ed task; but I don't know how to tell. Professionally, I agree changes of this type made local to a particular Linux release should be thoroughly documented and not left up to the installer to discover on his own. As my case shows, we're often the least well informed and the last to figure out such details. I still think your product is the best choice for me and others like me, Sam. I hand picked it personally after carefully evaluating the various alternatives. You've done a fine job on the mara docs too. And like it or not, I'm pretty much stuck with my choice of Debian now that I'm a full month into the server configuration setup process. Thanks a lot for your product and the time and effort you've put into it! Best Professional Regards, Greg Platt a.k.a. WebSissy -----Original Message----- From: Sam Trenholme [mailto:strenholme.usenet at gmail.com] Sent: Monday, August 25, 2008 9:42 AM To: gregplatt at ix.netcom.com Cc: list at maradns.org Subject: Re: SOLVED! Why doesn't Maradns start at boot time? > As mara works on a Debian system when it is installed, a default mararc file > is created in the /etc/maradns directory. However according to the mara docs > the NORMAL location of this file is in the /etc directory. The issue is that the Debian package needs to revise all of the MaraDNS docs to point out that the default mararc file is in /etc/maradns/, or to have a very prominent README.debian that points out that the mararc file is in /etc/maradns. I am sure Jakko can look at and address this issue; I think, since Mara's online docs say it's in /etc/mararc, but Debian needs it to be in /etc/maradns/mararc, the best thing to do is to have a README.debian pointing this out or to have an additional printf("NOTE: The Debian build of MaraDNS has the mararc file in /etc/maradns/mararc\n"); in the code run when MaraDNS is started up. From strenholme.usenet at gmail.com Mon Aug 25 12:56:32 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 25 Aug 2008 11:56:32 -0500 Subject: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: <00e001c906d2$1d4a7ed0$0200a8c0@gregsrocket> References: <7bd685720808250841o1aba9a63mf460308a8d8b221f@mail.gmail.com> <00e001c906d2$1d4a7ed0$0200a8c0@gregsrocket> Message-ID: <7bd685720808250956h47bbf621m5c00b49cf6e0f9a0@mail.gmail.com> > For the record, Sam, Debian does have a README.Debian but it is completely > silent on this topic... The problem, and I've seen this before (heck, I've had this problem with MaraDNS), is that you can't debug documentation like you can debug code. So, things missing in the documentation can be missed until someone points out "Hey, this is missing in the documentation!" and then we can fix the documentation. Kai: Thanks for popping in. What's the procedure Greg can do to submit a MaraDNS Debian bug report so you guys can look at the bug? Basically, Debian has its own bug reporting system, and Debian users should use that system. The thinking is this: Since Debian does make random changes to programs, bugs should be filed at Debian. If Debian determines upstream is responsible for the bug, they forward the bug on to me, or, as the case may be, I look over the Debian bug database for MaraDNS bugs. Also, the Debian bug database is the only way to report bugs for open source projects where the original author has long since abandoned the project (such as FVWM1, the window manager I still use today). - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From GregPlatt at ix.netcom.com Mon Aug 25 17:16:08 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Mon, 25 Aug 2008 15:16:08 -0600 Subject: URGENT: Bug Report for Debian's MaraDNS package... Message-ID: <018901c906f7$cb6fcb80$0200a8c0@gregsrocket> Per our conversation earlier today in the maradns mailman listserve please record a formal bug report for the current stable version of maradns etch 4.0r3 and for the stable sarge release as well. The Debian etch 4.0r3 installation of maradns has changed a very basic assumption of the program at startup time. Namely, maradns normally assumes it's basic configuration file will be found in /etc/mararc and it looks for it there. The mara setup documentation at http://maradns.org makes it very clear this is where the file should be placed. However in the Debian implementation this assumption has been changed and the file is expected to be in a different location (/etc/maradns/mararc). The maradns initialization script ( /etc/init.d/maradns ) package explicitly checks for the presence of the mararc configuration file in the /etc/maradns directory rather than in the /etc directory. If the configuration script is NOT found in that location, the script abends and mara is not loaded during the initialization process. As far as I could determine, none of the existing Debian etch documentation INCLUDING the README.Debian file in /usr/share/doc/maradns or the man page for maradns mentions this change in location for the mararc configuration file. Since the existing Debian etch maradns documentation is not designed to REPLACE the original mara docs, it should make a CLEAR and highly visible reference to this change in location for mara's main configuration file. The fact that the current documentation FAILS to do this causes one of two specific issues during mara installation. Frankly, I encountered BOTH of these issues during my own mara installation and setup. First, an installer who is following the regular mara setup and installation tutorials (from http://maradns.org ) for how to create a mararc file or how to create and modify mara zone files will tend to place the mararc script in the WRONG location. The maradns.org docs call for mararc to be in /etc and NOT in /etc/maradns. Later when mara does autostart all the parameters placed in the installer's /etc/mararc file will be IGNORED because Debian's boot-time script does not USE the USUAL mararc file (/etc/mararc). As a result the custom setup defined by the installer are ignored and mara defaults instead to the Debian-specific version of that file stored in /etc/maradns/mararc without informing the installer that it has done so. In short, mara ignores the user's custom setup for mararc and uses the Debian "default" setup stored in /etc/maradns/mararc instead. Second, and perhaps more importantly, if the "apparently unused" copy of mararc in /etc/maradns has been REMOVED or RENAMED by the installer (as I did on my server because this file was not identified as being USED for any purpose whatsoever in any of the docs I had oh-so-carefully read), then mara fails to start at all during the boot process without giving any error messages or warnings whatsoever. The way the boot script is now written if the file /etc/maradns/mararc does not exist, the startup /etc/init.d/maradns boot script just exits quietly and never gives any indication THAT mara did not start or WHY it did not start! Recommended Solution: Option 1: The standard documentation package and tutorials for Mara should either be converted and modified to reflect the change in location for mararc or Option 2: At the very least a prominent warning message should be added to the top of the README.Debian file that clearly states the location of mararc MUST be /etc/maradns/mararc and NOT /etc/mararc. The /etc/init.d/maradns boot script should ALSO check for the existence of a /etc/mararc file and give a HIGHLY visible WARNING message if this 'normal' mara configuration file is found. Conversely if the /etc/maradns/mararc configuration file is NOT found where it is expected to be, a HIGHLY visible ERROR message should also be displayed before the /etc/init.d/maradns script exits Conclusion: By failing to notify the installer that Debian has changed a very basic assumption about the location of Mara's primary configuration file, AND by then failing to WARN when TWO versions of the file are present AND by refusing to run the boot script when the relocated file is NOT present where Debian assumes it will be, the Debian package has effectively booby-trapped the road to a successful mara install in all directions! Please correct this error ASAP. From hendry at iki.fi Tue Aug 26 02:32:09 2008 From: hendry at iki.fi (Kai Hendry) Date: Tue, 26 Aug 2008 07:32:09 +0100 Subject: URGENT: Bug Report for Debian's MaraDNS package... In-Reply-To: <018901c906f7$cb6fcb80$0200a8c0@gregsrocket> References: <018901c906f7$cb6fcb80$0200a8c0@gregsrocket> Message-ID: Waiting for upload: http://hendry.iki.fi/debian/unstable/maradns_1.3.07.09-1_i386.changes Install it and check out the README.Debian From lew.payne at gmail.com Tue Aug 26 12:33:47 2008 From: lew.payne at gmail.com (Lew Payne) Date: Tue, 26 Aug 2008 10:33:47 -0600 Subject: duende Does Not Work Under FreeBSD Message-ID: I've been running the version of maradns that is in the ports collection for FreeBSD. In my case, it is MaraDNS version 1.2.12.08. The "duende" program has never worked for me, as far as logging. This is actually not a new discussion; I had an email discussion with Sam about this more than a year ago. The only way I have found to be able to capture maradns output for logging (syslog) has been to modify the /usr/local/etc/rc.d/maradns.sh startup script as follows: # diff maradns.* < command="${prefix}/bin/duende" --- > command="${prefix}/sbin/${name}" 36c36 < flags="${prefix}/sbin/${name} ${maradns_flags}" --- > flags="${maradns_flags} | logger -t maradns -p local1.notice &" Again, the duende program does spawn/start maradns the way it's supposed to. However, the logging does not work. I am noting this on this mailing list so that other future FreeBSD or BDS-derivative users can easily find it via a search. Lew Payne lew.payne at gmail.com From GregPlatt at ix.netcom.com Tue Aug 26 13:39:03 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Tue, 26 Aug 2008 11:39:03 -0600 Subject: duende Does Not Work Under FreeBSD In-Reply-To: Message-ID: <00fc01c907a2$a29af350$0200a8c0@gregsrocket> For the record, Lew, the Debian install of Mara does not use the duende program at all -- either for logging or for mara initiation. I've forgotten the name of the utility used to "daemon-ize" mara at this moment, but it's definitely NOT duende. And for the life of me, I couldn't figure out exactly where the mara run-time log gets placed on Debian either. I guess this is one of those cases where the "debian-ites" decided they had a "better way" to handle logging but never bothered to document how the new-improved method works. Sigh... -----Original Message----- From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf Of Lew Payne Sent: Tuesday, August 26, 2008 10:34 AM To: list at maradns.org Subject: duende Does Not Work Under FreeBSD I've been running the version of maradns that is in the ports collection for FreeBSD. In my case, it is MaraDNS version 1.2.12.08. The "duende" program has never worked for me, as far as logging. This is actually not a new discussion; I had an email discussion with Sam about this more than a year ago. The only way I have found to be able to capture maradns output for logging (syslog) has been to modify the /usr/local/etc/rc.d/maradns.sh startup script as follows: # diff maradns.* < command="${prefix}/bin/duende" --- > command="${prefix}/sbin/${name}" 36c36 < flags="${prefix}/sbin/${name} ${maradns_flags}" --- > flags="${maradns_flags} | logger -t maradns -p local1.notice &" Again, the duende program does spawn/start maradns the way it's supposed to. However, the logging does not work. I am noting this on this mailing list so that other future FreeBSD or BDS-derivative users can easily find it via a search. Lew Payne lew.payne at gmail.com From ruskie at codemages.net Tue Aug 26 13:52:19 2008 From: ruskie at codemages.net (=?UTF-8?B?IkFuZHJhxb4gJ3J1c2tpZScgTGV2c3RpayI=?=) Date: Tue, 26 Aug 2008 19:52:19 +0200 Subject: duende Does Not Work Under FreeBSD In-Reply-To: <00fc01c907a2$a29af350$0200a8c0@gregsrocket> References: <00fc01c907a2$a29af350$0200a8c0@gregsrocket> Message-ID: I'm running maradns on OpenBSD with duende logging just fine same version as you and a more recent one. On 19:39:03 2008-08-26 "Greg Platt - Platt Consultants" wrote: > For the record, Lew, the Debian install of Mara does not use the duende > program at all -- either for logging or for mara initiation. I've > forgotten the name of the utility used to "daemon-ize" mara at this > moment, but it's definitely NOT duende. And for the life of me, I > couldn't figure out exactly where the mara run-time log gets placed on > Debian either. I guess this is one of those cases where the > "debian-ites" decided they had a "better way" to handle logging but > never bothered to document how the new-improved method works. > > Sigh... > > -----Original Message----- > From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On > Behalf Of Lew Payne > Sent: Tuesday, August 26, 2008 10:34 AM > To: list at maradns.org > Subject: duende Does Not Work Under FreeBSD > > I've been running the version of maradns that is in the ports > collection for FreeBSD. In my case, it is MaraDNS version 1.2.12.08. > > The "duende" program has never worked for me, as far as logging. This > is actually not a new discussion; I had an email discussion with Sam > about this more than a year ago. The only way I have found to be able > to capture maradns output for logging (syslog) has been to modify the > /usr/local/etc/rc.d/maradns.sh startup script as follows: > > # diff maradns.* > < command="${prefix}/bin/duende" > --- > > command="${prefix}/sbin/${name}" > 36c36 > < flags="${prefix}/sbin/${name} ${maradns_flags}" > --- > > flags="${maradns_flags} | logger -t maradns -p local1.notice &" > > Again, the duende program does spawn/start maradns the way it's > supposed to. However, the logging does not work. I am noting this on > this mailing list so that other future FreeBSD or BDS-derivative users > can easily find it via a search. > > Lew Payne > lew.payne at gmail.com -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From GregPlatt at ix.netcom.com Tue Aug 26 15:03:56 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Tue, 26 Aug 2008 13:03:56 -0600 Subject: duende Does Not Work Under FreeBSD In-Reply-To: Message-ID: <013001c907ae$7e04af70$0200a8c0@gregsrocket> Aha! The borscht thickens... In my experience when comrade Andra? Levstik speaks his words are worth hearing. The 'ruskie' is a man of few words, who generally KNOWS what he's talking about! So listen-up, Lew. He may hold the solution to your conundrum... ;-) Go ahead, Andra?. Give 'em both barrels (or should I say, vodka bottles)? :-) -----Original Message----- From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf Of "Andra? 'ruskie' Levstik" Sent: Tuesday, August 26, 2008 11:52 AM To: list at maradns.org Subject: RE: duende Does Not Work Under FreeBSD I'm running maradns on OpenBSD with duende logging just fine same version as you and a more recent one. On 19:39:03 2008-08-26 "Greg Platt - Platt Consultants" wrote: > For the record, Lew, the Debian install of Mara does not use the duende > program at all -- either for logging or for mara initiation. I've > forgotten the name of the utility used to "daemon-ize" mara at this > moment, but it's definitely NOT duende. And for the life of me, I > couldn't figure out exactly where the mara run-time log gets placed on > Debian either. I guess this is one of those cases where the > "debian-ites" decided they had a "better way" to handle logging but > never bothered to document how the new-improved method works. > > Sigh... > > -----Original Message----- > From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On > Behalf Of Lew Payne > Sent: Tuesday, August 26, 2008 10:34 AM > To: list at maradns.org > Subject: duende Does Not Work Under FreeBSD > > I've been running the version of maradns that is in the ports > collection for FreeBSD. In my case, it is MaraDNS version 1.2.12.08. > > The "duende" program has never worked for me, as far as logging. This > is actually not a new discussion; I had an email discussion with Sam > about this more than a year ago. The only way I have found to be able > to capture maradns output for logging (syslog) has been to modify the > /usr/local/etc/rc.d/maradns.sh startup script as follows: > > # diff maradns.* > < command="${prefix}/bin/duende" > --- > > command="${prefix}/sbin/${name}" > 36c36 > < flags="${prefix}/sbin/${name} ${maradns_flags}" > --- > > flags="${maradns_flags} | logger -t maradns -p local1.notice &" > > Again, the duende program does spawn/start maradns the way it's > supposed to. However, the logging does not work. I am noting this on > this mailing list so that other future FreeBSD or BDS-derivative users > can easily find it via a search. > > Lew Payne > lew.payne at gmail.com -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From rick at linuxmafia.com Tue Aug 26 15:09:33 2008 From: rick at linuxmafia.com (Rick Moen) Date: Tue, 26 Aug 2008 12:09:33 -0700 Subject: duende Does Not Work Under FreeBSD In-Reply-To: <00fc01c907a2$a29af350$0200a8c0@gregsrocket> References: <00fc01c907a2$a29af350$0200a8c0@gregsrocket> Message-ID: <20080826190933.GA16693@linuxmafia.com> Quoting Greg Platt - Platt Consultants (GregPlatt at ix.netcom.com): > For the record, Lew, the Debian install of Mara does not use the duende > program at all -- either for logging or for mara initiation. I've forgotten > the name of the utility used to "daemon-ize" mara at this moment, but it's > definitely NOT duende. And for the life of me, I couldn't figure out exactly > where the mara run-time log gets placed on Debian either. If it's anything like Ubuntu - which seems very likely - than it's BSD syslog's logger(3) utility, logging Mara's data into /var/log/daemon.log . The exact startup line in Ubuntu's /etc/init.d/maradns script is: --exec $DAEMON -- -f $rcfile &1 | logger -p daemon.notice -t $SERVERNAME 2>/dev/null (Ubuntu has shifted away from SysVInit to "StartUp", an event-driven alternative init. Debian retains the classic SysVInit.) From strenholme.usenet at gmail.com Tue Aug 26 15:25:59 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 26 Aug 2008 14:25:59 -0500 Subject: duende Does Not Work Under FreeBSD In-Reply-To: References: Message-ID: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> > The "duende" program has never worked for me, as far as logging. You know, *BSDs have caused its share of headaches for MaraDNS. For example, there is an issue that Zoneserver in MaraDNS 1.3 doesn't compile under FreeBSD, and I never got a patch to fix the issue so that Zoneserver would compile in FreeBSD. As another example, NetBSD uses a system for ports called "pkgsrc" which doesn't work too well with MaraDNS because "pkgsrc" assumes you're using autoconf and can't handle non-autoconf build processes very well. I asked for patches from the NetBSD guys to resolve this issue; all I got was whining about how I characterized "pkgsrc" being NetBSD's form of ports, and empty promises. As another issue, the BSDs have handled threads poorly, which makes MaraDNS' heavy use of threads problematic. I am actually working on this issue (slowly); the new Deadwood non-recursive resolver doesn't use threads. Basically, if you're using BSD, sorry, I don't use it on my system. If you can give me an assurance that all of the hardware in my Linux Dell 1420 works under one of the BSDs (it's a Linux 1402 so there's no "secret specs" issue), I would be happy to try it (I'm sick of Linux's way of changing the driver model every three months or so, making it nay-to-impossible to use new drivers with older, stable kernels). Until then, it's up to the BSD guys to fix these issues yourself. Give me patches and I will seriously consider integrating them in the next release of MaraDNS. Give me a BSD startup script that doesn't use Duende and works, and I will consider using it. If you can find a piece of MaraDNS code that isn't POSIX compliant, resulting in compilation or running problems in MaraDNS, I will be happy to fix the issue if you can cite chapter and verse in POSIX. Yes, you can look at POSIX on the web: http://www.opengroup.org/onlinepubs/000095399/mindex.html Thank you for your understanding, - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From ruskie at codemages.net Tue Aug 26 15:37:46 2008 From: ruskie at codemages.net (=?UTF-8?B?IkFuZHJhxb4gJ3J1c2tpZScgTGV2c3RpayI=?=) Date: Tue, 26 Aug 2008 21:37:46 +0200 Subject: duende Does Not Work Under FreeBSD In-Reply-To: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> References: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> Message-ID: <844006c92c89ed09b2e2cc4ff92e4cff@hastymail.org> On 21:25:59 2008-08-26 "Sam Trenholme" wrote: > > The "duende" program has never worked for me, as far as logging. > > You know, *BSDs have caused its share of headaches for MaraDNS. For > example, there is an issue that Zoneserver in MaraDNS 1.3 doesn't > compile under FreeBSD, and I never got a patch to fix the issue so > that Zoneserver would compile in FreeBSD. > > As another example, NetBSD uses a system for ports called "pkgsrc" > which doesn't work too well with MaraDNS because "pkgsrc" assumes > you're using autoconf and can't handle non-autoconf build processes > very well. I asked for patches from the NetBSD guys to resolve this > issue; all I got was whining about how I characterized "pkgsrc" being > NetBSD's form of ports, and empty promises. > > As another issue, the BSDs have handled threads poorly, which makes > MaraDNS' heavy use of threads problematic. I am actually working on > this issue (slowly); the new Deadwood non-recursive resolver doesn't > use threads. > > Basically, if you're using BSD, sorry, I don't use it on my system. > If you can give me an assurance that all of the hardware in my Linux > Dell 1420 works under one of the BSDs (it's a Linux 1402 so there's no > "secret specs" issue), I would be happy to try it (I'm sick of Linux's > way of changing the driver model every three months or so, making it > nay-to-impossible to use new drivers with older, stable kernels). > > Until then, it's up to the BSD guys to fix these issues yourself. > Give me patches and I will seriously consider integrating them in the > next release of MaraDNS. Give me a BSD startup script that doesn't > use Duende and works, and I will consider using it. > > If you can find a piece of MaraDNS code that isn't POSIX compliant, > resulting in compilation or running problems in MaraDNS, I will be > happy to fix the issue if you can cite chapter and verse in POSIX. > Yes, you can look at POSIX on the web: > > http://www.opengroup.org/onlinepubs/000095399/mindex.html > > Thank you for your understanding, > You mean these: http://www.openbsd.org/cgi-bin/cvsweb/ports/net/maradns/patches/patch-server_udpsuccess_c http://www.openbsd.org/cgi-bin/cvsweb/ports/net/maradns/patches/patch-tcp_zoneserver_c That are needed for openbsd... -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From ruskie at codemages.net Tue Aug 26 15:41:35 2008 From: ruskie at codemages.net (=?UTF-8?B?IkFuZHJhxb4gJ3J1c2tpZScgTGV2c3RpayI=?=) Date: Tue, 26 Aug 2008 21:41:35 +0200 Subject: duende Does Not Work Under FreeBSD In-Reply-To: <013001c907ae$7e04af70$0200a8c0@gregsrocket> References: <013001c907ae$7e04af70$0200a8c0@gregsrocket> Message-ID: On 21:03:56 2008-08-26 "Greg Platt - Platt Consultants" wrote: > Aha! The borscht thickens... In my experience when comrade Andra? > Levstik speaks his words are worth hearing. The 'ruskie' is a man of > few words, who generally KNOWS what he's talking about! So listen-up, > Lew. He may hold the solution to your conundrum... ;-) > > Go ahead, Andra?. Give 'em both barrels (or should I say, vodka > bottles)? :-) > All that I need to launch it syslog will then stove it into daemon.log "duende /usr/local/sbin/maradns" I'm not russian FYI... Btw do I happen to know you??? *confused* -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From GregPlatt at ix.netcom.com Tue Aug 26 15:59:00 2008 From: GregPlatt at ix.netcom.com (Greg Platt - Platt Consultants) Date: Tue, 26 Aug 2008 13:59:00 -0600 Subject: duende Does Not Work Under FreeBSD In-Reply-To: Message-ID: <015d01c907b6$2f4a71a0$0200a8c0@gregsrocket> LOL yeah, I figured you were NOT a "born-there" Russian, Andra?. If you're a typical Yank, it's probably more like an Irish-Cherokee-Greek blend with a half a jigger of Scotch thrown in for flavor. I was just having fun, adding to the mystique and giving you headway to go where you wanted with the ruskie bit. ;-) Even if you're a more exotic blend of French-Canadian, Jamaican, Swedish, Hawaiian and Jewish, You're still a heckuva smart guy in my book! :-) 'scuse me for stretching the truth, please. The Devil made me do it. Best, Greg -----Original Message----- From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf Of "Andra? 'ruskie' Levstik" Sent: Tuesday, August 26, 2008 1:42 PM To: list at maradns.org Subject: RE: duende Does Not Work Under FreeBSD On 21:03:56 2008-08-26 "Greg Platt - Platt Consultants" wrote: > Aha! The borscht thickens... In my experience when comrade Andra? > Levstik speaks his words are worth hearing. The 'ruskie' is a man of > few words, who generally KNOWS what he's talking about! So listen-up, > Lew. He may hold the solution to your conundrum... ;-) > > Go ahead, Andra?. Give 'em both barrels (or should I say, vodka > bottles)? :-) > All that I need to launch it syslog will then stove it into daemon.log "duende /usr/local/sbin/maradns" I'm not russian FYI... Btw do I happen to know you??? *confused* -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From lew.payne at gmail.com Tue Aug 26 16:38:58 2008 From: lew.payne at gmail.com (Lew Payne) Date: Tue, 26 Aug 2008 14:38:58 -0600 Subject: duende Does Not Work Under FreeBSD In-Reply-To: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> References: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> Message-ID: Sam - Thanks for your reply regarding FreeBSD. When you and I last tested (more than a year ago), we concluded that maradns is indeed producing messages as it should (under FreeBSD), but that for some reason duende was not... 1) getting those messages via its pipe mechanism, or... 2) duende was not properly communicating with syslog ... under the FreeBSD flavor of things. To avoid this problem, I had to change the startup file (of which is showed a diff today) so that the output of maradns went to logger instead. For those who suspect my syslog is discarding the messages, it is not. I have specifically turned on all logging to temporarily debug this, and I've set up specific handlers for the processes themselves. Bottom line: maradns logs fine using (system) logger, but does not log using duende. This is an informational message so that others on FreeBSD systems can google and find it if they're having the same issues, now or in the future. Modify your /usr/local/etc/rc.d/maradns.sh startup script according to the previous diff that I posted in this same thread. Thank you all. From kai.hendry at gmail.com Wed Aug 27 04:29:18 2008 From: kai.hendry at gmail.com (Kai Hendry) Date: Wed, 27 Aug 2008 09:29:18 +0100 Subject: FW: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: <012701c906db$a2bd28c0$0200a8c0@gregsrocket> References: <012701c906db$a2bd28c0$0200a8c0@gregsrocket> Message-ID: New upload: http://packages.qa.debian.org/m/maradns/news/20080827T070206Z.html On Mon, Aug 25, 2008 at 6:54 PM, Greg Platt - Platt Consultants wrote: > I've also wondered why the Debian Mara install fails to create the Maradns > user and group with the correct number and what other down-stream > implications that may have. The packaging creates the user id number by using `adduser` of your system. It doesn't choose a particular number as you'll have conflicts. So `adduser` just increments a counter. You need to check this with your configuration ultimately, though I think there is a regex in the packaging to try setup it up in most cases correctly. From hendry at iki.fi Wed Aug 27 04:35:46 2008 From: hendry at iki.fi (Kai Hendry) Date: Wed, 27 Aug 2008 09:35:46 +0100 Subject: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: <7bd685720808250956h47bbf621m5c00b49cf6e0f9a0@mail.gmail.com> References: <7bd685720808250841o1aba9a63mf460308a8d8b221f@mail.gmail.com> <00e001c906d2$1d4a7ed0$0200a8c0@gregsrocket> <7bd685720808250956h47bbf621m5c00b49cf6e0f9a0@mail.gmail.com> Message-ID: On Mon, Aug 25, 2008 at 5:56 PM, Sam Trenholme wrote: > Kai: Thanks for popping in. What's the procedure Greg can do to > submit a MaraDNS Debian bug report so you guys can look at the bug? Greg has emailed me directly and I've since updated the package. Though yes, in future, please use `reportbug` and go through the Debian BTS. Most sysadmins know to read /etc/init.d/ daemon scripts when in doubt. I find it almost easier that pouring through documentation, but perhaps it shows you I am a total geek. =) > Also, the Debian bug database is the only way to report bugs for open > source projects where the original author has long since abandoned the > project (such as FVWM1, the window manager I still use today). Sam, you should try http://www.suckless.org/dwm/ as a replacement window manager. Kind regards, From strenholme.usenet at gmail.com Wed Aug 27 11:57:10 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 27 Aug 2008 10:57:10 -0500 Subject: duende Does Not Work Under FreeBSD In-Reply-To: <844006c92c89ed09b2e2cc4ff92e4cff@hastymail.org> References: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> <844006c92c89ed09b2e2cc4ff92e4cff@hastymail.org> Message-ID: <7bd685720808270857k6f6bfc55o55865a8ffa9e47b0@mail.gmail.com> > http://www.openbsd.org/cgi-bin/cvsweb/ports/net/maradns/patches/patch-server_udpsuccess_c > > http://www.openbsd.org/cgi-bin/cvsweb/ports/net/maradns/patches/patch-tcp_zoneserver_c Thank you. I have saved them and will release a snapshot of MaraDNS 1.3 today integrating these patches. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From strenholme.usenet at gmail.com Wed Aug 27 12:00:15 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 27 Aug 2008 11:00:15 -0500 Subject: duende Does Not Work Under FreeBSD In-Reply-To: References: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> Message-ID: <7bd685720808270900p2b9096fegf6caae13cf54a615@mail.gmail.com> > for some reason duende was not... > > 1) getting those messages via its pipe mechanism, or... > 2) duende was not properly communicating with syslog > > ... under the FreeBSD flavor of things. Again, that's nice. Really nice. And, you know, I don't have FreeBSD, so I can't fix this issue. It works fine in Linux, so maybe FreeBSD needs to fix their OS. A patch for Duende would be nice; if FreeBSD users want this problem fixed, I need a patch. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From strenholme.usenet at gmail.com Wed Aug 27 12:14:45 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 27 Aug 2008 11:14:45 -0500 Subject: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: References: <7bd685720808250841o1aba9a63mf460308a8d8b221f@mail.gmail.com> <00e001c906d2$1d4a7ed0$0200a8c0@gregsrocket> <7bd685720808250956h47bbf621m5c00b49cf6e0f9a0@mail.gmail.com> Message-ID: <7bd685720808270914s6e8ab87fic9975fe51cf5c4d@mail.gmail.com> > Greg has emailed me directly and I've since updated the package. > Though yes, in future, please use `reportbug` and go through the > Debian BTS. Thank you very much for doing that! > Sam, you should try http://www.suckless.org/dwm/ as a replacement > window manager. I kinda like the idea of the Ion window manager too: http://www.modeemi.fi/~tuomov/ion/ A little more bloated than DWM, but it has LUA scripting support. LUA is a cool "micro language" which I am familiar with because a Doom Random Level generator that I have hacked with uses LUA for the core code that makes the levels, and C++ with FLTK for the GUI frontend. For people interested in my side projects, check out my geek blog, which also has all MaraDNS updates: http://maradns.blogspot.com/ - Sam From ruskie at codemages.net Wed Aug 27 12:20:28 2008 From: ruskie at codemages.net (=?UTF-8?B?IkFuZHJhxb4gJ3J1c2tpZScgTGV2c3RpayI=?=) Date: Wed, 27 Aug 2008 18:20:28 +0200 Subject: duende Does Not Work Under FreeBSD In-Reply-To: <7bd685720808270857k6f6bfc55o55865a8ffa9e47b0@mail.gmail.com> References: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> <844006c92c89ed09b2e2cc4ff92e4cff@hastymail.org> <7bd685720808270857k6f6bfc55o55865a8ffa9e47b0@mail.gmail.com> Message-ID: On 17:57:10 2008-08-27 "Sam Trenholme" wrote: > > http://www.openbsd.org/cgi-bin/cvsweb/ports/net/maradns/patches/patch-server_udpsuccess_c > > > > > > http://www.openbsd.org/cgi-bin/cvsweb/ports/net/maradns/patches/patch-tcp_zoneserver_c > > > > Thank you. I have saved them and will release a snapshot of MaraDNS > 1.3 today integrating these patches. > Make sure they are correct first on other systems... -- Andra? "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker Be sure brain is in gear before engaging mouth. Quis custodiet ipsos custodies. Ryle hira. Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C From strenholme.usenet at gmail.com Wed Aug 27 12:29:43 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 27 Aug 2008 11:29:43 -0500 Subject: duende Does Not Work Under FreeBSD In-Reply-To: References: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> <844006c92c89ed09b2e2cc4ff92e4cff@hastymail.org> <7bd685720808270857k6f6bfc55o55865a8ffa9e47b0@mail.gmail.com> Message-ID: <7bd685720808270929w6dce3bd5r1778ee3afca15b5b@mail.gmail.com> > Make sure they are correct first on other systems... I have a pretty extensive regression I can run in Ubuntu or CentOS to make sure everything is OK. Which means I won't be able to release a new snapshot for a couple of days, since it takes about an hour to do the regression (It basically makes sure most mararc variables work as documented, that old security bugs are still patched, etc.) - Sam From babal at via.ecp.fr Wed Aug 27 13:21:49 2008 From: babal at via.ecp.fr (Boris Dores) Date: Wed, 27 Aug 2008 19:21:49 +0200 Subject: duende Does Not Work Under FreeBSD In-Reply-To: <844006c92c89ed09b2e2cc4ff92e4cff@hastymail.org> References: <7bd685720808261225v5c4319dbid759c532bba55250@mail.gmail.com> <844006c92c89ed09b2e2cc4ff92e4cff@hastymail.org> Message-ID: <20080827172149.GW11931@via.ecp.fr> On Tue, Aug 26, 2008 at 09:37:46PM (GMT+0200), "Andra? 'ruskie' Levstik" wrote: > http://www.openbsd.org/cgi-bin/cvsweb/ports/net/maradns/patches/patch-tcp_zoneserver_c Unfortunately, this one is wrong (won't compile on Linux). Please see my previous mail on the subject : http://marc.info/?l=maradns-list&m=121335233422732&w=2 To make it short, the correct platform-independant fix is "setpgid(0,0)". Kind regards. -- Boris Dor?s From strenholme.usenet at gmail.com Thu Aug 28 14:56:18 2008 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 28 Aug 2008 13:56:18 -0500 Subject: SOLVED! Why doesn't Maradns start at boot time? In-Reply-To: <7bd685720808270914s6e8ab87fic9975fe51cf5c4d@mail.gmail.com> References: <7bd685720808250841o1aba9a63mf460308a8d8b221f@mail.gmail.com> <00e001c906d2$1d4a7ed0$0200a8c0@gregsrocket> <7bd685720808250956h47bbf621m5c00b49cf6e0f9a0@mail.gmail.com> <7bd685720808270914s6e8ab87fic9975fe51cf5c4d@mail.gmail.com> Message-ID: <7bd685720808281156q3545a194l20ae7b09589db4ab@mail.gmail.com> > I kinda like the idea of the Ion window manager too: > > http://www.modeemi.fi/~tuomov/ion/ OK, I've changed my mind. It would appear, looking at the Wikipedia entry, that Ion isn't really open source. Well, OK, technically it's released under an open source license but then the author has gone ballisitic and threatened lawsuits when people distribute patched versions of Ion.