From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7408 invoked by uid 1108); 17 May 2001 16:30:38 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 17 May 2001 16:30:38 -0700 (PDT) From: X-Sender: To: Subject: Hello, there Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII MaraDNS is coming right along. I am releasing updates to the development branch--the branch that will eventually be a fully funcitonal recursive (occassionally called "proxy") nameserver. I fixed a fairly nasty bug today, I am sure there are countless other bugs to fix. The stable branch, which is an authoritative-only nameserver, has pretty much settled down. There are two bugs which I know need to be fixed: The ability to provide records for the root nameserver, and the ability for 'askmara' to have a timeout. I believe both problems have already been fixed in the development branch, so it is just a matter of back porting the fixes. Hopefully, one of the people who have volunteered to translate the documents and the core error messages MaraDNS generates will have a translation ready in short order. When that happens, MaraDNS will become multilingual. This message is, among other things, testing the mailing list. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 8246 invoked by uid 1108); 17 May 2001 22:23:31 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 17 May 2001 22:23:31 -0700 (PDT) From: X-Sender: To: Subject: New developer snapshot of the recursive namserver (0.6.15) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just uploaded a MaraDNS 0.6.15, which is a developers-only snapshot of MaraDNS. The main change is the addition of more debugging routines, so I can more closely look at how the code which is supposed to add data to the cache, based on the replies of remote nameservers. The problem with custom data structures, such as MaraDNS' buffer-over resistant string library, is that gdb does not handle them well. I have a lot of printfs and what not in the code so I can see what is going on. I have added a DEBUG #define so I can quickly make the debugging code invisible once the recursive nameserver becomes more usable. Summary: The recursive nameserver is coming along. I beleive that I will have something usable by June 1st, although it may not be very featureful, and will probably beak the specs in a number of ways. The authoritative nameserver, of course, is still at 0.5.22, and is quite stable. I will make a posting tomorrow sometime when MaraDNS 0.6.16 comes out (which will be another developer's snapshot). The files can be downloaded here: http://www.maradns.org/download.html http://www.maradns.org/download The reason I use frequently updated tarballs (.tar.bz2 files) instead of CVS is because I feel that anonymous CVS is a security risk. CVS only makes sense when a lot of people are working on the same code at the same time. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 11714 invoked by uid 1108); 18 May 2001 23:30:28 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 18 May 2001 23:30:28 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.6.18 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII MaraDNS 0.6.18 released. This is a developers-only release, one where I am working on recursive DNS. Please use the 0.5.22 released, which is a mostly debugged and stable authoritative-only nameserver. Release notes: -- I have added a lot more debugging stuff as I hunt down why it is RRs are not being added to the dns RR cache. I think I am pretty close to pinning it down, and hope tomorrow's release can add RRs to the big cache. (2001.05.18) -- Hopefully, I will have something that correctly updates the cache by the end of the weekend. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13546 invoked by uid 1108); 19 May 2001 11:56:34 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 19 May 2001 11:56:34 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.5.23 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have just released a bugfix release for the stable 0.5.xx branch of MaraDNS. MaraDNS 0.5.23 has three bug fixes: * MaraDNS can now handle the root nameserver: MaraDNS can be a root nameserver, and askmara can ask questions about the root nameserver. * The askmara tool now has a 10-second timeout. * The logging output is now unbuffered. The source code, and both source and binary RPMs are available at http://www.maradns.org/ This will hopefully be the last bugfix release for a while. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 24258 invoked by uid 1108); 21 May 2001 01:16:32 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 21 May 2001 01:16:32 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS stable branch updated to version 0.5.24 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello there, I have updated the stable branch of MaraDNS to version 0.5.24. This updated release has two minor bug fixes: * The "erre-con-erre-cigarro.maradns.org", which returns the version of MaraDNS being run, would not work if you had NS records for the root server. Fixed. * Some POSIX-complient OSes, such as the GNU HURD, do not support limiting the number of processes with setrlimit. MaraDNS will now continue to run on such OSes. Since the stable branch of MaraDNS no longer uses fork(), this is not a security issue for the stable branch. Downloads are here: http://www.maradns.org/download.html Next: Make this release available on the Sourceforge mirror of the stable branch of MaraDNS. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 27578 invoked by uid 1108); 21 May 2001 22:27:03 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 21 May 2001 22:27:03 -0700 (PDT) From: X-Sender: To: Subject: Developmant snap MaraDNS 0.6.17 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just made available, for semi-public consumption, another pre-alpha release of the recursive version of MaraDNS. The new release is 0.6.17, and I have hit a significant milestone: This version is capable of getting and processing information received from a remote nameserver, and appropriately updating the cache. Anyway, it is available here: http://www.maradns.org/download At this point, I think I will have a working alpha-quality recursive nameserver by June 1st--my target date for a working recursive nameserver. (see http://www.maradns.org/roadmap.html) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3927 invoked by uid 1108); 24 May 2001 22:58:20 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 24 May 2001 22:58:20 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.6.18 developer snapshot released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII After a three day delay, I have released another minor update to MaraDNS. The one features some minor updates: It now will query nameservers until it gets something besides a nameserver referral. At that point, well, I need to add code to add an answer to the cache, and make that answer visible to the end user. Once that is done, the next thing I need to do is add code to handle non-working nameservers (if this name server does not respond, try the next one), and then code to handle name servers which we need to look up the IP address of (ugh). I hope to have something working in a week, on June 1st--my original target date for a working recursive nameserver. Downloads, as always, are at http://www.maradns.org As for the stable branch, MaraDNS 0.5.24 seems to not have any major bugs. If no bugs are reported for a week or two, I will canonize it as a "stable" non-recursive nameserver. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 19830 invoked by uid 1108); 29 May 2001 00:20:45 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 29 May 2001 00:20:45 -0700 (PDT) From: X-Sender: To: Subject: Another development snapshot released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, everyone, Another development snapshot of MaraDNS, version 0.6.19, has been released. Not only did I get to spend some time with my family this memorial day weekend, I also was able to get Linux up and going on my new laptop. Took two installs, but everything except SSL in Konqueror now works. I also, now that the new laptop is (mostly) up and going, have gotten a chance to work on MaraDNS. This new laptop, since it has a working battery, should speed up MaraDNS development--I can now work on MaraDNS on the train. Considering that I spend over two hours a day on the train, this will really speed up development again. I hope. The latest version is able to go to a remote server and give us an incomplete answer (only one RR) based on what the remote server tells us. As for the stable branch, we are still at 0.5.24. Since I have not gotten any definite bug reports at this time (though I have gotten hints that there are little bugs in the stable branch), the code is perfect. Until, of course, the next bug is discovered. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 25693 invoked by uid 1108); 30 May 2001 22:25:38 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 30 May 2001 22:25:38 -0700 (PDT) From: X-Sender: To: Subject: Yet another development snapshot Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII For your pleasure and delight, I have yet another devlopment snapshot of MaraDNS. This one has two big improvments: 1) The recursive resolver can now handle multiple A records (MaraDNS deliberately ignores NS and AR records. Note that it is a good idea to give out the corresponding A record for a CNAME record [To do]) 2) There is now code which makes a local copy of the chain of NS records in an authoritative-only section, which will allow me to make thread-safe code which will query other nameservers, should a given nameserver not function (e.g. Someone changed a computer's IP. In the three weeks it can take Network Solutions to update the records on the root nameservers, we still want to be able to reach the domain in question by using the other listed nameserver for the domain) As always, check out: http://www.maradns.org/download.html - Sam (Being able to develop MaraDNS on the train and in the park while enjoying a beautiful sunset on one of the few hot days San Francisco allows me to make significant progress with MaraDNS without having to stay up to 2am the way I used to) -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 27356 invoked by uid 1108); 31 May 2001 10:08:45 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 31 May 2001 10:08:45 -0700 (PDT) From: X-Sender: To: Subject: Question and answer added to the FAQ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I just had multiple people ask me about how to bind MaraDNS to multiple IP addresses. The method is as follows: You know, someone else asked me the exact smae question. The current method is to run multiple copies of MaraDNS, each using its own mararc file. E.g: maradns -f /etc/mararc.1 maradns -f /etc/mararc.2 If you just want to bind to all IP addresses your computer has, binding to the ip "0.0.0.0" *should* work. I don't think this will be too hard to correctly implement, since I already have code for specifying multiple IP addresses with the IP ACL code used by the zone server. Until then, I will add this workaround to the faq. -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28373 invoked from network); 31 May 2001 12:49:37 -0700 Received: from unknown (HELO mail.dajoba.com) (216.133.235.30) by artemas.reachin.com with SMTP; 31 May 2001 12:49:37 -0700 Received: (qmail 22212 invoked from network); 31 May 2001 19:49:30 -0000 Received: from unknown (HELO we-24-130-20-168.we.mediaone.net) ([24.130.20.168]) (envelope-sender ) by mail.dajoba.com (qmail-ldap-1.03) with SMTP for ; 31 May 2001 19:49:30 -0000 Date: Thu, 31 May 2001 12:49:29 -0700 (PDT) From: Abraham Ingersoll X-X-Sender: To: cc: Subject: binding 0.0.0.0 & misc issues with 0.5.24 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Under tinydns, one can't bind 0.0.0.0 because the source address of the UDP response has to be the same as the destination address of the original request. If you bind 0.0.0.0 and a request comes into eth0:45 (10.0.0.45), it may then go out the default interface (eth0, 10.0.0.1). Most resolvers will drop responses that don't contain the correct source IP, port and sequence ID, AFAIK. I haven't examined your code, so don't hold me up to this if I'm wrong. While trying to test this, I noticed the following too -- - ./configure isn't +x and has to be run like this: '. ./configure'. Perhaps this is only true on my dist (RH7.1), but I think almost every package I've downloaded has ./configure as u+x. - for the life of me, I can't get 0.5.24 to read db.example.com: [root@mail maradns-0.5.24]# /usr/local/bin/maradns -f /etc/mararc Log: Root directory changed Log: Socket opened on UDP port 53 Log: Root privledges dropped Fatal error: Error running populate_main program. Possible reason: There is a zone without a trailing dot (see the FAQ) [root@mail maradns-0.5.24]# cat /etc/mararc # Example mararc file chroot_dir = "/etc/maradns" csv1["example.com."] = "db.example.com" #csv1 = {} bind_address = "127.0.0.1" maradns_uid = 99 maxprocs = 64 no_fingerprint = 0 default_rrany_set = 3 max_chain = 8 max_ar_chain = 1 max_total = 20 verbose_level = 3 [root@mail maradns-0.5.24]# ls -ald /etc/maradns/ drwxr-xr-x 2 nobody root 4096 May 31 11:43 /etc/maradns/ [root@mail maradns-0.5.24]# ls -ald /etc/maradns/db.example.com -rwxr-xr-x 1 nobody nobody 359 May 31 11:43 /etc/maradns/db.example.com [root@mail maradns-0.5.24]# cat /etc/maradns/db.example.com # Zone file for example.com (example file) Sexample.com.|86400|example.com.|hostmaster@example.com.|19771108|7200|3600|604800|1800 Nexample.com.|86400|ns1.example.com. Nexample.com.|86400|ns2.example.com. # Some 'IN A' records Aexample.com.|86400|10.1.2.3 Amx.example.com.|86400|10.1.2.4 Ans1.example.com.|86400|10.0.0.1 Ans2.example.com.|86400|192.168.0.1 [root@mail maradns-0.5.24]# grep nobody /etc/passwd nobody:x:99:99:Nobody:/: [root@mail maradns-0.5.24]# uname -a Linux localhost.localhost 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686 unknown I wanted to test out MaraDNS listening on 0.0.0.0, but it keeps giving me this darned populate_main error. :( Abe On Thu, 31 May 2001 aj7kwkp@maradns.org wrote: > I just had multiple people ask me about how to bind MaraDNS to multiple IP > addresses. The method is as follows: > > You know, someone else asked me the exact smae question. > > The current method is to run multiple copies of MaraDNS, each using its > own mararc file. > > E.g: > > maradns -f /etc/mararc.1 > maradns -f /etc/mararc.2 > > If you just want to bind to all IP addresses your computer has, binding to > the ip "0.0.0.0" *should* work. > > I don't think this will be too hard to correctly implement, since I > already have code for specifying multiple IP addresses with the IP ACL > code used by the zone server. Until then, I will add this workaround to > the faq. > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28653 invoked by uid 1108); 31 May 2001 14:25:47 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 31 May 2001 14:25:47 -0700 (PDT) From: X-Sender: To: Subject: Re: binding 0.0.0.0 & misc issues with 0.5.24 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > - ./configure isn't +x and has to be run like this: '. ./configure'. > Perhaps this is only true on my dist (RH7.1), but I think almost every > package I've downloaded has ./configure as u+x. Yep, I know what broke that. I have a script (fix.perms) that does a chmod 644 on everything except a handful of scripts. That script failed to note that configure needs to be executable. > - for the life of me, I can't get 0.5.24 to read db.example.com: [snip] > #csv1 = {} I failed to correctly document this. I have just updated the FAQ and the example mararc on the web page to correctly point out that the csv1 hash has to be initialized before it can be used. The above line initializes the hash. The reason for the unusual syntax is so that it is Python-compatible--the goal is to make a mararc file a legal Python script (that does nothing except set variables, mind you). It looks like it is time to make a 0.5.25 release. Things to do: * Add the man pages that Jakko generously made to the distribution. * Have it so that the zoneserver calls itself "zoneserver" instead of "maradns" * Fix the broken perms of the configure scripts * Better explain the setup of the mararc file (the necessity of csv1 = {}, etc.) * Add the FAQ to the distribution. * If I have time, make the parser for mararc give us better error messages which are actually helpful. Actually, better error messages are better than better documentation, since the last thing a sysadmin wants to do is plow through 30 reams of documentation before using a program * Test to see how binding on 0.0.0.0 works. Let's see, the train ride to my Spanish class this afternoon takes an hour. I should also have time after the class. > I wanted to test out MaraDNS listening on 0.0.0.0, but it keeps giving me > this darned populate_main error. :( Hopefully the above notes will help you. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 29181 invoked by uid 1108); 31 May 2001 16:35:16 -0700 Date: Thu, 31 May 2001 16:35:16 -0700 (PDT) From: To: Abraham Ingersoll cc: Subject: Re: binding 0.0.0.0 & misc issues with 0.5.24 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > You must do something with the UDP response packet to make sure it goes > out the right interface?? Well, what I am doing is sending out the reply in the simplest manner. Buried in getudp is this: counter = recvfrom(sock,data->string,max_len,0,client,&len_inet); Client here is a pointer to a sockaddr structure, which will have the IP address, port, and so on that the client sent their query on. Later on, buried in far too many functions, are various forms of this: sendto(sock,reply->string,reply->unit_count,0,client,len_inet); Recvfrom does all the work of making a note of where the client connected from, in a handy form that sendto can use. With TCP connections, one does not even need the overhead of remembering the sockaddr structure to send back a reply. The connection is essentially a file, and can be treated as such. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card Note that the return address for this message times out in 90 days A permanent address is here: http://www.samiam.org/ssi/mailme.shtml From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 30388 invoked by uid 1108); 31 May 2001 22:53:17 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 31 May 2001 22:53:17 -0700 (PDT) From: X-Sender: To: Subject: Another day, another release Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, everyone. I have just released MaraDNS 0.5.25. This has a number of enhancments over MaraDNS 0.5.24, mainly cosmetic bugfixes: * Some improvement to the error handling so that MaraDNS returns appropriate error codes when certain common mistakes are made, instead of useless obscure error messages. * Jaakko Niemi provided man pages for getzone, askmara, and zoneserver. * Reference where zoneserver calls itself maradns corrected. * FAQ in the document section updated. * configure had bad perms (it wasn't executable). Fixed. * example_mararc updated to point out that csv1 = {} is essential, and that you can use the IP 0.0.0.0 to bind to all IPs a given server has. Thanks to Abraham Ingersoll for testing the special 0.0.0.0 address. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32341 invoked from network); 1 Jun 2001 14:04:37 -0700 Received: from unknown (HELO ids.trivial.3va.net) (213.132.151.223) by artemas.reachin.com with SMTP; 1 Jun 2001 14:04:37 -0700 Received: (qmail 30773 invoked by uid 500); 1 Jun 2001 21:08:20 -0000 Date: Fri, 1 Jun 2001 23:08:20 +0200 From: arjen@ids.trivial.3va.net To: list@maradns.org Subject: maradns does not run Message-ID: <20010601230820.C30688@ids.trivial.3va.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hi, i just DLled the latest snap of maradns, 0.6.19. make went ok, did what was said in the Quickstart, but [root@ids maradns-0.6.20]# ./server/maradns Log: Root directory changed Log: Socket opened on UDP port 53 Log: Root privledges dropped Warning: Can not open zone file example.com. Log: All RRs have been loaded Log: Awaiting data on port 53 netstat doesn't show anything listening on port 53. When i do a query, like [root@ids maradns-0.6.20]# host -t ns example.com 127.0.0.1 ;; connection timed out; no servers could be reached and maradns logs: -2 Log: Awaiting data on port 53 Log: Message received, processing \007example\003com\000\000\374 \003com\000\000\374 \000\000\374 Querying nameserver 127.0.0.1 Can anybody push me into the right direction? I will now do /etc/init.d/named start or you won't get my msg :) Grtz, Arjen. From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32379 invoked from network); 1 Jun 2001 14:12:20 -0700 Received: from unknown (HELO ids.trivial.3va.net) (213.132.151.223) by artemas.reachin.com with SMTP; 1 Jun 2001 14:12:20 -0700 Received: (qmail 30850 invoked by uid 500); 1 Jun 2001 21:16:05 -0000 Date: Fri, 1 Jun 2001 23:16:05 +0200 From: Arjen To: list@maradns.org Subject: Fwd: maradns does not run Message-ID: <20010601231605.A30843@3va.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-howlong: 11:14pm up 6 days, 13:51, 4 users, load average: 0.11, 0.06, 0.01 ----- Sorry, a repost, my from address doesn't resolve properly. This one does ;) ----- Hi, i just DLled the latest snap of maradns, 0.6.19. make went ok, did what was said in the Quickstart, but [root@ids maradns-0.6.20]# ./server/maradns Log: Root directory changed Log: Socket opened on UDP port 53 Log: Root privledges dropped Warning: Can not open zone file example.com. Log: All RRs have been loaded Log: Awaiting data on port 53 netstat doesn't show anything listening on port 53. When i do a query, like [root@ids maradns-0.6.20]# host -t ns example.com 127.0.0.1 ;; connection timed out; no servers could be reached and maradns logs: -2 Log: Awaiting data on port 53 Log: Message received, processing \007example\003com\000\000\374 \003com\000\000\374 \000\000\374 Querying nameserver 127.0.0.1 Can anybody push me into the right direction? I will now do /etc/init.d/named start or you won't get my msg :) Grtz, Arjen. Please be aware that anything posted to this list is publically archived. To unsubscribe to this list, send a blank message to list-unsubscribe@maradns.org ----- End forwarded message ----- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32515 invoked by uid 1108); 1 Jun 2001 14:55:55 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 1 Jun 2001 14:55:55 -0700 (PDT) From: X-Sender: To: cc: Arjen Subject: Re: Fwd: maradns does not run In-Reply-To: <20010601231605.A30843@3va.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > netstat doesn't show anything listening on port 53. UDP servers do not "listen" in the output of netstat. LISTEN only applies for processes which are TCP servers. When MaraDNS is up, the relevent line in the netstat output is this: udp 0 0 127.0.0.4:53 0.0.0.0:* > [root@ids maradns-0.6.20]# host -t ns example.com 127.0.0.1 > ;; connection timed out; no servers could be reached The default ip is 127.0.0.3, since 127.0.0.1 may be used for production use. Keep this in mind: MaraDNS 0.6.xx, while being developed as a working recursive nameserver, is not a working recursive nameserver at this point. It is, essentially, a series of pre-alpha snapshots being released in taballs instead of CVS because I feel running an open CVS server is a security concern. Even when it becomes a working nameserver, hopefully later on this week, it will probably not have good support for all of the various name servers that can exist out there. > Can anybody push me into the right direction? Yep. Download and install MaraDNS 0.5.25, which does not work as a recursive nameserver, but is stable and does everything it is supposed to do. I hope to have something ready by the end of this week. I had an original projection done a couple of months ago that today was the release date for a working recursive nameserver. Unfortunatly, some factors delayed the release: * A lack of time, caused by 12-hour days (2 hours on the train to work, 8 hours at work, and 2 hours on the way home) * The need to maintain two branches of MaraDNS * A realization that sleeping 4-6 hours a night when I was developing the authoritative-only nameserver was killing me * Difficulties "kick-starting" myself to start working on the recursive code after I had a working authoritative nameserver up and running * The Heretic video game (the original one based on the Doom engine, not the quake-engine-based Heretic II game) Of this list of excuses, the only valid one is spending time mastering Heretic instead of doing trivial things like having a production-ready recursive nameserver ready when I said it would be ready. To allow MaraDNS to be released in a timely fashion, I recently purchased a laptop computer which allows me to develop MaraDNS while on the train. This allows me to develop MaraDNS while commuting, allowing me to both work on MaraDNS and get more than six hours of sleep a night. - Sam (who now understands why open-source projects are never released on time: Heretic, Quake, Loki's offerings, etc.) -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 1336 invoked by uid 1108); 1 Jun 2001 23:18:19 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 1 Jun 2001 23:18:19 -0700 (PDT) From: X-Sender: To: Subject: Yet another CVS-style snapshot Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have released another pre-alpha snapshot of MaraDNS. This is MaraDNS 0.6.21, and it now has the ability to go to the next nameserver with a known IP. This code does not do anything useful. I am only making it public becuase I feel that making pre-alpha snapshots publically available lets people know that MaraDNS is being actively developed. Next: Add the code to handle out of bailiwick name servers. Or maybe I should just get good enough in Heretic to be able to finish E1M8 starting with just the pea shooter. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12514 invoked by uid 1108); 3 Jun 2001 20:33:02 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 3 Jun 2001 20:33:02 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.00 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII MaraDNS 0.7.00, the first pre-alpha release that can possibly be used as a real recursive nameserver, has been released. Here are the changelog notes: Albert Prats kindly provided Spanish translations for various text files. To get MaraDNS to compile in Spanish instead of English, type in ./locale.es before compiling MaraDNS. MaraDNS now can handle gluelessness. I am bumping up the minor version number to reflect that MaraDNS now has recursive nameserving capabilities, albeit without some security features. Next: Work on cache flushing and security. (2001.06.03) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12630 invoked by uid 1108); 3 Jun 2001 21:38:09 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 3 Jun 2001 21:38:09 -0700 (PDT) From: X-Sender: To: Subject: Re: MaraDNS 0.7.00 released In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > MaraDNS 0.7.00, the first pre-alpha release that can possibly be used as a > real recursive nameserver, has been released. This release can not be used as a recursive nameserver with the real root nameserver, because the root nameservers deliberately answer all queries in all-uppercase, in an attempt to keep all domain queries case-insensitive. This is what one gets when they develop internet software on a train without a internet connection. I did figure out a way to preserve case while being compatible with real-world nameservers with the authoritative nameserver. Now I have to figure out how to do the same thing with the recursive nameserver. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21325 invoked by uid 1108); 6 Jun 2001 22:34:16 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 6 Jun 2001 22:34:16 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.01 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello there. MaraDNS 0.7.01 has been released. This is strictly a "CVS snapshot" release. I have verified that it compiles, but not that it runs. It has the following two changes: * A spec sheet which describes how to add case-insensitive yet case-preserving DNS resolution. * The beginnings of code which implements just that. The addition of code which causes MaraDNS to be case-insensitive yet case-preserving will add about a week to the development cycle to MaraDNS. However, I feel that doing this right is more important than meeting some arbitrary deadline. Hopefully, there will be a stable recursive nameserver by the end of the month of June. Hopefully. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 5519 invoked by uid 1108); 11 Jun 2001 00:28:18 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 11 Jun 2001 00:28:18 -0700 (PDT) From: X-Sender: To: Subject: Whoo hoo! MaraDNS is now a working recursive nameserver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OK, there are a lot of things in the spec I still need to implement (negative cacheing, choosing a random nameserver when performing a query, cache expiration and cache size control, a secure psudo-random query ID and query port number, an ACL to determine who is allowed to make recursive queries, etc.), but MaraDNS is now a working caching name server. So, for the brave, the foolhardy, those that must have the most unstable and incomplete cutting edge version of MaraDNS, we now have a working recursive nameserver. The release I just put up is MaraDNS 0.7.02, and it does perform recursive name queries, albeit not very well. Look here for a download: http://www.maradns.org/download.html I hope to implement all of the items on the above list by the end of the month. Note that "hope" is the operative word here. This is, for better or for worse, a free software project, so things like my day job (oh, how I long for the days when things were slow and I could develop MaraDNS all day at work again), visiting my family and friends, getting something resembling sleep, my Spanish lessons, among other things, have this nasty way of slowing down development. The good news that this make the code have better quality, since it gives me time to think about the bugs the code has while doing items on the above list, allowing me to implement it right. Hopefully. Anyway, enjoy! - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 8612 invoked by uid 1108); 11 Jun 2001 23:52:35 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 11 Jun 2001 23:52:35 -0700 (PDT) From: X-Sender: To: Subject: Another release of MaraDNS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Another development snapshot of MaraDNS has been released. From the changelog: This release has implemented the ability to expire records from the cache. All Name server records have a fixed expire of 1 day (this can be changed by changing one #define in recursive.c), but all other records have an expire time based on the TTL of the record. **I have not yet tested DNS RR expire**. Also, I (think) I fixed a bug where only one case-insensitive name would have its case folded. Anyway, for the brave and foolhardy, this is my second development snapshot of MaraDNS for the day (eight minutes left in the day!) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 11899 invoked by uid 1108); 12 Jun 2001 23:41:56 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 12 Jun 2001 23:41:56 -0700 (PDT) From: X-Sender: To: Subject: The nasty cache expire bugs have been fixed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, The nasty cache expire bugs in MaraDNS 0.7.03 have been fixed in MaraDNS 0.7.04. This is what I get for releasing a development snapshot without testing my changes first. Anyway, for those foolhardy to download pre-alpha snapshots, the current cnapshot of MaraDNS has working cache expire. In other words, RRs that have expired from the cache are discarded. As always: http://www.maradns.org/download/ Next: Set MaraDNS up so that it chooses a random nameserver to query. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21663 invoked by uid 1108); 16 Jun 2001 01:48:44 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 16 Jun 2001 01:48:44 -0700 (PDT) From: X-Sender: To: Subject: I have released MaraDNS 0.7.05 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The DNS server now has a psudo-random number generator which uses the Rijndael algorithm. This PRNG randomizes both the query ID and (I believe) the source port of any and all DNS queries. This PNRG now needs to become secure (by setting up either a random or a user-defined Rijndael key) In related news, I am getting reports of incompatibility problems with MaraDNS's getzone client and the Bind 8.2.4. According to the report, this problem can be fixed by a simple one line patch (change the class of the query from 255 [all classes] to 1 [only the internet class]). Unfortunatly, the report in question failed to include the relevent portions of their named.conf file. I know that the current getzone client can get zones from other versions of Bind--I tested against Bind4, Bind8, and axfrdns when I wrote the zone client--so I need to get a machine that is in no way connected to the internet, put Bind on it, and see if it is a Bind configuration issue, or if I need to patch MaraDNS to make it Bind-compatible. I also need to make sure the patch does not break MaraDNS' zone transfer client when it talks to other zone servers. Ugh. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 22899 invoked from network); 16 Jun 2001 14:08:46 -0700 Received: from unknown (HELO trafficmagnet.net) (211.101.236.27) by artemas.reachin.com with SMTP; 16 Jun 2001 14:08:46 -0700 Received: from screencapture1 ([211.101.236.29]) by trafficmagnet.net (8.11.0/8.11.0) with ESMTP id f5GL6Yl17040 for ; Sun, 17 Jun 2001 05:06:34 +0800 Message-Id: <200106162106.f5GL6Yl17040@trafficmagnet.net> From: "Christine Hall" Subject: WWW.MARADNS.ORG To: list@maradns.org Content-Type: text/html; Sender: Christine Hall Reply-To: "Christine Hall" Date: Sun, 17 Jun 2001 05:21:37 +0800 X-Priority: 3 X-Library: Trafficmagnet 8.0

Hello,

I visited www.maradns.org and I noticed that you are not listed on some search engines. I am sure you can increase the number of people who visit www.maradns.org . Do you know TrafficMagnet? TrafficMagnet is a unique technology that instantly submits your web site to over 300,000+ search engines and directories every month. This is a very low-cost and effective way of advertising your site.

To check our prices and submit www.maradns.org to 300,000+ search engines, go to TrafficMagnet.net

I would love to hear from you.

Best Regards,
Christine Hall
Sales & Marketing
www.TrafficMagnet.net

   

From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32400 invoked by uid 1108); 17 Jun 2001 21:04:52 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 17 Jun 2001 21:04:52 -0700 (PDT) From: X-Sender: To: Subject: I have shored up the anti-spam filter Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII First of all, I would like to apologize for letting that spam through. I have taken mesaures to insure that it does not happen again--what I have done is set up the list so that only subscribers may post to the list. (I had to write a "quick and dirty" Perl script to do this because the built-in tools ezmlm has are not smart enough to look beyond the envelope sender) Since more and more people are setting up anti-spam filters to reject "bcc"'d mail, the spammers are setting up the bulk mailers so that they send one message per recipient. In the old days, when spammers had to rape open mail relays, and when the spammers had dial-up connections, nobcc filters worked. Unfortunatly, times have changed. Second of all, I have a MaraDNS 0.7.06 release almost ready to go. Once I update its FAQ, it will be released. Probably within 30 minutes. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 515 invoked by uid 1108); 17 Jun 2001 21:21:33 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 17 Jun 2001 21:21:33 -0700 (PDT) From: X-Sender: To: Subject: OK, here it is Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have released MaraDNS 0.7.06. This is a "snapshot" release that can probably be used by people willing to try out an incomplete piece of software. I have updated the non-recursive code to use code from MaraDNS 0.5.25, which adds a number of features from there (round robin rotation, etc.) I have alos made a list of things which need to be done before I can make this a beta candidate for a 1.0 release. In addition, the code now makes sure that the query ID we receive is the same one we sent out. I have also started work on a CREDITS file, updated the FAQ, and added a couple of interesting (if not MaraDNS-specific) Perl scripts to the archive. One of these scripts is the "you must be on this list to send mail to this list" script. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 6541 invoked by uid 1108); 19 Jun 2001 23:25:52 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 19 Jun 2001 23:25:52 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.07 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have released another development snapshot of MaraDNS, version 0.7.07. I have added ACLs which limit who is allowed to make recursive queries. I have also begun work on making the random number seed truly random. This is a development snapshot which is only for the brave. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7947 invoked by uid 1108); 20 Jun 2001 10:47:03 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 20 Jun 2001 10:47:03 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.08 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII MaraDNS 0.7.08 released. From the changelog: I have made the RNG truly random, and I have added code to the resolution algorithm which allows it to perform recursive queries when the only authoritative records are NS delegation records. Also, updates to the todo list. Changed cc to gcc in all the makefiles to make MaraDNS more Solaris-friendly. Note that MaraDNS does not (yet) cleanly compile on Solaris, but this is one of the (various) goals for the 1.0 release. (Solaris is a hard beast to port to compared to the free OSes, since it does not have the same header files. u_int32_t and so on are not in and so on.) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 9729 invoked by uid 1108); 20 Jun 2001 22:46:06 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 20 Jun 2001 22:46:06 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.09, a working (if incomplete) recursive nameserver Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I ave fixed a nasty bug in MaraDNS 0.7.08 where she was not properly closing open sockets. I have also begun working on the cache custodial code--code that removes entries from the cache when the cache starts to fill up. In addition, I have added code to make the cache size user-defined. I am running a "burn in" test of MaraDNS 0.7.09 right now. Other people who are interested in looking at a *currently working*, if not finished recursive DNS server that uses no code from BIND nor DJBDNS, can look here: http://www.maradns.org/download.html Next: Cache clean up. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 9986 invoked from network); 21 Jun 2001 01:13:10 -0700 Received: from unknown (HELO ids.trivial.3va.net) (213.132.151.223) by artemas.reachin.com with SMTP; 21 Jun 2001 01:13:10 -0700 Received: (qmail 27715 invoked by uid 500); 21 Jun 2001 08:15:54 -0000 Date: Thu, 21 Jun 2001 10:15:54 +0200 From: Arjen To: list@maradns.org Subject: recursive... Message-ID: <20010621101554.A27704@3va.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-howlong: 10:11am up 16 days, 15:07, 1 user, load average: 0.00, 0.00, 0.00 Hi, i just compiled 0.7.09 successfully. I tried to get it to resolve names it is not authoritive for, but haven't succeeded yet. I couldn't find anything in the docs if i need a root.cache file or something similar for the "." top level. Anyone got this to work yet? Could you tell me how you did it? Grtz, Arjen. From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 10854 invoked by uid 1108); 21 Jun 2001 09:17:00 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 21 Jun 2001 09:17:00 -0700 (PDT) From: X-Sender: To: Subject: Re: recursive... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sorry about that. I haven't bothered to document it yet. 198.41.0.4 as a root name server is currently hard-coded in to MaraDNS (in server/recursive.c, look for "198.41.0.4" in that program). Basically, add these lines to the mararc file to make recursive name service work: recursive_acl = "0.0.0.0/0" random_seed_file = "/dev/urnadom" Note that, if you only want a subset of computers making recursive queries, change the "recursive_acl" value. For example, if you want everyone on 192.168.0.xxx and 10.20.xxx.xxx, and no one else, to be able to make recursive name queries: recursive_acl = "192.168.0.0/24,10.20.0.0/16" random_seed_file = "/dev/urandom" If your OS does not have /dev/urandom, just have random_seed_file point to a file of random bytes which is at least 16 bytes long (it is a 128-bit binary seed for the secure random number generator). The file is read as root, so it should be owned by root with 600 perms if it is a fixed file. - Sam > Anyone got this to work yet? Could you > tell me how you did it? -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 11213 invoked by uid 1108); 21 Jun 2001 09:42:52 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 21 Jun 2001 09:42:52 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.10 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In a mad effort to get a beta-quality recursive nameserver released by July 1st, I have released another development snapshot of MaraDNS. This one is mainly a bigfix release: I added code which makes the recursive thingy work with cname records (hopefully, I have not had a chance to test it), I have plugged some memory leaks, and I am continuing work on the "custodian" which will remove records from the cache once the cache starts filling up. This released compiles, but I have not tested it yet. Use at your won risk. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 11291 invoked by uid 1108); 21 Jun 2001 09:55:43 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 21 Jun 2001 09:55:43 -0700 (PDT) From: X-Sender: To: Subject: Changing the configuration of this mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have just changed the configuration of this mailing list so that it adds a "Reply-To" header which points to the list. Hence, when replying to mail sent to the list, the mail will be made public unless you remove the list address (list@maradns.org) from the list of people who get the mail. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12927 invoked by uid 1108); 21 Jun 2001 23:26:22 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 21 Jun 2001 23:26:22 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.11 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As part of the mad rush to release as many releases of MaraDNS until a stable recursive nameserver becomes a reality (people who have tried using MaraDNS as a stable recursive nameserver know what I am talking about), I present the 0.7.11 (24-hour convenience store) release of MaraDNS. The release notes: Finished work on the custodian. Now, I need to make sure the custodian works. Also fixed CNAME support so it now works, plugged a couple more memory leaks, and revised the offline testbed to have a CNAME record. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 14937 invoked by uid 1108); 22 Jun 2001 23:51:45 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 22 Jun 2001 23:51:45 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.12 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII You know, tonight on the train I saw three attractive girls. I was thinking to myself how I could impress these girls so that they would think that I was, like, really cool. I realized that the best way to impress these girls would be one of the following: * Work out at the gym every day and get bug muscles * Buy a new wardrobe of clothing that looks good on me * Learn how to give back massages by becoming a certified massage therapist * Read Maxim magazine (http://www.maximonline.com) and do whatever they suggest men do to impress girls * Write a functioning recursive name server After much thought on the subject, I realized that writing a funcitonal name server was the best way to impress these girls. So I set out to do that. Which is why we have MaraDNS 0.7.12 released tonight. Only one problem: It didn't impress the girls. See, these girls, begin as hip on that internet thingy as they are, wanted to go to www.yahoo.com. Which, for technical reasons which I did not have a chance to explain to the girls, for they suddenly were too busy to talk to me when I started explaining the difference between A records and CNAME records, did not work when we were using MaraDNS to resolve www.yahoo.com. Now, if these girls were a littel more tech-savvy and wanted to go to www.google.com, I would have been able to impress them, since a query for www.google.com returns an A record instead of a CNAME record. However, a DNS query for www.yahoo.com returns a CNAME record which points to www.yahoo.akadns.net. Unfortunatly, the current version of MaraDNS, when it encounters a CNAME record, only returns the actual CNAME record. This is not a problem, except that most stub resolvers are not smart enough to, when they see a CNAME record, to perform another query to find out exactly where the CNAME in record points. Therefore, when a stub resolver asks for www.yahoo.com from MaraDNS running in recursive mode, it can not determine where it can find www.yahoo.com on the internet. Hence, I am working on the code to make MaraDNS be able to return at least one A record along with a CNAME record. More records would be nice, mind you, since www.yahoo.com is really six IPs, but I am sure the previously mentioned girls would not care that we were going to only one of the six possible IPs that www.yahoo.com xan have. Until I can come up with a version of MaraDNS that will truly impress the Yahoo-loving girls of the world, I present to you MaraDNS-0.7.12. From the changelog: More work done on plugging memory leaks. Working on code that will determine the ip for a given CNAME record, since stub resolvers are not smart enough to do a second A query themselves when they see a CNAME record. Also some minor cleanups that Franky Van Liedekerke suggested. Not mentioned in the changelog: Bug fixes which should stop a circular query from happeneing (a query where we keep asking ourselves for a given record). Basically, the recursor is only kicked on if recursion is asked for, and does not ask for recursion when making queries. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 15218 invoked from network); 23 Jun 2001 05:04:34 -0700 Received: from unknown (HELO tasty.zukeran.org) (202.238.192.20) by artemas.reachin.com with SMTP; 23 Jun 2001 05:04:34 -0700 Received: from zukeran.org (localhost [127.0.0.1]) by tasty.zukeran.org (Postfix) with ESMTP id 65D539BFDB for ; Sat, 23 Jun 2001 21:04:35 +0900 (JST) To: list@maradns.org Subject: bug in MaraDNS 0.7.12 In-reply-to: Your message of "Fri, 22 Jun 2001 23:51:45 JST" References: From: "ZUKERAN, shin" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <6259.993297875.1@zukeran.org> Content-Transfer-Encoding: 7bit Date: Sat, 23 Jun 2001 21:04:35 +0900 Sender: shin@zukeran.org Message-Id: <20010623120435.65D539BFDB@tasty.zukeran.org> Dear sam, When I am going to operate maradns as recursive name server, I found a bug. In function init_crypt (server/recursive.c), js_str is passed to open() as it is. I think this must be converted by js_js2str. I cannot yet run maradns as recursive name server. diff -uNr maradns-0.7.12.orig/server/recursive.c maradns-0.7.12/server/recursive.c --- maradns-0.7.12.orig/server/recursive.c Sat Jun 23 15:21:40 2001 +++ maradns-0.7.12/server/recursive.c Sat Jun 23 20:58:03 2001 @@ -21,6 +21,7 @@ #include #include #include +#include #include "../dns/functions_dns.h" #include "../parse/functions_parse.h" #include "../rijndael/rijndael-api-fst.h" @@ -2025,12 +2026,16 @@ int init_crypto(js_string *key) { unsigned char crypto_key[34]; int desc; + char path[MAXPATHLEN]; /* Initialize the input block and the "binKey" (is this used?) */ memset(r_inBlock,0,16); time((time_t *)&r_inBlock[0]); memset(r_binKey,0,16); /* Read the key in from the file */ - desc = open(key->string,O_RDONLY); + if(js_js2str(key,path,MAXPATHLEN) == JS_ERROR) { + return JS_ERROR; + } + desc = open(path,O_RDONLY); if(desc == -1) return JS_ERROR; if(read(desc,crypto_key,16) != 16) /* 16 bytes: 128-bit key */ ----- ZUKERAN, shin shin@ryukyu.ad.jp From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 24457 invoked by uid 1108); 24 Jun 2001 13:50:22 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 24 Jun 2001 13:50:22 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.13 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I was walking in San Francisco yesterday, you see, and I saw this very attractive girn in a red car. She had blond hair, and far too much lipstick on her lips. She smiled at me, opened up the door to her car, and said "Come in". I entered the car, and we started driving. I looked at her, smiled, and asked her "Do you like boys?" "Oh, sometimes" "Like, when" "Like, when they write a DNS server which actually works as a recursive nameserver" "Hey, listen, I'm working on it" "Yeah, but it isn't working today. How am I supposed to be impressed when your DNS server can't even perform recursive queries. What is taking you so long anyway?" "Well, girl--do you have a name, anyway--I have been fighting a cold. In addition, I have friends to visit, an ongoing series of Spanish classes, not to mention a day job as a Linux programmer and SQA monkey" "Well, Sam--and my name is Kristy--if you really loved me, you would have a working recursive DNS server. In addition, it would have support for SQL servers, allow different IPs to get different records for the same queries, have full IPV6 support..." "Even for A6 queries? A6 queries are evil" "Yeah, but do you have a better way of handling IPv6 renumbering" "Variable substitution in zone files..." "...you're not listening to me. How come, every time I need to talk to a man, instead of listening to me, he has to open up his big mouth. If you really loved me, you would also have full Solaris support, round robin rotates of data in the cache, and full Bind 8.2.4 compatibility" "These things take time to implement. I mean, if you really want all those nice features, patches will be mightily appreciated, but only after I get the core recursive name serving in reasonable condition." "Sam! You're not listening to me! See, I want a man who loves me, and a man who loves me would have already done all of these things..." "What's you name--Kristy--you know, Ihave never made love to you, so I don't understand why you are already demanding all of these things from me. I mean, a releationship is give and take. We make love, you cook for me, clean my room, and, in return, I buy you dinner and implement all of the DNS features you want." "Oh, but Sam, in order to get love, you have to first show love..." At this point, I relized that the conversation was going nowhere with Kristy, so I jumped out of the car at the next stop sign we stopped at. However, even though I was not able to make Kristy happy, we do have a 0.7.13 release of MaraDNS. This particular release does not seem to be working as a recursive DNS server. However, it does have support for returning an A record in addition to a CNAME record when an A query returns a CNAME. This took quite a bit of coding to implement, since the original data structures did not support this. In addition, Shin Zukeran provided a patch to recursive.c which properly makes a normal null-terminated string from a js_string object, to send as an argument to open() so we can get the rijndael key for the PRNG. I presume that Shin has no objections to releasing his patch to the public domain. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 25352 invoked by uid 1108); 25 Jun 2001 03:31:48 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 25 Jun 2001 03:31:48 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.14 released; credits file Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Seeking to find enlightenment? Well, for those who wish to explore more deeply the mysteries of DNS resolution, or, more practically, download and use my code, so you don't have to learn such deep things, we now have a version of MaraDNS that works as a recursive nameserver. MaraDNS 0.7.14. It is a recursive nameserver. Kinda. Sorta. Not at all on Solaris. Unfortunatly, in order to chack out the kinds sorta recursive name serving with this version of MaraDNS, I have added yet another undocumented feature that only those enlighened enough to read this list will know about. Here is the recipe for making MaraDNS an open recursive name server: recursive_acl = "0.0.0.0/0" random_seed_file = "/dev/urandom" root_servers = {} root_servers["."] = "198.41.0.4" Replace "0.0.0.0/0" with the range of IPs you wish to allow to connect to the recursive nameserver (the format is 100% identical to zone_transfer_acl, complete with ipv4_alias support), and "198.41.0.4" with the single nameserver you want to use as a root nameserver (only one nameserver right now). Download it at the usual place (http://www.maradns.org) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 25764 invoked from network); 25 Jun 2001 06:19:01 -0700 Received: from unknown (HELO tasty.zukeran.org) (202.238.192.20) by artemas.reachin.com with SMTP; 25 Jun 2001 06:19:01 -0700 Received: from zukeran.org (localhost [127.0.0.1]) by tasty.zukeran.org (Postfix) with ESMTP id 4F6EB9BFBB for ; Mon, 25 Jun 2001 22:19:03 +0900 (JST) To: list@maradns.org Subject: Re: MaraDNS 0.7.13 released In-reply-to: Your message of "Sun, 24 Jun 2001 13:50:22 JST" References: From: "ZUKERAN, shin" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15747.993475142.1@zukeran.org> Content-Transfer-Encoding: 7bit Date: Mon, 25 Jun 2001 22:19:03 +0900 Sender: shin@zukeran.org Message-Id: <20010625131903.4F6EB9BFBB@tasty.zukeran.org> In message , aj7k wkp@maradns.org writes: >In addition, Shin Zukeran provided a patch to recursive.c which properly >makes a normal null-terminated string from a js_string object, to send as >an argument to open() so we can get the rijndael key for the PRNG. > >I presume that Shin has no objections to releasing his patch to the public >domain. Of cource, I have no objections. By the way, I tried the version 0.7.14. It seems to run as recursive name server with A and NS request. However, timeout was occured if ANY request is given. I do not understand why it becomes like this. >$ nslookup >Default Server: *.*.*.* >Address: *.*.*.* > >> server 127.0.0.1 >Default Server: localhost >Address: 127.0.0.1 > >> set type=A >> www.maradns.org. >Server: localhost >Address: 127.0.0.1 > >Non-authoritative answer: >Name: www.maradns.org >Address: 64.14.214.33 > >> set type=ANY >> www.maradns.org. >Server: localhost >Address: 127.0.0.1 > >*** Request to localhost timed-out log is displayed as follows: >Log: Awaiting data on port 53 >Log: Message received, processing >Log: Bad query received: =\352\0000\206\330\010\006\370t\277\377\003www\007maradns\003org\000\000\377\000\001 ---- ZUKERAN, shin From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 2928 invoked by uid 1108); 28 Jun 2001 10:41:44 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 28 Jun 2001 10:41:44 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.15 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello there, First of all, I got some really great news. People awaiting a stable recursive nameserver can now rejoice in the streets: I was laid off from the job I work at as a Linux systems administrator. I, however, am still on good terms with them: I still have root on all their Linux servers, and am still on the list of employees who are part of the comapny (still getting Medical and Dental, etc.). And, the way I see it, anyone who can write a working recursive DNS server can probably find a job. Of course, I can see the job interview now: "Well, so you have written a working recursive nameserver, yes?" "Sure have, sir" "And does it work with all known hosts?" "Well, there is that problem with www.monty.de..." "And, does it work with the ANY DNS query? MTA use ANY queries, you know" "Well..." "Well, this job demands people who can write working DNS queries. But, we may still hire you. Here is a bell. Every time I ring it during the interview, you must sing 'Ding, song, the witch is dead'" "OK......" "And, you must sing the song on your knees. So, Sam, get down on your knees on the floor" That aside, MaraDNS is a working DNS server: I was able to use it to surf the web this morning. Don't use it for any production use yet, though: I need to get RR_ANY to work, and I need to work out the kinks that cause www.monty.de to not work (I know what the kinks are, it is just a matter of coding the fixes). The download is availale in the usual place: http://www.maradns.org. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3411 invoked from network); 28 Jun 2001 14:08:38 -0700 Received: from unknown (HELO ids.trivial.3va.net) (213.132.151.223) by artemas.reachin.com with SMTP; 28 Jun 2001 14:08:38 -0700 Received: (qmail 24693 invoked by uid 500); 28 Jun 2001 21:11:38 -0000 Date: Thu, 28 Jun 2001 23:11:38 +0200 From: Arjen To: list@maradns.org Subject: Re: MaraDNS 0.7.15 released Message-ID: <20010628231138.B24665@3va.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aj7kwkp@maradns.org on Thu, Jun 28, 2001 at 10:41:44AM -0700 X-howlong: 11:01pm up 5 days, 4 min, 1 user, load average: 0.08, 0.02, 0.01 On Thu, Jun 28, 2001 at 10:41:44AM -0700, aj7kwkp@maradns.org wrote: > > > >That aside, MaraDNS is a working DNS server: I was able to use it to surf >the web this morning. I already did that with the .14 version :) I take the liberty to speak on behalf of all peeps following maradns development: we are very proud of you Sam! I certainly hope that maradns will become a standard. That one uses Bind, Maradns or Djbdns. Pity I am not a C coder, for I would certainly join in. Keep up the good work. Arjen. From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3505 invoked from network); 28 Jun 2001 14:38:04 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 28 Jun 2001 14:38:04 -0700 Received: (qmail 20306 invoked from network); 28 Jun 2001 21:38:04 -0000 Received: from unknown (HELO pandora.be) ([213.224.90.7]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 28 Jun 2001 21:38:04 -0000 Sender: liedekef Message-ID: <3B3BA553.7468484C@pandora.be> Date: Thu, 28 Jun 2001 23:44:51 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.7.15 released References: <20010628231138.B24665@3va.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Arjen wrote: > I take the liberty to speak on behalf of all peeps following > maradns development: we are very proud of you Sam! > > I certainly hope that maradns will become a standard. That one uses > Bind, Maradns or Djbdns. Pity I am not a C coder, for I would certainly > join in. > > Keep up the good work. > > Arjen. I couldn't agree more! Keep it up, Sam! Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7684 invoked by uid 1108); 30 Jun 2001 03:22:43 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 30 Jun 2001 03:22:43 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.16 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII A funny thing happened as I was working on MaraDNS yesterday. I was trying to code a solution to the www.monty.de problem. The code I was writing was getting rather messy. But, I wanted there to be a solution, so I continued to code. Boom! The hard disk that my work on MaraDNS was stored on died this morning. I spent an hour trying to mount enough files so that I could back things up. No success. The hard disk was toast. Which means that the code I wrote last night was obviously far too sloppy to become part of MaraDNS proper. What I did do tonight was more relevent to the end user using MaraDNS: I have added documentation on how to get recursive name serving to work (finally!), and have fixed the bug where a CNAME chains (www.imdb.com and groups.yahoo.com come to mind) were not working. I also saw A.I., which I (for the most part) enjoyed seeing. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 18504 invoked by uid 1108); 1 Jul 2001 22:31:22 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 1 Jul 2001 22:31:22 -0700 (PDT) From: X-Sender: To: Subject: A MaraDNS double feature Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Tonight I have released not one, but two versions of MaraDNS. I released MaraDNS-0.7.17 earlier this afternoon with precisely 0 fanfare. Yes, sometimes I keep my releases a well-kept secret. MaraDNS-0.7.18, on the other hand, is being relesed with great fanfare: __ __ ____ _ _ ____ ___ ______ _ ___ | \/ | __ _ _ __ __ _| _ \| \ | / ___| / _ \ |___ /| |( _ ) | |\/| |/ _` | '__/ _` | | | | \| \___ \ | | | | / / | |/ _ \ | | | | (_| | | | (_| | |_| | |\ |___) | | |_| | / /_ | | (_) | |_| |_|\__,_|_| \__,_|____/|_| \_|____/ \___/(_)_/(_)|_|\___/ _ _ _ _ __ ___| | ___ __ _ ___ ___ __| | | | '__/ _ \ |/ _ \/ _` / __|/ _ \/ _` | | | | | __/ | __/ (_| \__ \ __/ (_| |_| |_| \___|_|\___|\__,_|___/\___|\__,_(_) Here are the changes: 0.7.17: We now slect a random nameserver (using the weak random() syscall because this is to balance the load between the nameservers). 0.7.18: We now properly handle cache expire for "no such host queries". Also, some documentation cleanup. There are six items on my action list before I release a more public 0.9.00 beta release of MaraDNS: Critical bug fixes: * There is a bug where the production-test DNS server does not work after resolving queries for a while. This needs to be found and fixed. * Find out why www.monty.de does not resolve. Perhaps we are exceeding the glueless level (currently 4) * The code is leaky (has memory leaks). Plug the memory leaks. (ongoing work) * The code does not stop "going up the tree" when it gets a good answer from a nameserver. Fix. Security issues: * Allow MaraDNS to change her GID (in addition to the UID) Other critical issues: * Recursive RR_ANY requests do not work. Other issues, such as Solaris support, will be handled after the 0.9.00 beta release. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 20735 invoked from network); 2 Jul 2001 16:53:09 -0700 Received: from unknown (HELO jumper.lonesom.pp.fi) (212.226.133.178) by artemas.reachin.com with SMTP; 2 Jul 2001 16:53:09 -0700 Received: by jumper.lonesom.pp.fi (Postfix, from userid 1000) id C0A686187B; Tue, 3 Jul 2001 02:53:00 +0300 (EEST) Sender: liiwi@jumper.lonesom.pp.fi To: Subject: Re: A MaraDNS double feature References: From: Jaakko Niemi Date: 03 Jul 2001 02:52:59 +0300 In-Reply-To: ('s message of "Sun, 1 Jul 2001 22:31:22 -0700 (PDT)") Message-ID: <87elryriqs.fsf@jumper.lonesom.pp.fi> Lines: 17 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Academic Rigor) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii writes: > Tonight I have released not one, but two versions of MaraDNS. I released > MaraDNS-0.7.17 earlier this afternoon with precisely 0 fanfare. Yes, > sometimes I keep my releases a well-kept secret. MaraDNS-0.7.18, on the > other hand, is being relesed with great fanfare: ... Debian package of 0.7.18 is available at: http://people.debian.org/~liiwi/ same dir holds also autoconf stuff and bits I needed to get it rolling in separate tarball. -j From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 25407 invoked by uid 1108); 4 Jul 2001 02:09:39 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 4 Jul 2001 02:09:39 -0700 (PDT) From: X-Sender: To: Subject: Happy 4th of July! Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello there, Today is the fourth of July. I assume that everyone here is familiar with this holiday which we celebrate here in the good 'ole, USA, but just in case: July 4th is a day on which we celebrate freedom and independence. This is dome with fireworks, Bar-be-cues, people drinking beer in the park, nad by making it a national holiday that most people get off. Some Americans, like myself, also celebrate July 4th by talking about the improtance of freedom in software. Freedom, like liberty, like freedom from the chains of proprietary software vendors. I could go on for hours about how great freedom in software is. Since talk is cheap, however, I figure the members of this list would prefer yet another incremental release of MaraDNS. MaraDNS 0.7.19 has been released. I am working on getting RR_ANY to work with recursive queries (this is tricky to do, because, for technical reasons, I can't just use the code that the authoritative nameserver uses to handle RR_ANY). That still need to be done. I have also added maradns_gid, which works just like maradns_uid, but for group-id numbers. Right now, I have five critical items on my action list. Three of them need to be addressed before I will go to an "alpha" branch--a branch that indicates that, while the code is not ready for public consumption, no new features of significance will be added before the 1.0 release of MaraDNS. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 26087 invoked by uid 1108); 4 Jul 2001 03:19:23 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 4 Jul 2001 03:19:23 -0700 (PDT) From: X-Sender: To: Subject: I want to go to the late night double feature MaraDNS show Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Tonight, we have, for your special pleasure and delight, the late night double feature MaraDNS show. The 0.7.20 release of MaraDNS, which I just released on the coattails of MaraDNS 0.7.19, is a bugfix release. Jaakko pointed out a nasty bug in MaraDNS last morning. Since I did most of my MaraDNS 0.7.19 work offline in a cafe, I was unable to test and fix the bug until being online tonight. The bug had to do with the fact that the MaraDNS code did not properly handle cases where there are both in-bailiwick and out-of-bailiwick name servers for a given host name, there is only one out-of-bailiwick name server, and all the in-bailiwick name servers do not function. Note to self: Do circular linked lists better next time. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 1395 invoked by uid 1108); 6 Jul 2001 20:37:22 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 6 Jul 2001 20:37:22 -0700 (PDT) From: X-Sender: To: Subject: MaraDNS 0.7.21 released Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII MaraDNS 0.7.21 released. Type ANY queries now work for recursive queries. Finally. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 1221 invoked by uid 1108); 7 Jul 2001 11:23:18 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 7 Jul 2001 11:23:18 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Mirror of webpage set up Message-ID: <20010707112318.B1196@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Due to the continual problems that the main website www.maradns.org is having with her T1 line, I have set up a secondary mirror of maradns.org: http://www2.maradns.org:8000 While this site may not always be up to date with the main one, and does not have all the files the main web site has, it has the feature of being up whenever www.maradns.org goes down. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card Note that the return address for this message times out in 2 weeks From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3928 invoked by uid 1108); 7 Jul 2001 23:58:40 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 7 Jul 2001 23:58:40 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.7.22 released Message-ID: <20010707235840.A3862@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i I think there is a reason why America has some problems getting enough people attracted to technology, and getting enough people who are serious about technology involved in the technical fields. Tonight, me and a friend [1] went to the bookstore to look at some magazines and books. We noticed a young [2] and attractive girl putting away magazines, and the three of us started talking here and there. Then she started asking us a question "Hey, since you guys are in the know, do you know if this computer thing is going to melt down..." At this point she suddenly stopped her conversation with us. She saw a tall, somewhat attractive man that she must of had a crush on, because she suddenly stopped talking with us, ran to him, gave him a big hug, and started eagerly talking to him. When my friend tried cutting in to the conversation, she dismissed us and started talking more quietly so that we could not hear her conversation any more. As for myself, as soon as this girl started talking to the man she had a crush on, I knew that it was useless trying to talk with her, so I was reading about how the Linux kernel allocates memory in this month's issue of _Linux_ magazine. I could overhear the girl refer to us dismissively as "Those computer guys". And people wonder why not enough people are interested in the technical fields here in the states. (And unlike some of my other tongue in cheek stories, this actually happened) After getting home, I fixed a couple of bugs in MaraDNS: * www.monty.de now works * It is no longer possible for the custodian (the thingy that deletes cache entries when the cache starts to fill up) to accidently delete the root name server entry, which would render the MaraDNS cache ineffective. Which is why we now have MaraDNS 0.7.22. Thanks to the kind help of Remco Rijnders [3], we now have a europian mirror. The release can be found in the following locations: http://www.maradns.org/ (Mountain View, California) http://www2.maradns.org:8000/ (Mountain View, California) http://www3.maradns.org/ (I believe Holland, Netherlands) - Sam [1] I know English grammer is supposed to place my friend before me in a statement like this, but I am speaking in collatial American, which is probably bad English. In addition, I am using me even though it is the subject instead of the direct object, but that is how Americans use this term in casual American English. [2] I didn't ask her her age, but she was probably young enough to be what we Californians (people who live in the state of California in America) call "jailbait". Until a girl turns 18 in California, it is illegal to engage in sexual releations with such a girl, hence the "jailbait" term. And yes, they do enforce these laws--the last govenor of California allocated a lot of money advertising that having sex with such a girl *will* put you in jail, and gave a lot of money to prosecutors to arrest people for doing that. More details: http://www.metroactive.com/papers/metro/12.18.97/cover/teensex-9751.html [3] Apologies to Remco, but his last name sounds a lot like "Rijndael", which is the secure PRNG I use for the query ID and query source port. -- "Reality is the most perfect vision of God's will" -- Orson Scott Card Note that the return address for this message times out in 2 weeks From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12133 invoked by uid 1108); 8 Jul 2001 10:52:50 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 8 Jul 2001 10:52:50 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS notes section Message-ID: <20010708105250.A12098@artemas.reachin.com> References: <3B483C62.57853B48@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B483C62.57853B48@pandora.be>; from liedekef@pandora.be on Sun, Jul 08, 2001 at 12:56:34PM +0200 > I was wondering about some parts of the "Notes" section on the > MaraDNS website. Especially I wonder if the following parts there are > still up-to-date with the 0.7.22 release (and newer, of course): > - How MaraDNS currently breaks the DNS spec This is still up to date. > - Known quirks in MaraDNS' behavior I just updated this the other night. It is current. > - An informal speed comparison between MaraDNS and two other DNS > servers. The informal speed question is still valid if all requests are authoritative requests. As far as recursive requests are concerned, MaraDNS is about half as fast as she is when performing authoritative requests. [1] The main reason for the slowdown is the time it takes to spwawn a new thread. Like the pdnsd program, and to a certain extent like Bind 9, MaraDNS spwawns a new thread for each and every recursive request becuase this multithreaded model is the most simple and straightforward method to implement a recursive nameserver. - Sam [1] In the case of the answer being in the cache. Otherwise, MaraDNS is as slow as the nameservers she contacts. There is a two-second delay in a recursive request every time a given nameserver is non-functional. -- "Reality is the most perfect vision of God's will" -- Orson Scott Card Note that the return address for this message times out in 2 weeks From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12921 invoked by uid 1108); 8 Jul 2001 16:29:04 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 8 Jul 2001 16:29:04 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS has gone Alpha Message-ID: <20010708162904.A12896@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello, everyone, I am releasing MaraDNS 0.8.00. This is the first "Alpha" release of the recursive nameserver. Which means that I will not add any new features. The main focus of development at this point is to find and eliminate bugs, and to get MaraDNS to sucessfully compile on as many platforms as possible. In particular, I want to get MaraDNS to compile on Solaris. The bug fixes in this release are as follows: Queries where name server entries only have hostnames and not IPs work again (I used to somewhat incorrectly call these out-of-bailiwick entries. The real name for these buggers is 'glueless name server entries'). Jaakko pointed out that a MX query for tekheads.co.uk did not work a while ago. I finally tracked down and fixed this bug: There was a subtle bug in the compression code which would only pop up in rare circumstances. Since this is a long-standing bug, the next thing I will do is release MaraDNS 0.5.26, which fixes this bug, not to mention another bug involving ANY queries (fixed in the recursive branch). Also, Remco pointed out that www3.maradns.org is, in fact, not located in Holland, but in actually located in Florida, here in the states. Anyway, MaraDNS 0.8.00 can be downloaded at the usual placed: http://www.maradns.org/ (Mountain View, CA, intermittent ISP problems) http://www2.maradns.org:8000/ (Mountain View, CA, more stable) http://www3.maradns.org/ Next: MaraDNS 0.5.26. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13760 invoked by uid 1108); 8 Jul 2001 17:51:49 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 8 Jul 2001 17:51:49 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.5.26 released Message-ID: <20010708175149.A13746@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Work on the recursive version of MaraDNS unearthed some long-standing bugs which were also present in the authoritative-only branch of MaraDNS. Hence, I have released an updated version of the authoritative-only nameserver, MaraDNS 0.5.26, which fixes these bugs. The files are available in the usual places: http://www.maradns.org/ http://www2.maradns.org:8000/ (shift-click to download) http://www3.maradns.org/ (Shift click to download the .bz2 files) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 14004 invoked by uid 1108); 8 Jul 2001 18:48:09 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 8 Jul 2001 18:48:09 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS MD5 sums Message-ID: <20010708184809.A13992@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Here are the MD5 sums of the current MaraDNS packages: cae470b23e4eaa865a4766b2663bd139 maradns-0.8.00.tar.bz2 f69c1eecc5b47aa8f16856ef39efb835 maradns-0.5.26.tar.bz2 579bfa0bbf69f8ffd95794368e90fc3a maradns-0.5.26-1.i386.rpm 7ba57ab77bd0a6eefe31bb35c7ce86f1 maradns-0.5.26-1.src.rpm - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 17077 invoked by uid 1108); 9 Jul 2001 13:02:02 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 9 Jul 2001 13:02:02 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.01 released Message-ID: <20010709130202.A17035@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Boris Manojlovic pointed out that MaraDNS does not correctly close the file descripters for zone files, limiting the number of zone files to the number of permitted file descripters. I have fixed this bug, and hence, MaraDNS 0.8.01. Md5 sum: c3adc8b61af4f02d7472084fa1f7ba72 maradns-0.8.01.tar.bz2 Let's see, the time involved in a one-line bugfix like this: * Making the actual one-line bugfix: 2 minutes * Making sure the fixed program compiles, and tarring up the new release, including changing the changelog, etc.: 5 minutes * Uploading the new bugfix to the main webserver: 2 minutes * Updating the two mirror sites so that they also are up to date: 10-15 minutes * Updating the data on freshmeat: 5 minutes * Uploading the data and file on sourceforge: 10 minutes * Making an announcement on this list: 10-15 minutes As you can see, most of the work involved with a bugfix release has little to do with the actual bugfix. With companies, it is even worse. Let us suppose one has a one-line bugfix, akin to the one-line bugfix I just made available: * It takes 5 minutes to make the one-line change * 30 minutes to compile a new release with the change * 4 hours to discuss the one line change in a meeting * Another 4 hours for the SQA department to inform all their SQA testers and all the SQA houses they have contracted out to about the change so that they can do a full SQA test of the program with the one-line bugfix. * 2 weeks for SQA to test the *entire* program. Yes, it is stupid to test things that the engineer knows have nothing to do with the change, but this is corporate America, where fear and "covering your ass" are the modus operandi. * Another week of meetings to decide that the new release is "good" * Much time coordinating with marketing to decide on how widely the release should be dessiminated, how the release should be made known to the public, etc. There are many reasons that I am really glad that I am not involved with corporate America at this time. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 17210 invoked by uid 1108); 9 Jul 2001 13:20:55 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 9 Jul 2001 13:20:55 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS SQL support Message-ID: <20010709132055.B17124@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i [This is a copy of a message I just sent to Boris Manojlovic, who is a System administrator of Verat Net ISP] Boris, If you are interested in joining the MaraDNS mailing list, send a mail to list-subscribe@maradns.org. It is a fairly low-traffic mailing list, since, right now, it only has software announcements for MaraDNS. It is a unmoderated mailing list. The only rules are: * The email address for the mailing list must be in the headers to any posting sent to the list. * Only email addresses subscribed to the list can post to the list > I've had a problems with your program. I intend to use it for ISP I work > for. I've tried to startup about 10000 domain zones. > It seems that your program does not close file descriptors while it opens a > zone files for reading from MaraBigHash.c with js_open() > Because of that there is a problem with system FD_LIMIT > which on Linux is 1024 possible open files( domain names in this case) Thanks for the heads up. I just released MaraDNS-0.8.01 which fixes this bug. Basically, there is no need to use a zone file after I add its contents to the big hash. MaraDNS uses two big hashes to store the data: * One big hash with all the authoritative data * One big hash with all the cached data for recrusive queries > And another thing how do you plan to implement SQL. These are my questions: I will not start SQL until MaraDNS 1.0.00 is out the door. I figure that I need about 1-2 months of good testing before I feel MaraDNS is stable enough to call a release "1.0.00". We're still at the stage where small things like making sure I close the files I have opened have not been fully checked yet. > 1. What Database you will use The first database I plan to support is MySQL > 2. Do you have any idea for look off tables in database >From a posting I made to the djbdns list: Here is the fields I would have in a SQL table for a RR: ID: Unique id for this row Question: The query this row is an answer for Type: The type of RR this row is an answer for TTL: The TTL for this RR Rddata: The data contined in the RR (e.g. 10.1.2.3 if it is an A query). Use a delimiter, such as a comma for RRs with multiple data points (MX and SOA records, mainly) Next: This is a pointer to the "next" row for the answer in question. If this is the last answer in the "answer" section, this will point to the first NS record in the authority section. If this is the last NS in the authority section, this points to nothing. Additional: If this is a NS, CNAME, or MX answer, this points to the IP that corresponds to the record in question. For example, if this row is an MX for "example.com", which is a preference 10 mail exchanger pointing to "mx.example.com", this will point to row with the IP for "mx.example.com". (Strangely enough, this layout has a remarkable similarity to how MaraDNS internally stores RRs. The only difference is that MaraDNS is using a structure instead of a SQL row) > 3. What sort of data will be put in db (only zones or even csv1 hashes) See above for the current idea. Basically, a conversion of the internal structure MaraDNS uses to store zones. > 4. Do you plan to have dynamic db lookup (changes in database are > imidiately viewable) Here is the plan: * First, I make MaraDNS have a more complicated lookup, in this form: Database --> Memory-based cache --> Data made visible to the end user MaraDNS can be a *lot* faster if I do not look at the database to see if someone changed the data in it before making data visible to the end user. Perhaps I can do this check every 15 minutes or so, or have a "expire" for records in the local cache (30 minutes or something similarily short, longer for records that do not get updated as often) > 5. do you need help (we here at Verat could help to do it) Yes, I think I will. Since I do not use SQL myself, and since the cries for SQL support are pretty vague about how exactly MaraDNS will store the data in a SQL table, I could use some discussion on the list from people who like using SQL as to how they would like to see the data in the database. I personally opt for something as similar as possible to how the data is stored internally by MaraDNS. I plan on, after MaraDNS 1.0.00 (September sometime), to start making the ocde more modular and receptive to having a SQL "plug in". At that point, I can have people develop SQL and other plugins. As for having zones, zones are only a convenience which is discarded after I fill up the internal data structures. It makes things much simpler to not use zones at all in a SQL database. > It looks to me that the only change needed for database zone storage is to > replace parsing functions and to make queries to database. The whole engine > would be unchanged. There is a horrible speed penalty if we do a SQL lookup for every single DNS query, so I need to implement a fairly sophisticated ram cache for the SQL data before I can think about SQL. Again, I will probably start really working on this when I am down in Mexico this September. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 20385 invoked by uid 1108); 10 Jul 2001 10:17:46 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 10 Jul 2001 10:17:46 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.02 released Message-ID: <20010710101746.A20359@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, I proudly present to the world MaraDNS 0.8.02. D Richard Felker III pointed out that when a record does not exist at the top of a zone (for example, if one has example.com. as a zone, but does not have an A record for example.com.), instead of returning a "host is not there", MaraDNS would incorrectly attempt to perform a recursive query if somone asked for Aexample.com. I have fixed this bug, and have released MaraDNS 0.8.02. It is right now available at the following locations: http://www.maradns.org (Mountain View, California, USA) http://www2.maradns.org:8000 (Mountain View, California, USA) http://www3.maradns.org (Florida, USA) Arjen has kindly set up a Europian mirror of MaraDNS. This mirror takes a little longer to be up to date, and is located here: http://maradns.subweb.cc (Holland, Netherlands) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 20445 invoked by uid 1108); 10 Jul 2001 10:21:22 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 10 Jul 2001 10:21:22 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.02 md5 sum Message-ID: <20010710102122.A20434@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i I forgot to include this in the original announcement. MaraDNS 0.8.02 has the following md5 sum: 4b2750d770ce8d35dbe61df6236a1207 maradns-0.8.02.tar.bz2 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 20809 invoked from network); 10 Jul 2001 12:24:18 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 10 Jul 2001 12:24:18 -0700 Received: (qmail 15524 invoked from network); 10 Jul 2001 19:24:17 -0000 Received: from unknown (HELO pandora.be) ([213.224.87.50]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 10 Jul 2001 19:24:17 -0000 Sender: liedekef Message-ID: <3B4B5805.C82A1083@pandora.be> Date: Tue, 10 Jul 2001 21:31:17 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: benchmark program Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi all, I just installed MaraDNS 0.8.02 (on my old laptop) with just the default example.com domain in it, and recursive requests allowed with caching. Now when I try the benchmark program, which runs for 10 seconds I get the following: Doing it for Awww.example.com. ===> 26233 queries in 10 seconds Doing it for Agames.telenet.be (non authorative domain) ===> 12582 queries in 10 seconds Now they both are A records, and both are in the cache, so can anybody explain the difference in performance for both records? Greets, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 20852 invoked from network); 10 Jul 2001 12:29:46 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 10 Jul 2001 12:29:46 -0700 Received: (qmail 23182 invoked from network); 10 Jul 2001 19:29:45 -0000 Received: from unknown (HELO pandora.be) ([213.224.87.50]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 10 Jul 2001 19:29:45 -0000 Sender: liedekef Message-ID: <3B4B594F.C25DA9A5@pandora.be> Date: Tue, 10 Jul 2001 21:36:47 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: benchmark program References: <3B4B5805.C82A1083@pandora.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Franky Van Liedekerke wrote: > Doing it for Awww.example.com. ===> 26233 queries in 10 seconds > Doing it for Agames.telenet.be (non authorative domain) ===> 12582 > queries in 10 seconds > > Now they both are A records, and both are in the cache, so can anybody > explain the difference in performance for both records? > Arghhh... I should read mail from Sam more carefully: "As far as recursive requests are concerned, MaraDNS is about half as fast as she is when performing authoritative requests. The main reason for the slowdown is the time it takes to spwawn a new thread. MaraDNS spwawns a new thread for each and every recursive request" So this would explain the difference, right? Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 31527 invoked by uid 1108); 13 Jul 2001 02:08:20 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 13 Jul 2001 02:08:20 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.03 Message-ID: <20010713020820.A31489@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i I have released MaraDNS 0.8.03. Among other things, this release has better Solaris support. I have not been able to confirm whether this actually compiles on Solaris, since the Solaris testbed system I have access to appears to have broken pthread include files. If any Solaris users could check to see if removing the appropriate four lines from the Makefile causes this to compile on Solaris, I would greatly appreciate it. I have also improved the way in which MaraDNS drops group privledges. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 31777 invoked from network); 13 Jul 2001 03:27:25 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 13 Jul 2001 03:27:25 -0700 Received: (qmail 25185 invoked from network); 13 Jul 2001 10:27:25 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 13 Jul 2001 10:27:25 -0000 Date: Fri, 13 Jul 2001 12:27:25 +0200 (CEST) From: X-X-Sender: To: Subject: Re: MaraDNS 0.8.03 In-Reply-To: <20010713020820.A31489@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi all, after a smaal change, I managed to compile MaraDNS on solaris, but now I'm getting a memory error: Aieeeeee, can not allocate memory Anybody got a clue for this? This is the last trace output: Log: Socket opened on UDP port 53 write(1, " L o g : S o c k e t ".., 34) = 34 setuid(99) = 0 setuid(0) Err#1 EPERM Log: Root privledges dropped write(1, " L o g : R o o t p r".., 29) = 29 open("db.example.com", O_RDONLY) = 5 read(5, " # Z o n e f i l e ".., 1024) = 1024 brk(0x00050170) = 0 brk(0x00052170) Err#12 ENOMEM llseek(0, 0, SEEK_CUR) = 650555 Aieeeeee, can not allocate memory!write(1, " A i e e e e e e , c a".., 34) = 34 _exit(64) On Fri, 13 Jul 2001 aj7kwkp@maradns.org wrote: > > I have released MaraDNS 0.8.03. > > Among other things, this release has better Solaris support. I have not > been able to confirm whether this actually compiles on Solaris, since the > Solaris testbed system I have access to appears to have broken pthread > include files. > > If any Solaris users could check to see if removing the appropriate four > lines from the Makefile causes this to compile on Solaris, I would greatly > appreciate it. > > I have also improved the way in which MaraDNS drops group privledges. > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32182 invoked from network); 13 Jul 2001 05:33:01 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 13 Jul 2001 05:33:01 -0700 Received: (qmail 9814 invoked from network); 13 Jul 2001 12:33:01 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 13 Jul 2001 12:33:01 -0000 Date: Fri, 13 Jul 2001 14:33:01 +0200 (CEST) From: X-X-Sender: To: Subject: Re: MaraDNS 0.8.03 In-Reply-To: <20010713020820.A31489@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I just found out why I got the memory problem on Solaris, it's because of "RLIMIT_NPROC". It's defined as "6" (in my suggested changes for solaris) while defining it as "6" on solaris does effectivily limit the memory to 6 bytes. For solaris in fact, this parameter must not be used, and I wonder why it is used in the first place: why limiting in maradns the number of processes this uid can have, while there's only one maradns program? Anyway, the solution is to change in server/MaraDns.c the lines if(setrlimit(RLIMIT_NPROC,&rlim) != 0 && errno != ENOSYS) sys_harderror(L_MAXPROC_SET); /* "Unable to set maximum number of proces ses" */ to: #ifndef SOLARIS if(setrlimit(RLIMIT_NPROC,&rlim) != 0 && errno != ENOSYS) sys_harderror(L_MAXPROC_SET); /* "Unable to set maximum number of proces ses" */ #endif The same accounts for tuzona/zoneserver.c And ofcourse, the #define RLIMIT_NPROC statement in the main Makefile must be removed again. Greets, Franky On Fri, 13 Jul 2001 aj7kwkp@maradns.org wrote: > > I have released MaraDNS 0.8.03. > > Among other things, this release has better Solaris support. I have not > been able to confirm whether this actually compiles on Solaris, since the > Solaris testbed system I have access to appears to have broken pthread > include files. > > If any Solaris users could check to see if removing the appropriate four > lines from the Makefile causes this to compile on Solaris, I would greatly > appreciate it. > > I have also improved the way in which MaraDNS drops group privledges. > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 2908 invoked by uid 1108); 14 Jul 2001 03:00:28 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 14 Jul 2001 03:00:28 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.04 released Message-ID: <20010714030028.A2897@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i I have released MaraDNS 0.8.04. Basically, it now sucessfully compiles on Solaris. I would like to think Franky for the pointers on how to get this beast to compile, and thank Danny who provided me with access to Solaris so I could test the compile of MaraDNS on Solaris. Now, on to the Sourceforge update and the Freshmeat announcment. Next: Change it so one can specify multiple root name servers. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3167 invoked from network); 14 Jul 2001 04:14:07 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 14 Jul 2001 04:14:07 -0700 Received: (qmail 26338 invoked from network); 14 Jul 2001 11:14:07 -0000 Received: from unknown (HELO pandora.be) ([213.224.87.194]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 14 Jul 2001 11:14:07 -0000 Sender: liedekef Message-ID: <3B502B26.72CD1F65@pandora.be> Date: Sat, 14 Jul 2001 13:21:10 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.04 released References: <20010714030028.A2897@artemas.reachin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit aj7kwkp@maradns.org wrote: > I have released MaraDNS 0.8.04. Basically, it now sucessfully compiles on > Solaris. I would like to think Franky for the pointers on how to get this > beast to compile, and thank Danny who provided me with access to Solaris > so I could test the compile of MaraDNS on Solaris. > > Now, on to the Sourceforge update and the Freshmeat announcment. > > Next: Change it so one can specify multiple root name servers. > > - Sam Hi Sam, two small remark for a "good" compilation on solaris: the "ifndef SOLARIS" should also be in tuzona/zoneserver.c for the RLIMIT_NPROC instruction the definition of RLIMIT_NPROC in MaraDns.h in case of SOLARIS should be deleted, it serves no purpose Greets, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 16420 invoked by uid 1108); 15 Jul 2001 13:32:38 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 15 Jul 2001 13:32:38 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.5.27 released Message-ID: <20010715133238.A16404@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i MaraDNS was in the strange state of having the "stable" branch having more known bugs than the "development" branch. No more. I just released MaraDNS 0.5.27, which incorperates two (one line) bug fixes based on bugs people recently found. For people using the authoritative-only branch, get it at the usual places. - Sam (Are people still using the authoritative-only branch?) -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 20709 invoked by uid 1108); 16 Jul 2001 22:32:06 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 16 Jul 2001 22:32:06 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.05 released Message-ID: <20010716223206.A20639@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i MaraDNS: It is no longer just a recursive name server. MaraDNS is now a political statement. Now, as a mere software developer, I try to keep myself above the level of making mere petty political statements. People who enjoy this kind of thing waste countless time arguing in Usenet and on Slashdot, trying in vain to make the perceived "other" side submit to their position. One of the common "hot button" issues that Slashdot covers is the ICANN--those people who are in charge of the top level domains. And, if you have not been partying on top of Mount Everest for the last five years, you are aware that the ICANN has added precisely 0 new TLDs. Time to spur the ICANN in to taking action. OK, so it wasn't really that deep of a political statement. See, Franky asked me to add support for multiple root name servers to MaraDNS before the 1.0 release, pointing out that having multiple root name servers increases reliability. The easiest way for me to do this was to use the already-in-place [1] ACL code (ignoring the netmasks). The already existing code makes it trivial to have various lists of IPs that various alternate namespaces use. MaraDNS now has the IP lists of no less than eight different alternate namespaces (ICANN, OSRC, AlterNIC, OpenNIC, Pacific Root, IRSC, TINC, and Super Root), which makes it trivial for one to change which namespace they wish to use. And so, MaraDNS 0.8.05 is released to the world. Keep in mind that one has to change their mararc file to use the new root nameservers. Also, I fixed an issue which allows Solaris to run the zoneserver now. http://www.maradns.org baby. - Sam [1] It is too bad English is not very good at letting people make new words by combining small words together. German is very good at this, of course. Esperanto has the art of making new words based on words already in one's vocabulary down to rocket science. -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21056 invoked by uid 1108); 16 Jul 2001 22:36:43 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 16 Jul 2001 22:36:43 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.05 MD5 sum Message-ID: <20010716223643.A21045@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i MaraDNS 0.8.05 MD5 sum: 9f07b7990e080c146fd450fb322232d6 maradns-0.8.05.tar.bz2 -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21275 invoked by uid 1108); 16 Jul 2001 23:04:18 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 16 Jul 2001 23:04:18 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: New MD5 sum for MaraDNS 0.8.05 Message-ID: <20010716230418.A21262@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i There was a two character typo in the new example_mararc file, causing people who would use it to not be able to start MaraDNS if they enabled recursive name serving. I fixed this two-character typo, and have had to update maradns-0.8.05 as a result. (I don't feel a fix this small merits a new release number) The new md5sum is: 4bbd73484c8ce532b8859b81574781fb maradns-0.8.05.tar.bz2 Note that the sourceforge mirror still has this typo, since Sourceforge makes it impossible to change a file once it has been uploaded. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21662 invoked from network); 17 Jul 2001 01:04:53 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 17 Jul 2001 01:04:53 -0700 Received: (qmail 24426 invoked from network); 17 Jul 2001 08:04:53 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 17 Jul 2001 08:04:53 -0000 Date: Tue, 17 Jul 2001 10:04:53 +0200 (CEST) From: X-X-Sender: To: Subject: Re: MaraDNS 0.8.05 released In-Reply-To: <20010716223206.A20639@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sam you're the greatest :) I'm now planning an alpa trial here with your software. Franky On Mon, 16 Jul 2001 aj7kwkp@maradns.org wrote: > > MaraDNS: It is no longer just a recursive name server. > > MaraDNS is now a political statement. > > Now, as a mere software developer, I try to keep myself above the level of > making mere petty political statements. People who enjoy this kind of > thing waste countless time arguing in Usenet and on Slashdot, trying in > vain to make the perceived "other" side submit to their position. > > One of the common "hot button" issues that Slashdot covers is the > ICANN--those people who are in charge of the top level domains. And, if > you have not been partying on top of Mount Everest for the last five > years, you are aware that the ICANN has added precisely 0 new TLDs. > > Time to spur the ICANN in to taking action. > > OK, so it wasn't really that deep of a political statement. > > See, Franky asked me to add support for multiple root name servers to > MaraDNS before the 1.0 release, pointing out that having multiple root > name servers increases reliability. > > The easiest way for me to do this was to use the already-in-place [1] ACL > code (ignoring the netmasks). The already existing code makes it trivial > to have various lists of IPs that various alternate namespaces use. > > MaraDNS now has the IP lists of no less than eight different alternate > namespaces (ICANN, OSRC, AlterNIC, OpenNIC, Pacific Root, IRSC, TINC, and > Super Root), which makes it trivial for one to change which namespace they > wish to use. > > And so, MaraDNS 0.8.05 is released to the world. Keep in mind that > one has to change their mararc file to use the new root nameservers. > > Also, I fixed an issue which allows Solaris to run the zoneserver now. > > http://www.maradns.org baby. > > - Sam > > [1] It is too bad English is not very good at letting people make new > words by combining small words together. German is very good at this, > of course. Esperanto has the art of making new words based on words > already in one's vocabulary down to rocket science. > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21748 invoked from network); 17 Jul 2001 01:24:43 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 17 Jul 2001 01:24:43 -0700 Received: (qmail 11027 invoked from network); 17 Jul 2001 08:24:43 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 17 Jul 2001 08:24:43 -0000 Date: Tue, 17 Jul 2001 10:24:43 +0200 (CEST) From: X-X-Sender: To: Subject: small bug in getzone Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I think I found a small bug in getzone. When I do getzone katho.be x.x.x.x I get for the mailserver entry: @katho.be.|3600|10@mail.katho.be. Now I think this should be (according to csv format doc) @katho.be.|3600|10|mail.katho.be. Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 26552 invoked from network); 18 Jul 2001 08:45:30 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 18 Jul 2001 08:45:30 -0700 Received: (qmail 13181 invoked from network); 18 Jul 2001 15:45:31 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 18 Jul 2001 15:45:31 -0000 Date: Wed, 18 Jul 2001 17:45:26 +0200 (CEST) From: X-X-Sender: To: Subject: heavy test shows possible memory/thread leaks Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I just tested maradns using the benchmark utility by starting 10 benchmarks in parallel. I'm always asking the same name (www.telenet.be). Now I observe some strange behaviour here: 1) after the test is finished, maradns takes up a certain amount of memory. Running the same test again and checking the memory again, I see that maradns now uses again more memory, while I expected it to stay the same for the second time. After each test, the memory keeps increasing. 2) the number of threads: when I do my 10 benchmarks in parallel, I see the number of used threads going up to 52. Running the same test again shows the number of threads is again increasing (up to 55 now). Third test: 58 threads. After waiting about 4 minutes, the number of threads boils back down to the initial number of 5. For any details: contact me :) Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 26822 invoked from network); 18 Jul 2001 09:59:14 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 18 Jul 2001 09:59:14 -0700 Received: (qmail 17591 invoked from network); 18 Jul 2001 16:59:16 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 18 Jul 2001 16:59:16 -0000 Date: Wed, 18 Jul 2001 18:59:16 +0200 (CEST) From: X-X-Sender: To: Subject: Re: heavy test shows possible memory/thread leaks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hmmm.... as far as the thread leak concerns: disregard it, apparently the number of threads reported in top is different than reported by pstack (on solaris that is). I trust pstack, which results in no thread leaks. The mem leak stays unfortunately :) On Wed, 18 Jul 2001 liedekef@pandora.be wrote: > Hi, > > I just tested maradns using the benchmark utility by starting 10 > benchmarks in parallel. I'm always asking the same name (www.telenet.be). > Now I observe some strange behaviour here: > > 1) after the test is finished, maradns takes up a certain amount of > memory. Running the same test again and checking the memory again, I see > that maradns now uses again more memory, while I expected it to stay the > same for the second time. After each test, the memory keeps increasing. > 2) the number of threads: when I do my 10 benchmarks in parallel, I see > the number of used threads going up to 52. Running the same test again > shows the number of threads is again increasing (up to 55 now). Third > test: 58 threads. After waiting about 4 minutes, the number of threads > boils back down to the initial number of 5. > > For any details: contact me :) > > Franky > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28232 invoked from network); 18 Jul 2001 11:01:04 -0700 Received: from unknown (HELO smtp9.xs4all.nl) (194.109.127.135) by artemas.reachin.com with SMTP; 18 Jul 2001 11:01:04 -0700 Received: from winter (remmy.xs4all.nl [213.84.15.171]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA18709 for ; Wed, 18 Jul 2001 20:01:04 +0200 (CEST) Received: by cistron.nl via sendmail from stdin id (Debian Smail3.2.0.111) for list@maradns.org; Wed, 18 Jul 2001 20:01:03 +0200 (CEST) Date: Wed, 18 Jul 2001 20:01:03 +0200 From: Remco Rijnders To: list@maradns.org Subject: Re: heavy test shows possible memory/thread leaks Message-ID: <20010718200103.D553@winter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.18i > On Wed, 18 Jul 2001 liedekef@pandora.be wrote: > > > Hi, > > > > I just tested maradns using the benchmark utility by starting 10 > > benchmarks in parallel. I'm always asking the same name (www.telenet.be). > > Now I observe some strange behaviour here: > > > > 1) after the test is finished, maradns takes up a certain amount of > > memory. Running the same test again and checking the memory again, I see > > that maradns now uses again more memory, while I expected it to stay the > > same for the second time. After each test, the memory keeps increasing. I'm not an expert at all on these things, but I compiled maradns with a memorychecker. To do this I changed MaraDNS.c to #include at the top and to add the following call as the first function call in the main() function: mtrace(); After compiling, I started the program, and it resulted in the following output: Memory not freed: ----------------- Address Size Caller 0x08068fa8 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08068fc8 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x080690d0 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x080690f0 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x080691f8 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069218 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069320 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069340 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069448 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069468 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069570 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069590 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069698 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x080696b8 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x080697c0 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x080697e0 0x43 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069828 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069848 0x303 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 0x08069b50 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 (rest of output snipped) Perhaps this gives Sam a pointer as to where to look? Remmy -- ICQ: 760542, Tel: (+31) 6 11316573, http://www.webconquest.com -*- Zippy's revelation of the moment: -*- BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI-BI- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28315 invoked by uid 1108); 18 Jul 2001 11:07:18 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 18 Jul 2001 11:07:18 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: heavy test shows possible memory/thread leaks Message-ID: <20010718110717.A28284@artemas.reachin.com> References: <20010718200103.D553@winter> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010718200103.D553@winter>; from remmy@cistron.nl on Wed, Jul 18, 2001 at 08:01:03PM +0200 This can very well be a legitimate problem. The problem, however, could be that these could just simply be cases where items are being added to the cache. Items in the cache are not freed until they expire from the cache (and only when the custodian looks for them). I will look at it tonight, when I have time again. - Sam > 0x08068fa8 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08068fc8 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x080690d0 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x080690f0 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x080691f8 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069218 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069320 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069340 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069448 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069468 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069570 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069590 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069698 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x080696b8 0x103 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x080697c0 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x080697e0 0x43 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069828 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069848 0x303 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 > 0x08069b50 0x18 at /home/remmy/maradns-0.8.05/libs/JessStrOS.c:25 -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28356 invoked from network); 18 Jul 2001 11:10:47 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 18 Jul 2001 11:10:47 -0700 Received: (qmail 18419 invoked from network); 18 Jul 2001 18:10:46 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 18 Jul 2001 18:10:46 -0000 Date: Wed, 18 Jul 2001 20:10:46 +0200 (CEST) From: X-X-Sender: To: Subject: Re: heavy test shows possible memory/thread leaks In-Reply-To: <20010718110717.A28284@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 18 Jul 2001 aj7kwkp@maradns.org wrote: > > The problem, however, could be that these could just simply be cases where > items are being added to the cache. Items in the cache are not freed > until they expire from the cache (and only when the custodian looks for > them). This would be the case, if I not always asked for the same entry in my tests, so I expect this to be cached of course :) From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28416 invoked from network); 18 Jul 2001 11:13:33 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 18 Jul 2001 11:13:33 -0700 Received: (qmail 21038 invoked from network); 18 Jul 2001 18:13:34 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 18 Jul 2001 18:13:34 -0000 Date: Wed, 18 Jul 2001 20:13:34 +0200 (CEST) From: X-X-Sender: To: Subject: max number of threads Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Sam, I just realized why you use the setrlimit call to set the max number of processes: in linux (at least 2.2.* kernel) , a thread is emulated by a process, so this is an easy way of accomplishing this. On solaris, where a thread is really a thread (with the risk of starting a OS war), this limit of course is of no use. But then again, there's really a need to limit the number of threads, so what I suggest would be (in order to get the limit to work on solaris as well): in the parent process, increment a counter for each thread successfully created (using mutex_lock and mutex_unlock of course) unless counter is equal to the max number specified.. Then for each started thread, wherever it may exit, call a function that (also using mutex) decrements the counter again. Of course, there may be better/other ways of accomplishing this, this was just "wild thinking". Greets, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28469 invoked by uid 1108); 18 Jul 2001 11:18:08 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 18 Jul 2001 11:18:08 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: SECURITY: MaraDNS 0.5.28 and MaraDNS 0.8.06 released Message-ID: <20010718111808.C28284@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello, everyone, First of all, I would like to thank Roy Arends for pointing out that MaraDNS has the following security hole: * Send a packet to a MaraDNS server with a spoofed source address of the MaraDNS server * MaraDNS will send a reply to herself * MaraDNS will then, incorrectly, reply to the reply she sent herself * Then reply to that reply * And so on (sort of like the tupperwear ad from the 70s, if anyone else remembers that ad) Anyway, I have released both MaraDNS 0.5.28 and MaraDNS 0.8.06, which fix the bug. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28506 invoked from network); 18 Jul 2001 11:18:25 -0700 Received: from unknown (HELO smtp9.xs4all.nl) (194.109.127.135) by artemas.reachin.com with SMTP; 18 Jul 2001 11:18:25 -0700 Received: from winter (remmy.xs4all.nl [213.84.15.171]) by smtp9.xs4all.nl (8.9.3/8.9.3) with ESMTP id UAA20596 for ; Wed, 18 Jul 2001 20:18:26 +0200 (CEST) Received: by cistron.nl via sendmail from stdin id (Debian Smail3.2.0.111) for list@maradns.org; Wed, 18 Jul 2001 20:18:25 +0200 (CEST) Date: Wed, 18 Jul 2001 20:18:25 +0200 From: Remco Rijnders To: list@maradns.org Subject: Re: heavy test shows possible memory/thread leaks Message-ID: <20010718201825.E553@winter> References: <20010718200103.D553@winter> <20010718110717.A28284@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20010718110717.A28284@artemas.reachin.com> User-Agent: Mutt/1.3.18i On Wed, Jul 18, 2001 at 11:07:18AM -0700, aj7kwkp@maradns.org wrote: > This can very well be a legitimate problem. > > The problem, however, could be that these could just simply be cases where > items are being added to the cache. Items in the cache are not freed > until they expire from the cache (and only when the custodian looks for > them). These were the results after doing a few queries and then ctrl-c'ing out of maradns. However, when I ran this test using the benchmark program, the output was many many times larger... after about roughly 2000 queries using the benchmark program the list with memleaks was 4637 lines long where it was much shorter after doing just a few identical askmara queries on example.com. > I will look at it tonight, when I have time again. Ofcourse :) Thanks for the great work! Remmy -- ICQ: 760542, Tel: (+31) 6 11316573, http://www.webconquest.com -*- Zippy's revelation of the moment: -*- What GOOD is a CARDBOARD suitcase ANYWAY? From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28575 invoked by uid 1108); 18 Jul 2001 11:32:42 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 18 Jul 2001 11:32:42 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: max number of threads Message-ID: <20010718113242.D28284@artemas.reachin.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from liedekef@pandora.be on Wed, Jul 18, 2001 at 08:13:34PM +0200 > On solaris, where a thread is really a thread (with the risk of starting > a OS war) You know, I used to be rather annoyed with Solaris. Why? In the days of the dot-com boom, job interviews I had trying to get a systems administrator position would go like this: Interviewer: So, Sam, how much Solaris experience do you have? Me: I have five years of Linux experience Interviewer: But, that doesn't count. How many years have you been using SOLARIS? Me: Well... Interviewer: (In so many words) Linux is not a real OS. We only hire Solaris people. Bye. I got out of the trap of working tech support and SQA by working for, of all people, Microsoft as a contract programmer. Microsoft looked good enough on my resume that it was pretty easy to get a dot-com job after that. At least for the year or so before the who dot-com thing went kaput. Now the surviving dot-coms are moving to Linux to save costs (Amazon and IMDB both now use Linux for their web servers), many Solaris people are on the street desperately looking for work, along with all of the Linux people who used to work for Linuxcare (before the layoffs), icast, VA Linux (before the layoffs), and so on. I actaully have a pretty nasty page about Solaris up, which I will replace with these comments I just posted to the list. > in the parent process, increment a counter for each thread successfully > created (using mutex_lock and mutex_unlock of course) unless counter is > equal to the max number specified.. Then for each started thread, wherever > it may exit, call a function that (also using mutex) decrements the > counter again. Sounds like a good way to do it. Probably better than the current way, because it is more portable. The "limit the processes" code is a bit of legacy code which was written in the days when MaraDNS would fork() a new process to answer a DNS query. (the 0.4.xx series, IIRC) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 29248 invoked by uid 1108); 18 Jul 2001 12:05:40 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 18 Jul 2001 12:05:40 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Md5 sums of the new releases Message-ID: <20010718120540.A29237@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i I forgot the Md5 sums in the last announcment: e43b74eadc29e756ca1365a1c79586e5 maradns-0.8.06.tar.bz2 6f2282a59377703a04d2b260a9d321ed maradns-0.5.28.tar.bz2 17f40573bfc819be3c88b2f263739cfb maradns-0.5.28-1.i386.rpm a6956fb1748f2f3ceb5665e5a5d324ce maradns-0.5.28-1.src.rpm - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 29323 invoked from network); 18 Jul 2001 12:27:57 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 18 Jul 2001 12:27:57 -0700 Received: (qmail 23460 invoked from network); 18 Jul 2001 19:27:56 -0000 Received: from unknown (HELO pandora.be) ([213.224.87.108]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 18 Jul 2001 19:27:56 -0000 Sender: liedekef Message-ID: <3B55E4E9.57A7E140@pandora.be> Date: Wed, 18 Jul 2001 21:35:06 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: max number of threads References: <20010718113242.D28284@artemas.reachin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Don't get me wrong, I also like linux much better, but you know the rule: company policy ... Maybe I can try to convince them to switch over one day. They already listened to me when I advised to switch to linux for the qmail servers, I'd love to see some of the money they saved by not having to pay for solaris support and incredible expensive sparc HW. Btw I think the 2.4 kernel has native thread support, so the change would be probably needed there as well (I'm not sure, so don't shoot me if I'm wrong). Franky And as a finishing touch, one of my favorite quotes: ====================================================================== The manual said: "install Win95 or better" so I installed linux. ====================================================================== aj7kwkp@maradns.org wrote: > > On solaris, where a thread is really a thread (with the risk of starting > > a OS war) > > You know, I used to be rather annoyed with Solaris. Why? In the days of > the dot-com boom, job interviews I had trying to get a systems > administrator position would go like this: > > Interviewer: So, Sam, how much Solaris experience do you have? > > Me: I have five years of Linux experience > > Interviewer: But, that doesn't count. How many years have you been using > SOLARIS? > > Me: Well... > > Interviewer: (In so many words) Linux is not a real OS. We only hire > Solaris people. Bye. > > I got out of the trap of working tech support and SQA by working for, of > all people, Microsoft as a contract programmer. Microsoft looked good > enough on my resume that it was pretty easy to get a dot-com job after > that. At least for the year or so before the who dot-com thing went > kaput. > > Now the surviving dot-coms are moving to Linux to save costs (Amazon and > IMDB both now use Linux for their web servers), many Solaris people are on > the street desperately looking for work, along with all of the Linux > people who used to work for Linuxcare (before the layoffs), icast, VA > Linux (before the layoffs), and so on. > > I actaully have a pretty nasty page about Solaris up, which I will replace > with these comments I just posted to the list. > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32348 invoked by uid 1108); 19 Jul 2001 09:46:37 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 19 Jul 2001 09:46:37 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: List of current MaraDNS bugs Message-ID: <20010719094637.A32310@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i There is an interesting article that Slashdot current points to, whoses thesis is that good software takes ten years to develop. Not true. Well, OK, true for really big projects. Linux is just starting to become a true enterprise-class OS, and has been in development for a little over 10 years. A DNS server, however, takes roughly six months to develop. Probably another six months before it is ready for a 1.0 release. Software development consists of four stages: 1. Design 2. Develop 3. Debug 4. Document Right now, MaraDNS is at stage 3, "Debug". Here is the current list of bugs to fix: Current known bugs: * Looks like the code which "overwrites" an element in the cache fails to add the new element after overwriting the old data. * The getzone client does not handle a zone with root nameservers correctly * The getzone client sometimes outputs an @ instead of a | as a delimiter for a MX record she gets. * Change Rijndael Makefile, since NetBSD's make doesn't like it * Asking for a non-A record which points to a CNAME still chases down the A record. Fix. * Make sure a CNAME request still "goes through", even if we can't find the A record assosciated with the CNAME record. * Make sure the recursive code is not leaking. That said, I am in the process of moving, so I probably won't have time to look at these bugs until this weekend. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 14770 invoked from network); 22 Jul 2001 05:19:14 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 22 Jul 2001 05:19:14 -0700 Received: (qmail 712 invoked from network); 22 Jul 2001 12:15:23 -0000 Received: from unknown (HELO pandora.be) ([213.224.89.93]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 22 Jul 2001 12:15:23 -0000 Sender: liedekef Message-ID: <3B5AC58E.320AB8D0@pandora.be> Date: Sun, 22 Jul 2001 14:22:38 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: How does MaraDns react to cache poisining? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit definition of cache poisoning: a malicious attacker might set up a dns server that, when queried, returns forged additional records. This way, he might replace trusted servers in your cache with his own ones by making your dns server return bad IP addresses I've seen this happen in Bind, I've read that pdnsd and djbdns protect themselves from this (pdnsd is configurable for this). Dunno about latest versions of Bind. So I wonder: how does MaraDns react to this poisoning? Greets, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 15474 invoked by uid 1108); 22 Jul 2001 11:47:27 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 22 Jul 2001 11:47:27 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: How does MaraDns react to cache poisining? Message-ID: <20010722114727.A15367@artemas.reachin.com> References: <3B5AC58E.320AB8D0@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5AC58E.320AB8D0@pandora.be>; from liedekef@pandora.be on Sun, Jul 22, 2001 at 02:22:38PM +0200 > I've seen this happen in Bind, I've read that pdnsd and djbdns protect > themselves from this (pdnsd is configurable for this). Dunno about > latest versions of Bind. So I wonder: how does MaraDns react to this > poisoning? Depends on where the bad records are. The way we process name server referrals with the same names in the additional section is by ignoring the names, and storing in the cache the IPs of the name server in question. For example, let us suppose that www.killerporn.nasty.foo wants to poison our cache: $ dig @ns.nasty.foo www.killerporn.nasty.foo ;; ANSWER SECTION ; blank ;; AUTHORITY SECTION killerporn.nasty.foo. 123456 IN NS www.google.com. killerporn.nasty.foo. 123456 IN NS www.cnn.com. ;; ADDITIONAL SECTION www.google.com. 123456 IN A 10.1.2.3 www.cnn.com. 123456 IN A 10.1.2.4 When MaraDNS, in recursive mode, sees these bad records, what she does is this: * She does not change the values for "www.google.com" nor "www.cnn.com" in the cache. * She "links" the records in question, and stores this in the cache: killerporn.nasty.foo. 123456 IN NS 10.1.2.3 killerporn.nasty.foo. 123456 IN NS 10.1.2.4 --- In the case of a NS record being out of bailiwick, MaraDNS discards the out-of-bailiwick records. E.G: $ dig @ns.nasty.foo www.killerporn.nasty.foo ;; ANSWER SECTION ; blank ;; AUTHORITY SECTION com. 123456 IN NS ns1.killerporn.nasty.foo. killerporn.nasty.foo. 123456 IN NS ns2.killerporn.nasty.foo. killerporn.nasty.foo. 123456 IN NS ns3.killerporn.nasty.foo. ;; ADDITIONAL SECTION ns1.killerporn.nasty.foo. 123456 IN A 10.1.2.1 ns2.killerporn.nasty.foo. 123456 IN A 10.1.2.2 ns3.killerporn.nasty.foo. 123456 IN A 10.1.2.3 The "com." record is discarded, and the other two records are added to the cache. --- In the case of an answer being an answer for something besides our question, we discard the answer. --- Note that I need to perform regression tests to verify that this is how MaraDNS acts. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 16310 invoked from network); 22 Jul 2001 16:41:47 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 22 Jul 2001 16:41:47 -0700 Received: (qmail 22663 invoked from network); 22 Jul 2001 20:43:25 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 22 Jul 2001 20:43:25 -0000 Date: Sun, 22 Jul 2001 22:43:28 +0200 (CEST) From: X-X-Sender: To: Subject: Re: How does MaraDns react to cache poisining? In-Reply-To: <20010722114727.A15367@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cool, so if the regression test comes out ok, cache poisoning is a nono in MaraDns. Tx, Sam. Franky On Sun, 22 Jul 2001 aj7kwkp@maradns.org wrote: > > > I've seen this happen in Bind, I've read that pdnsd and djbdns protect > > themselves from this (pdnsd is configurable for this). Dunno about > > latest versions of Bind. So I wonder: how does MaraDns react to this > > poisoning? > > Depends on where the bad records are. > > The way we process name server referrals with the same names in the > additional section is by ignoring the names, and storing in the cache the > IPs of the name server in question. > > For example, let us suppose that www.killerporn.nasty.foo wants to poison > our cache: > > $ dig @ns.nasty.foo www.killerporn.nasty.foo > > ;; ANSWER SECTION > ; blank > > ;; AUTHORITY SECTION > killerporn.nasty.foo. 123456 IN NS www.google.com. > killerporn.nasty.foo. 123456 IN NS www.cnn.com. > > ;; ADDITIONAL SECTION > www.google.com. 123456 IN A 10.1.2.3 > www.cnn.com. 123456 IN A 10.1.2.4 > > When MaraDNS, in recursive mode, sees these bad records, what she does is > this: > > * She does not change the values for "www.google.com" nor "www.cnn.com" in > the cache. > > * She "links" the records in question, and stores this in the cache: > > killerporn.nasty.foo. 123456 IN NS 10.1.2.3 > killerporn.nasty.foo. 123456 IN NS 10.1.2.4 > > --- > > In the case of a NS record being out of bailiwick, MaraDNS discards the > out-of-bailiwick records. E.G: > > $ dig @ns.nasty.foo www.killerporn.nasty.foo > > ;; ANSWER SECTION > ; blank > > ;; AUTHORITY SECTION > com. 123456 IN NS ns1.killerporn.nasty.foo. > killerporn.nasty.foo. 123456 IN NS ns2.killerporn.nasty.foo. > killerporn.nasty.foo. 123456 IN NS ns3.killerporn.nasty.foo. > > ;; ADDITIONAL SECTION > ns1.killerporn.nasty.foo. 123456 IN A 10.1.2.1 > ns2.killerporn.nasty.foo. 123456 IN A 10.1.2.2 > ns3.killerporn.nasty.foo. 123456 IN A 10.1.2.3 > > The "com." record is discarded, and the other two records are added to the > cache. > > --- > > In the case of an answer being an answer for something besides our > question, we discard the answer. > > --- > > Note that I need to perform regression tests to verify that this is how > MaraDNS acts. > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 1167 invoked by uid 1108); 27 Jul 2001 00:18:47 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 27 Jul 2001 00:18:47 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS update Message-ID: <20010727001847.A1146@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello, there, This is a non-update update on the progress of MaraDNS. Namely, that there has not been any in the last week. I have been moving this last week, as I allued to in a previous posting. As of tonight, I have completed my move: * Moving everything out of where I was living in San Francisco, and taking it to the trash, recycling it, taking it to storage, or taking it to the temporary place of residence I had in San Jose. * Building a computer for a friend out of old used parts hanging around. This took a while, since I had to deal with DOA motherboards and BIOSes too dumb to boot from a CDROM drive. * Today, moving everything in my temporary residence in San Jose, putting it in my car, and driving down to San Diego. * Figuring out how to hook up to my family's internet connection. Is it possible to get on the 'net with an AOL DSL account? I will find out very soon. Until then, I am using the dialup account which will cease to be on August 9th--two weeks from today. Anyway, I have a headache from driving all day today (I managed to do the San Jose-San Diego drive in 8.5 hours), and am about to go to bed. Now that I am in San Diego, and have finished my moving for now (I get to do some moving again when I go down to Mexico) I should have more time to work on MaraDNS. I have a long list of bugs that need to be fixed. I will start on the bugs with the getzone zone transfer client, then work on some of the other nasty bugs that MaraDNS has. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 4859 invoked by uid 1108); 27 Jul 2001 22:33:11 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 27 Jul 2001 22:33:11 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.07 released Message-ID: <20010727223311.A4843@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, Now that I am settled down in San Diego, I have had time to release version 0.8.07 of MaraDNS. This has three bug fixes: * The same bug which allowed a loop to happen with the UDP server was also in the TCP zone server. This is less critical than the UDP bug, since it is difficult, with most modern unices, to spoof a TCP source address. * Franky pointed out that the getzone client incorrectly formats MX records. Fixed. * I noticed that the getzone client incorrectly formats pointers to the root nameserver(s). Fixed. Next: Figure out how to access an AOL DSL account from Linux. This dialup lag is driving me crazy. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 4959 invoked by uid 1108); 27 Jul 2001 22:53:09 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 27 Jul 2001 22:53:09 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.07 MD5 sum Message-ID: <20010727225309.A4948@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i MaraDNS 0.8.07 Md5 sum: 8d12d17ef682f5306c5fe81238f672a9 maradns-0.8.07.tar.bz2 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7868 invoked by uid 1108); 28 Jul 2001 23:14:33 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 28 Jul 2001 23:14:33 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.08 released Message-ID: <20010728231433.A7850@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello, I present to you, my faithgul subscribers, MaraDNS 0.8.08, the obsolete and overpriced Roland drum machine release. [1] This is a bug swatting release. Basically: * The problem that was causing www.fairytale-abuse.com to not resolve is fixed. (Better lame delegation handling) * The problem that was causing www.cs.cmu.edu and www.roaringpenguin.com to not resolve is fixed (Better case sensitivity handling) - Sam [1] Back in 1982, in Keyboard Magazine's review of the Linn Drum, they indirectly compared the Rolard TR-808 to "Marching Anteaters locked in 4/4 time" -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7911 invoked by uid 1108); 28 Jul 2001 23:15:14 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 28 Jul 2001 23:15:14 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.08 Md5 SUM Message-ID: <20010728231514.B7850@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i MaraDNS 0.8.08 Md5 sum: f01068a8ad800b545d33a564e326637f maradns-0.8.08.tar.bz2 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 23907 invoked by uid 1108); 3 Aug 2001 02:26:51 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 3 Aug 2001 02:26:51 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.09 released Message-ID: <20010803022651.A23885@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i Finally, after a week, I have released another copy of MaraDNS. Let me tell you, my friend's cable modem conneciton to the internet, like, really rocks. Development is a breeze with this internet connection. In fact, this connection is so nice, I even remembered to include the Md5sum in the release notes, instead of needing to place it in a separate message. MaraDNS 0.8.09 has better lame delegation handling, and fixed another minor bug, allowing "linuxemu.retrofaction.com" to correctly resolve. In addition, in the interest of making sure all new tools added to MaraDNS are directly DNS-releated, I added a Perl script which filters mail against the SirCam virus to the MaraDNS package. One may get the impression that the MaraDNS tarball is being used to puff up my resumé, among other things. In fact, for the first time, I proudly present the Md5 sum of MaraDNS, without needing to include it in a separate mailing: f36ca9e670f47b18c465b6e8d3ae2811 maradns-0.8.09.tar.bz2 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 24085 invoked by uid 1108); 3 Aug 2001 02:32:55 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 3 Aug 2001 02:32:55 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Now I know why I always forget the md5 sum Message-ID: <20010803023255.A24042@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, I realized, after "releasing" MaraDNS, that I forgot to change the flags in server/Makefile to make a functioning DNS server. Hence, I have change the flags so that MaraDNS can be used for production use. It's a one-byte change, but this necessitates a new md5sum: 0787fa045530ac37912a1ed212b0a55e maradns-0.8.09.tar.bz2 Thank you for your understanding. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28423 invoked from network); 3 Aug 2001 09:20:06 -0700 Received: from unknown (HELO gateway.local.net) (193.218.212.121) by artemas.reachin.com with SMTP; 3 Aug 2001 09:20:06 -0700 Received: from dynamic-25.local.net (cloned.local.net) [192.168.100.125] by gateway.local.net with smtp (Exim 2.05 #1 (Debian)) id 15ShgN-00031T-00; Fri, 3 Aug 2001 18:20:15 +0200 From: Michael Knigge Date: Fri, 03 Aug 2001 16:20:05 GMT Message-ID: <20010803.16200570@cloned.local.net> Subject: Multiple Domains? To: list@maradns.org X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Win32) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, I'm new to maradns and just entered two problemns. The first is: How can I tell maradns to handle more than one domain?=20= We have our official Domain "set-software.de" and for our LAN the=20 internal Domain "local.net". I wand maradns to handle both - but how? My second problem is: nslookup will not work :-( Here is my db file (just an extract): Slocal.net.|86400|local.net.|root@set-software.de.|1|7200|3600|604800 |1800 Nlocal.net.|86400|dns.local.net. # gateway.local.net ########################################### Adns.local.net.|86400|192.168.100.222 P222.100.168.192.in-addr.arpa.|86400|dns.local.net. Cwww.local.net.|86400|dns.local.net. Cmail.local.net.|86400|dns.local.net. Cproxy.local.net.|86400|dns.local.net. Cgateway.local.net.|86400|dns.local.net. Now, when I just start "nslookup" I see the following in the=20 /var/log/syslog: Bad query received:=20 \2248\001\000\000\001\000\000\000\000\000\000\\0011\0010\0010\003127\ 007in-addr\004arpa\000\000\014\000\001 Seems to me he wants so resolve 127.0.0.1.... But it is contained in=20= my /etc/hosts: 127.0.0.1 localhost Can anybody help me?!? Thank you Michael From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28777 invoked from network); 3 Aug 2001 09:43:44 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 3 Aug 2001 09:43:44 -0700 Received: from pandora.be (D5E058B7.kabel.telenet.be [213.224.88.183]) by pop3.telenet-ops.be (Postfix) with ESMTP id 2FE869BB49 for ; Fri, 3 Aug 2001 18:43:46 +0200 (CEST) Sender: liedekef@pop3.telenet-ops.be Message-ID: <3B6AD67B.6311E62E@pandora.be> Date: Fri, 03 Aug 2001 18:51:07 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: Multiple Domains? References: <20010803.16200570@cloned.local.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm gonna take a shot at this, but if I'm wrong, feel free to correct me :) Michael Knigge wrote: > Hi all, > > I'm new to maradns and just entered two problemns. > > The first is: How can I tell maradns to handle more than one domain? > We have our official Domain "set-software.de" and for our LAN the > internal Domain "local.net". I wand maradns to handle both - but how? Add the folowing to the mararc file: csv1["local.net."] = "db.local.net" csv1["set-software.de."] = "db.set-software.de" and create those db files. > > My second problem is: nslookup will not work :-( > > Here is my db file (just an extract): > > Slocal.net.|86400|local.net.|root@set-software.de.|1|7200|3600|604800 > |1800 > Nlocal.net.|86400|dns.local.net. > > # gateway.local.net > ########################################### > Adns.local.net.|86400|192.168.100.222 > P222.100.168.192.in-addr.arpa.|86400|dns.local.net. > > Cwww.local.net.|86400|dns.local.net. > Cmail.local.net.|86400|dns.local.net. > Cproxy.local.net.|86400|dns.local.net. > Cgateway.local.net.|86400|dns.local.net. > > Now, when I just start "nslookup" I see the following in the > /var/log/syslog: > > Bad query received: > \2248\001\000\000\001\000\000\000\000\000\000\\0011\0010\0010\003127\ > 007in-addr\004arpa\000\000\014\000\001 > > Seems to me he wants so resolve 127.0.0.1.... But it is contained in > my /etc/hosts: > > 127.0.0.1 localhost > > Can anybody help me?!? > An old nslookup bug: there are two awys to solve this: 1) use the following command sequence: nslookup server 127.0.0.1 2) if you use "nslookup 127.0.0.1": make sure this 127.0.0.1 exists somewhere in a zone definition. From example_cvs1: # A 'PTR' record which, while marked as unauthoritative, allows this # program to work with nslookup when bound on IP 127.0.0.3 P3.0.0.127.in-addr.arpa.|1234|nslookup.bug.workaround. Here it is done for 127.0.0.3, but just change it to 127.0.0.1 and you're all set. But if you use your public ip to query using nslookup, you won't have these problems (if the ip is resolvable) Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 31002 invoked from network); 3 Aug 2001 13:11:56 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 3 Aug 2001 13:11:56 -0700 Received: from pandora.be (D5E058B7.kabel.telenet.be [213.224.88.183]) by tartarus.telenet-ops.be (Postfix) with ESMTP id 8B525216FD0 for ; Fri, 3 Aug 2001 22:11:55 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B6B0741.F3565B53@pandora.be> Date: Fri, 03 Aug 2001 22:19:14 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Bug in MaraDNS 0.8.09 askmara client References: <20010803022651.A23885@artemas.reachin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit It took me a while to figure it out, but now I have it pinned down: the askmara client doesn't work any more for recursive queries, it *does* work for authorative queries. The askmara client I compiled with the MaraDNS 0.8.06 source works just fine. I tried copying the askmara source from 0.8.06 to 0.8.09 (very little differences) and compile (which works) but still nothing. nslookup also works fine (that's what took me so long: I didn't use nslookup at first and was surprised to see it working where askmara didn't). Now the error I receive: from askmara: Server reply: Query id: 6 Query type: 1 Opcode: 0 Authoritative: 0 Truncated: 0 Recurs desired: 0 Recurs available: 0 Z data: 0 Result code: 5 Num Questions: 0 Num Answers: 0 Number NS records: 0 Number additional records: 0 and with verbose_level=3, at the server: Log: Bad query received: \000\006\000\000\000\001\000\000\000\000\000\000\003www\007telenet\002be\000\000\001\000\001 Hope this helps, Franky btw: I accidently found tis error because I was going to benchmark maradns again to measure possible mem leaks, but obviously I didn't get that far :-) From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 31396 invoked from network); 3 Aug 2001 13:47:44 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 3 Aug 2001 13:47:44 -0700 Received: from pandora.be (D5E058B7.kabel.telenet.be [213.224.88.183]) by pop3.telenet-ops.be (Postfix) with ESMTP id 8557A9BB48 for ; Fri, 3 Aug 2001 22:47:44 +0200 (CEST) Sender: liedekef@pop3.telenet-ops.be Message-ID: <3B6B0FA7.7AC8CF4A@pandora.be> Date: Fri, 03 Aug 2001 22:55:03 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: Bug in MaraDNS 0.8.09 askmara client References: <20010803022651.A23885@artemas.reachin.com> <3B6B0741.F3565B53@pandora.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hmmm... I just tested MaraDNS 0.8.07 and it also has the same problem, but there the askmara.c code didn't change compared to MaraDNS 0.8.06, so my guess is that there's a problem with Queries.c (the only diff there compared to 0.8.06 is the code to handle the special case of a zero-length zone name). F. Franky Van Liedekerke wrote: > It took me a while to figure it out, but now I have it pinned down: > > the askmara client doesn't work any more for recursive queries, it *does* > work for authorative queries. > The askmara client I compiled with the MaraDNS 0.8.06 source works just fine. > I tried copying the askmara source from 0.8.06 to 0.8.09 (very little > differences) and compile (which works) but still nothing. > nslookup also works fine (that's what took me so long: I didn't use nslookup > at first and was surprised to see it working where askmara didn't). > > Now the error I receive: > > from askmara: > Server reply: > Query id: 6 > Query type: 1 > Opcode: 0 > Authoritative: 0 > Truncated: 0 > Recurs desired: 0 > Recurs available: 0 > Z data: 0 > Result code: 5 > Num Questions: 0 > Num Answers: 0 > Number NS records: 0 > Number additional records: 0 > > and with verbose_level=3, at the server: > Log: Bad query received: > \000\006\000\000\000\001\000\000\000\000\000\000\003www\007telenet\002be\000\000\001\000\001 > > Hope this helps, > > Franky > > btw: I accidently found tis error because I was going to benchmark maradns > again to measure possible mem leaks, but obviously I didn't get that far :-) > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32027 invoked from network); 3 Aug 2001 14:41:56 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 3 Aug 2001 14:41:56 -0700 Received: from pandora.be (D5E058B7.kabel.telenet.be [213.224.88.183]) by tartarus.telenet-ops.be (Postfix) with ESMTP id 48C76216F64 for ; Fri, 3 Aug 2001 23:41:56 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B6B1C5A.953F2887@pandora.be> Date: Fri, 03 Aug 2001 23:49:14 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: Bug in MaraDNS 0.8.09 askmara client References: <20010803022651.A23885@artemas.reachin.com> <3B6B0741.F3565B53@pandora.be> <3B6B0FA7.7AC8CF4A@pandora.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hmmm... I just retested MaraDNS 0.8.07 and at first it gives me a timeout (because the request isn't in the cache yet) but after that it works just fine, so there's no problem there. Also MaraDNS 0.8.08 works fine, but in the latest version, there's on line 82: header.rd = 0; If I change that to header.rd = 1; then it works ok. Sam, does this mean anything to you? Franky Franky Van Liedekerke wrote: > Hmmm... I just tested MaraDNS 0.8.07 and it also has the same problem, but there the askmara.c > code didn't change compared to MaraDNS 0.8.06, so my guess is that there's a problem with > Queries.c (the only diff there compared to 0.8.06 is the code to handle the special case of a > zero-length zone name). > > F. From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32226 invoked from network); 3 Aug 2001 14:57:55 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 3 Aug 2001 14:57:55 -0700 Received: from pandora.be (D5E058B7.kabel.telenet.be [213.224.88.183]) by pop3.telenet-ops.be (Postfix) with ESMTP id 077A49BB34 for ; Fri, 3 Aug 2001 23:57:55 +0200 (CEST) Sender: liedekef@pop3.telenet-ops.be Message-ID: <3B6B201A.AD74A62D@pandora.be> Date: Sat, 04 Aug 2001 00:05:15 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: Bug in MaraDNS 0.8.09 askmara client References: <20010803022651.A23885@artemas.reachin.com> <3B6B0741.F3565B53@pandora.be> <3B6B0FA7.7AC8CF4A@pandora.be> <3B6B1C5A.953F2887@pandora.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit of course it makes sense, it's the "recursion desired" flag, and when this is set to 0, no recusion takes place. So it probably should always be 1. Franky I'm feeling kinda silly talking to myself here .... Franky Van Liedekerke wrote: > Hmmm... I just retested MaraDNS 0.8.07 and at first it gives me a timeout (because the request > isn't in the cache yet) but after that it works just fine, so there's no problem there. Also > MaraDNS 0.8.08 works fine, but in the latest version, there's on line 82: > header.rd = 0; > > If I change that to > header.rd = 1; > > then it works ok. Sam, does this mean anything to you? > > Franky > > Franky Van Liedekerke wrote: > > > Hmmm... I just tested MaraDNS 0.8.07 and it also has the same problem, but there the askmara.c > > code didn't change compared to MaraDNS 0.8.06, so my guess is that there's a problem with > > Queries.c (the only diff there compared to 0.8.06 is the code to handle the special case of a > > zero-length zone name). > > > > F. > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 911 invoked by uid 1108); 3 Aug 2001 16:34:10 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 3 Aug 2001 16:34:10 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: Bug in MaraDNS 0.8.09 askmara client Message-ID: <20010803163410.A859@artemas.reachin.com> References: <20010803022651.A23885@artemas.reachin.com> <3B6B0741.F3565B53@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B6B0741.F3565B53@pandora.be>; from liedekef@pandora.be on Fri, Aug 03, 2001 at 10:19:14PM +0200 > the askmara client doesn't work any more for recursive queries, it *does* > work for authorative queries. Opps. I changed the askmara client when I was looking for the cause of the linuxemu.retrofaction.com bug. I will change it back in the 0.8.10 release. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 27662 invoked by uid 1108); 7 Aug 2001 23:10:57 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 7 Aug 2001 23:10:57 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.10 released (minor update) Message-ID: <20010807231057.A27642@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, I have released MaraDNS 0.8.10. This is a minor update to MaraDNS 0.8.09: Namely, the Makefile for the rijndael code should now work on NetBSD. In related news, the ISP I am currently using will expire in two days. I have some friends with cable modems in the area, fortunatly, so I will have to use their connections to the 'net to work on the parts of MaraDNS that require a continuous network connection (this host does not resolve bugs and what not). For whatever reason, I can no longer reproduce the problem with resolving kain.cx, so I am marking this bug 'unreproducable', and concentrating on other issues. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 27975 invoked by uid 1108); 7 Aug 2001 23:17:57 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 7 Aug 2001 23:17:57 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.10 MD5 sum Message-ID: <20010807231757.A27962@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i MaraDNS 0.8.10 MD5 sum: aa1fe55292c25b73db92645df6049ac8 maradns-0.8.10.tar.bz2 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 31078 invoked from network); 8 Aug 2001 13:38:29 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 8 Aug 2001 13:38:29 -0700 Received: from pandora.be (D5E05A4E.kabel.telenet.be [213.224.90.78]) by tartarus.telenet-ops.be (Postfix) with ESMTP id C8F1F216F9B for ; Wed, 8 Aug 2001 22:38:28 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B71A501.579977F1@pandora.be> Date: Wed, 08 Aug 2001 22:45:54 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: small perl tool Content-Type: multipart/mixed; boundary="------------90147CD7B64DDF0086CEA609" --------------90147CD7B64DDF0086CEA609 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sam, I quickly cooked up a small perl script to check for "human" errors in recursive.c (or any other programfile): it checks for js_alloc and js_create and sees that on every return, the corresponding variables are deallocated or destroyed (this per function). It's not very smart but it can give an indication of wether a js_destroy/js_dealloc should be there. Not everything it says is correct (it doesn't know which variables shouldn't be destroyed/deallocated upon return) but it might help. usage: cat |./js_test Now for recursive.c, the output is quite large, but not all are errors I suppose (and hope :) Hope this is of any use. Franky --------------90147CD7B64DDF0086CEA609 Content-Type: text/plain; charset=us-ascii; name="js_test" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="js_test" #!/usr/bin/perl $i=0; while(<>) { # keep a linenumber $i++; # keep a two line history $old3=$$old2;$old2=$old;$old=$nu;$nu=$_; if (/^\S/) { (/^\//) && (next); (/^\#/) && (next); (/^\*/) && (next); undef(%js_alloc); undef(%js_create); print "===>Entering function $_"; } if (/\W+\s*(\w+)\s*\=\s*js_alloc/) { $js_alloc{$1}=$i; next; } if (/\W+\s*(\w+)\s*\=\s*js_create/) { $js_create{$1}=$i; next; } if (/js_dealloc\((.*)\)/) { delete $js_alloc{$1}; next; } if (/js_destroy\((.*)\)/) { delete $js_create{$1}; next; } if (/return \w\w+/) { if (($old =~ /js_create|js_alloc/) || ($old2 =~ /js_create|js_alloc/) || ($old3 =~ /js_create|js_alloc/)) { # print "Line $i: variable destroyed after erornous creation:\t$old\t$nu"; next; } foreach $el (keys %js_alloc) { print "\t$el (from line $js_alloc{$el}) not deallocated upon return on line $i\n"; } foreach $el (keys %js_create) { print "\t$el (from line $js_create{$el}) not destroyed upon return on line $i\n"; } undef %js_dealloc,%js_destroy; } } --------------90147CD7B64DDF0086CEA609-- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 32307 invoked by uid 1108); 8 Aug 2001 21:18:43 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 8 Aug 2001 21:18:43 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: small perl tool Message-ID: <20010808211843.A32289@artemas.reachin.com> References: <3B71A501.579977F1@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B71A501.579977F1@pandora.be>; from liedekef@pandora.be on Wed, Aug 08, 2001 at 10:45:54PM +0200 Franky, Is it OK if I include this tool in the MaraDNS tarball? It would, for better or for worse, need to be public domain or have a BSD-style copyright. I have back on track and will be releasing another release of MaraDNS tonight. Tomorrow's release (I hope to have time to release one tomorrow) will hopefully have made use of this tool. - Sam > I quickly cooked up a small perl script to check for "human" errors in > recursive.c (or any other programfile) -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 556 invoked by uid 1108); 8 Aug 2001 23:32:40 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 8 Aug 2001 23:32:40 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.11 released Message-ID: <20010808233240.A496@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i MaraDNS 0.8.11, yet another debug release, is released. And, yes, I remembered to include the Md5 sum (see the bottom). I have improved the CNAME handling, so that a CNAME should always return an A record along with a CNAME record when needed, and never return this A record when not needed. I have also, against my own best judgment, disabled some unused functions that use BSD-style flock() calls when MaraDNS is being compiled under Solaris. My objection is that Solaris really ought to have proper support for BSD-style calls without needing to link to a separate BSD library. The fact that Solaris is still using the outdated System-V vs BSD model is positively archaic compared to the free Unices. I find it ironic that Solaris is the only OS I am dealing with that has this problem. Some history: Back in the late 80s and early 90s, there were two main flavors of Unix, BSD and SYSV (System V). The reason for the split was because the developers in Berkeley forked off of, as I recall, version six or seven of UNIX in the late 70s. In the 80s, both the original UNIX developers at Bell labs and the Berkeley developers were adding features to UNIX. In many cases, both groups implemented the same feature differently. Resulting in the split. In the early 90s, it was fashionable to ask whether a given UNIX was "Sytem V" or "BSD". For whatever reason, corporate types decided that BSD was going to become obsolete, and that System V was the hot new buzzword. In response to this, all of the commercial Unices decided that they should be System V systems instead of BSD systems. Including Sun, who stopped supporting their excellent SunOS, and relabelled it "Solaris", making it SysV in the process. Ten years later, System V is but a memory. POSIX is a merge of both System V and BSD. In cases where merging is convenient, Linux merges both BSD and System V functionality. In places where merging is not convenient (such as the printing system), Linux has a BSD flavour. The BSD systems, once scorened by management types a "the wave of the past" are thriving, both as Free/Net/OpenBSD and as Mac OS X. History repeats itself: It is not the best, but the most open, that won in the marketplace. Something to keep in mind when management soupts a new buzzword, like "XML" or "Java". It is only UNIX systems living in the past that still have a System V slant to them. Solaris is nortorious for being extremely conservative when it comes to making changes to their system. I just wish that Sun never went SysV, and stuck with their BSD-derived SunOS systems. However, I will not be like other developers. Just because I feel that systems should support pureblood BSD calls, such as flock(), does not mean that I will shove flock() down the throats of my users unless I need to actually lock files. Hence, the unused routines that use flock() are disabled when compiling on Solaris. Anyway, let me get off of the soap box. MaraDNS is currently available here: http://www.maradns.org/ http://www2.maradns.org:8000 Other mirrors should obtain the new MaraDNS shortly. Md5 sum (I remembered it this time!): 3baac9e745b773ce9c68e6f44a58e2ae maradns-0.8.11.tar.bz2 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 949 invoked from network); 9 Aug 2001 01:27:11 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 9 Aug 2001 01:27:11 -0700 Received: from pandora.be (D5E05B77.kabel.telenet.be [213.224.91.119]) by tartarus.telenet-ops.be (Postfix) with ESMTP id 56C53216F98 for ; Thu, 9 Aug 2001 10:27:10 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B724B1C.7706E6A3@pandora.be> Date: Thu, 09 Aug 2001 10:34:37 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: small perl tool References: <3B71A501.579977F1@pandora.be> <20010808211843.A32289@artemas.reachin.com> Content-Type: multipart/mixed; boundary="------------FE3BC9FDD1174F2FB2DD7FFB" --------------FE3BC9FDD1174F2FB2DD7FFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sam, sure it's ok, but I've to stress (again) that the tool is not perfect, it won't detect situations like this: a=js_alloc...; b=js_alloc...; js_dealloc(a); if (...) js_dealloc(b); return A; if (...) js_dealloc(b); return B; The second return will yield an error (a not deallocated) because the tool does not remember a dealloc/destroy after a return (see the code). Anyway, here's the tool with a small modif and a public domain comment in it. Franky aj7kwkp@maradns.org wrote: > Franky, > > Is it OK if I include this tool in the MaraDNS tarball? > > It would, for better or for worse, need to be public domain or have a > BSD-style copyright. > > I have back on track and will be releasing another release of MaraDNS > tonight. Tomorrow's release (I hope to have time to release one > tomorrow) will hopefully have made use of this tool. > > - Sam --------------FE3BC9FDD1174F2FB2DD7FFB Content-Type: text/plain; charset=us-ascii; name="js_test" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="js_test" #!/usr/bin/perl $i=0; while(<>) { # keep a linenumber $i++; # keep a two line history $old3=$$old2;$old2=$old;$old=$nu;$nu=$_; if (/^\S/) { (/^\//) && (next); (/^\#/) && (next); (/^\*/) && (next); undef(%js_alloc); undef(%js_create); print "===>Entering function $_"; } if (/\W+\s*(\w+)\s*\=\s*js_alloc/) { $js_alloc{$1}=$i; next; } if (/\W+\s*(\w+)\s*\=\s*js_create/) { $js_create{$1}=$i; next; } if (/js_dealloc\((.*)\)/) { delete $js_alloc{$1}; $js_dealloc{$1}=$i; next; } if (/js_destroy\((.*)\)/) { delete $js_create{$1}; $js_destroy{$1}=$i; next; } if (/return \w\w+/) { if (($old =~ /js_create|js_alloc/) || ($old2 =~ /js_create|js_alloc/) || ($old3 =~ /js_create|js_alloc/)) { # print "Line $i: variable destroyed after erornous creation:\t$old\t$nu"; next; } foreach $el (keys %js_alloc) { print "\t$el (from line $js_alloc{$el}) not deallocated upon return on line $i\n" if (!$js_dealloc{$el}); } foreach $el (keys %js_create) { print "\t$el (from line $js_create{$el}) not destroyed upon return on line $i\n" if (!$js_destroy{$el}); } undef %js_dealloc,%js_destroy; } } --------------FE3BC9FDD1174F2FB2DD7FFB-- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 1060 invoked from network); 9 Aug 2001 01:34:14 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 9 Aug 2001 01:34:14 -0700 Received: from pandora.be (D5E05B77.kabel.telenet.be [213.224.91.119]) by tartarus.telenet-ops.be (Postfix) with ESMTP id A6522216FB8 for ; Thu, 9 Aug 2001 10:34:13 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B724CC4.62B21096@pandora.be> Date: Thu, 09 Aug 2001 10:41:40 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: small perl tool References: <3B71A501.579977F1@pandora.be> <20010808211843.A32289@artemas.reachin.com> <3B724B1C.7706E6A3@pandora.be> Content-Type: multipart/mixed; boundary="------------6C0BD4BBE1B5CFE2E341E156" --------------6C0BD4BBE1B5CFE2E341E156 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit and here's the correct attachment Franky Franky Van Liedekerke wrote: > Hi Sam, > > sure it's ok, but I've to stress (again) that the tool is not perfect, it > won't detect situations like this: > > a=js_alloc...; > b=js_alloc...; > js_dealloc(a); > if (...) > js_dealloc(b); > return A; > if (...) > js_dealloc(b); > return B; > > The second return will yield an error (a not deallocated) because the tool > does not remember a dealloc/destroy after a return (see the code). > Anyway, here's the tool with a small modif and a public domain comment in > it. > > Franky > > aj7kwkp@maradns.org wrote: > > > Franky, > > > > Is it OK if I include this tool in the MaraDNS tarball? > > > > It would, for better or for worse, need to be public domain or have a > > BSD-style copyright. > > > > I have back on track and will be releasing another release of MaraDNS > > tonight. Tomorrow's release (I hope to have time to release one > > tomorrow) will hopefully have made use of this tool. > > > > - Sam > > ------------------------------------------------------------------------ > #!/usr/bin/perl > > $i=0; > while(<>) { > # keep a linenumber > $i++; > # keep a two line history > $old3=$$old2;$old2=$old;$old=$nu;$nu=$_; > > if (/^\S/) { > (/^\//) && (next); > (/^\#/) && (next); > (/^\*/) && (next); > undef(%js_alloc); > undef(%js_create); > print "===>Entering function $_"; > } > > if (/\W+\s*(\w+)\s*\=\s*js_alloc/) { > $js_alloc{$1}=$i; > next; > } > if (/\W+\s*(\w+)\s*\=\s*js_create/) { > $js_create{$1}=$i; > next; > } > if (/js_dealloc\((.*)\)/) { > delete $js_alloc{$1}; > $js_dealloc{$1}=$i; > next; > } > if (/js_destroy\((.*)\)/) { > delete $js_create{$1}; > $js_destroy{$1}=$i; > next; > } > if (/return \w\w+/) { > if (($old =~ /js_create|js_alloc/) || > ($old2 =~ /js_create|js_alloc/) || > ($old3 =~ /js_create|js_alloc/)) { > # print "Line $i: variable destroyed after erornous creation:\t$old\t$nu"; > next; > } > foreach $el (keys %js_alloc) { > print "\t$el (from line $js_alloc{$el}) not deallocated upon return on line $i\n" if (!$js_dealloc{$el}); > } > foreach $el (keys %js_create) { > > print "\t$el (from line $js_create{$el}) not destroyed upon return on line $i\n" if (!$js_destroy{$el}); > } > undef %js_dealloc,%js_destroy; > } > } > > ------------------------------------------------------------------------ > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org --------------6C0BD4BBE1B5CFE2E341E156 Content-Type: text/plain; charset=us-ascii; name="js_test" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="js_test" #!/usr/bin/perl # Released to the public domain 2001 by Franky Van Liedekerke $i=0; while(<>) { # keep a linenumber $i++; # keep a two line history $old3=$$old2;$old2=$old;$old=$nu;$nu=$_; if (/^\S/) { (/^\//) && (next); (/^\#/) && (next); (/^\*/) && (next); undef(%js_alloc); undef(%js_create); print "===>Entering function $_"; } if (/\W+\s*(\w+)\s*\=\s*js_alloc/) { $js_alloc{$1}=$i; next; } if (/\W+\s*(\w+)\s*\=\s*js_create/) { $js_create{$1}=$i; next; } if (/js_dealloc\((.*)\)/) { # delete $js_alloc{$1}; $js_dealloc{$1}=$i; next; } if (/js_destroy\((.*)\)/) { # delete $js_create{$1}; $js_destroy{$1}=$i; next; } if (/return \w\w+/) { if (($old =~ /js_create|js_alloc/) || ($old2 =~ /js_create|js_alloc/) || ($old3 =~ /js_create|js_alloc/)) { # print "Line $i: variable destroyed after erornous creation:\t$old\t$nu"; next; } foreach $el (keys %js_alloc) { print "\t$el (from line $js_alloc{$el}) not deallocated upon return on line $i\n" if (!$js_dealloc{$el}); } foreach $el (keys %js_create) { print "\t$el (from line $js_create{$el}) not destroyed upon return on line $i\n" if (!$js_destroy{$el}); } undef %js_dealloc,%js_destroy; } } --------------6C0BD4BBE1B5CFE2E341E156-- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 1841 invoked from network); 9 Aug 2001 06:08:30 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 9 Aug 2001 06:08:30 -0700 Received: from pandora.be (D5E057FB.kabel.telenet.be [213.224.87.251]) by pop3.telenet-ops.be (Postfix) with ESMTP id 8DF709BB56 for ; Thu, 9 Aug 2001 15:08:30 +0200 (CEST) Sender: liedekef@pop3.telenet-ops.be Message-ID: <3B728D0D.8FBD8882@pandora.be> Date: Thu, 09 Aug 2001 15:15:57 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.11 released References: <20010808233240.A496@artemas.reachin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Sam, thanks for the lock-disable (hope I don't offend too much people here by using Solaris :) A small suggestion: as long as the locking stuff is disabled, the following lines for SOLARIS compilation in the Makefile should be: old: # CFLAGS=-I/usr/ucbinclude # LDFLAGS=-L/usr/ucblib -lucb -lxnet new: # CFLAGS= # LDFLAGS=-lxnet (maybe the old part can stay as an extra comment for when locking is used in a future version) And another small thing: please remove the definition of RLIMIT_NPROC from MaraDns.h, it was a foolish thing of me to suggest that. On solaris the RLIMIT_NPROC parameter simply doesn't exist, and when you change the thread-limit mechanism to be more general (a TODO item?), this is totally no longer an issue. Franky aj7kwkp@maradns.org wrote: > I have also, against my own best judgment, disabled some unused functions > that use BSD-style flock() calls when MaraDNS is being compiled under > Solaris. My objection is that Solaris really ought to have proper support > for BSD-style calls without needing to link to a separate BSD > library. The fact that Solaris is still using the outdated System-V vs > BSD model is positively archaic compared to the free Unices. From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 8776 invoked by uid 1108); 10 Aug 2001 21:20:23 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 10 Aug 2001 21:20:23 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.5.29 released Message-ID: <20010810212023.A8763@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello, Just real quickly: I have backported some bugfixes in the 0.8.xx trees back to the "stable" branch of MaraDNS. Hence, MaraDNS 0.5.29 is released. Md5 SUMS: 5d181a76fbcd4630c5f9c827cb8e6bf0 maradns-0.5.29.tar.bz2 f8383e61c5853b6ff33054e4d28013f0 maradns-0.5.29-1.src.rpm b510758f28663cf60fb0a40880feff38 maradns-0.5.29-1.i386.rpm Now, I need to make these files available on www2.maradns.org:8000 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 9733 invoked by uid 1108); 11 Aug 2001 00:58:37 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 11 Aug 2001 00:58:37 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.12 released Message-ID: <20010811005837.A9722@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Just my luck. Now that I backported the last batch of bugfixes for the authoritative nameserver back to the 0.5.xx series, out comes another bug which needs to be fixed. Namely, as I was looking through the code, I saw that udperror was not giving out the correct query ID in most cases. So, I need to backport that fix. 0.5.30 will probably come out in a week or so, to give me time to find other bugs. I also am slowly making MaraDNS more Solaris friendly. There are things I do not like about Solaris, yes, mainly due to the fact that Linux has always been much more accessible to the average 15-year-old geek or the geek who is working at Burger King, but that doesn't stop me from making sure MaraDNS is as Solaris-happy as possible. Namely, there is now a working system in place which uses a counter to track the number of threads. If one has more threads than the maximum allowed by "maxprocs", MaraDNS refuses to spwawn more threads. This code needs a little more work, since the right thing to do is to give a server fail error message to the stub resolver, so it can try again. Also, this is fairly vulnerable to a DOS attack, but at least overloading the nameserver no longer can bring the rest of the system down. I have also fixed a long standing problem with round robin rotates and cached data. Namely: Cache data now will now round-robin rotate. Finally, MaraDNS compiles again if the locale is set to Spanish instead of English. I did this copying the English translations of a couple of newer error messages to a Spanish locale file. If there are any Spanish speakers here, I still need a good number of Spanish translations. Time to announce it to Freshmeat and Sourceforge [1], then go to sleep. Md5 sum: (I almost forgot this. Thankfully, I sent this note to the wrong address, causing it to bounce) 241e1a6e36dc2bb39073ddfe32f9c5b4 maradns-0.8.12.tar.bz2 - Sam [1] Am I the only one who is worried that a good portion of open source websites are tied to the fortunes of a small .com which has had to cut back several times due to money problems. In particular, a good number of important open-source projects are only hosted on Sourceforge, and I worry that Sourceforge will not be around in five years. My advice to developers: Find another place to make your files public. Ibiblio is a good choice, since they have been around for at least seven years, and will most likely outlive sourceforge. -- "Reality is the most perfect vision of God's will" -- Orson Scott Card ----- End forwarded message ----- -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 9807 invoked from network); 11 Aug 2001 01:49:16 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 11 Aug 2001 01:49:16 -0700 Received: from pandora.be (D5E05A85.kabel.telenet.be [213.224.90.133]) by tartarus.telenet-ops.be (Postfix) with ESMTP id 62B94216FEB for ; Sat, 11 Aug 2001 10:49:16 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B74F34C.B03A4551@pandora.be> Date: Sat, 11 Aug 2001 10:56:44 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released References: <20010811005837.A9722@artemas.reachin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Great: threading limit will be tested by me :) btw, a small question: in the function launch_thread (recursive.c), you read the variable num_of_threads_running, but is it needed there to tcount_lock it? And another small thingie: maybe, after the thread_limit has been tested, the use of RLIMIT can be probably be deleted everywhere, yes? Franky aj7kwkp@maradns.org wrote: > Just my luck. > > Now that I backported the last batch of bugfixes for the authoritative > nameserver back to the 0.5.xx series, out comes another bug which needs to > be fixed. Namely, as I was looking through the code, I saw that udperror > was not giving out the correct query ID in most cases. So, I need to > backport that fix. 0.5.30 will probably come out in a week or so, to give > me time to find other bugs. > > I also am slowly making MaraDNS more Solaris friendly. There are things I > do not like about Solaris, yes, mainly due to the fact that Linux has > always been much more accessible to the average 15-year-old geek or the > geek who is working at Burger King, but that doesn't stop me from making > sure MaraDNS is as Solaris-happy as possible. > > Namely, there is now a working system in place which uses a counter to > track the number of threads. If one has more threads than the maximum > allowed by "maxprocs", MaraDNS refuses to spwawn more threads. This code > needs a little more work, since the right thing to do is to give a server > fail error message to the stub resolver, so it can try again. Also, this > is fairly vulnerable to a DOS attack, but at least overloading the > nameserver no longer can bring the rest of the system down. > > I have also fixed a long standing problem with round robin rotates and > cached data. Namely: Cache data now will now round-robin rotate. > > Finally, MaraDNS compiles again if the locale is set to Spanish instead of > English. I did this copying the English translations of a couple of newer > error messages to a Spanish locale file. If there are any Spanish > speakers here, I still need a good number of Spanish translations. > > Time to announce it to Freshmeat and Sourceforge [1], then go to sleep. > > Md5 sum: (I almost forgot this. Thankfully, I sent this note to the > wrong address, causing it to bounce) > > 241e1a6e36dc2bb39073ddfe32f9c5b4 maradns-0.8.12.tar.bz2 > > - Sam > > [1] Am I the only one who is worried that a good portion of open > source websites are tied to the fortunes of a small .com > which has had to cut back several times due to money problems. > In particular, a good number of important open-source projects > are only hosted on Sourceforge, and I worry that Sourceforge will > not be around in five years. My advice to developers: Find another > place to make your files public. Ibiblio is a good choice, since > they have been around for at least seven years, and will most likely > outlive sourceforge. > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > ----- End forwarded message ----- > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 9856 invoked from network); 11 Aug 2001 02:09:41 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 11 Aug 2001 02:09:41 -0700 Received: from pandora.be (D5E05A85.kabel.telenet.be [213.224.90.133]) by tartarus.telenet-ops.be (Postfix) with ESMTP id 8D7EA216F48 for ; Sat, 11 Aug 2001 11:09:41 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B74F815.690AC3B9@pandora.be> Date: Sat, 11 Aug 2001 11:17:09 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released References: <20010811005837.A9722@artemas.reachin.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Two small remarks (not even worth the name bugs): 1) MaraBigHash_es.h: dos2unix is a nice tool to get rid of those "^M" at the end of a line :) 2) askmara: everytime I use it in a xterm, it now screws up my character sets, leaving totally unreadable rubbish as output (exept the numbers, I can read those :) Probably due to extra characters printed at the top of askmara output, eg if I do a lookup of www.telenet.be, I get this at the top: wwwtelenetbeÀFPnapollotelenet-opsÀnapollotelenet-opsÀFPÃT wwwtelenetbewwwtelenetbeFPnapollotelenet-opsbenapollotelenet-opsbeFPÃTServer reply: Now this (luckely) doesn't screw up my settings, but a resolve of eg proxy.pandora.be does. My guess is that the lines starting at linenumber 133 should be commented out: js_show_stdout(indata); printf("%s",L_NEWLINE); js_show_stdout(uindata); Franky aj7kwkp@maradns.org wrote: > Just my luck. > > Now that I backported the last batch of bugfixes for the authoritative > nameserver back to the 0.5.xx series, out comes another bug which needs to > be fixed. Namely, as I was looking through the code, I saw that udperror > was not giving out the correct query ID in most cases. So, I need to > backport that fix. 0.5.30 will probably come out in a week or so, to give > me time to find other bugs. > > I also am slowly making MaraDNS more Solaris friendly. There are things I > do not like about Solaris, yes, mainly due to the fact that Linux has > always been much more accessible to the average 15-year-old geek or the > geek who is working at Burger King, but that doesn't stop me from making > sure MaraDNS is as Solaris-happy as possible. > > Namely, there is now a working system in place which uses a counter to > track the number of threads. If one has more threads than the maximum > allowed by "maxprocs", MaraDNS refuses to spwawn more threads. This code > needs a little more work, since the right thing to do is to give a server > fail error message to the stub resolver, so it can try again. Also, this > is fairly vulnerable to a DOS attack, but at least overloading the > nameserver no longer can bring the rest of the system down. > > I have also fixed a long standing problem with round robin rotates and > cached data. Namely: Cache data now will now round-robin rotate. > > Finally, MaraDNS compiles again if the locale is set to Spanish instead of > English. I did this copying the English translations of a couple of newer > error messages to a Spanish locale file. If there are any Spanish > speakers here, I still need a good number of Spanish translations. > > Time to announce it to Freshmeat and Sourceforge [1], then go to sleep. > > Md5 sum: (I almost forgot this. Thankfully, I sent this note to the > wrong address, causing it to bounce) > > 241e1a6e36dc2bb39073ddfe32f9c5b4 maradns-0.8.12.tar.bz2 > > - Sam > > [1] Am I the only one who is worried that a good portion of open > source websites are tied to the fortunes of a small .com > which has had to cut back several times due to money problems. > In particular, a good number of important open-source projects > are only hosted on Sourceforge, and I worry that Sourceforge will > not be around in five years. My advice to developers: Find another > place to make your files public. Ibiblio is a good choice, since > they have been around for at least seven years, and will most likely > outlive sourceforge. > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > ----- End forwarded message ----- > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12267 invoked by uid 1108); 11 Aug 2001 17:18:14 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 11 Aug 2001 17:18:14 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released Message-ID: <20010811171814.B12134@artemas.reachin.com> References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B74F34C.B03A4551@pandora.be>; from liedekef@pandora.be on Sat, Aug 11, 2001 at 10:56:44AM +0200 > And another small thingie: maybe, after the thread_limit has been tested, the > use of RLIMIT can be probably be deleted everywhere, yes? I will keep RLIMIT around. I have already ifdef'd it out if SOLARIS is defined. Also, the zone server (which currently does not have any other method of protecting herself from a DOS) needs it. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13472 invoked by uid 1108); 12 Aug 2001 00:39:01 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 12 Aug 2001 00:39:01 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.13 released Message-ID: <20010812003901.A13438@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Some of you probably imaigne me diligently working on MaraDNS in a clean, well-organized, room, with a array of state of the art computers, including 1.7 ghz Pentium 4s, 1.3ghz Athelons, top-of-the-line Sun boxes, Apple G4s with Mac OS X on them, every single distribution of Linux imaginable at my fingertips. You may imagine me in an ergonomically designed chair, with a 21" LCD monitor and a switch which allows me to switch effortlessly from computer to computer. You may imagine pleasant new age music in the background, which I can change to any style of music with a flip of a switch. It would be nice if imagining something made it real. For example, I met these pretty girls this morning when I was doing my daily exercise. However, we are digressing. The real development environment that MaraDNS is being developed under is quite different. Since I do not have a home right now (I am staying with family and friends down in San Diego right now), the place where I develop MaraDNS constantly changes. Right now, I am in my buddy's room. Bless his heart, but he is almost as messy as I was before I gave up on most material things. RPG books and clothes are strewn everywhere. A single light lights up the room. The ethernet card of my laptop is hooked up to his cable modem box. My buddy, a deep sleeper, is a really nice guy and totally cool to hang out with. He also snores like a log. So, the reality of recent MaraDNS developmet has been like this: Me on my laptop in a messy room listening to the neighbor's TV, my buddy's roomate's TV, and my buddy's snoring. Cat hair from the long-haired cat is everywhere. Open source software takes dedication to develop at times, let me tell you. ----- A bad thing happened to me today. I received a spam message. This, I know, is the kind of news that goes along with "Rain is wet today" and "A politician did not keep a campaign promise today". However, this spam was sent to a very special and very secret email address. Which incensed me. So I started investigating the spam. I found out that the spam pointed to a website which uses known Spam-friendly DNS provider: azmalink.net. A quick Google search for azmalink.net shows page after page of spam advertized web pages which use azmalink.net DNS servers. Clearly, something had to be done. And something was, in fact, done. I added a new feature to MaraDNS. Spam-blocking. It goes like this: If you know of some DNS servers which, well, turn a blind eye to spam domains that they serve, you can now blacklist these DNS servers. MaraDNS will refuse to process DNS queries from those DNS servers. Which makes it so MaraDNS will not resolve spam-advertised domains. The feature works by adding lines like this to the mararc file: ipv4_alias["azmalink"] = "206.169.88.7/24" spammers = "azmalink" With these two lines, any domain that azmalink provides DNS service for will no longer resolve. Now, this is just the "quick and dirty" version of spam blacklisting. Since azmalink is a known spam-friendly DNS provider, they constantly change ISPs, resulting in them frequently having new IP. The deluxe version of spam blocking would allow MaraDNS to refuse to process queries from certain names, such as "*.azmalink.net". To implement this, however, requires more new code than I am comfortable adding to MaraDNS at this point in the development cycle. In fact, adding any new features at this point is something I really should not be doing, but spammers have a way of really annoying me. I have documented this new feature in the example_mararc file, but not in the man page yet. The file doc/spammers/azmalink.net details why I consider them a spamhaus. Some other changes: Fixed MaraDNS so it no longer spits out binary data which messes up terminals (this is a debug feature which I sometimes turn on to troubleshoot some bugs). Also, when an element in the cache is overwritten, the new data is now actually added to the cache after deleting the old data. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13523 invoked by uid 1108); 12 Aug 2001 00:42:39 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 12 Aug 2001 00:42:39 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: The md5 sum Message-ID: <20010812004239.B13438@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i The md5 sum of MaraDNS 0.5.13: ad0b92721096cd63faf250128497e173 maradns-0.8.13.tar.bz2 (I really need to hack up a md5 + haval + tiger + sha2 summer program) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13599 invoked from network); 12 Aug 2001 01:34:52 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 12 Aug 2001 01:34:52 -0700 Received: from pandora.be (D5E05A02.kabel.telenet.be [213.224.90.2]) by pop3.telenet-ops.be (Postfix) with ESMTP id 467AA9BB74 for ; Sun, 12 Aug 2001 10:34:53 +0200 (CEST) Sender: liedekef@pop3.telenet-ops.be Message-ID: <3B76416E.BBB8DD4B@pandora.be> Date: Sun, 12 Aug 2001 10:42:22 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit aj7kwkp@maradns.org wrote: > > And another small thingie: maybe, after the thread_limit has been tested, the > > use of RLIMIT can be probably be deleted everywhere, yes? > > I will keep RLIMIT around. I have already ifdef'd it out if SOLARIS is > defined. Also, the zone server (which currently does not > have any other method of protecting herself from a DOS) needs it. Ok, a good enough reason. One thing about the zoneserver code: if I'm not mistaking, it's waiting for tcp connections, yes? So maybe a new variable might be introduced to limit the number of tcp connections to the zoneserver, because you typically want to keep this much lower than the possible number of udp connections, no? And in order for the thread limit to be effective on all platforms (Solaris issue, again) for the zoneserver, wouldn't it be possible to do the same as you did for recursive.c (using a counter with mutex lock, unlock)? Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13652 invoked by uid 1108); 12 Aug 2001 01:43:57 -0700 Sender: aj7kwkp@maradns.org Date: Sun, 12 Aug 2001 01:43:57 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released Message-ID: <20010812014357.A13638@artemas.reachin.com> References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> <3B76416E.BBB8DD4B@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B76416E.BBB8DD4B@pandora.be>; from liedekef@pandora.be on Sun, Aug 12, 2001 at 10:42:22AM +0200 > Ok, a good enough reason. One thing about the zoneserver code: if I'm > not mistaking, it's waiting for tcp connections, yes? So maybe a new > variable might be introduced to limit the number of tcp connections to > the zoneserver, because you typically want to keep this much lower than > the possible number of udp connections, no? The problem is that I am using separate processes instead of threads for the zone server. Having a process reliably know how many children she has may [2] be a pain with the UNIX api. [1] Also, it is difficult to share variables with children processes--The idea of using shm-style shared memory gives me nightmares. - Sam [1] while(waitpid(0,NULL,WNOHANG) > 0) children--; might [2] work [2] I'm using a verb tense which means "I am not really sure, but I think so" in this context. Ugh, the vaugities of human language. -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13706 invoked from network); 12 Aug 2001 02:09:27 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 12 Aug 2001 02:09:27 -0700 Received: from pandora.be (D5E05A02.kabel.telenet.be [213.224.90.2]) by tartarus.telenet-ops.be (Postfix) with ESMTP id BB7CB2170CC for ; Sun, 12 Aug 2001 11:09:27 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B764989.C0104A36@pandora.be> Date: Sun, 12 Aug 2001 11:16:57 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> <3B76416E.BBB8DD4B@pandora.be> <20010812014357.A13638@artemas.reachin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit aj7kwkp@maradns.org wrote: > > Ok, a good enough reason. One thing about the zoneserver code: if I'm > > not mistaking, it's waiting for tcp connections, yes? So maybe a new > > variable might be introduced to limit the number of tcp connections to > > the zoneserver, because you typically want to keep this much lower than > > the possible number of udp connections, no? > > The problem is that I am using separate processes instead of threads for > the zone server. Having a process reliably know how many children she has > may [2] be a pain with the UNIX api. [1] Also, it is difficult to share > variables with children processes--The idea of using shm-style shared > memory gives me nightmares. > > - Sam > > [1] while(waitpid(0,NULL,WNOHANG) > 0) children--; might [2] work > > [2] I'm using a verb tense which means "I am not really sure, but I think > so" in this context. Ugh, the vaugities of human language. > Almost 2 AM and still awake? I can believe now your buddy's snoring is annoying you :) True, it's worth a shot though (the [1] method I mean) Btw Sam, two other small remarks: 1) for Solaris, you'll always need to link against "-lxnet" so the comment in the Makefile is not totally correct 2) would you be so kind to remove the "#define RLIMIT_NPROC" from MaraDns.h for solaris. It was just wrong from the beginning for me to suggest that. And I have a small question: what happens now when the thread limit is reached (for recursive requests, that is)? Does the server returns an error and let the client try again, or does it just let the client wait until one is available? Since it's for udp connections, I'm not quite sure how to reason about it... And something else: if you want me to finetune the js_test program, just let me know in private. Greets, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13894 invoked from network); 12 Aug 2001 03:37:59 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 12 Aug 2001 03:37:59 -0700 Received: from pandora.be (D5E05A02.kabel.telenet.be [213.224.90.2]) by pop3.telenet-ops.be (Postfix) with ESMTP id D5B429BBBC for ; Sun, 12 Aug 2001 12:37:59 +0200 (CEST) Sender: liedekef@pop3.telenet-ops.be Message-ID: <3B765E47.B0D70DA3@pandora.be> Date: Sun, 12 Aug 2001 12:45:27 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> <3B76416E.BBB8DD4B@pandora.be> <20010812014357.A13638@artemas.reachin.com> <3B764989.C0104A36@pandora.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > The problem is that I am using separate processes instead of threads for > > the zone server. Having a process reliably know how many children she has > > may [2] be a pain with the UNIX api. [1] Also, it is difficult to share > > variables with children processes--The idea of using shm-style shared > > memory gives me nightmares. > > > > - Sam > > > > [1] while(waitpid(0,NULL,WNOHANG) > 0) children--; might [2] work > > Sam, I just fond an excellent example for how to limit the number of processes, it's one of DJB his programs: http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz Now if you look in the sourcecode of tcpserver.c (at the bottom) you see how the number of child processes is limited there, together with the function sigchld and sig_catch. The trick with sig_catch is you need to catch the SIGCHLD signal when the child unexpectedly exists (by a kill for example). For the rest, I think your suggestion [1] would be correct. Hope this helps, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21401 invoked from network); 12 Aug 2001 04:28:24 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 12 Aug 2001 04:28:24 -0700 Received: from pandora.be (D5E05A02.kabel.telenet.be [213.224.90.2]) by tartarus.telenet-ops.be (Postfix) with ESMTP id 9DB682170E9 for ; Sun, 12 Aug 2001 13:28:25 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B766A19.4271239A@pandora.be> Date: Sun, 12 Aug 2001 13:35:53 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> <3B76416E.BBB8DD4B@pandora.be> <20010812014357.A13638@artemas.reachin.com> <3B764989.C0104A36@pandora.be> <3B765E47.B0D70DA3@pandora.be> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Franky Van Liedekerke wrote: > I just fond an excellent example for how to limit the number of processes, it's > one of DJB his programs: http://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz > Now if you look in the sourcecode of tcpserver.c (at the bottom) you see how the > number of child processes is limited there, together with the function sigchld > and sig_catch. The trick with sig_catch is you need to catch the SIGCHLD signal > when the child unexpectedly exists (by a kill for example). For the rest, I > think your suggestion [1] would be correct. > Hmm...just found that counting signals is not a good way (signals can get lost), you have to count the number of childs exited using waitpid, so your way seems to be ok. But you have to make sure dead clients don't count. Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 27246 invoked by uid 1108); 13 Aug 2001 11:30:34 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 13 Aug 2001 11:30:34 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released Message-ID: <20010813113034.A27228@artemas.reachin.com> References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> <3B76416E.BBB8DD4B@pandora.be> <20010812014357.A13638@artemas.reachin.com> <3B764989.C0104A36@pandora.be> <3B765E47.B0D70DA3@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B765E47.B0D70DA3@pandora.be>; from liedekef@pandora.be on Sun, Aug 12, 2001 at 12:45:27PM +0200 > The trick with sig_catch is you need to catch the SIGCHLD signal > when the child unexpectedly exists (by a kill for example). Yep, you're right. A SIGCHILD ahndler would be the best way (since the "number of childer" counter would immediately decrement whenever a child exited). The problem: A SIGCHILD can be spoofed on a multiuser system as the user nobody. Maybe have a non-blocking waitpid call in the SIGCHILD handler. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 27410 invoked from network); 13 Aug 2001 12:15:08 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 13 Aug 2001 12:15:08 -0700 Received: from pandora.be (D5E05B5E.kabel.telenet.be [213.224.91.94]) by tartarus.telenet-ops.be (Postfix) with ESMTP id 7602A217430 for ; Mon, 13 Aug 2001 21:14:53 +0200 (CEST) Sender: liedekef@tartarus.telenet-ops.be Message-ID: <3B7828EF.32A5E894@pandora.be> Date: Mon, 13 Aug 2001 21:22:23 +0200 From: Franky Van Liedekerke X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> <3B76416E.BBB8DD4B@pandora.be> <20010812014357.A13638@artemas.reachin.com> <3B764989.C0104A36@pandora.be> <3B765E47.B0D70DA3@pandora.be> <20010813113034.A27228@artemas.reachin.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit aj7kwkp@maradns.org wrote: > > The trick with sig_catch is you need to catch the SIGCHLD signal > > when the child unexpectedly exists (by a kill for example). > > Yep, you're right. A SIGCHILD ahndler would be the best way (since the > "number of childer" counter would immediately decrement whenever a child > exited). The problem: A SIGCHILD can be spoofed on a multiuser system as > the user nobody. Maybe have a non-blocking waitpid call in the SIGCHILD > handler. Through the method of "non-blocking waitpid call in the SIGCHILD handler" is it done in the ucspi-tcp tcpserver.c program (if I remember correctly what I've read yesterday) Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28129 invoked by uid 1108); 13 Aug 2001 15:48:12 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 13 Aug 2001 15:48:12 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.12 released Message-ID: <20010813154812.B28085@artemas.reachin.com> References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> <3B76416E.BBB8DD4B@pandora.be> <20010812014357.A13638@artemas.reachin.com> <3B764989.C0104A36@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B764989.C0104A36@pandora.be>; from liedekef@pandora.be on Sun, Aug 12, 2001 at 11:16:57AM +0200 > Almost 2 AM and still awake? I can believe now your buddy's snoring is > annoying you :) Well, at least he doesn't snore during the day. > 1) for Solaris, you'll always need to link against "-lxnet" so the comment in > the Makefile is not totally correct Here is the current makefile comments for the 0.8.14 release: # Uncomment the following four lines to get this to compile on Solaris # CFLAGS=-I/usr/ucbinclude # LDFLAGS=-lxnet # CC=gcc $(LDFLAGS) -DSOLARIS # M="CC=$(CC)" > 2) would you be so kind to remove the "#define RLIMIT_NPROC" from MaraDns.h > for solaris. It was just wrong from the beginning for me to suggest that. Done for version 0.8.14. > And I have a small question: what happens now when the thread limit is > reached (for recursive requests, that is)? Does the server returns an error > and let the client try again, or does it just let the client wait until one > is available? The client "drops" the query. There is a "TODO" in the code to return an error, and I intend to have it return an error before MaraDNS goes beta. The problem is that the interface to udperror is broken (it expects a JS_STRING of the query, which it obtains the ID from, instead of an interger with the query ID), and is called too many places for me to fix it before a 1.0 release. So, I have to write code which synthesizes a header in a js_string format that udperror can handle. Ugh. This is the kind of stuff that bites you once your program gets really big, the way MaraDNS is. > Since it's for udp connections, I'm not quite sure how to reason about > it... Well, the main disadvantage of it being a UDP connection is that it is not reasonable to make the client wait if we can't get a thread, the way we can with the TCP Zone server. So, we just drop requests right now (soon, with errors) until MaraDNS has threads to spawn again. Yes, I know, MaraDNS should be able to return answers from the cache *without* first spawning a thread. That is one of the first things I will fix once version 1.0 is out. Hopefully (talk is cheap). - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28200 invoked from network); 13 Aug 2001 16:04:46 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 13 Aug 2001 16:04:46 -0700 Received: from franky (D5E05B5E.kabel.telenet.be [213.224.91.94]) by pop3.telenet-ops.be (Postfix) with SMTP id 80FFB9BC18 for ; Tue, 14 Aug 2001 01:04:46 +0200 (CEST) Date: Tue, 14 Aug 2001 01:12:16 +0200 From: Franky Van Liedekerke To: Subject: Re: MaraDNS 0.8.12 released Message-Id: <20010814011216.3485e65e.liedekef@pandora.be> In-Reply-To: <20010813154812.B28085@artemas.reachin.com> References: <20010811005837.A9722@artemas.reachin.com> <3B74F34C.B03A4551@pandora.be> <20010811171814.B12134@artemas.reachin.com> <3B76416E.BBB8DD4B@pandora.be> <20010812014357.A13638@artemas.reachin.com> <3B764989.C0104A36@pandora.be> <20010813154812.B28085@artemas.reachin.com> X-Mailer: Sylpheed version 0.5.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Mon, 13 Aug 2001 15:48:12 -0700 aj7kwkp@maradns.org wrote: > > 1) for Solaris, you'll always need to link against "-lxnet" so the comment in > > the Makefile is not totally correct > > Here is the current makefile comments for the 0.8.14 release: > > # Uncomment the following four lines to get this to compile on Solaris > # CFLAGS=-I/usr/ucbinclude > # LDFLAGS=-lxnet > # CC=gcc $(LDFLAGS) -DSOLARIS > # M="CC=$(CC)" small thingie: ucbinclude is not necessary unless ucb libs are used on Solaris, and these aren't necessary at the moment, so the CFLAGS can be left empty. > > Well, the main disadvantage of it being a UDP connection is that it is not > reasonable to make the client wait if we can't get a thread, the way we > can with the TCP Zone server. So, we just drop requests right now (soon, > with errors) until MaraDNS has threads to spawn again. how does the client reacts when the requst is dropped, does it retry it's dns request? I'm thinking about mailserver software as a client here: a dns request is done, but no response follows, does a "normal intelligent" mailserver asks again? > Yes, I know, MaraDNS should be able to return answers from the cache > *without* first spawning a thread. That is one of the first things I will > fix once version 1.0 is out. Why? A thread leads to more clients being able to be served at the same time, no? Greets, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 29964 invoked by uid 1108); 13 Aug 2001 17:15:25 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 13 Aug 2001 17:15:25 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.14 released Message-ID: <20010813171525.A29945@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, MaraDNS 0.8.14 has been released. Mainly, this has some tweaks (thanks, Franky, for the suggestions) which make MaraDNS a much more happy puppy on Solaris. The zone file now uses a counter to keep track of the number of children that she has. The Makefile has been tweaked to be much happier with Solaris. I also mumbled that I needed to write a program which performs various cryptographic and non-cryptographic sums on a file, and shows the output of all the various hashes. I have now written this program, and it is available as: http://www.maradns.org/sums-20010813.tar.bz2 This includes the md5 hash, the sha1 hash (both available with recent versions of GNU textutils, but many people are not blessed enough to have GNU textutils), the Haval hash (which doesn't compile on RH6.2. Argh), the sha2 hases (256, 384, and 512-bit versions, courtesy Aaron D. Gifford), and the Whirlpool hash. Note that a good deal (if not all) of the code is *not* under the public domain. There is no top-level makefile, but all of the makesfiles in the directories of the corresponding hash functions is verified to work (with the exception of no 'make install'--I feel it is better for root to copy the binarys over to /usr/local/bin by hand) on RedHat 7.1, and everything except the haval hash works on RedHat 6.2. There is a shell script called 'sums' which will run a given file under every single sum imaginable. For example, here are the sums for MaraDNS-0.8.14: BSD sum and 1024-byte block count: 53851 179 SYSV sum and 512-byte block count: 20211 358 maradns-0.8.14.tar.bz2 CRC checksum and byte count 241643137 183274 maradns-0.8.14.tar.bz2 MD5 sum: cbe19c25669e0d149c578259f0b293d1 maradns-0.8.14.tar.bz2 SHA1 sum: b1e8e14ad1400bfb67df2599fbc6b38b8b1d7256 maradns-0.8.14.tar.bz2 Whirlpool sum: Whirlpool digest: af88ffecb210426ff2fc81157f415d1806a1d06562a3ff92bb430ce2e5c6c5afef911de96f1a0d3d4c344f90670471632c10f02110642f62ffaba24dec5e09a8 SHA2 sums: SHA-256 = 0xcbe224f948113180f144e716f19a593d288a63d265c6363d2890ab70412f68de SHA-384 = 0xe7911b7371051859d9b2952a3baf3561a69f2683b7b5855168ef9cff2243244eb9d33fc2490eb52d3ac82be51aae673e SHA-512 = 0x01f0c3cb8c68fc09c451dab67fdb837d12001b4f6cba1d6ba898d6ca59714307f773876fbec0191e6499b74c1cb27418bc3b9304c62fb86053f7edadb8fb4a64 HAVAL (5-pass, 256-bit) sum: HAVAL(File maradns-0.8.14.tar.bz2) = D900837904DAD6CF94511C15F895A5AA45918581A8A78D9D8D9E6AD96F396D55 The reason why Tiger is not included is because I could not figure out how to use the API in the reference implementation of Tiger without loading the entire file to get the sum of in to memory first (ugh). Not that it matters on my laptop, but I feel such a design is not exactly elegent. Now, time to release it on Sourceforge and Freshmeat. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 31259 invoked from network); 14 Aug 2001 02:05:35 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 14 Aug 2001 02:05:35 -0700 Received: from franky (D5E0580F.kabel.telenet.be [213.224.88.15]) by tartarus.telenet-ops.be (Postfix) with SMTP id 8BDCD21755C for ; Tue, 14 Aug 2001 11:05:35 +0200 (CEST) Date: Tue, 14 Aug 2001 11:13:07 +0200 From: Franky Van Liedekerke To: Subject: Re: MaraDNS 0.8.14 released Message-Id: <20010814111307.789b3855.liedekef@pandora.be> In-Reply-To: <20010813171525.A29945@artemas.reachin.com> References: <20010813171525.A29945@artemas.reachin.com> X-Mailer: Sylpheed version 0.5.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit On Mon, 13 Aug 2001 17:15:25 -0700 aj7kwkp@maradns.org wrote: > > Hello there, > > MaraDNS 0.8.14 has been released. > > Mainly, this has some tweaks (thanks, Franky, for the suggestions) which > make MaraDNS a much more happy puppy on Solaris. The zone file now uses a > counter to keep track of the number of children that she has. The > Makefile has been tweaked to be much happier with Solaris. Tx Sam, I'll check it asap (whenever I get back from the beach, it's 34 °C here :) Btw, I already took a look at the sourcecode and I have a little question (mostly because I just don't know): You use a signal handler to catch whenever a child exits, but what is then the purpose of the waitpid in the main for-loop for? > > I also mumbled that I needed to write a program which performs various > cryptographic and non-cryptographic sums on a file, and shows the output > of all the various hashes. I have now written this program, and it is > available as: > > http://www.maradns.org/sums-20010813.tar.bz2 > The file is not there ... greets, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 31320 invoked by uid 1108); 14 Aug 2001 02:12:26 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 14 Aug 2001 02:12:26 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.14 released Message-ID: <20010814021226.A31308@artemas.reachin.com> References: <20010813171525.A29945@artemas.reachin.com> <20010814111307.789b3855.liedekef@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010814111307.789b3855.liedekef@pandora.be>; from liedekef@pandora.be on Tue, Aug 14, 2001 at 11:13:07AM +0200 > > http://www.maradns.org/sums-20010813.tar.bz2 > > > The file is not there ... Actually, it is: http://www.maradns.org/download/sums-20010813.tar.bz2 I will probably whittle down the number of summing algorithms used om my sums. Enjoy the outdoors! - Sam (Down here, in San Diego, we have to worry about it getting too hot, not too cold. Every day is sunny this time of year) -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 4939 invoked from network); 15 Aug 2001 08:23:38 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 15 Aug 2001 08:23:38 -0700 Received: from franky (D5E057BA.kabel.telenet.be [213.224.87.186]) by pop3.telenet-ops.be (Postfix) with SMTP id 3F59A9BDBE for ; Wed, 15 Aug 2001 17:23:40 +0200 (CEST) Date: Wed, 15 Aug 2001 17:31:13 +0200 From: Franky Van Liedekerke To: list@maradns.org Subject: seperate limit on udp, tcp, zonestransfers Message-Id: <20010815173113.756545a0.liedekef@pandora.be> X-Mailer: Sylpheed version 0.5.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Sam, now that the limit is implemented (and working) on solaris, I have another small question: would it be possible to split the maxproc parameter in three? I was thinking of one parameter for udp connection limit, one for tcp (future) and one for the number of concurrent zonetransfers. This doesn't require any real code changes (exept for one file that defines the keywords and some name changes in the files using the parameters) unless it woud interfer with the setrlimit call. Franky btw: in MaraDns.h, the lines (for Solaris) containing "According to Franky..." should be removed, as they belonged to the RLIMIT_NPROC definition, but that has been removed now. btw 2: do you have any feedback for the js_test program I send? I have some (2) days left, so I can still work on it a bit. From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 6700 invoked by uid 1108); 15 Aug 2001 17:14:38 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 15 Aug 2001 17:14:38 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.15 released Message-ID: <20010815171438.A6659@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i I am starting to actually believe the popular online comment that only the cluless use AOL to get on the internet. Being forced to use an AOL account does this to me. Currently, since I am staying with family before going to Mexico, I am stuck with using whatever internet connection my family or friends have. @home network connections are a breeze. Just hook up my ethernet card to the cable modem via a crosslink table, and use ifconfig and route to get the IP my freinds computer has. Voila, I am on the internet from my laptop. Unfortunatly, my friends with @home cable modem connections are busy today. Hence, I am stuck with AOHell. At least it is AOHell DSL. First of all, forget about hooking up Linux to an AOL connection. While AOL mumbles about making a Linux AOL client, it just has not happened yet. And, quite frankly, I don't think it is agonna happen either. So, all the changes I make to MaraDNS have to be done without an active network connection. Forget about fixing the "This host name does not resolve" kinds of bugs. Then, once I make the changes, I have to do all this: * Copy the files to a floppy * Copy the files to a Windoze computer * Figure out how to copy those files over AOL's crappy internet. Did I say crappy internet? Yes. I founf out, the hard way, that AOL's tcp/ip stack for Windoze is incapable of performing file uploads. Not only do none of the scp clients for Windoze work (they barf out after transferring 4k or so of data), but that plain old FTP has the same problem. The only reliable way to send files from an AOL network connection is via email attachments. Grrrr. And, if I have more than one attachment in a file, AOL forces the attachments together in a ZIP file, in order to "save space". Never mind that the files are already bz2 compressed, which is an far more effective compression scheme than .zip compression. Argh. Despite this, I have made available an update to MaraDNS. This update has a new program, "asktest", which is a modification of askmara which is optimized for regression testing. This program contacts the name server, and return an error code if there is anything wrong with the reply. I will use this for the regression testing. The report on the 'net is that the custodian() is horribly broken--it considerably slows things down once it "kicks in". I will look in to this and hope to fix things. Hopefully, I will get something better than AOHell, which will actaully allow me to test these things from my laptop. I have also updated the sums program. The main change is some improvments in the md5 wrapper, and the addition of the Tiger hash. As an aisde, the md5sum bundled with redhat is extremely slow. By recompiling md5 with -O3, I can get performance three times faster than the normal md5sum. The new summers: http://www.maradns.org/download/sums-20010815.tar.bz2 http://www.maradns.org/download/sums-papers-20010815.tar.bz2 Until I am able to update the web page, check out: http://www.maradns.org/download/maradns-0.8.15.tar.bz2 See ya soon! - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 6780 invoked by uid 1108); 15 Aug 2001 17:17:00 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 15 Aug 2001 17:17:00 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: sums Message-ID: <20010815171700.A6765@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Here are the sums: File maradns-0.8.15.tar.bz2 BSD sum and 1024-byte block count: 04025 182 SYSV sum and 512-byte block count: 18736 363 maradns-0.8.15.tar.bz2 CRC checksum and byte count 3167251983 185456 maradns-0.8.15.tar.bz2 MD5 sum: f8a08e37 27a3b624 7e91d0b2 714e2b31 maradns-0.8.15.tar.bz2 SHA1 sum: ccdd27b9636393f77f92e5b0c5e6aa8383a5e2f2 maradns-0.8.15.tar.bz2 Whirlpool digest: 0238f7481bbe9b1812bf88cac99685512a2afc45221147504c2899fbd5add583cc14b18b5dc225869df42ffec7a88efbf045ed77e88aef6e2eefe0803f0fcd86 HAVAL (5-pass, 256-bit) sum: HAVAL(File maradns-0.8.15.tar.bz2) = 24655acaebeb2191007203ec749554e0db047edfab42d5c353bb432461265975 Tiger digest: 04a7fba9dd547c375f9c14385e39d7ec2de4adb36dae8cb9 File sums-20010815.tar.bz2 BSD sum and 1024-byte block count: 27743 96 SYSV sum and 512-byte block count: 34116 191 sums-20010815.tar.bz2 CRC checksum and byte count 4008538367 97436 sums-20010815.tar.bz2 MD5 sum: 8f32e3e8 ff8376ba 1ca45f9b 4ae6fa36 sums-20010815.tar.bz2 SHA1 sum: 5d3e6af16253719a1fd77ac189e64a4e48f44d37 sums-20010815.tar.bz2 Whirlpool digest: 9f80a18b52949bfef84344e7c41757888850c4ce495d0c7314f0793107726781204e6ecb176fe981512d400ba23076bd49b5069892ee4e293a2376f8c327adb8 HAVAL (5-pass, 256-bit) sum: HAVAL(File sums-20010815.tar.bz2) = f873e4c6f19c646b80a7fb18ff8ffc295f26f7e5850135c1614afa54ac5236a9 Tiger digest: 700af284813beb731e2212c51d77dd0b412e085b782e896b File sums-papers-20010815.tar.bz2 BSD sum and 1024-byte block count: 18994 1029 SYSV sum and 512-byte block count: 738 2058 sums-papers-20010815.tar.bz2 CRC checksum and byte count 1495864467 1053651 sums-papers-20010815.tar.bz2 MD5 sum: c0884c21 7bf50c88 83915f58 890ff395 sums-papers-20010815.tar.bz2 SHA1 sum: 6ba75203fd411d7efbbb0312f8734a8ac0192395 sums-papers-20010815.tar.bz2 Whirlpool digest: 0b86ac96a3ad086cecf7c08a8d6458f28915b8030068ba89a0dd368d738aaa8efac6b442694ece8ab9e526dc6fc21c00c3963b1e66875e9e5525524ee74e20e7 HAVAL (5-pass, 256-bit) sum: HAVAL(File sums-papers-20010815.tar.bz2) = 49c93e31246bbd22d38eb921392f0c3bcb92fed21cff666130243b2e22fdbb91 Tiger digest: c99c9c0d2ffe81380a611bf9c5449403d34b212c337f2695 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 9503 invoked from network); 16 Aug 2001 06:44:50 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 16 Aug 2001 06:44:50 -0700 Received: from franky (D5E059C5.kabel.telenet.be [213.224.89.197]) by pop3.telenet-ops.be (Postfix) with SMTP id BB0D99BB3B for ; Thu, 16 Aug 2001 15:44:51 +0200 (CEST) Date: Thu, 16 Aug 2001 15:52:24 +0200 From: Franky Van Liedekerke To: maradns Subject: maradns 0.8.15 Message-Id: <20010816155224.0017bb4b.liedekef@pandora.be> X-Mailer: Sylpheed version 0.5.3 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, some small remarks on the latest of maradns: 1) the number of child limiting in the zonestransfer works, but since you start counting from 0, the following should change from (file zoneserver.c): while(num_children > maxprocs) to: while(num_children >= maxprocs) The same goes for recursive.c. From: if(num_of_threads_running > maximum_num_of_threads) { to: if(num_of_threads_running >= maximum_num_of_threads) { 2) For the zonetransfer test, I just added some debug lines and did concurrent telnet sessions, but I saw no timeout on the telnet sessions. Is this supposed to be? Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 11595 invoked from network); 16 Aug 2001 15:59:33 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 16 Aug 2001 15:59:33 -0700 Received: from franky (D5E059C5.kabel.telenet.be [213.224.89.197]) by tartarus.telenet-ops.be (Postfix) with SMTP id F0338216F61 for ; Fri, 17 Aug 2001 00:59:33 +0200 (CEST) Date: Fri, 17 Aug 2001 01:07:04 +0200 From: Franky Van Liedekerke To: maradns Subject: strange behaviour Message-Id: <20010817010704.71834c7c.liedekef@pandora.be> X-Mailer: Sylpheed version 0.5.3 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit When I say in the mararc file: maradns_uid = 99 everything works, but when I say: maradns_uid = 500 (with 500 being an existing userid, other than nobody) and I do then a recursive query, it never succeeds. In the strace, I see this: clone(child_stack=0x8076048, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PTRACE) = -1 EAGAIN (Resource temporarily unavailable) Any idea what this means? Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13165 invoked from network); 16 Aug 2001 20:32:56 -0700 Received: from unknown (HELO ns.infocentr.ru) (195.161.195.130) by artemas.reachin.com with SMTP; 16 Aug 2001 20:32:56 -0700 Received: (qmail 1320 invoked from network); 17 Aug 2001 03:32:55 -0000 Received: from kishkin.ru (195.161.195.197) by infocentr.ru with SMTP; 17 Aug 2001 03:32:55 -0000 Date: Fri, 17 Aug 2001 09:33:02 +0600 From: Aleksey Kishkin To: Subject: Re: strange behaviour Message-Id: <20010817093302.66a663df.aleksey@kishkin.ru> In-Reply-To: <20010817010704.71834c7c.liedekef@pandora.be> References: <20010817010704.71834c7c.liedekef@pandora.be> X-Mailer: Sylpheed version 0.4.99 (GTK+ 1.2.10; i586-alt-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 17 Aug 2001 01:07:04 +0200 Franky Van Liedekerke wrote: > maradns_uid = 500 (with 500 being an existing userid, other than nobody) > > and I do then a recursive query, it never succeeds. In the strace, I see this: > > clone(child_stack=0x8076048, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_PTRACE) = -1 EAGAIN (Resource temporarily unavailable) > > Any idea what this means? > May be user with uid=500 has ulimit -u "somelowvalue" ? From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 18323 invoked by uid 1108); 17 Aug 2001 22:30:52 -0700 Sender: aj7kwkp@maradns.org Date: Fri, 17 Aug 2001 22:30:52 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.16 released Message-ID: <20010817223052.A18279@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, First of all, Sunday is the big day: I am going down to Mexico on Sunday and will spend four months there learning Spanish. Hopefully, I will know a few words in Spanish when I return. Second of all, I got a real network connection again, at least for tonight (this may be a pain to get in Mexico). So, we have MaraDNS-0.8.16, which has: * Code cleanup * Another regression test added to the sqa (formerly 'regression') section * Document reorganization. Basically, the stuff to get started with MaraDNS is in the main 'doc' directory, with more technical docs in a "detailed/" subdirectory. * Added Franky's suggestion for a user-customizable TCP limit separate from the UDP maxprocs in the "Do for the 1.2 release" section. I have also updated the program the generates the sums. The main changes is that I have made the output more compact, and have added support for RIPEM128 and RIPEM160 hashes. The sum program can be found on the MaraDNS download page, or can be downloaded here: http://www.maradns.org/download/sums-20010817.tar.bz2 http://www.maradns.org/download/sums-papers-20010817.tar.bz2 The sums for all the programs are included after my signature. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card vela 22:16:00 maradns $ sums maradns-0.8.16.tar.bz2 BSD = 56322 184 SYSV = 30217 367 CRC = 2019857083 187412 MD5 = e48afe22554e4830c76868cd95a16683 SHA1 = 9d96dc96c52145cf29d87276afffd0dd9be5ac0b SHA-256 = 35024f55b604690c9b0720028a9ebd27a3c0106875870057ddfe9b4d0cad9456 SHA-384 = 75309eb2a4e1b08ddfb8ee6e34425694d4519fdb36a1966f3d95b0a9760f61f7e231ad977a7c889beef2265a7c2083cd SHA-512 = d8f457c2c4d730f47bf7a3ef6c1754817c97f3da6eb7375d28c699c8c39f05edac9b4525fcc3c5b8eb9ee248c34fab96351ccc1e1244fd7dd814d41697fa03e9 Wrlpool = 906baf3af9692919ec1f61fed3ed977f0c7410acf379e3d446e547808cbd8bd560107bc5964b64dbd27dd5485156f869b71f54731074ca0b3410a74eca6ff662 HAVAL5 = 98b45c090829f8c583cd178ff7f5ad9fa0c7b060496c5dbbe42d125f913e612d Tiger = 06ef7dd043e52af74b33693ef348d6a3f8346c0b3125b2aa RMD128 = 788c0f9ab221f00fe5f36d4e33bb4ac0 RMD160 = 28e5e4b9c02834a810fa779fdcfbc0335649610d vela 22:16:09 maradns $ sums sums-20010817.tar.bz2 BSD = 29015 154 SYSV = 20102 308 CRC = 3515048080 157280 MD5 = df4fbc2ed76c8b0eecb401ec5d641043 SHA1 = 751889401145322d86168fa52864c90358220ab6 SHA-256 = ea292a8cc9817cf10805ba43ba64e77f276278bc6193e4d12cb541833b83dafa SHA-384 = d2af08848980be9aa6b40d04fbe3c5b3bf83619febb4a59a7fa1b893f3e5e3308d97f011154bd917d981dc08659fa084 SHA-512 = 3f7f44a9695c6d30e6b90071c6d0fd7a01906f2f41fa60396a773a455189ec8b4d4cfd4685ebbace26a5f9e99cc7c9d52bb83fe4c53af56086c36cb1c9185b74 Wrlpool = 0d919cfde9fcda4ee17f6610ac40b395cbd2aa732fd005b1901f728331ba65c248e5919c06ccf78af00779fe94424e260f63debc2fb674d4c201fdcb3c6d6ccf HAVAL5 = 5a710ab505d6de0fb69fd4ec5210f959994d38c8f71bf297a66d0e1736b8f889 Tiger = c4be8ff46f8f42de6307004ebe3d7e8e17ef9e8bd900fbc8 RMD128 = b3a71cac2f4d79289b1b4f0e19932e18 RMD160 = b6b71a920fbed7df50b9237fc7268b6758e4a957 vela 22:17:32 maradns $ sums sums-papers-20010817.tar.bz2 BSD = 63735 1119 SYSV = 46063 2238 CRC = 2011589970 1145491 MD5 = b58eeffe5e746855abde9e2d83da4eb4 SHA1 = d613931bf162a7d2d1d7176431056d5303199750 SHA-256 = b83d2af891820641c55fd2536f158de32fb6f6faa8fa3107da77b14621caa515 SHA-384 = e06c917a274a2f4f837df3f83f0a13ea94eba2b36f9e273cc484e77e3d406912b723ceb2a1e30912da3a81902ff32c0b SHA-512 = 4e4caf2df36576844dc2baec822cbcc2db733bdd9071111c09ebd43ce930dd0536ca6fce7ebf342ccff469033d3498690f3d4440d37ffbfcc6747f70940670b0 Wrlpool = 4eaf4ed55dd30d5f6f00023e13bb19a6da35308415150738c31cda57b2c0e31d54c9615d487115b88184a65231fdfb6e2c7044b064ab871328d11b715b4c7654 HAVAL5 = a1aec812bfb2868cbbabd4c7bc0382f921cd2a2e0b2003a3a17b7954379ef3a7 Tiger = cbb54af536ba942a2649fdeaacc09ea871042bfc2c8bc472 RMD128 = 03520d096264880655edd6251828117a RMD160 = 8a183a1f490694f2701387e3b97c23e1ee2f4412 From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 18573 invoked from network); 18 Aug 2001 02:52:32 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 18 Aug 2001 02:52:32 -0700 Received: from franky (D5E05BC8.kabel.telenet.be [213.224.91.200]) by pop3.telenet-ops.be (Postfix) with SMTP id B08219BB47 for ; Sat, 18 Aug 2001 11:52:32 +0200 (CEST) Date: Sat, 18 Aug 2001 12:00:06 +0200 From: Franky Van Liedekerke To: Subject: Re: MaraDNS 0.8.16 released Message-Id: <20010818120006.3d8ebd8f.liedekef@pandora.be> In-Reply-To: <20010817223052.A18279@artemas.reachin.com> References: <20010817223052.A18279@artemas.reachin.com> X-Mailer: Sylpheed version 0.5.3 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 17 Aug 2001 22:30:52 -0700 aj7kwkp@maradns.org wrote: > * Added Franky's suggestion for a user-customizable TCP limit separate > from the UDP maxprocs in the "Do for the 1.2 release" section. > Hi Sam, if you like, I can submit a patch that implements this. I would replace the "maxprocs" keyword by "max_udp_threads" and "max_tcp_procs". If this is ok for you, I'll create a patch and submit it. btw: let us know when you're alive again in Mexico :) Franky btw (again): in the TODO.second file, you mention "Round robin rotates of data in the cache", but I believe this is done already, yes? From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 18817 invoked from network); 18 Aug 2001 05:46:10 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 18 Aug 2001 05:46:10 -0700 Received: from franky (D5E05BC8.kabel.telenet.be [213.224.91.200]) by tartarus.telenet-ops.be (Postfix) with SMTP id 7C0B7216F98 for ; Sat, 18 Aug 2001 14:46:09 +0200 (CEST) Date: Sat, 18 Aug 2001 14:53:43 +0200 From: Franky Van Liedekerke To: maradns Subject: patch for version 0.8.16 Message-Id: <20010818145343.0e73f605.liedekef@pandora.be> X-Mailer: Sylpheed version 0.5.3 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Sat__18_Aug_2001_14:53:43_+0200_081cba70" --Multipart_Sat__18_Aug_2001_14:53:43_+0200_081cba70 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This is a small patch against version 0.8.16 that does the following: 1) remove some leftover comment from MaraDns.h 2) changed line in TODO.second so it reflects that round robin from cached data is done 3) implemented my comment for number of children counting from zero (see a previous mail, is two lines of changes) 4) implemented splitting up maxprocs in "max_udp_threads" and "max_tcp_procs". The names of the new variables can be changed at will of course. Oh, and something else: this patch is public domain code. Franky --Multipart_Sat__18_Aug_2001_14:53:43_+0200_081cba70 Content-Type: application/octet-stream; name="diff.patch" Content-Disposition: attachment; filename="diff.patch" Content-Transfer-Encoding: base64 ZGlmZiAtdXIgbWFyYWRucy0wLjguMTYub3JpZy9NYXJhRG5zLmggbWFyYWRucy0wLjguMTYvTWFy YURucy5oCi0tLSBtYXJhZG5zLTAuOC4xNi5vcmlnL01hcmFEbnMuaAlUdWUgQXVnIDE0IDAwOjQw OjQ1IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L01hcmFEbnMuaAlTYXQgQXVnIDE4IDEyOjAwOjUz IDIwMDEKQEAgLTgsMTAgKzgsNiBAQAogI2RlZmluZSBfdWludF9kZWZpbmVkCiAjZW5kaWYgLyog X3VpbnRfZGVmaW5lZCAqLwogI2RlZmluZSAgICAgICBJTkFERFJfTk9ORSAgICAgICAgICAgICAw eGZmZmZmZmZmCi0vKiBBY2NvcmRpbmcgdG8gRnJhbmt5LCB0aGUgdmFsdWUgb2YgdGhpcyB2YXJp ZXMgZGVwZW5kaW5nIG9uIHRoZSB2ZXJzaW9uCi0gICBvZiBTb2xhcmlzIGJlaW5nIHVzZWQuICBT b21lIHZlcnNpb25zIG9mIFNvbGFyaXMgaGF2ZSBhIHZhbHVlIG9mICI2IiAKLSAgIGZvciB0aGlz Ci0qLwogI2VuZGlmIC8qIFNPTEFSSVMgKi8KIAogCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9y aWcvVE9ETy5zZWNvbmQgbWFyYWRucy0wLjguMTYvVE9ETy5zZWNvbmQKLS0tIG1hcmFkbnMtMC44 LjE2Lm9yaWcvVE9ETy5zZWNvbmQJRnJpIEF1ZyAxNyAxMToyODo0MSAyMDAxCisrKyBtYXJhZG5z LTAuOC4xNi9UT0RPLnNlY29uZAlTYXQgQXVnIDE4IDEyOjAwOjQyIDIwMDEKQEAgLTIzLDcgKzIz LDcgQEAKIAogKiBNYWtlIHRoZSBjYWNoZSBzaXplIHVzZXItY29uZmlndXJhYmxlIChET05FKQog Ci0qIFJvdW5kIHJvYmluIHJvdGF0ZXMgb2YgZGF0YSBpbiB0aGUgY2FjaGUgKFRoaXMgaXMgMS4y IG1hdGVyaWFsKQorKiBSb3VuZCByb2JpbiByb3RhdGVzIG9mIGRhdGEgaW4gdGhlIGNhY2hlIChE T05FKQogCiAqIEN1c3RvbWl6YWJsZSByb290IG5hbWUgc2VydmVycyB3aGljaCBhbGxvdyBwZW9w bGUgdG8gdXNlIGRpZmZlcmVudAogICBhbHRlcm5hdGUgcmVnaXN0cmllcyBmb3IgZGlmZmVybmV0 IFRMRHMuCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvZG9jL2RldGFpbGVkL2V4YW1wbGVf ZnVsbF9tYXJhcmMgbWFyYWRucy0wLjguMTYvZG9jL2RldGFpbGVkL2V4YW1wbGVfZnVsbF9tYXJh cmMKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvZG9jL2RldGFpbGVkL2V4YW1wbGVfZnVsbF9tYXJh cmMJRnJpIEF1ZyAxNyAxMTowODoxMCAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9kb2MvZGV0YWls ZWQvZXhhbXBsZV9mdWxsX21hcmFyYwlTYXQgQXVnIDE4IDE0OjE0OjQ1IDIwMDEKQEAgLTE4LDkg KzE4LDExIEBACiBtYXJhZG5zX3VpZCA9IDk5CiAjIFRoZSAob3B0aW9uYWwpIG51bWVyaWMgR0lE IE1hcmFETlMgd2lsbCBydW4gYXMKICMgbWFyYWRuc19naWQgPSA5OQotIyBUaGUgbWF4aW11bSBu dW1iZXIgb2YgdGhyZWFkcyAob3IgcHJvY2Vzc2VzLCB3aXRoIHRoZSB6b25lIHNlcnZlcikKKyMg VGhlIG1heGltdW0gbnVtYmVyIG9mIHVkcCB0aHJlYWRzIE1hcmFETlMgaXMgYWxsb3dlZCB0byBy dW4KK21heF91ZHBfdGhyZWFkcyA9IDk2CisjIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNz ZXMgd2l0aCB0aGUgem9uZSBzZXJ2ZXIKICMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgotbWF4 cHJvY3MgPSA5NgorbWF4X3RjcF9wcm9jcyA9IDk2CiAKICMgTm9ybWFsbHksIE1hcmFETlMgaGFz IHNvbWUgTWFyYUROUy1zcGVjaWZpYyBmZWF0dXJlcywgc3VjaCBhcyBERElQCiAjIHN5bnRoZXNp emluZywgYSBzcGVjaWFsIEROUyBxdWVyeSAoImVycmUtY29uLWVycmUtY2lnYXJyby5tYXJhZG5z Lm9yZy4iIApkaWZmIC11ciBtYXJhZG5zLTAuOC4xNi5vcmlnL2RvYy9leGFtcGxlX21hcmFyYyBt YXJhZG5zLTAuOC4xNi9kb2MvZXhhbXBsZV9tYXJhcmMKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcv ZG9jL2V4YW1wbGVfbWFyYXJjCUZyaSBBdWcgMTcgMTE6MTg6NDQgMjAwMQorKysgbWFyYWRucy0w LjguMTYvZG9jL2V4YW1wbGVfbWFyYXJjCVNhdCBBdWcgMTggMTQ6MTQ6MzcgMjAwMQpAQCAtMjAs OSArMjAsMTEgQEAKIGNocm9vdF9kaXIgPSAiL2V0Yy9tYXJhZG5zIgogIyBUaGUgbnVtZXJpYyBV SUQgTWFyYUROUyB3aWxsIHJ1biBhcwogbWFyYWRuc191aWQgPSA5OQotIyBUaGUgbWF4aW11bSBu dW1iZXIgb2YgdGhyZWFkcyAob3IgcHJvY2Vzc2VzLCB3aXRoIHRoZSB6b25lIHNlcnZlcikKKyMg VGhlIG1heGltdW0gbnVtYmVyIG9mIHVkcCB0aHJlYWRzIE1hcmFETlMgaXMgYWxsb3dlZCB0byBy dW4KK21heF91ZHBfdGhyZWFkcyA9IDk2CisjIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNz ZXMgd2l0aCB0aGUgem9uZSBzZXJ2ZXIKICMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgotbWF4 cHJvY3MgPSA5NgorbWF4X3RjcF9wcm9jcyA9IDk2CiAKICMgTW9zdCBvZiB0aGUgdGltZSwgdGhp cyBjYW4gc3RheSAzLiAgSG93ZXZlciwgd2hlbiByZWdpc3RlcmluZwogIyBhIGRvbWFpbiB1bmRl ciAuZGUsIC5hdSwgYW5kIHBvc3NpYmx5IG90aGVyIHRvcC1sZXZlbC1kb21haW5zLCB0aGlzCmRp ZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvZG9jL21hbi9tYXJhZG5zLjggbWFyYWRucy0wLjgu MTYvZG9jL21hbi9tYXJhZG5zLjgKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvZG9jL21hbi9tYXJh ZG5zLjgJVHVlIEp1bCAxNyAwNzo1OToyNyAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9kb2MvbWFu L21hcmFkbnMuOAlTYXQgQXVnIDE4IDE0OjE1OjE3IDIwMDEKQEAgLTU1LDggKzU1LDExIEBACiBj aHJvb3RfZGlyID0gIi9ldGMvbWFyYWRucyIKICMgVGhlIG51bWVyaWMgVUlEIE1hcmFETlMgd2ls bCBydW4gYXMKIG1hcmFkbnNfdWlkID0gOTkKLSMgVGhlIG1heGltdW0gbnVtYmVyIG9mIHByb2Nl c3NlcyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gdXNlCi1tYXhwcm9jcyA9IDY0CisjIFRoZSBtYXhp bXVtIG51bWJlciBvZiB1ZHAgdGhyZWFkcyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gcnVuCittYXhf dWRwX3RocmVhZHMgPSA5NgorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgcHJvY2Vzc2VzIHdpdGgg dGhlIHpvbmUgc2VydmVyCisjIE1hcmFETlMgaXMgYWxsb3dlZCB0byBydW4KK21heF90Y3BfcHJv Y3MgPSA5NgogCiAjIFRoZSBudW1iZXIgb2YgbWVzc2FnZXMgd2UgbG9nIHRvIHN0ZG91dAogIyAw OiBObyBtZXNzYWdlcywgZXhjZXB0IHN5bnRheCBlcnJvciBtZXNzYWdlcyAKZGlmZiAtdXIgbWFy YWRucy0wLjguMTYub3JpZy9wYXJzZS9QYXJzZU1hcmFSYy5jIG1hcmFkbnMtMC44LjE2L3BhcnNl L1BhcnNlTWFyYVJjLmMKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvcGFyc2UvUGFyc2VNYXJhUmMu YwlTdW4gQXVnIDEyIDA3OjI4OjQ2IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3BhcnNlL1BhcnNl TWFyYVJjLmMJU2F0IEF1ZyAxOCAxNDowMjozNSAyMDAxCkBAIC0xMSwxNCArMTEsMTUgQEAKIAog LyogS2V5d29yZHMgdGhhdCBhcmUgbm9uLWRpY3Rpb25hcnkgc3RyaW5ncyBpbiBNYXJhJ3MgcmMg ZmlsZSAqLwogCi0jZGVmaW5lIEtFWUNPVU5UIDE3CisjZGVmaW5lIEtFWUNPVU5UIDE4CiAKIGNo YXIgKmtleXdvcmRzW0tFWUNPVU5UXSA9IHsgCiAJImJpbmRfYWRkcmVzcyIsCiAgICAgICAgICJj aHJvb3RfZGlyIiwKICAgICAgICAgIm1hcmFkbnNfdWlkIiwKICAgICAgICAgIm1hcmFkbnNfZ2lk IiwKLSAgICAgICAgIm1heHByb2NzIiwKKyAgICAgICAgIm1heF90Y3BfcHJvY3MiLAorICAgICAg ICAibWF4X3VkcF90aHJlYWRzIiwKIAkidmVyYm9zZV9sZXZlbCIsCiAJInpvbmVfdHJhbnNmZXJf YWNsIiwKIAkicmVjdXJzaXZlX2FjbCIsCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvc2Vy dmVyL01hcmFETlMuYyBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvTWFyYUROUy5jCi0tLSBtYXJhZG5z LTAuOC4xNi5vcmlnL3NlcnZlci9NYXJhRE5TLmMJU3VuIEF1ZyAxMiAwODo0MzozMSAyMDAxCisr KyBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvTWFyYUROUy5jCVNhdCBBdWcgMTggMTQ6MDQ6NDYgMjAw MQpAQCAtMjQ4Myw3ICsyNDgzLDcgQEAKICAgICB1bnNpZ25lZCBjaGFyIGNocm9vdF96dFsyNTVd OwogICAgIHVpZF90IHVpZDsKICAgICBnaWRfdCBnaWQ7Ci0gICAgaW50IGVycm9ybiwgdmFsdWUs IHNvY2ssIG1heHByb2NzLCBjb3VudGVyOworICAgIGludCBlcnJvcm4sIHZhbHVlLCBzb2NrLCBt YXhfdWRwX3RocmVhZHMsIGNvdW50ZXI7CiAgICAgaW50IGNhY2hlX3NpemU7CiAgICAgc3RydWN0 IHNvY2thZGRyIGNsaWVudDsKICAgICBzdHJ1Y3QgcmxpbWl0IHJsaW07CkBAIC0yNTU4LDE5ICsy NTU4LDE5IEBACiAgICAgLyogR2V0IGluIHRvIGEgc3RhdGUgb2YgbGVhc3QgcHJpdmxlZGdlIEFT QVAgKi8KIAogICAgIC8qIExpbWl0IHRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNzZXMgKi8K LSAgICBpZihqc19xc3RyMmpzKGt2YXJfcXVlcnksIm1heHByb2NzIikgPT0gSlNfRVJST1IpCisg ICAgaWYoanNfcXN0cjJqcyhrdmFyX3F1ZXJ5LCJtYXhfdWRwX3RocmVhZHMiKSA9PSBKU19FUlJP UikKICAgICAgICAgaGFyZGVycm9yKExfS1ZBUl9RKTsgLyogIkNvdWxkIG5vdCBjcmVhdGUga3Zh cl9xdWVyeSIgKi8KICAgICBpZihyZWFkX2t2YXIoa3Zhcl9xdWVyeSxtYXhwc3RyKSA9PSBKU19F UlJPUikKLSAgICAgICAgaGFyZGVycm9yKExfTUFYUFJPQyk7IC8qICJQcm9ibGVtIGdldHRpbmcg bWF4cHJvY3MgdmFsdWUuXG5tYXhwcm9jcyBtdXN0IGJlIHNldCBiZWZvcmUgc3RhcnRpbmcgdGhl IE1hcmFETlMgc2VydmVyIiAqLwotICAgIGlmKChtYXhwcm9jcyA9IGpzX2F0b2kobWF4cHN0ciww KSkgPT0gMCkKLSAgICAgICAgaGFyZGVycm9yKExfTUFYUFJPQ19OVU0pOyAvKiAiUHJvYmxlbSBj b252ZXJ0aW5nIG1heHByb2NzIHRvIGEgbnVtYmVyXG5UaGlzIG11c3QgYmUgYSBub24temVybyBu dW1iZXIiICovCi0gICAgcmxpbS5ybGltX2N1ciA9IHJsaW0ucmxpbV9tYXggPSBtYXhwcm9jczsK KyAgICAgICAgaGFyZGVycm9yKExfTUFYX1VEUF9USFJFQURTKTsgLyogIlByb2JsZW0gZ2V0dGlu ZyBtYXhfdWRwX3RocmVhZHMgdmFsdWUuXG5tYXhfdWRwX3RocmVhZHMgbXVzdCBiZSBzZXQgYmVm b3JlIHN0YXJ0aW5nIHRoZSBNYXJhRE5TIHNlcnZlciIgKi8KKyAgICBpZigobWF4X3VkcF90aHJl YWRzID0ganNfYXRvaShtYXhwc3RyLDApKSA9PSAwKQorICAgICAgICBoYXJkZXJyb3IoTF9NQVhf VURQX1RIUkVBRFNfTlVNKTsgLyogIlByb2JsZW0gY29udmVydGluZyBtYXhfdWRwX3RocmVhZHMg dG8gYSBudW1iZXJcblRoaXMgbXVzdCBiZSBhIG5vbi16ZXJvIG51bWJlciIgKi8KKyAgICBybGlt LnJsaW1fY3VyID0gcmxpbS5ybGltX21heCA9IG1heF91ZHBfdGhyZWFkczsKIAogICAgIC8qIElm IHRoaXMgT1Mgc3VwcG9ydHMgc2V0cmxpbWl0IGFuZCBpZiBzZXRybGltaXQgZmFpbHMsIGJhaWwg KHRoZSBFTk9TWVMKICAgICAgICBjaGVjayBpcyB0aGVyZSBzbyBPU2VzIHcvbyBzZXRybGltaXQg c3VwcG9ydCBjYW4gc3RpbGwgcnVuIE1hcmFETlMpICovCiAjaWZuZGVmIFNPTEFSSVMKICAgICBp ZihzZXRybGltaXQoUkxJTUlUX05QUk9DLCZybGltKSAhPSAwICYmIGVycm5vICE9IEVOT1NZUykg Ci0gICAgICAgIHN5c19oYXJkZXJyb3IoTF9NQVhQUk9DX1NFVCk7IC8qICJVbmFibGUgdG8gc2V0 IG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyIgKi8KKyAgICAgICAgc3lzX2hhcmRlcnJvcihM X01BWF9VRFBfVEhSRUFEU19TRVQpOyAvKiAiVW5hYmxlIHRvIHNldCBtYXhpbXVtIG51bWJlciBv ZiBwcm9jZXNzZXMiICovCiAjZW5kaWYgLyogU09MQVJJUyAqLwogCiAgICAgLyogRGV0ZXJtaW5l IHRoZSBsZXZlbCBvZiBlcnJvciByZXBvcnRpbmcgKi8KQEAgLTI2NDQsNyArMjY0NCw3IEBACiAJ aWYobWFrZV9pcF9hY2wodmVyYnN0cixyZWN1cnNlX2FjbCw1MDAsMCkgPT0gSlNfRVJST1IpCiAJ ICAgIGhhcmRlcnJvcihMX0FDTF9MSVNUX1JFQ1VSU0UpOyAvKiAiQ291bGQgbm90IG1ha2UgaXAg QUNMIGxpc3QiICovCiAgICAgICAgIC8qIExvYWQgdGhlICJzZWVkIiBkYXRhIGluIHRvIHRoZSBE TlMgY2FjaGUgKi8KLSAgICAgICAgaWYoaW5pdF9jYWNoZShjYWNoZV9zaXplLG1heHByb2NzKSA9 PSBKU19FUlJPUikKKyAgICAgICAgaWYoaW5pdF9jYWNoZShjYWNoZV9zaXplLG1heF91ZHBfdGhy ZWFkcykgPT0gSlNfRVJST1IpCiAgICAgICAgICAgICBoYXJkZXJyb3IoTF9JTklUQ0FDSEVfRkFJ TCk7IC8qICJJbml0X2NhY2hlKCkgZmFpbGVkIiAqLwogICAgICAgICB9CiAKZGlmZiAtdXIgbWFy YWRucy0wLjguMTYub3JpZy9zZXJ2ZXIvTWFyYUROU19kZS5oIG1hcmFkbnMtMC44LjE2L3NlcnZl ci9NYXJhRE5TX2RlLmgKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvc2VydmVyL01hcmFETlNfZGUu aAlUaHUgQXByIDI2IDEwOjI0OjQ3IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3NlcnZlci9NYXJh RE5TX2RlLmgJU2F0IEF1ZyAxOCAxNDowNzoyMyAyMDAxCkBAIC0zNCw5ICszNCw5IEBACiAjZGVm aW5lIExfTUFSQVJDX0xJTkUgIlNhdHpnbGllZGVydW5nc2ZlaGxlciBpbSBJbmhhbHQgZGVyIE1h cmFyY2RhdGVpIgogI2RlZmluZSBMX0VSUk9SX0NPREUgIkZlaGxlcmNvZGU6ICIKICNkZWZpbmUg TF9LVkFSX1EgIktvbm50ZSBLZWluZUt2YXJfYWJmcmFnZXplaWNoZW5rZXR0ZSBoZXJzdGVsbGVu IgotI2RlZmluZSBMX01BWFBST0MgIkRhcyBQcm9ibGVtLCBkYXMgTWF4cHJvY3MgZXJoYWVsdCwg bXVzcyBlaW5nZXN0ZWxsdCB3ZXJkZW4sIGJldm9yIG1hbiBkZW4gTWFyYUROUy1zZXJ2ZXIgYW5z dGVsbHQiCi0jZGVmaW5lIExfTUFYUFJPQ19OVU0gIlByb2JsZW0gYmVpIGRlciBVbXdhbmRsdW5n IGRlciBNYXhwcm9jcyB6dSBlaW5lciBOdW1tZXJcbi4gRGllc2VzIG11c3Mga2VpbmUgTnVsbHph aGwgc2VpbiIuCi0jZGVmaW5lIExfTUFYUFJPQ19TRVQgIkRpZUVpbnN0ZWxsdW5nIGVpbmVyIG1h eGltYWxlIEFuemFobCB2b24gUHJvemVzc2VuIGlzdCBuaWNodCBtb2VnbGljaCIKKyNkZWZpbmUg TF9NQVhfVURQX1RIUkVBRFMgIkRhcyBQcm9ibGVtLCBkYXMgTWF4X3VkcF90aHJlYWRzIGVyaGFl bHQsIG11c3MgZWluZ2VzdGVsbHQgd2VyZGVuLCBiZXZvciBtYW4gZGVuIE1hcmFETlMtc2VydmVy IGFuc3RlbGx0IgorI2RlZmluZSBMX01BWF9VRFBfVEhSRUFEU19OVU0gIlByb2JsZW0gYmVpIGRl ciBVbXdhbmRsdW5nIGRlciBNYXhfdWRwX3RocmVhZHMgenUgZWluZXIgTnVtbWVyXG4uIERpZXNl cyBtdXNzIGtlaW5lIE51bGx6YWhsIHNlaW4iLgorI2RlZmluZSBMX01BWF9VRFBfVEhSRUFEU19T RVQgIkRpZUVpbnN0ZWxsdW5nIGVpbmVyIG1heGltYWxlIEFuemFobCB2b24gUHJvemVzc2VuIGlz dCBuaWNodCBtb2VnbGljaCIKICNkZWZpbmUgTF9DSFJPT1RfS1ZBUiAiUHJvYmxlbSBiZWltIEVt cGZhbmcgZGVyIENocm9vdCBLdmFyLlxuLiBNYW4gbXVzcyBkaWUgQ2hyb290X2RpciBlaW5zdGVs bGVuLCB1bSBpbSBVcnNwcnVuZyBhbnp1ZmFuZ2VuIgogI2RlZmluZSBMX0NIUk9PVF9OVCAiUHJv YmxlbSBiZWkgZGVyIEhlcnN0ZWxsdW5nIGRlciBDaHJvb3QgbnQgKHplaWNoZW4pa2V0dGUuIFN0 ZWxsZW4gU2llIHNpY2hlciwgZGFzcyBkYXMgQ2hyb290dmVyemVpY2huaXMgYXVzIDIwMCBaZWlj aGVuIG9kZXIgd2VuaWdlciBiZXN0ZWh0IgogI2RlZmluZSBMX0NIUk9PVF9DSEFOR0UgIlByb2Js ZW0gYmVpbSBXZWNoc2VsbiB6dW0gQ2hyb290dmVyemVpY2huaXMiCmRpZmYgLXVyIG1hcmFkbnMt MC44LjE2Lm9yaWcvc2VydmVyL01hcmFETlNfZW4uaCBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvTWFy YUROU19lbi5oCi0tLSBtYXJhZG5zLTAuOC4xNi5vcmlnL3NlcnZlci9NYXJhRE5TX2VuLmgJU3Vu IEF1ZyAxMiAwODoxNDoxOSAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvTWFyYUROU19l bi5oCVNhdCBBdWcgMTggMTQ6MDU6MTEgMjAwMQpAQCAtMzcsOSArMzcsOSBAQAogI2RlZmluZSBM X01BUkFSQ19MSU5FICJFcnJvciBwYXJzaW5nIGNvbnRlbnRzIG9mIG1hcmFyYyBmaWxlIG9uIGxp bmUgIgogI2RlZmluZSBMX0VSUk9SX0NPREUgIkVycm9yIGNvZGU6ICIKICNkZWZpbmUgTF9LVkFS X1EgIkNvdWxkIG5vdCBjcmVhdGUga3Zhcl9xdWVyeSIKLSNkZWZpbmUgTF9NQVhQUk9DICJQcm9i bGVtIGdldHRpbmcgbWF4cHJvY3MgdmFsdWUuXG5tYXhwcm9jcyBtdXN0IGJlIHNldCBiZWZvcmUg c3RhcnRpbmcgdGhlIE1hcmFETlMgc2VydmVyIgotI2RlZmluZSBMX01BWFBST0NfTlVNICJQcm9i bGVtIGNvbnZlcnRpbmcgbWF4cHJvY3MgdG8gYSBudW1iZXJcblRoaXMgbXVzdCBiZSBhIG5vbi16 ZXJvIG51bWJlciIKLSNkZWZpbmUgTF9NQVhQUk9DX1NFVCAiVW5hYmxlIHRvIHNldCBtYXhpbXVt IG51bWJlciBvZiBwcm9jZXNzZXMiCisjZGVmaW5lIExfTUFYX1VEUF9USFJFQURTICJQcm9ibGVt IGdldHRpbmcgbWF4X3VkcF90aHJlYWRzIHZhbHVlLlxubWF4X3VkcF90aHJlYWRzIG11c3QgYmUg c2V0IGJlZm9yZSBzdGFydGluZyB0aGUgTWFyYUROUyBzZXJ2ZXIiCisjZGVmaW5lIExfTUFYX1VE UF9USFJFQURTX05VTSAiUHJvYmxlbSBjb252ZXJ0aW5nIG1heF91ZHBfdGhyZWFkcyB0byBhIG51 bWJlclxuVGhpcyBtdXN0IGJlIGEgbm9uLXplcm8gbnVtYmVyIgorI2RlZmluZSBMX01BWF9VRFBf VEhSRUFEU19TRVQgIlVuYWJsZSB0byBzZXQgbWF4aW11bSBudW1iZXIgb2YgdGhyZWFkcyIKICNk ZWZpbmUgTF9DSFJPT1RfS1ZBUiAiUHJvYmxlbSBnZXR0aW5nIGNocm9vdCBrdmFyLlxuWW91IG11 c3QgaGF2ZSBjaHJvb3RfZGlyIHNldCBpZiB5b3Ugc3RhcnQgdGhpcyBhcyByb290IgogI2RlZmlu ZSBMX0NIUk9PVF9OVCAiUHJvYmxlbSBtYWtpbmcgY2hyb290IG50IHN0cmluZy5cbk1ha2Ugc3Vy ZSB0aGUgY2hyb290IGRpcmVjdG9yeSBpcyAyMDAgY2hhcnMgb3IgbGVzcyIKICNkZWZpbmUgTF9D SFJPT1RfQ0hBTkdFICJQcm9ibGVtIGNoYW5naW5nIHRvIGNocm9vdCBkaXIuXG5NYWtlIHN1cmUg Y2hyb290X2RpciBwb2ludHMgdG8gYSB2YWxpZCBkaXJlY3RvcnkiCmRpZmYgLXVyIG1hcmFkbnMt MC44LjE2Lm9yaWcvc2VydmVyL3JlY3Vyc2l2ZS5jIG1hcmFkbnMtMC44LjE2L3NlcnZlci9yZWN1 cnNpdmUuYwotLS0gbWFyYWRucy0wLjguMTYub3JpZy9zZXJ2ZXIvcmVjdXJzaXZlLmMJU2F0IEF1 ZyAxOCAwNzoxMTo1NCAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvcmVjdXJzaXZlLmMJ U2F0IEF1ZyAxOCAxMjowMjoxMCAyMDAxCkBAIC0yMTE4LDcgKzIxMTgsNyBAQAogCiAgICAgLyog TWFrZSBzdXJlIHdlIGNhbiBzcHdhd24gdGhlIHRocmVhZC4gKi8KICAgICB0Y291bnRfbG9jaygp OwotICAgIGlmKG51bV9vZl90aHJlYWRzX3J1bm5pbmcgPiBtYXhpbXVtX251bV9vZl90aHJlYWRz KSB7CisgICAgaWYobnVtX29mX3RocmVhZHNfcnVubmluZyA+PSBtYXhpbXVtX251bV9vZl90aHJl YWRzKSB7CiAgICAgICAgIHRjb3VudF91bmxvY2soKTsKIAlqc19kZWFsbG9jKHJlcSk7IGpzX2Rl c3Ryb3koY29weSk7CiAJLyogUmV0dXJuIGEgInNlcnZlciBmYWlsIiBlcnJvciBtZXNzYWdlIGlm IHdlIGNhbiBub3Qgc3Bhd24gCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvc3FhL3Rlc3Ri ZWQvbWFyYXJjIG1hcmFkbnMtMC44LjE2L3NxYS90ZXN0YmVkL21hcmFyYwotLS0gbWFyYWRucy0w LjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJhcmMJU3VuIEp1biAgMyAwNzowMDo0MCAyMDAxCisr KyBtYXJhZG5zLTAuOC4xNi9zcWEvdGVzdGJlZC9tYXJhcmMJU2F0IEF1ZyAxOCAxNDoxMzoxNCAy MDAxCkBAIC0xNCw4ICsxNCwxMSBAQAogIyBjaHJvb3RfZGlyID0gIi9ob21lL3NldC9tYXJhZG5z L3pvbmUiCiAjIFRoZSBudW1lcmljIFVJRCBNYXJhRE5TIHdpbGwgcnVuIGFzCiBtYXJhZG5zX3Vp ZCA9IDk5Ci0jIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNzZXMgTWFyYUROUyBpcyBhbGxv d2VkIHRvIHVzZQotbWF4cHJvY3MgPSA2NAorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgdWRwIHRo cmVhZHMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgorbWF4X3VkcF90aHJlYWRzID0gNjQKKyMg VGhlIG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyB3aXRoIHRoZSB6b25lIHNlcnZlcgorIyBN YXJhRE5TIGlzIGFsbG93ZWQgdG8gcnVuCittYXhfdGNwX3Byb2NzID0gNjQKIAogIyBUaGVzZSBj b25zdGFudHMgbGltaXQgdGhlIG51bWJlciBvZiByZWNvcmRzIHdlIHdpbGwgZGlzcGxheSwgaW4g b3JkZXIKICMgdG8gaGVscCBrZWVwIHBhY2tldHMgNTEyIGJ5dGVzIG9yIHNtYWxsZXIuICBUaGlz LCBjb21iaW5lZCB3aXRoIHJvdW5kX3JvYmluCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcv c3FhL3Rlc3RiZWQvbWFyYXJjLjEgbWFyYWRucy0wLjguMTYvc3FhL3Rlc3RiZWQvbWFyYXJjLjEK LS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvc3FhL3Rlc3RiZWQvbWFyYXJjLjEJTW9uIE1heSAxNCAy MDo1NjoyMiAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9zcWEvdGVzdGJlZC9tYXJhcmMuMQlTYXQg QXVnIDE4IDE0OjEzOjI4IDIwMDEKQEAgLTE3LDggKzE3LDExIEBACiAjIGNocm9vdF9kaXIgPSAi L2hvbWUvc2V0L21hcmFkbnMvem9uZSIKICMgVGhlIG51bWVyaWMgVUlEIE1hcmFETlMgd2lsbCBy dW4gYXMKIG1hcmFkbnNfdWlkID0gOTkKLSMgVGhlIG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3Nl cyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gdXNlCi1tYXhwcm9jcyA9IDY0CisjIFRoZSBtYXhpbXVt IG51bWJlciBvZiB1ZHAgdGhyZWFkcyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gcnVuCittYXhfdWRw X3RocmVhZHMgPSA2NAorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgcHJvY2Vzc2VzIHdpdGggdGhl IHpvbmUgc2VydmVyCisjIE1hcmFETlMgaXMgYWxsb3dlZCB0byBydW4KK21heF90Y3BfcHJvY3Mg PSA2NAogCiAjIFRoZXNlIGNvbnN0YW50cyBsaW1pdCB0aGUgbnVtYmVyIG9mIHJlY29yZHMgd2Ug d2lsbCBkaXNwbGF5LCBpbiBvcmRlcgogIyB0byBoZWxwIGtlZXAgcGFja2V0cyA1MTIgYnl0ZXMg b3Igc21hbGxlci4gIFRoaXMsIGNvbWJpbmVkIHdpdGggcm91bmRfcm9iaW4KZGlmZiAtdXIgbWFy YWRucy0wLjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJhcmMuMiBtYXJhZG5zLTAuOC4xNi9zcWEv dGVzdGJlZC9tYXJhcmMuMgotLS0gbWFyYWRucy0wLjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJh cmMuMglTdW4gSnVuICAzIDA2OjM3OjEzIDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3NxYS90ZXN0 YmVkL21hcmFyYy4yCVNhdCBBdWcgMTggMTQ6MTI6MTQgMjAwMQpAQCAtMTQsOCArMTQsMTEgQEAK ICMgY2hyb290X2RpciA9ICIvaG9tZS9zZXQvbWFyYWRucy96b25lIgogIyBUaGUgbnVtZXJpYyBV SUQgTWFyYUROUyB3aWxsIHJ1biBhcwogbWFyYWRuc191aWQgPSA5OQotIyBUaGUgbWF4aW11bSBu dW1iZXIgb2YgcHJvY2Vzc2VzIE1hcmFETlMgaXMgYWxsb3dlZCB0byB1c2UKLW1heHByb2NzID0g NjQKKyMgVGhlIG1heGltdW0gbnVtYmVyIG9mIHVkcCB0aHJlYWRzIE1hcmFETlMgaXMgYWxsb3dl ZCB0byBydW4KK21heF91ZHBfdGhyZWFkcyA9IDY0CisjIFRoZSBtYXhpbXVtIG51bWJlciBvZiBw cm9jZXNzZXMgd2l0aCB0aGUgem9uZSBzZXJ2ZXIKKyMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1 bgorbWF4X3RjcF9wcm9jcyA9IDY0CiAKICMgVGhlc2UgY29uc3RhbnRzIGxpbWl0IHRoZSBudW1i ZXIgb2YgcmVjb3JkcyB3ZSB3aWxsIGRpc3BsYXksIGluIG9yZGVyCiAjIHRvIGhlbHAga2VlcCBw YWNrZXRzIDUxMiBieXRlcyBvciBzbWFsbGVyLiAgVGhpcywgY29tYmluZWQgd2l0aCByb3VuZF9y b2JpbgpkaWZmIC11ciBtYXJhZG5zLTAuOC4xNi5vcmlnL3NxYS90ZXN0YmVkL21hcmFyYy40IG1h cmFkbnMtMC44LjE2L3NxYS90ZXN0YmVkL21hcmFyYy40Ci0tLSBtYXJhZG5zLTAuOC4xNi5vcmln L3NxYS90ZXN0YmVkL21hcmFyYy40CVN1biBKdW4gIDMgMDY6Mzc6MTggMjAwMQorKysgbWFyYWRu cy0wLjguMTYvc3FhL3Rlc3RiZWQvbWFyYXJjLjQJU2F0IEF1ZyAxOCAxNDoxMjoyOCAyMDAxCkBA IC0xNCw4ICsxNCwxMSBAQAogIyBjaHJvb3RfZGlyID0gIi9ob21lL3NldC9tYXJhZG5zL3pvbmUi CiAjIFRoZSBudW1lcmljIFVJRCBNYXJhRE5TIHdpbGwgcnVuIGFzCiBtYXJhZG5zX3VpZCA9IDk5 Ci0jIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNzZXMgTWFyYUROUyBpcyBhbGxvd2VkIHRv IHVzZQotbWF4cHJvY3MgPSA2NAorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgdWRwIHRocmVhZHMg TWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgorbWF4X3VkcF90aHJlYWRzID0gNjQKKyMgVGhlIG1h eGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyB3aXRoIHRoZSB6b25lIHNlcnZlcgorIyBNYXJhRE5T IGlzIGFsbG93ZWQgdG8gcnVuCittYXhfdGNwX3Byb2NzID0gNjQKIAogIyBUaGVzZSBjb25zdGFu dHMgbGltaXQgdGhlIG51bWJlciBvZiByZWNvcmRzIHdlIHdpbGwgZGlzcGxheSwgaW4gb3JkZXIK ICMgdG8gaGVscCBrZWVwIHBhY2tldHMgNTEyIGJ5dGVzIG9yIHNtYWxsZXIuICBUaGlzLCBjb21i aW5lZCB3aXRoIHJvdW5kX3JvYmluCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvc3FhL3Rl c3RiZWQvbWFyYXJjLjUgbWFyYWRucy0wLjguMTYvc3FhL3Rlc3RiZWQvbWFyYXJjLjUKLS0tIG1h cmFkbnMtMC44LjE2Lm9yaWcvc3FhL3Rlc3RiZWQvbWFyYXJjLjUJU3VuIEp1biAgMyAwOTowNjow MiAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9zcWEvdGVzdGJlZC9tYXJhcmMuNQlTYXQgQXVnIDE4 IDE0OjEyOjQyIDIwMDEKQEAgLTE0LDggKzE0LDExIEBACiAjIGNocm9vdF9kaXIgPSAiL2hvbWUv c2V0L21hcmFkbnMvem9uZSIKICMgVGhlIG51bWVyaWMgVUlEIE1hcmFETlMgd2lsbCBydW4gYXMK IG1hcmFkbnNfdWlkID0gOTkKLSMgVGhlIG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyBNYXJh RE5TIGlzIGFsbG93ZWQgdG8gdXNlCi1tYXhwcm9jcyA9IDY0CisjIFRoZSBtYXhpbXVtIG51bWJl ciBvZiB1ZHAgdGhyZWFkcyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gcnVuCittYXhfdWRwX3RocmVh ZHMgPSA2NAorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgcHJvY2Vzc2VzIHdpdGggdGhlIHpvbmUg c2VydmVyCisjIE1hcmFETlMgaXMgYWxsb3dlZCB0byBydW4KK21heF90Y3BfcHJvY3MgPSA2NAog CiAjIFRoZXNlIGNvbnN0YW50cyBsaW1pdCB0aGUgbnVtYmVyIG9mIHJlY29yZHMgd2Ugd2lsbCBk aXNwbGF5LCBpbiBvcmRlcgogIyB0byBoZWxwIGtlZXAgcGFja2V0cyA1MTIgYnl0ZXMgb3Igc21h bGxlci4gIFRoaXMsIGNvbWJpbmVkIHdpdGggcm91bmRfcm9iaW4KZGlmZiAtdXIgbWFyYWRucy0w LjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJhcmMuNiBtYXJhZG5zLTAuOC4xNi9zcWEvdGVzdGJl ZC9tYXJhcmMuNgotLS0gbWFyYWRucy0wLjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJhcmMuNglT dW4gSnVuICAzIDA2OjU4OjI1IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3NxYS90ZXN0YmVkL21h cmFyYy42CVNhdCBBdWcgMTggMTQ6MTI6NTUgMjAwMQpAQCAtMTQsOCArMTQsMTEgQEAKICMgY2hy b290X2RpciA9ICIvaG9tZS9zZXQvbWFyYWRucy96b25lIgogIyBUaGUgbnVtZXJpYyBVSUQgTWFy YUROUyB3aWxsIHJ1biBhcwogbWFyYWRuc191aWQgPSA5OQotIyBUaGUgbWF4aW11bSBudW1iZXIg b2YgcHJvY2Vzc2VzIE1hcmFETlMgaXMgYWxsb3dlZCB0byB1c2UKLW1heHByb2NzID0gNjQKKyMg VGhlIG1heGltdW0gbnVtYmVyIG9mIHVkcCB0aHJlYWRzIE1hcmFETlMgaXMgYWxsb3dlZCB0byBy dW4KK21heF91ZHBfdGhyZWFkcyA9IDY0CisjIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNz ZXMgd2l0aCB0aGUgem9uZSBzZXJ2ZXIKKyMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgorbWF4 X3RjcF9wcm9jcyA9IDY0CiAKICMgVGhlc2UgY29uc3RhbnRzIGxpbWl0IHRoZSBudW1iZXIgb2Yg cmVjb3JkcyB3ZSB3aWxsIGRpc3BsYXksIGluIG9yZGVyCiAjIHRvIGhlbHAga2VlcCBwYWNrZXRz IDUxMiBieXRlcyBvciBzbWFsbGVyLiAgVGhpcywgY29tYmluZWQgd2l0aCByb3VuZF9yb2Jpbgpk aWZmIC11ciBtYXJhZG5zLTAuOC4xNi5vcmlnL3R1em9uYS96b25lc2VydmVyLmMgbWFyYWRucy0w LjguMTYvdHV6b25hL3pvbmVzZXJ2ZXIuYwotLS0gbWFyYWRucy0wLjguMTYub3JpZy90dXpvbmEv em9uZXNlcnZlci5jCVR1ZSBBdWcgMTQgMDA6MTg6MzggMjAwMQorKysgbWFyYWRucy0wLjguMTYv dHV6b25hL3pvbmVzZXJ2ZXIuYwlTYXQgQXVnIDE4IDE0OjAxOjE0IDIwMDEKQEAgLTUxNyw3ICs1 MTcsNyBAQAogICAgIGpzX3N0cmluZyAqbWFyYXJjX2xvYywgKmVycm9ycywgKmNocm9vdG4sICpr dmFyX3N0ciwgKm1heHBzdHIsCiAgICAgICAgICAgICAgICprdmFyX3F1ZXJ5LCAqYmluZF9hZGRy ZXNzLCAqaW5jb21pbmcsICp1bmNvbXAsICp2ZXJic3RyOwogICAgIHVuc2lnbmVkIGNoYXIgY2hy b290X3p0WzI1NV07Ci0gICAgaW50IGVycm9ybiwgdmFsdWUsIHVpZCwgc29jaywgbWF4cHJvY3Ms IHZlcmJvc2UsIGNvdW50ZXIsIGNvbm5lY3Rpb24sCisgICAgaW50IGVycm9ybiwgdmFsdWUsIHVp ZCwgc29jaywgbWF4X3RjcF9wcm9jcywgdmVyYm9zZSwgY291bnRlciwgY29ubmVjdGlvbiwKICAg ICAgICAgaW5ldGQ7CiAgICAgbWhhc2hfZSBkZWJ1ZzI7CiAgICAgbWhhc2hfb2Zmc2V0IGRlYnVn OwpAQCAtNjA0LDEzICs2MDQsMTMgQEAKICAgICAvKiBHZXQgaW4gdG8gYSBzdGF0ZSBvZiBsZWFz dCBwcml2bGVkZ2UgQVNBUCAqLwogCiAgICAgLyogTGltaXQgdGhlIG1heGltdW0gbnVtYmVyIG9m IHByb2Nlc3NlcyAqLwotICAgIGlmKGpzX3FzdHIyanMoa3Zhcl9xdWVyeSwibWF4cHJvY3MiKSA9 PSBKU19FUlJPUikKKyAgICBpZihqc19xc3RyMmpzKGt2YXJfcXVlcnksIm1heF90Y3BfcHJvY3Mi KSA9PSBKU19FUlJPUikKICAgICAgICAgaGFyZGVycm9yKExfTUFLRV9LUSk7IC8qICJDb3VsZCBu b3QgY3JlYXRlIGt2YXJfcXVlcnkiICovCiAgICAgaWYocmVhZF9rdmFyKGt2YXJfcXVlcnksbWF4 cHN0cikgPT0gSlNfRVJST1IpCi0gICAgICAgIGhhcmRlcnJvcihMX01BWFBST0NTKTsgLyogIlBy b2JsZW0gZ2V0dGluZyBtYXhwcm9jcyB2YWx1ZS5cbm1heHByb2NzIG11c3QgYmUgc2V0IGJlZm9y ZSBzdGFydGluZyB0aGUgTWFyYUROUyBzZXJ2ZXIiICovCi0gICAgaWYoKG1heHByb2NzID0ganNf YXRvaShtYXhwc3RyLDApKSA9PSAwKQotICAgICAgICBoYXJkZXJyb3IoTF9NQVhQUk9DU19OVU0p OyAvKiAiUHJvYmxlbSBjb252ZXJ0aW5nIG1heHByb2NzIHRvIGEgbnVtYmVyXG5UaGlzIG11c3Qg YmUgYSBub24temVybyBudW1iZXIiICovCi0gICAgcmxpbS5ybGltX2N1ciA9IHJsaW0ucmxpbV9t YXggPSBtYXhwcm9jczsKKyAgICAgICAgaGFyZGVycm9yKExfTUFYX1RDUF9QUk9DUyk7IC8qICJQ cm9ibGVtIGdldHRpbmcgbWF4X3RjcF9wcm9jcyB2YWx1ZS5cbm1heF90Y3BfcHJvY3MgbXVzdCBi ZSBzZXQgYmVmb3JlIHN0YXJ0aW5nIHRoZSBNYXJhRE5TIHNlcnZlciIgKi8KKyAgICBpZigobWF4 X3RjcF9wcm9jcyA9IGpzX2F0b2kobWF4cHN0ciwwKSkgPT0gMCkKKyAgICAgICAgaGFyZGVycm9y KExfTUFYUF9UQ1BfUk9DU19OVU0pOyAvKiAiUHJvYmxlbSBjb252ZXJ0aW5nIG1heF90Y3BfcHJv Y3MgdG8gYSBudW1iZXJcblRoaXMgbXVzdCBiZSBhIG5vbi16ZXJvIG51bWJlciIgKi8KKyAgICBy bGltLnJsaW1fY3VyID0gcmxpbS5ybGltX21heCA9IG1heF90Y3BfcHJvY3M7CiAjaWZuZGVmIFNP TEFSSVMKICAgICBpZihzZXRybGltaXQoUkxJTUlUX05QUk9DLCZybGltKSAhPSAwKQogICAgICAg ICBoYXJkZXJyb3IoTF9TRVRNQVgpOyAvKiAiVW5hYmxlIHRvIHNldCBtYXhpbXVtIG51bWJlciBv ZiBwcm9jZXNzZXMiICovCkBAIC03MjIsNyArNzIyLDcgQEAKICAgICAgICAgICAgIG1sb2coTF9H T1QpOyAvKiAiTWVzc2FnZSByZWNlaXZlZCwgcHJvY2Vzc2luZyIgKi8KIAogICAgICAgICAvKiBN YWtlIHN1cmUgd2UgZG9uJ3QgaGF2ZSBtb3JlIGNoaWxkcmVuIHRoYW4gd2UgY2FuIGhhbmRsZSAq LwotCXdoaWxlKG51bV9jaGlsZHJlbiA+IG1heHByb2NzKQorCXdoaWxlKG51bV9jaGlsZHJlbiA+ PSBtYXhfdGNwX3Byb2NzKQogCSAgICBzbGVlcCgxKTsKIAogICAgICAgICAvKiBGb3JrIGFuZCBo YXZlIHRoZSBjaGlsZCBoYW5kbGUgdGhlIGRhdGEgKi8KZGlmZiAtdXIgbWFyYWRucy0wLjguMTYu b3JpZy90dXpvbmEvem9uZXNlcnZlcl9lbi5oIG1hcmFkbnMtMC44LjE2L3R1em9uYS96b25lc2Vy dmVyX2VuLmgKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvdHV6b25hL3pvbmVzZXJ2ZXJfZW4uaAlT dW4gSnVuIDE3IDIyOjIxOjA1IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3R1em9uYS96b25lc2Vy dmVyX2VuLmgJU2F0IEF1ZyAxOCAxNDowMTo0MCAyMDAxCkBAIC0yOCw4ICsyOCw4IEBACiAjZGVm aW5lIExfRVJST1JfQ09ERSAiRXJyb3IgY29kZTogIgogI2RlZmluZSBMRiAiXG4iCiAjZGVmaW5l IExfTUFLRV9LUSAiQ291bGQgbm90IGNyZWF0ZSBrdmFyX3F1ZXJ5IgotI2RlZmluZSBMX01BWFBS T0NTICJQcm9ibGVtIGdldHRpbmcgbWF4cHJvY3MgdmFsdWUuXG5tYXhwcm9jcyBtdXN0IGJlIHNl dCBiZWZvcmUgc3RhcnRpbmcgdGhlIE1hcmFETlMgc2VydmVyIgotI2RlZmluZSBMX01BWFBST0NT X05VTSAiUHJvYmxlbSBjb252ZXJ0aW5nIG1heHByb2NzIHRvIGEgbnVtYmVyXG5UaGlzIG11c3Qg YmUgYSBub24temVybyBudW1iZXIiCisjZGVmaW5lIExfTUFYX1RDUF9QUk9DUyAiUHJvYmxlbSBn ZXR0aW5nIG1heF90Y3BfcHJvY3MgdmFsdWUuXG5tYXhfdGNwX3Byb2NzIG11c3QgYmUgc2V0IGJl Zm9yZSBzdGFydGluZyB0aGUgTWFyYUROUyBzZXJ2ZXIiCisjZGVmaW5lIExfTUFYX1RDUF9QUk9D U19OVU0gIlByb2JsZW0gY29udmVydGluZyBtYXhfdGNwX3Byb2NzIHRvIGEgbnVtYmVyXG5UaGlz IG11c3QgYmUgYSBub24temVybyBudW1iZXIiCiAjZGVmaW5lIExfU0VUTUFYICJVbmFibGUgdG8g c2V0IG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyIKICNkZWZpbmUgTF9DSFJPT1QgIlByb2Js ZW0gZ2V0dGluZyBjaHJvb3Qga3Zhci5cbllvdSBtdXN0IGhhdmUgY2hyb290X2RpciBzZXQgaWYg eW91IHN0YXJ0IHRoaXMgYXMgcm9vdCIKICNkZWZpbmUgTF9DSFJPT1RfTlQgIlByb2JsZW0gbWFr aW5nIGNocm9vdCBudCBzdHJpbmcuXG5NYWtlIHN1cmUgdGhlIGNocm9vdCBkaXJlY3RvcnkgaXMg MjAwIGNoYXJzIG9yIGxlc3MiCg== --Multipart_Sat__18_Aug_2001_14:53:43_+0200_081cba70-- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 18859 invoked from network); 18 Aug 2001 05:57:39 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 18 Aug 2001 05:57:39 -0700 Received: from franky (D5E05BC8.kabel.telenet.be [213.224.91.200]) by pop3.telenet-ops.be (Postfix) with SMTP id 4515A9BB3C for ; Sat, 18 Aug 2001 14:57:38 +0200 (CEST) Date: Sat, 18 Aug 2001 15:05:11 +0200 From: Franky Van Liedekerke To: Subject: Re: patch for version 0.8.16 Message-Id: <20010818150511.3fd1529d.liedekef@pandora.be> In-Reply-To: <20010818145343.0e73f605.liedekef@pandora.be> References: <20010818145343.0e73f605.liedekef@pandora.be> X-Mailer: Sylpheed version 0.5.3 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart_Sat__18_Aug_2001_15:05:11_+0200_082464b0" --Multipart_Sat__18_Aug_2001_15:05:11_+0200_082464b0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 18 Aug 2001 14:53:43 +0200 Franky Van Liedekerke wrote: > This is a small patch against version 0.8.16 that does the following: > > 1) remove some leftover comment from MaraDns.h > 2) changed line in TODO.second so it reflects that round robin from cached data is done > 3) implemented my comment for number of children counting from zero (see a previous mail, is two lines of changes) > 4) implemented splitting up maxprocs in "max_udp_threads" and "max_tcp_procs". The names of the new variables can be changed at will of course. > > Oh, and something else: this patch is public domain code. > > Franky Just found a small typo in the patch (should have done make before sending the mail). Here's the correct patch. Franky --Multipart_Sat__18_Aug_2001_15:05:11_+0200_082464b0 Content-Type: application/octet-stream; name="diff.patch" Content-Disposition: attachment; filename="diff.patch" Content-Transfer-Encoding: base64 ZGlmZiAtdXIgbWFyYWRucy0wLjguMTYub3JpZy9NYXJhRG5zLmggbWFyYWRucy0wLjguMTYvTWFy YURucy5oCi0tLSBtYXJhZG5zLTAuOC4xNi5vcmlnL01hcmFEbnMuaAlUdWUgQXVnIDE0IDAwOjQw OjQ1IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L01hcmFEbnMuaAlTYXQgQXVnIDE4IDEyOjAwOjUz IDIwMDEKQEAgLTgsMTAgKzgsNiBAQAogI2RlZmluZSBfdWludF9kZWZpbmVkCiAjZW5kaWYgLyog X3VpbnRfZGVmaW5lZCAqLwogI2RlZmluZSAgICAgICBJTkFERFJfTk9ORSAgICAgICAgICAgICAw eGZmZmZmZmZmCi0vKiBBY2NvcmRpbmcgdG8gRnJhbmt5LCB0aGUgdmFsdWUgb2YgdGhpcyB2YXJp ZXMgZGVwZW5kaW5nIG9uIHRoZSB2ZXJzaW9uCi0gICBvZiBTb2xhcmlzIGJlaW5nIHVzZWQuICBT b21lIHZlcnNpb25zIG9mIFNvbGFyaXMgaGF2ZSBhIHZhbHVlIG9mICI2IiAKLSAgIGZvciB0aGlz Ci0qLwogI2VuZGlmIC8qIFNPTEFSSVMgKi8KIAogCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9y aWcvVE9ETy5zZWNvbmQgbWFyYWRucy0wLjguMTYvVE9ETy5zZWNvbmQKLS0tIG1hcmFkbnMtMC44 LjE2Lm9yaWcvVE9ETy5zZWNvbmQJRnJpIEF1ZyAxNyAxMToyODo0MSAyMDAxCisrKyBtYXJhZG5z LTAuOC4xNi9UT0RPLnNlY29uZAlTYXQgQXVnIDE4IDEyOjAwOjQyIDIwMDEKQEAgLTIzLDcgKzIz LDcgQEAKIAogKiBNYWtlIHRoZSBjYWNoZSBzaXplIHVzZXItY29uZmlndXJhYmxlIChET05FKQog Ci0qIFJvdW5kIHJvYmluIHJvdGF0ZXMgb2YgZGF0YSBpbiB0aGUgY2FjaGUgKFRoaXMgaXMgMS4y IG1hdGVyaWFsKQorKiBSb3VuZCByb2JpbiByb3RhdGVzIG9mIGRhdGEgaW4gdGhlIGNhY2hlIChE T05FKQogCiAqIEN1c3RvbWl6YWJsZSByb290IG5hbWUgc2VydmVycyB3aGljaCBhbGxvdyBwZW9w bGUgdG8gdXNlIGRpZmZlcmVudAogICBhbHRlcm5hdGUgcmVnaXN0cmllcyBmb3IgZGlmZmVybmV0 IFRMRHMuCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvZG9jL2RldGFpbGVkL2V4YW1wbGVf ZnVsbF9tYXJhcmMgbWFyYWRucy0wLjguMTYvZG9jL2RldGFpbGVkL2V4YW1wbGVfZnVsbF9tYXJh cmMKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvZG9jL2RldGFpbGVkL2V4YW1wbGVfZnVsbF9tYXJh cmMJRnJpIEF1ZyAxNyAxMTowODoxMCAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9kb2MvZGV0YWls ZWQvZXhhbXBsZV9mdWxsX21hcmFyYwlTYXQgQXVnIDE4IDE0OjE0OjQ1IDIwMDEKQEAgLTE4LDkg KzE4LDExIEBACiBtYXJhZG5zX3VpZCA9IDk5CiAjIFRoZSAob3B0aW9uYWwpIG51bWVyaWMgR0lE IE1hcmFETlMgd2lsbCBydW4gYXMKICMgbWFyYWRuc19naWQgPSA5OQotIyBUaGUgbWF4aW11bSBu dW1iZXIgb2YgdGhyZWFkcyAob3IgcHJvY2Vzc2VzLCB3aXRoIHRoZSB6b25lIHNlcnZlcikKKyMg VGhlIG1heGltdW0gbnVtYmVyIG9mIHVkcCB0aHJlYWRzIE1hcmFETlMgaXMgYWxsb3dlZCB0byBy dW4KK21heF91ZHBfdGhyZWFkcyA9IDk2CisjIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNz ZXMgd2l0aCB0aGUgem9uZSBzZXJ2ZXIKICMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgotbWF4 cHJvY3MgPSA5NgorbWF4X3RjcF9wcm9jcyA9IDk2CiAKICMgTm9ybWFsbHksIE1hcmFETlMgaGFz IHNvbWUgTWFyYUROUy1zcGVjaWZpYyBmZWF0dXJlcywgc3VjaCBhcyBERElQCiAjIHN5bnRoZXNp emluZywgYSBzcGVjaWFsIEROUyBxdWVyeSAoImVycmUtY29uLWVycmUtY2lnYXJyby5tYXJhZG5z Lm9yZy4iIApkaWZmIC11ciBtYXJhZG5zLTAuOC4xNi5vcmlnL2RvYy9leGFtcGxlX21hcmFyYyBt YXJhZG5zLTAuOC4xNi9kb2MvZXhhbXBsZV9tYXJhcmMKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcv ZG9jL2V4YW1wbGVfbWFyYXJjCUZyaSBBdWcgMTcgMTE6MTg6NDQgMjAwMQorKysgbWFyYWRucy0w LjguMTYvZG9jL2V4YW1wbGVfbWFyYXJjCVNhdCBBdWcgMTggMTQ6MTQ6MzcgMjAwMQpAQCAtMjAs OSArMjAsMTEgQEAKIGNocm9vdF9kaXIgPSAiL2V0Yy9tYXJhZG5zIgogIyBUaGUgbnVtZXJpYyBV SUQgTWFyYUROUyB3aWxsIHJ1biBhcwogbWFyYWRuc191aWQgPSA5OQotIyBUaGUgbWF4aW11bSBu dW1iZXIgb2YgdGhyZWFkcyAob3IgcHJvY2Vzc2VzLCB3aXRoIHRoZSB6b25lIHNlcnZlcikKKyMg VGhlIG1heGltdW0gbnVtYmVyIG9mIHVkcCB0aHJlYWRzIE1hcmFETlMgaXMgYWxsb3dlZCB0byBy dW4KK21heF91ZHBfdGhyZWFkcyA9IDk2CisjIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNz ZXMgd2l0aCB0aGUgem9uZSBzZXJ2ZXIKICMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgotbWF4 cHJvY3MgPSA5NgorbWF4X3RjcF9wcm9jcyA9IDk2CiAKICMgTW9zdCBvZiB0aGUgdGltZSwgdGhp cyBjYW4gc3RheSAzLiAgSG93ZXZlciwgd2hlbiByZWdpc3RlcmluZwogIyBhIGRvbWFpbiB1bmRl ciAuZGUsIC5hdSwgYW5kIHBvc3NpYmx5IG90aGVyIHRvcC1sZXZlbC1kb21haW5zLCB0aGlzCmRp ZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvZG9jL21hbi9tYXJhZG5zLjggbWFyYWRucy0wLjgu MTYvZG9jL21hbi9tYXJhZG5zLjgKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvZG9jL21hbi9tYXJh ZG5zLjgJVHVlIEp1bCAxNyAwNzo1OToyNyAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9kb2MvbWFu L21hcmFkbnMuOAlTYXQgQXVnIDE4IDE0OjE1OjE3IDIwMDEKQEAgLTU1LDggKzU1LDExIEBACiBj aHJvb3RfZGlyID0gIi9ldGMvbWFyYWRucyIKICMgVGhlIG51bWVyaWMgVUlEIE1hcmFETlMgd2ls bCBydW4gYXMKIG1hcmFkbnNfdWlkID0gOTkKLSMgVGhlIG1heGltdW0gbnVtYmVyIG9mIHByb2Nl c3NlcyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gdXNlCi1tYXhwcm9jcyA9IDY0CisjIFRoZSBtYXhp bXVtIG51bWJlciBvZiB1ZHAgdGhyZWFkcyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gcnVuCittYXhf dWRwX3RocmVhZHMgPSA5NgorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgcHJvY2Vzc2VzIHdpdGgg dGhlIHpvbmUgc2VydmVyCisjIE1hcmFETlMgaXMgYWxsb3dlZCB0byBydW4KK21heF90Y3BfcHJv Y3MgPSA5NgogCiAjIFRoZSBudW1iZXIgb2YgbWVzc2FnZXMgd2UgbG9nIHRvIHN0ZG91dAogIyAw OiBObyBtZXNzYWdlcywgZXhjZXB0IHN5bnRheCBlcnJvciBtZXNzYWdlcyAKZGlmZiAtdXIgbWFy YWRucy0wLjguMTYub3JpZy9wYXJzZS9QYXJzZU1hcmFSYy5jIG1hcmFkbnMtMC44LjE2L3BhcnNl L1BhcnNlTWFyYVJjLmMKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvcGFyc2UvUGFyc2VNYXJhUmMu YwlTdW4gQXVnIDEyIDA3OjI4OjQ2IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3BhcnNlL1BhcnNl TWFyYVJjLmMJU2F0IEF1ZyAxOCAxNDowMjozNSAyMDAxCkBAIC0xMSwxNCArMTEsMTUgQEAKIAog LyogS2V5d29yZHMgdGhhdCBhcmUgbm9uLWRpY3Rpb25hcnkgc3RyaW5ncyBpbiBNYXJhJ3MgcmMg ZmlsZSAqLwogCi0jZGVmaW5lIEtFWUNPVU5UIDE3CisjZGVmaW5lIEtFWUNPVU5UIDE4CiAKIGNo YXIgKmtleXdvcmRzW0tFWUNPVU5UXSA9IHsgCiAJImJpbmRfYWRkcmVzcyIsCiAgICAgICAgICJj aHJvb3RfZGlyIiwKICAgICAgICAgIm1hcmFkbnNfdWlkIiwKICAgICAgICAgIm1hcmFkbnNfZ2lk IiwKLSAgICAgICAgIm1heHByb2NzIiwKKyAgICAgICAgIm1heF90Y3BfcHJvY3MiLAorICAgICAg ICAibWF4X3VkcF90aHJlYWRzIiwKIAkidmVyYm9zZV9sZXZlbCIsCiAJInpvbmVfdHJhbnNmZXJf YWNsIiwKIAkicmVjdXJzaXZlX2FjbCIsCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvc2Vy dmVyL01hcmFETlMuYyBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvTWFyYUROUy5jCi0tLSBtYXJhZG5z LTAuOC4xNi5vcmlnL3NlcnZlci9NYXJhRE5TLmMJU3VuIEF1ZyAxMiAwODo0MzozMSAyMDAxCisr KyBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvTWFyYUROUy5jCVNhdCBBdWcgMTggMTQ6MDQ6NDYgMjAw MQpAQCAtMjQ4Myw3ICsyNDgzLDcgQEAKICAgICB1bnNpZ25lZCBjaGFyIGNocm9vdF96dFsyNTVd OwogICAgIHVpZF90IHVpZDsKICAgICBnaWRfdCBnaWQ7Ci0gICAgaW50IGVycm9ybiwgdmFsdWUs IHNvY2ssIG1heHByb2NzLCBjb3VudGVyOworICAgIGludCBlcnJvcm4sIHZhbHVlLCBzb2NrLCBt YXhfdWRwX3RocmVhZHMsIGNvdW50ZXI7CiAgICAgaW50IGNhY2hlX3NpemU7CiAgICAgc3RydWN0 IHNvY2thZGRyIGNsaWVudDsKICAgICBzdHJ1Y3QgcmxpbWl0IHJsaW07CkBAIC0yNTU4LDE5ICsy NTU4LDE5IEBACiAgICAgLyogR2V0IGluIHRvIGEgc3RhdGUgb2YgbGVhc3QgcHJpdmxlZGdlIEFT QVAgKi8KIAogICAgIC8qIExpbWl0IHRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNzZXMgKi8K LSAgICBpZihqc19xc3RyMmpzKGt2YXJfcXVlcnksIm1heHByb2NzIikgPT0gSlNfRVJST1IpCisg ICAgaWYoanNfcXN0cjJqcyhrdmFyX3F1ZXJ5LCJtYXhfdWRwX3RocmVhZHMiKSA9PSBKU19FUlJP UikKICAgICAgICAgaGFyZGVycm9yKExfS1ZBUl9RKTsgLyogIkNvdWxkIG5vdCBjcmVhdGUga3Zh cl9xdWVyeSIgKi8KICAgICBpZihyZWFkX2t2YXIoa3Zhcl9xdWVyeSxtYXhwc3RyKSA9PSBKU19F UlJPUikKLSAgICAgICAgaGFyZGVycm9yKExfTUFYUFJPQyk7IC8qICJQcm9ibGVtIGdldHRpbmcg bWF4cHJvY3MgdmFsdWUuXG5tYXhwcm9jcyBtdXN0IGJlIHNldCBiZWZvcmUgc3RhcnRpbmcgdGhl IE1hcmFETlMgc2VydmVyIiAqLwotICAgIGlmKChtYXhwcm9jcyA9IGpzX2F0b2kobWF4cHN0ciww KSkgPT0gMCkKLSAgICAgICAgaGFyZGVycm9yKExfTUFYUFJPQ19OVU0pOyAvKiAiUHJvYmxlbSBj b252ZXJ0aW5nIG1heHByb2NzIHRvIGEgbnVtYmVyXG5UaGlzIG11c3QgYmUgYSBub24temVybyBu dW1iZXIiICovCi0gICAgcmxpbS5ybGltX2N1ciA9IHJsaW0ucmxpbV9tYXggPSBtYXhwcm9jczsK KyAgICAgICAgaGFyZGVycm9yKExfTUFYX1VEUF9USFJFQURTKTsgLyogIlByb2JsZW0gZ2V0dGlu ZyBtYXhfdWRwX3RocmVhZHMgdmFsdWUuXG5tYXhfdWRwX3RocmVhZHMgbXVzdCBiZSBzZXQgYmVm b3JlIHN0YXJ0aW5nIHRoZSBNYXJhRE5TIHNlcnZlciIgKi8KKyAgICBpZigobWF4X3VkcF90aHJl YWRzID0ganNfYXRvaShtYXhwc3RyLDApKSA9PSAwKQorICAgICAgICBoYXJkZXJyb3IoTF9NQVhf VURQX1RIUkVBRFNfTlVNKTsgLyogIlByb2JsZW0gY29udmVydGluZyBtYXhfdWRwX3RocmVhZHMg dG8gYSBudW1iZXJcblRoaXMgbXVzdCBiZSBhIG5vbi16ZXJvIG51bWJlciIgKi8KKyAgICBybGlt LnJsaW1fY3VyID0gcmxpbS5ybGltX21heCA9IG1heF91ZHBfdGhyZWFkczsKIAogICAgIC8qIElm IHRoaXMgT1Mgc3VwcG9ydHMgc2V0cmxpbWl0IGFuZCBpZiBzZXRybGltaXQgZmFpbHMsIGJhaWwg KHRoZSBFTk9TWVMKICAgICAgICBjaGVjayBpcyB0aGVyZSBzbyBPU2VzIHcvbyBzZXRybGltaXQg c3VwcG9ydCBjYW4gc3RpbGwgcnVuIE1hcmFETlMpICovCiAjaWZuZGVmIFNPTEFSSVMKICAgICBp ZihzZXRybGltaXQoUkxJTUlUX05QUk9DLCZybGltKSAhPSAwICYmIGVycm5vICE9IEVOT1NZUykg Ci0gICAgICAgIHN5c19oYXJkZXJyb3IoTF9NQVhQUk9DX1NFVCk7IC8qICJVbmFibGUgdG8gc2V0 IG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyIgKi8KKyAgICAgICAgc3lzX2hhcmRlcnJvcihM X01BWF9VRFBfVEhSRUFEU19TRVQpOyAvKiAiVW5hYmxlIHRvIHNldCBtYXhpbXVtIG51bWJlciBv ZiBwcm9jZXNzZXMiICovCiAjZW5kaWYgLyogU09MQVJJUyAqLwogCiAgICAgLyogRGV0ZXJtaW5l IHRoZSBsZXZlbCBvZiBlcnJvciByZXBvcnRpbmcgKi8KQEAgLTI2NDQsNyArMjY0NCw3IEBACiAJ aWYobWFrZV9pcF9hY2wodmVyYnN0cixyZWN1cnNlX2FjbCw1MDAsMCkgPT0gSlNfRVJST1IpCiAJ ICAgIGhhcmRlcnJvcihMX0FDTF9MSVNUX1JFQ1VSU0UpOyAvKiAiQ291bGQgbm90IG1ha2UgaXAg QUNMIGxpc3QiICovCiAgICAgICAgIC8qIExvYWQgdGhlICJzZWVkIiBkYXRhIGluIHRvIHRoZSBE TlMgY2FjaGUgKi8KLSAgICAgICAgaWYoaW5pdF9jYWNoZShjYWNoZV9zaXplLG1heHByb2NzKSA9 PSBKU19FUlJPUikKKyAgICAgICAgaWYoaW5pdF9jYWNoZShjYWNoZV9zaXplLG1heF91ZHBfdGhy ZWFkcykgPT0gSlNfRVJST1IpCiAgICAgICAgICAgICBoYXJkZXJyb3IoTF9JTklUQ0FDSEVfRkFJ TCk7IC8qICJJbml0X2NhY2hlKCkgZmFpbGVkIiAqLwogICAgICAgICB9CiAKZGlmZiAtdXIgbWFy YWRucy0wLjguMTYub3JpZy9zZXJ2ZXIvTWFyYUROU19kZS5oIG1hcmFkbnMtMC44LjE2L3NlcnZl ci9NYXJhRE5TX2RlLmgKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvc2VydmVyL01hcmFETlNfZGUu aAlUaHUgQXByIDI2IDEwOjI0OjQ3IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3NlcnZlci9NYXJh RE5TX2RlLmgJU2F0IEF1ZyAxOCAxNDowNzoyMyAyMDAxCkBAIC0zNCw5ICszNCw5IEBACiAjZGVm aW5lIExfTUFSQVJDX0xJTkUgIlNhdHpnbGllZGVydW5nc2ZlaGxlciBpbSBJbmhhbHQgZGVyIE1h cmFyY2RhdGVpIgogI2RlZmluZSBMX0VSUk9SX0NPREUgIkZlaGxlcmNvZGU6ICIKICNkZWZpbmUg TF9LVkFSX1EgIktvbm50ZSBLZWluZUt2YXJfYWJmcmFnZXplaWNoZW5rZXR0ZSBoZXJzdGVsbGVu IgotI2RlZmluZSBMX01BWFBST0MgIkRhcyBQcm9ibGVtLCBkYXMgTWF4cHJvY3MgZXJoYWVsdCwg bXVzcyBlaW5nZXN0ZWxsdCB3ZXJkZW4sIGJldm9yIG1hbiBkZW4gTWFyYUROUy1zZXJ2ZXIgYW5z dGVsbHQiCi0jZGVmaW5lIExfTUFYUFJPQ19OVU0gIlByb2JsZW0gYmVpIGRlciBVbXdhbmRsdW5n IGRlciBNYXhwcm9jcyB6dSBlaW5lciBOdW1tZXJcbi4gRGllc2VzIG11c3Mga2VpbmUgTnVsbHph aGwgc2VpbiIuCi0jZGVmaW5lIExfTUFYUFJPQ19TRVQgIkRpZUVpbnN0ZWxsdW5nIGVpbmVyIG1h eGltYWxlIEFuemFobCB2b24gUHJvemVzc2VuIGlzdCBuaWNodCBtb2VnbGljaCIKKyNkZWZpbmUg TF9NQVhfVURQX1RIUkVBRFMgIkRhcyBQcm9ibGVtLCBkYXMgTWF4X3VkcF90aHJlYWRzIGVyaGFl bHQsIG11c3MgZWluZ2VzdGVsbHQgd2VyZGVuLCBiZXZvciBtYW4gZGVuIE1hcmFETlMtc2VydmVy IGFuc3RlbGx0IgorI2RlZmluZSBMX01BWF9VRFBfVEhSRUFEU19OVU0gIlByb2JsZW0gYmVpIGRl ciBVbXdhbmRsdW5nIGRlciBNYXhfdWRwX3RocmVhZHMgenUgZWluZXIgTnVtbWVyXG4uIERpZXNl cyBtdXNzIGtlaW5lIE51bGx6YWhsIHNlaW4iLgorI2RlZmluZSBMX01BWF9VRFBfVEhSRUFEU19T RVQgIkRpZUVpbnN0ZWxsdW5nIGVpbmVyIG1heGltYWxlIEFuemFobCB2b24gUHJvemVzc2VuIGlz dCBuaWNodCBtb2VnbGljaCIKICNkZWZpbmUgTF9DSFJPT1RfS1ZBUiAiUHJvYmxlbSBiZWltIEVt cGZhbmcgZGVyIENocm9vdCBLdmFyLlxuLiBNYW4gbXVzcyBkaWUgQ2hyb290X2RpciBlaW5zdGVs bGVuLCB1bSBpbSBVcnNwcnVuZyBhbnp1ZmFuZ2VuIgogI2RlZmluZSBMX0NIUk9PVF9OVCAiUHJv YmxlbSBiZWkgZGVyIEhlcnN0ZWxsdW5nIGRlciBDaHJvb3QgbnQgKHplaWNoZW4pa2V0dGUuIFN0 ZWxsZW4gU2llIHNpY2hlciwgZGFzcyBkYXMgQ2hyb290dmVyemVpY2huaXMgYXVzIDIwMCBaZWlj aGVuIG9kZXIgd2VuaWdlciBiZXN0ZWh0IgogI2RlZmluZSBMX0NIUk9PVF9DSEFOR0UgIlByb2Js ZW0gYmVpbSBXZWNoc2VsbiB6dW0gQ2hyb290dmVyemVpY2huaXMiCmRpZmYgLXVyIG1hcmFkbnMt MC44LjE2Lm9yaWcvc2VydmVyL01hcmFETlNfZW4uaCBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvTWFy YUROU19lbi5oCi0tLSBtYXJhZG5zLTAuOC4xNi5vcmlnL3NlcnZlci9NYXJhRE5TX2VuLmgJU3Vu IEF1ZyAxMiAwODoxNDoxOSAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvTWFyYUROU19l bi5oCVNhdCBBdWcgMTggMTQ6NDg6MzEgMjAwMQpAQCAtMzcsOSArMzcsOSBAQAogI2RlZmluZSBM X01BUkFSQ19MSU5FICJFcnJvciBwYXJzaW5nIGNvbnRlbnRzIG9mIG1hcmFyYyBmaWxlIG9uIGxp bmUgIgogI2RlZmluZSBMX0VSUk9SX0NPREUgIkVycm9yIGNvZGU6ICIKICNkZWZpbmUgTF9LVkFS X1EgIkNvdWxkIG5vdCBjcmVhdGUga3Zhcl9xdWVyeSIKLSNkZWZpbmUgTF9NQVhQUk9DICJQcm9i bGVtIGdldHRpbmcgbWF4cHJvY3MgdmFsdWUuXG5tYXhwcm9jcyBtdXN0IGJlIHNldCBiZWZvcmUg c3RhcnRpbmcgdGhlIE1hcmFETlMgc2VydmVyIgotI2RlZmluZSBMX01BWFBST0NfTlVNICJQcm9i bGVtIGNvbnZlcnRpbmcgbWF4cHJvY3MgdG8gYSBudW1iZXJcblRoaXMgbXVzdCBiZSBhIG5vbi16 ZXJvIG51bWJlciIKLSNkZWZpbmUgTF9NQVhQUk9DX1NFVCAiVW5hYmxlIHRvIHNldCBtYXhpbXVt IG51bWJlciBvZiBwcm9jZXNzZXMiCisjZGVmaW5lIExfTUFYX1VEUF9USFJFQURTICJQcm9ibGVt IGdldHRpbmcgbWF4X3VkcF90aHJlYWRzIHZhbHVlLlxubWF4X3VkcF90aHJlYWRzIG11c3QgYmUg c2V0IGJlZm9yZSBzdGFydGluZyB0aGUgTWFyYUROUyBzZXJ2ZXIiCisjZGVmaW5lIExfTUFYX1VE UF9USFJFQURTX05VTSAiUHJvYmxlbSBjb252ZXJ0aW5nIG1heF91ZHBfdGhyZWFkcyB0byBhIG51 bWJlclxuVGhpcyBtdXN0IGJlIGEgbm9uLXplcm8gbnVtYmVyIgorI2RlZmluZSBMX01BWF9VRFBf VEhSRUFEU19TRVQgIlVuYWJsZSB0byBzZXQgbWF4aW11bSBudW1iZXIgb2YgdGhyZWFkcyIKICNk ZWZpbmUgTF9DSFJPT1RfS1ZBUiAiUHJvYmxlbSBnZXR0aW5nIGNocm9vdCBrdmFyLlxuWW91IG11 c3QgaGF2ZSBjaHJvb3RfZGlyIHNldCBpZiB5b3Ugc3RhcnQgdGhpcyBhcyByb290IgogI2RlZmlu ZSBMX0NIUk9PVF9OVCAiUHJvYmxlbSBtYWtpbmcgY2hyb290IG50IHN0cmluZy5cbk1ha2Ugc3Vy ZSB0aGUgY2hyb290IGRpcmVjdG9yeSBpcyAyMDAgY2hhcnMgb3IgbGVzcyIKICNkZWZpbmUgTF9D SFJPT1RfQ0hBTkdFICJQcm9ibGVtIGNoYW5naW5nIHRvIGNocm9vdCBkaXIuXG5NYWtlIHN1cmUg Y2hyb290X2RpciBwb2ludHMgdG8gYSB2YWxpZCBkaXJlY3RvcnkiCmRpZmYgLXVyIG1hcmFkbnMt MC44LjE2Lm9yaWcvc2VydmVyL3JlY3Vyc2l2ZS5jIG1hcmFkbnMtMC44LjE2L3NlcnZlci9yZWN1 cnNpdmUuYwotLS0gbWFyYWRucy0wLjguMTYub3JpZy9zZXJ2ZXIvcmVjdXJzaXZlLmMJU2F0IEF1 ZyAxOCAwNzoxMTo1NCAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9zZXJ2ZXIvcmVjdXJzaXZlLmMJ U2F0IEF1ZyAxOCAxMjowMjoxMCAyMDAxCkBAIC0yMTE4LDcgKzIxMTgsNyBAQAogCiAgICAgLyog TWFrZSBzdXJlIHdlIGNhbiBzcHdhd24gdGhlIHRocmVhZC4gKi8KICAgICB0Y291bnRfbG9jaygp OwotICAgIGlmKG51bV9vZl90aHJlYWRzX3J1bm5pbmcgPiBtYXhpbXVtX251bV9vZl90aHJlYWRz KSB7CisgICAgaWYobnVtX29mX3RocmVhZHNfcnVubmluZyA+PSBtYXhpbXVtX251bV9vZl90aHJl YWRzKSB7CiAgICAgICAgIHRjb3VudF91bmxvY2soKTsKIAlqc19kZWFsbG9jKHJlcSk7IGpzX2Rl c3Ryb3koY29weSk7CiAJLyogUmV0dXJuIGEgInNlcnZlciBmYWlsIiBlcnJvciBtZXNzYWdlIGlm IHdlIGNhbiBub3Qgc3Bhd24gCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvc3FhL3Rlc3Ri ZWQvbWFyYXJjIG1hcmFkbnMtMC44LjE2L3NxYS90ZXN0YmVkL21hcmFyYwotLS0gbWFyYWRucy0w LjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJhcmMJU3VuIEp1biAgMyAwNzowMDo0MCAyMDAxCisr KyBtYXJhZG5zLTAuOC4xNi9zcWEvdGVzdGJlZC9tYXJhcmMJU2F0IEF1ZyAxOCAxNDoxMzoxNCAy MDAxCkBAIC0xNCw4ICsxNCwxMSBAQAogIyBjaHJvb3RfZGlyID0gIi9ob21lL3NldC9tYXJhZG5z L3pvbmUiCiAjIFRoZSBudW1lcmljIFVJRCBNYXJhRE5TIHdpbGwgcnVuIGFzCiBtYXJhZG5zX3Vp ZCA9IDk5Ci0jIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNzZXMgTWFyYUROUyBpcyBhbGxv d2VkIHRvIHVzZQotbWF4cHJvY3MgPSA2NAorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgdWRwIHRo cmVhZHMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgorbWF4X3VkcF90aHJlYWRzID0gNjQKKyMg VGhlIG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyB3aXRoIHRoZSB6b25lIHNlcnZlcgorIyBN YXJhRE5TIGlzIGFsbG93ZWQgdG8gcnVuCittYXhfdGNwX3Byb2NzID0gNjQKIAogIyBUaGVzZSBj b25zdGFudHMgbGltaXQgdGhlIG51bWJlciBvZiByZWNvcmRzIHdlIHdpbGwgZGlzcGxheSwgaW4g b3JkZXIKICMgdG8gaGVscCBrZWVwIHBhY2tldHMgNTEyIGJ5dGVzIG9yIHNtYWxsZXIuICBUaGlz LCBjb21iaW5lZCB3aXRoIHJvdW5kX3JvYmluCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcv c3FhL3Rlc3RiZWQvbWFyYXJjLjEgbWFyYWRucy0wLjguMTYvc3FhL3Rlc3RiZWQvbWFyYXJjLjEK LS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvc3FhL3Rlc3RiZWQvbWFyYXJjLjEJTW9uIE1heSAxNCAy MDo1NjoyMiAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9zcWEvdGVzdGJlZC9tYXJhcmMuMQlTYXQg QXVnIDE4IDE0OjEzOjI4IDIwMDEKQEAgLTE3LDggKzE3LDExIEBACiAjIGNocm9vdF9kaXIgPSAi L2hvbWUvc2V0L21hcmFkbnMvem9uZSIKICMgVGhlIG51bWVyaWMgVUlEIE1hcmFETlMgd2lsbCBy dW4gYXMKIG1hcmFkbnNfdWlkID0gOTkKLSMgVGhlIG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3Nl cyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gdXNlCi1tYXhwcm9jcyA9IDY0CisjIFRoZSBtYXhpbXVt IG51bWJlciBvZiB1ZHAgdGhyZWFkcyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gcnVuCittYXhfdWRw X3RocmVhZHMgPSA2NAorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgcHJvY2Vzc2VzIHdpdGggdGhl IHpvbmUgc2VydmVyCisjIE1hcmFETlMgaXMgYWxsb3dlZCB0byBydW4KK21heF90Y3BfcHJvY3Mg PSA2NAogCiAjIFRoZXNlIGNvbnN0YW50cyBsaW1pdCB0aGUgbnVtYmVyIG9mIHJlY29yZHMgd2Ug d2lsbCBkaXNwbGF5LCBpbiBvcmRlcgogIyB0byBoZWxwIGtlZXAgcGFja2V0cyA1MTIgYnl0ZXMg b3Igc21hbGxlci4gIFRoaXMsIGNvbWJpbmVkIHdpdGggcm91bmRfcm9iaW4KZGlmZiAtdXIgbWFy YWRucy0wLjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJhcmMuMiBtYXJhZG5zLTAuOC4xNi9zcWEv dGVzdGJlZC9tYXJhcmMuMgotLS0gbWFyYWRucy0wLjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJh cmMuMglTdW4gSnVuICAzIDA2OjM3OjEzIDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3NxYS90ZXN0 YmVkL21hcmFyYy4yCVNhdCBBdWcgMTggMTQ6MTI6MTQgMjAwMQpAQCAtMTQsOCArMTQsMTEgQEAK ICMgY2hyb290X2RpciA9ICIvaG9tZS9zZXQvbWFyYWRucy96b25lIgogIyBUaGUgbnVtZXJpYyBV SUQgTWFyYUROUyB3aWxsIHJ1biBhcwogbWFyYWRuc191aWQgPSA5OQotIyBUaGUgbWF4aW11bSBu dW1iZXIgb2YgcHJvY2Vzc2VzIE1hcmFETlMgaXMgYWxsb3dlZCB0byB1c2UKLW1heHByb2NzID0g NjQKKyMgVGhlIG1heGltdW0gbnVtYmVyIG9mIHVkcCB0aHJlYWRzIE1hcmFETlMgaXMgYWxsb3dl ZCB0byBydW4KK21heF91ZHBfdGhyZWFkcyA9IDY0CisjIFRoZSBtYXhpbXVtIG51bWJlciBvZiBw cm9jZXNzZXMgd2l0aCB0aGUgem9uZSBzZXJ2ZXIKKyMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1 bgorbWF4X3RjcF9wcm9jcyA9IDY0CiAKICMgVGhlc2UgY29uc3RhbnRzIGxpbWl0IHRoZSBudW1i ZXIgb2YgcmVjb3JkcyB3ZSB3aWxsIGRpc3BsYXksIGluIG9yZGVyCiAjIHRvIGhlbHAga2VlcCBw YWNrZXRzIDUxMiBieXRlcyBvciBzbWFsbGVyLiAgVGhpcywgY29tYmluZWQgd2l0aCByb3VuZF9y b2JpbgpkaWZmIC11ciBtYXJhZG5zLTAuOC4xNi5vcmlnL3NxYS90ZXN0YmVkL21hcmFyYy40IG1h cmFkbnMtMC44LjE2L3NxYS90ZXN0YmVkL21hcmFyYy40Ci0tLSBtYXJhZG5zLTAuOC4xNi5vcmln L3NxYS90ZXN0YmVkL21hcmFyYy40CVN1biBKdW4gIDMgMDY6Mzc6MTggMjAwMQorKysgbWFyYWRu cy0wLjguMTYvc3FhL3Rlc3RiZWQvbWFyYXJjLjQJU2F0IEF1ZyAxOCAxNDoxMjoyOCAyMDAxCkBA IC0xNCw4ICsxNCwxMSBAQAogIyBjaHJvb3RfZGlyID0gIi9ob21lL3NldC9tYXJhZG5zL3pvbmUi CiAjIFRoZSBudW1lcmljIFVJRCBNYXJhRE5TIHdpbGwgcnVuIGFzCiBtYXJhZG5zX3VpZCA9IDk5 Ci0jIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNzZXMgTWFyYUROUyBpcyBhbGxvd2VkIHRv IHVzZQotbWF4cHJvY3MgPSA2NAorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgdWRwIHRocmVhZHMg TWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgorbWF4X3VkcF90aHJlYWRzID0gNjQKKyMgVGhlIG1h eGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyB3aXRoIHRoZSB6b25lIHNlcnZlcgorIyBNYXJhRE5T IGlzIGFsbG93ZWQgdG8gcnVuCittYXhfdGNwX3Byb2NzID0gNjQKIAogIyBUaGVzZSBjb25zdGFu dHMgbGltaXQgdGhlIG51bWJlciBvZiByZWNvcmRzIHdlIHdpbGwgZGlzcGxheSwgaW4gb3JkZXIK ICMgdG8gaGVscCBrZWVwIHBhY2tldHMgNTEyIGJ5dGVzIG9yIHNtYWxsZXIuICBUaGlzLCBjb21i aW5lZCB3aXRoIHJvdW5kX3JvYmluCmRpZmYgLXVyIG1hcmFkbnMtMC44LjE2Lm9yaWcvc3FhL3Rl c3RiZWQvbWFyYXJjLjUgbWFyYWRucy0wLjguMTYvc3FhL3Rlc3RiZWQvbWFyYXJjLjUKLS0tIG1h cmFkbnMtMC44LjE2Lm9yaWcvc3FhL3Rlc3RiZWQvbWFyYXJjLjUJU3VuIEp1biAgMyAwOTowNjow MiAyMDAxCisrKyBtYXJhZG5zLTAuOC4xNi9zcWEvdGVzdGJlZC9tYXJhcmMuNQlTYXQgQXVnIDE4 IDE0OjEyOjQyIDIwMDEKQEAgLTE0LDggKzE0LDExIEBACiAjIGNocm9vdF9kaXIgPSAiL2hvbWUv c2V0L21hcmFkbnMvem9uZSIKICMgVGhlIG51bWVyaWMgVUlEIE1hcmFETlMgd2lsbCBydW4gYXMK IG1hcmFkbnNfdWlkID0gOTkKLSMgVGhlIG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyBNYXJh RE5TIGlzIGFsbG93ZWQgdG8gdXNlCi1tYXhwcm9jcyA9IDY0CisjIFRoZSBtYXhpbXVtIG51bWJl ciBvZiB1ZHAgdGhyZWFkcyBNYXJhRE5TIGlzIGFsbG93ZWQgdG8gcnVuCittYXhfdWRwX3RocmVh ZHMgPSA2NAorIyBUaGUgbWF4aW11bSBudW1iZXIgb2YgcHJvY2Vzc2VzIHdpdGggdGhlIHpvbmUg c2VydmVyCisjIE1hcmFETlMgaXMgYWxsb3dlZCB0byBydW4KK21heF90Y3BfcHJvY3MgPSA2NAog CiAjIFRoZXNlIGNvbnN0YW50cyBsaW1pdCB0aGUgbnVtYmVyIG9mIHJlY29yZHMgd2Ugd2lsbCBk aXNwbGF5LCBpbiBvcmRlcgogIyB0byBoZWxwIGtlZXAgcGFja2V0cyA1MTIgYnl0ZXMgb3Igc21h bGxlci4gIFRoaXMsIGNvbWJpbmVkIHdpdGggcm91bmRfcm9iaW4KZGlmZiAtdXIgbWFyYWRucy0w LjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJhcmMuNiBtYXJhZG5zLTAuOC4xNi9zcWEvdGVzdGJl ZC9tYXJhcmMuNgotLS0gbWFyYWRucy0wLjguMTYub3JpZy9zcWEvdGVzdGJlZC9tYXJhcmMuNglT dW4gSnVuICAzIDA2OjU4OjI1IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3NxYS90ZXN0YmVkL21h cmFyYy42CVNhdCBBdWcgMTggMTQ6MTI6NTUgMjAwMQpAQCAtMTQsOCArMTQsMTEgQEAKICMgY2hy b290X2RpciA9ICIvaG9tZS9zZXQvbWFyYWRucy96b25lIgogIyBUaGUgbnVtZXJpYyBVSUQgTWFy YUROUyB3aWxsIHJ1biBhcwogbWFyYWRuc191aWQgPSA5OQotIyBUaGUgbWF4aW11bSBudW1iZXIg b2YgcHJvY2Vzc2VzIE1hcmFETlMgaXMgYWxsb3dlZCB0byB1c2UKLW1heHByb2NzID0gNjQKKyMg VGhlIG1heGltdW0gbnVtYmVyIG9mIHVkcCB0aHJlYWRzIE1hcmFETlMgaXMgYWxsb3dlZCB0byBy dW4KK21heF91ZHBfdGhyZWFkcyA9IDY0CisjIFRoZSBtYXhpbXVtIG51bWJlciBvZiBwcm9jZXNz ZXMgd2l0aCB0aGUgem9uZSBzZXJ2ZXIKKyMgTWFyYUROUyBpcyBhbGxvd2VkIHRvIHJ1bgorbWF4 X3RjcF9wcm9jcyA9IDY0CiAKICMgVGhlc2UgY29uc3RhbnRzIGxpbWl0IHRoZSBudW1iZXIgb2Yg cmVjb3JkcyB3ZSB3aWxsIGRpc3BsYXksIGluIG9yZGVyCiAjIHRvIGhlbHAga2VlcCBwYWNrZXRz IDUxMiBieXRlcyBvciBzbWFsbGVyLiAgVGhpcywgY29tYmluZWQgd2l0aCByb3VuZF9yb2Jpbgpk aWZmIC11ciBtYXJhZG5zLTAuOC4xNi5vcmlnL3R1em9uYS96b25lc2VydmVyLmMgbWFyYWRucy0w LjguMTYvdHV6b25hL3pvbmVzZXJ2ZXIuYwotLS0gbWFyYWRucy0wLjguMTYub3JpZy90dXpvbmEv em9uZXNlcnZlci5jCVR1ZSBBdWcgMTQgMDA6MTg6MzggMjAwMQorKysgbWFyYWRucy0wLjguMTYv dHV6b25hL3pvbmVzZXJ2ZXIuYwlTYXQgQXVnIDE4IDE1OjAwOjU2IDIwMDEKQEAgLTUxNyw3ICs1 MTcsNyBAQAogICAgIGpzX3N0cmluZyAqbWFyYXJjX2xvYywgKmVycm9ycywgKmNocm9vdG4sICpr dmFyX3N0ciwgKm1heHBzdHIsCiAgICAgICAgICAgICAgICprdmFyX3F1ZXJ5LCAqYmluZF9hZGRy ZXNzLCAqaW5jb21pbmcsICp1bmNvbXAsICp2ZXJic3RyOwogICAgIHVuc2lnbmVkIGNoYXIgY2hy b290X3p0WzI1NV07Ci0gICAgaW50IGVycm9ybiwgdmFsdWUsIHVpZCwgc29jaywgbWF4cHJvY3Ms IHZlcmJvc2UsIGNvdW50ZXIsIGNvbm5lY3Rpb24sCisgICAgaW50IGVycm9ybiwgdmFsdWUsIHVp ZCwgc29jaywgbWF4X3RjcF9wcm9jcywgdmVyYm9zZSwgY291bnRlciwgY29ubmVjdGlvbiwKICAg ICAgICAgaW5ldGQ7CiAgICAgbWhhc2hfZSBkZWJ1ZzI7CiAgICAgbWhhc2hfb2Zmc2V0IGRlYnVn OwpAQCAtNjA0LDEzICs2MDQsMTMgQEAKICAgICAvKiBHZXQgaW4gdG8gYSBzdGF0ZSBvZiBsZWFz dCBwcml2bGVkZ2UgQVNBUCAqLwogCiAgICAgLyogTGltaXQgdGhlIG1heGltdW0gbnVtYmVyIG9m IHByb2Nlc3NlcyAqLwotICAgIGlmKGpzX3FzdHIyanMoa3Zhcl9xdWVyeSwibWF4cHJvY3MiKSA9 PSBKU19FUlJPUikKKyAgICBpZihqc19xc3RyMmpzKGt2YXJfcXVlcnksIm1heF90Y3BfcHJvY3Mi KSA9PSBKU19FUlJPUikKICAgICAgICAgaGFyZGVycm9yKExfTUFLRV9LUSk7IC8qICJDb3VsZCBu b3QgY3JlYXRlIGt2YXJfcXVlcnkiICovCiAgICAgaWYocmVhZF9rdmFyKGt2YXJfcXVlcnksbWF4 cHN0cikgPT0gSlNfRVJST1IpCi0gICAgICAgIGhhcmRlcnJvcihMX01BWFBST0NTKTsgLyogIlBy b2JsZW0gZ2V0dGluZyBtYXhwcm9jcyB2YWx1ZS5cbm1heHByb2NzIG11c3QgYmUgc2V0IGJlZm9y ZSBzdGFydGluZyB0aGUgTWFyYUROUyBzZXJ2ZXIiICovCi0gICAgaWYoKG1heHByb2NzID0ganNf YXRvaShtYXhwc3RyLDApKSA9PSAwKQotICAgICAgICBoYXJkZXJyb3IoTF9NQVhQUk9DU19OVU0p OyAvKiAiUHJvYmxlbSBjb252ZXJ0aW5nIG1heHByb2NzIHRvIGEgbnVtYmVyXG5UaGlzIG11c3Qg YmUgYSBub24temVybyBudW1iZXIiICovCi0gICAgcmxpbS5ybGltX2N1ciA9IHJsaW0ucmxpbV9t YXggPSBtYXhwcm9jczsKKyAgICAgICAgaGFyZGVycm9yKExfTUFYX1RDUF9QUk9DUyk7IC8qICJQ cm9ibGVtIGdldHRpbmcgbWF4X3RjcF9wcm9jcyB2YWx1ZS5cbm1heF90Y3BfcHJvY3MgbXVzdCBi ZSBzZXQgYmVmb3JlIHN0YXJ0aW5nIHRoZSBNYXJhRE5TIHNlcnZlciIgKi8KKyAgICBpZigobWF4 X3RjcF9wcm9jcyA9IGpzX2F0b2kobWF4cHN0ciwwKSkgPT0gMCkKKyAgICAgICAgaGFyZGVycm9y KExfTUFYX1RDUF9QUk9DU19OVU0pOyAvKiAiUHJvYmxlbSBjb252ZXJ0aW5nIG1heF90Y3BfcHJv Y3MgdG8gYSBudW1iZXJcblRoaXMgbXVzdCBiZSBhIG5vbi16ZXJvIG51bWJlciIgKi8KKyAgICBy bGltLnJsaW1fY3VyID0gcmxpbS5ybGltX21heCA9IG1heF90Y3BfcHJvY3M7CiAjaWZuZGVmIFNP TEFSSVMKICAgICBpZihzZXRybGltaXQoUkxJTUlUX05QUk9DLCZybGltKSAhPSAwKQogICAgICAg ICBoYXJkZXJyb3IoTF9TRVRNQVgpOyAvKiAiVW5hYmxlIHRvIHNldCBtYXhpbXVtIG51bWJlciBv ZiBwcm9jZXNzZXMiICovCkBAIC03MjIsNyArNzIyLDcgQEAKICAgICAgICAgICAgIG1sb2coTF9H T1QpOyAvKiAiTWVzc2FnZSByZWNlaXZlZCwgcHJvY2Vzc2luZyIgKi8KIAogICAgICAgICAvKiBN YWtlIHN1cmUgd2UgZG9uJ3QgaGF2ZSBtb3JlIGNoaWxkcmVuIHRoYW4gd2UgY2FuIGhhbmRsZSAq LwotCXdoaWxlKG51bV9jaGlsZHJlbiA+IG1heHByb2NzKQorCXdoaWxlKG51bV9jaGlsZHJlbiA+ PSBtYXhfdGNwX3Byb2NzKQogCSAgICBzbGVlcCgxKTsKIAogICAgICAgICAvKiBGb3JrIGFuZCBo YXZlIHRoZSBjaGlsZCBoYW5kbGUgdGhlIGRhdGEgKi8KZGlmZiAtdXIgbWFyYWRucy0wLjguMTYu b3JpZy90dXpvbmEvem9uZXNlcnZlcl9lbi5oIG1hcmFkbnMtMC44LjE2L3R1em9uYS96b25lc2Vy dmVyX2VuLmgKLS0tIG1hcmFkbnMtMC44LjE2Lm9yaWcvdHV6b25hL3pvbmVzZXJ2ZXJfZW4uaAlT dW4gSnVuIDE3IDIyOjIxOjA1IDIwMDEKKysrIG1hcmFkbnMtMC44LjE2L3R1em9uYS96b25lc2Vy dmVyX2VuLmgJU2F0IEF1ZyAxOCAxNDowMTo0MCAyMDAxCkBAIC0yOCw4ICsyOCw4IEBACiAjZGVm aW5lIExfRVJST1JfQ09ERSAiRXJyb3IgY29kZTogIgogI2RlZmluZSBMRiAiXG4iCiAjZGVmaW5l IExfTUFLRV9LUSAiQ291bGQgbm90IGNyZWF0ZSBrdmFyX3F1ZXJ5IgotI2RlZmluZSBMX01BWFBS T0NTICJQcm9ibGVtIGdldHRpbmcgbWF4cHJvY3MgdmFsdWUuXG5tYXhwcm9jcyBtdXN0IGJlIHNl dCBiZWZvcmUgc3RhcnRpbmcgdGhlIE1hcmFETlMgc2VydmVyIgotI2RlZmluZSBMX01BWFBST0NT X05VTSAiUHJvYmxlbSBjb252ZXJ0aW5nIG1heHByb2NzIHRvIGEgbnVtYmVyXG5UaGlzIG11c3Qg YmUgYSBub24temVybyBudW1iZXIiCisjZGVmaW5lIExfTUFYX1RDUF9QUk9DUyAiUHJvYmxlbSBn ZXR0aW5nIG1heF90Y3BfcHJvY3MgdmFsdWUuXG5tYXhfdGNwX3Byb2NzIG11c3QgYmUgc2V0IGJl Zm9yZSBzdGFydGluZyB0aGUgTWFyYUROUyBzZXJ2ZXIiCisjZGVmaW5lIExfTUFYX1RDUF9QUk9D U19OVU0gIlByb2JsZW0gY29udmVydGluZyBtYXhfdGNwX3Byb2NzIHRvIGEgbnVtYmVyXG5UaGlz IG11c3QgYmUgYSBub24temVybyBudW1iZXIiCiAjZGVmaW5lIExfU0VUTUFYICJVbmFibGUgdG8g c2V0IG1heGltdW0gbnVtYmVyIG9mIHByb2Nlc3NlcyIKICNkZWZpbmUgTF9DSFJPT1QgIlByb2Js ZW0gZ2V0dGluZyBjaHJvb3Qga3Zhci5cbllvdSBtdXN0IGhhdmUgY2hyb290X2RpciBzZXQgaWYg eW91IHN0YXJ0IHRoaXMgYXMgcm9vdCIKICNkZWZpbmUgTF9DSFJPT1RfTlQgIlByb2JsZW0gbWFr aW5nIGNocm9vdCBudCBzdHJpbmcuXG5NYWtlIHN1cmUgdGhlIGNocm9vdCBkaXJlY3RvcnkgaXMg MjAwIGNoYXJzIG9yIGxlc3MiCg== --Multipart_Sat__18_Aug_2001_15:05:11_+0200_082464b0-- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7499 invoked from network); 22 Aug 2001 06:17:45 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 22 Aug 2001 06:17:45 -0700 Received: (qmail 7054 invoked from network); 22 Aug 2001 13:17:46 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 22 Aug 2001 13:17:46 -0000 Date: Wed, 22 Aug 2001 15:17:46 +0200 (CEST) From: X-X-Sender: To: Subject: Re: patch for version 0.8.16 In-Reply-To: <20010818150511.3fd1529d.liedekef@pandora.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Now there's just one big issue left: the mem leaks. I've just confirmed that 1 recursive request leads to about 8KB of mem leakage. Does anybody know about an easy tool to track memory leakage on a solaris machine (and that can handle threads of course)? Franky On Sat, 18 Aug 2001, Franky Van Liedekerke wrote: > On Sat, 18 Aug 2001 14:53:43 +0200 > Franky Van Liedekerke wrote: > > > This is a small patch against version 0.8.16 that does the following: > > > > 1) remove some leftover comment from MaraDns.h > > 2) changed line in TODO.second so it reflects that round robin from cached data is done > > 3) implemented my comment for number of children counting from zero (see a previous mail, is two lines of changes) > > 4) implemented splitting up maxprocs in "max_udp_threads" and "max_tcp_procs". The names of the new variables can be changed at will of course. > > > > Oh, and something else: this patch is public domain code. > > > > Franky > > Just found a small typo in the patch (should have done make before sending the mail). Here's the correct patch. > > Franky > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7664 invoked from network); 22 Aug 2001 07:21:54 -0700 Received: from unknown (HELO jumper.lonesom.pp.fi) (212.226.133.178) by artemas.reachin.com with SMTP; 22 Aug 2001 07:21:54 -0700 Received: by jumper.lonesom.pp.fi (Postfix, from userid 1000) id 8C456619E0; Wed, 22 Aug 2001 17:21:56 +0300 (EEST) Sender: liiwi@jumper.lonesom.pp.fi To: Subject: Re: patch for version 0.8.16 References: From: Jaakko Niemi Date: 22 Aug 2001 17:21:56 +0300 In-Reply-To: ('s message of "Wed, 22 Aug 2001 15:17:46 +0200 (CEST)") Message-ID: <87snekxji3.fsf@jumper.lonesom.pp.fi> Lines: 18 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii writes: > Now there's just one big issue left: the mem leaks. I've just confirmed > that 1 recursive request leads to about 8KB of mem leakage. Does anybody > know about an easy tool to track memory leakage on a solaris machine (and > that can handle threads of course)? Found these links from my bookmarks. Haven't tried any of them. http://www.inf.ethz.ch/personal/biere/projects/ccmalloc/ http://quorum.tamu.edu/jon/gnu/README.debauch http://dmalloc.com/ http://perens.com/FreeSoftware/ --j From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7742 invoked from network); 22 Aug 2001 07:50:49 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 22 Aug 2001 07:50:49 -0700 Received: (qmail 25829 invoked from network); 22 Aug 2001 14:50:50 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 22 Aug 2001 14:50:50 -0000 Date: Wed, 22 Aug 2001 16:50:50 +0200 (CEST) From: X-X-Sender: To: Subject: Re: patch for version 0.8.16 In-Reply-To: <87snekxji3.fsf@jumper.lonesom.pp.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ok, tx. I'll look into ccmalloc (have already tried some of the others you suggested). But I'm not a "heavy" programmer and mem leaks detecting might be out of my league :) Anyway, I'll give it a try. Franky On 22 Aug 2001, Jaakko Niemi wrote: > writes: > > > Now there's just one big issue left: the mem leaks. I've just confirmed > > that 1 recursive request leads to about 8KB of mem leakage. Does anybody > > know about an easy tool to track memory leakage on a solaris machine (and > > that can handle threads of course)? > > Found these links from my bookmarks. Haven't tried any of them. > > http://www.inf.ethz.ch/personal/biere/projects/ccmalloc/ > > http://quorum.tamu.edu/jon/gnu/README.debauch > > http://dmalloc.com/ > > http://perens.com/FreeSoftware/ > > --j > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13099 invoked by uid 1108); 23 Aug 2001 15:53:15 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 23 Aug 2001 15:53:15 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: =?iso-8859-1?Q?Update_from_M=E9xico?= Message-ID: <20010823155315.A13088@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i Hello, everyone, Classes are keeping me busy. However, I should have more free time this weekend to continue working on MaraDNS. In México, internet access is mainly from cyber-cafes and from the lab at this school. Which means that I need to do the lion's share of the work (most of the work) from home, without internet access. Telephone lines are very expensive here. Also, I am getting a lot of homework and need to work very hard on my studies. I have not had time to even look at the code of MaraDNS since coming here. I hope to have more time to look at the code this weekend, and have another release ready this coming Monday. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 6264 invoked by uid 1108); 28 Aug 2001 08:35:42 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 28 Aug 2001 08:35:42 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.17 released Message-ID: <20010828083542.A6253@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i ¡Hola from México! I have just released MaraDNS 0.8.17. Changes: * Incorpated a modified form of Franky's patch which gives a separate limit for tcp connections * Some code cleanup * Added some tools not directly related to DNS in the "tools" directory. Sums: vela 10:31:05 maradns $ sums maradns-0.8.17.tar.bz2 BSD = 05250 188 SYSV = 39635 375 CRC = 4090733018 191526 MD5 = 4d74830972dd99511b3b8a084db05c66 SHA1 = aeb991083c20d02f1e79f4687af8e1485954ba80 SHA-256 = d4374f4303946f99ebd5a504fdca2d031dc484571a023521b7dc6bd03f99fc9f SHA-384 = 6779f38852d93c818ca1fe6d05dcd2c86d85441922602bf966becf84c95386fbc8a5020cc14e24420bbffe9440e6c5b9 SHA-512 = 6a9f083a1240344ae57dacb7dc0c1c33f101fca43d8a6882dddff87a940da556243f9cf1a1e95e34ce220e3f3156be212d832cc00503a1a6b72bfd30b2109f22 Wrlpool = ca0d97bc779badb347c12de3738bd1b5ba5454a575d354cd31e3dc65eae94658cdfa89efceaa3e5b65c27043f6901ec7c9b9f763eac6b09fd98e1c65fe829abd HAVAL5 = cef3f93cb564c0747bdb9ea4dcf877ec1c02cafc1cb2829e32139e484647795f Tiger = 68ae12e713ee6747fb21f73695379cf8e549c570b937fb6a RMD128 = 5b6cfe0ac2e87cda34b8c809bb3fe8c7 RMD160 = a157d8f5a702950ebe416aae641f64f58ad2b637 AES128 = e82270e47b1e40632d806e420b22b4f6 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3444 invoked by uid 1108); 15 Sep 2001 12:51:33 -0700 Sender: aj7kwkp@maradns.org Date: Sat, 15 Sep 2001 12:51:33 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.18 released Message-ID: <20010915125133.A3429@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, First of all, I have added a message giving my coldolences concerning the recent horrible events that happened in New York and in Washington. This message is prominently visible both on the MaraDNS webpage and on my personal web page (http>://www.samiam.org). Second of all, after much delay, I have finally released maradns 0.8.18. This is a release with special code which I used to hunt down and find memory leaks. After this code was activated, I found four memory leaks, which I have holed up. Since I have holed up the memory leaks, the special memory leak hunting code is now disabled. If one wishes to see this code in action, do the following: in libs/, change Makefile so that the compiler flags DEBUG and THREADS are active in server/, rename recursive.c.debug recursive.c, and add the DEBUG flag to the Makefile. At this point, memory allocation is being tracked for some memory allocating calls. When MaraDNS is interrupted with control-C, or is sent a TERM signal, MaraDNS prints out a list of all unfreed memory to the standard output before quitting. Here are the sums. maradns-0.8.18.tar.bz2: BSD = 00991 195 SYSV = 43046 389 CRC = 1732101190 199164 MD5 = 70392659221ae7b45d77f172660b2d06 SHA1 = b1a2d14a9b381398b256f353b5b972d12fbcb443 SHA-256 = 4ca78454537d65bb236a555df77259041b7004ebd5d6cc8c110148c2982043ac SHA-384 = 25b75a2d9d3ce2ca03c6eae3f8c5cbd8f5200780496bea95314ac65259d5904133b608bec466c57b4ae4ca0cec33a6e5 SHA-512 = 611027ecac1a28b20344450d905003cd274bdada6ce0c446697decea10760a936e86c131652c135a4bb88a443651146ced713875c7b316877073f733a25662e8 Wrlpool = da476aeae3473a362900bc0034b7f53cf87887af288f697f3d75fde3be3a7b896f19f2429e8f3bacb5523b5696cd2772cd3788ae7316d7bb17f4db1b6598aa67 HAVAL5 = ac7db6ea9399a2995d014c78a09a48dd0036c1e3c194171fd3b997b7be0dc696 Tiger = 9337bd896bd62fb66260f9b8c1c61b43ebe6d1aa87717d88 RMD128 = 0ea266cef7206ab2e12da5276dde13c0 RMD160 = 8f503d9768626232f317ed85bcd2d84c88d2fb15 AES128 = a53a7e703d204f5f52cac1ad952396a6 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3568 invoked from network); 15 Sep 2001 13:47:11 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 15 Sep 2001 13:47:11 -0700 Received: from franky (D5E059EC.kabel.telenet.be [213.224.89.236]) by pop3.telenet-ops.be (Postfix) with SMTP id 708CC9BB3C for ; Sat, 15 Sep 2001 22:47:11 +0200 (CEST) Date: Sat, 15 Sep 2001 22:55:16 +0200 From: Franky Van Liedekerke To: Subject: Re: MaraDNS 0.8.18 released Message-Id: <20010915225516.6cdf8a84.liedekef@pandora.be> In-Reply-To: <20010915125133.A3429@artemas.reachin.com> References: <20010915125133.A3429@artemas.reachin.com> X-Mailer: Sylpheed version 0.6.1 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 15 Sep 2001 12:51:33 -0700 aj7kwkp@maradns.org wrote: > First of all, I have added a message giving my coldolences concerning the > recent horrible events that happened in New York and in Washington. I agree completely. My deepest sympathies to all who suffered in any way because of those terrible actions!!! Hopefully the world will one day come to it's sences and people will stop killing each other for some stupid reason ... and ban al terrorism to hell. > > Second of all, after much delay, I have finally released maradns > 0.8.18. This is a release with special code which I used to hunt down and > find memory leaks. After this code was activated, I found four memory > leaks, which I have holed up. > > Since I have holed up the memory leaks, the special memory leak hunting > code is now disabled. > I'll check it out :) Greets, Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21163 invoked by uid 1108); 17 Sep 2001 08:16:35 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 17 Sep 2001 08:16:35 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.19 released Message-ID: <20010917081635.A21091@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Since this weekend I was between classes, and hence had no homework, I have had a lot of time to work on MaraDNS. Hence, MaraDNS 0.8.19 is released today. I have updated the CREDITS file in this distribution. If you have contributed to MaraDNS in any way, no matter how small, and are not listed in this file, please let me know. I know I need to include Roy Arends, a BIND developer who pointed out a serious security problem with MaraDNS, in this file. There are other people who I may need to put in this file. I also clean up and updated the documentation. In particular, I have improved the man pages. Among other things, I have disabled justification and hyphenation in the man pages. I have also made it so that ./configure automatically can tell what OS it is in. Franky (or someone else using Solaris), could you check to make sure that './configure; make' now works on Solaris (it should, but I can not test it). Finally, I have removedthe decryption code from the aes directory, since MaraDNS only uses AES in "encrypt" mode as a secure PRNG (psudo-random number generator). Here are various cryptographic sums of the maradns-0.8.19.tar.bz2 file: BSD = 59579 175 SYSV = 37200 350 CRC = 139249900 179181 MD5 = f1e287fa4471a34d841bb54e5e6574ce SHA1 = 9a57a516112c3debefb3793d1f2519768dbec55d SHA-256 = 6ea5fa6e5e252159b34feceb8aee5e8a81b7b204f24209fc6b4e2fae2c09cf8f SHA-384 = e594a8bfc22a377471fba4ed57458ff9a458367a3009783440d8986a651d7aa940927542ec5f863b261bd8b473ec4a6e SHA-512 = 685ebd816599e175175c9869d629c7009b9879ee44febd496ef42bd04503f6ca936fbe1d13431f5f8d6bef5349f3e74041aed859fe60a3818681c9cfe7fab748 Wrlpool = 9dbe65c70545cc4ff64ce589ef2a0b6bd28d00407582ed141a67151aeef410e8e4ecd7e31d5e0a63d045369d675e37407d0f9bd7e72ca97a9f794bc26fcae088 HAVAL5 = b538dc723282bea795dc6fa38e103e4e71f16cf34d030dcb6bc53727a286b57e Tiger = a658486e00cda83de17578d3c032f0cb752be194e8846d29 RMD128 = 1461940e54551478d0b15b58790fc861 RMD160 = f91677299e90a44e0960b41f1b8a15fc72d0bfa9 AES128 = baef7aa2aee125675ee08ec6279c1e3e - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 21256 invoked from network); 17 Sep 2001 08:30:24 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 17 Sep 2001 08:30:24 -0700 Received: (qmail 17478 invoked from network); 17 Sep 2001 15:30:25 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 17 Sep 2001 15:30:25 -0000 Date: Mon, 17 Sep 2001 17:30:25 +0200 (CEST) From: X-X-Sender: To: Subject: Re: MaraDNS 0.8.19 released In-Reply-To: <20010917081635.A21091@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII confirmation: the configure detects solaris ok, and the make succeeds just fine. Haven't had a chance to check for memleaks yet, will do so tomorrow. Franky On Mon, 17 Sep 2001 aj7kwkp@maradns.org wrote: > > > Since this weekend I was between classes, and hence had no homework, I > have had a lot of time to work on MaraDNS. Hence, MaraDNS 0.8.19 is > released today. > > I have updated the CREDITS file in this distribution. If you have > contributed to MaraDNS in any way, no matter how small, and are not listed > in this file, please let me know. I know I need to include Roy Arends, > a BIND developer who pointed out a serious security problem with MaraDNS, > in this file. There are other people who I may need to put in this file. > > I also clean up and updated the documentation. In particular, I have > improved the man pages. Among other things, I have disabled justification > and hyphenation in the man pages. > > I have also made it so that ./configure automatically can tell what OS it > is in. Franky (or someone else using Solaris), could you check to make > sure that './configure; make' now works on Solaris (it should, but I can > not test it). > > Finally, I have removedthe decryption code from the aes directory, since > MaraDNS only uses AES in "encrypt" mode as a secure PRNG (psudo-random > number generator). > > Here are various cryptographic sums of the maradns-0.8.19.tar.bz2 file: > > BSD = 59579 175 > SYSV = 37200 350 > CRC = 139249900 179181 > MD5 = f1e287fa4471a34d841bb54e5e6574ce > SHA1 = 9a57a516112c3debefb3793d1f2519768dbec55d > SHA-256 = 6ea5fa6e5e252159b34feceb8aee5e8a81b7b204f24209fc6b4e2fae2c09cf8f > SHA-384 = e594a8bfc22a377471fba4ed57458ff9a458367a3009783440d8986a651d7aa940927542ec5f863b261bd8b473ec4a6e > SHA-512 = 685ebd816599e175175c9869d629c7009b9879ee44febd496ef42bd04503f6ca936fbe1d13431f5f8d6bef5349f3e74041aed859fe60a3818681c9cfe7fab748 > Wrlpool = 9dbe65c70545cc4ff64ce589ef2a0b6bd28d00407582ed141a67151aeef410e8e4ecd7e31d5e0a63d045369d675e37407d0f9bd7e72ca97a9f794bc26fcae088 > HAVAL5 = b538dc723282bea795dc6fa38e103e4e71f16cf34d030dcb6bc53727a286b57e > Tiger = a658486e00cda83de17578d3c032f0cb752be194e8846d29 > RMD128 = 1461940e54551478d0b15b58790fc861 > RMD160 = f91677299e90a44e0960b41f1b8a15fc72d0bfa9 > AES128 = baef7aa2aee125675ee08ec6279c1e3e > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 27130 invoked by uid 1108); 18 Sep 2001 06:58:15 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 18 Sep 2001 06:58:15 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: SECURITY: maradns-0.8.20 released Message-ID: <20010918065815.A27101@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i I have released MaraDNS 0.8.20 today. This is a security update, and all people using the 0.8.x branch of MaraDNS are encouraged to upgrade. When doing some tests with the AES engine in MaraDNS, I found that I inadvertently created a minor security problem with ASCII nulls in the AES key. Basically, an "out of the box" MaraDNS configuration had a 1 in 16 chance of the aes key not having a full 128 bits of entropy, and a 1 in 256 chance of having no entropy at all. I also corrected a minor fault in the aes128 hasher (it did not previously fully follow the spec, since it counted bytes, not bits), a minor fault with the top-level Makefile (which did not clean up tools/misc with a make clean), and did some minor manpage clean-up. I have also updated the program to generate cryptographic sums, since the aes128 hasher had the same security problem. Here are the cryptographic sums of the updated files, available at http://www.maradns.org/download: maradns-0.8.20.tar.bz2: BSD = 34334 176 SYSV = 161 351 CRC = 293245091 179451 MD5 = ac41248d3e285e90da6b0d8cefab88d5 SHA1 = 2648ddf94547e8a863eae76fecb309260f29d978 SHA-256 = e46759201365afff27d5017981b35c7a92bce270e2fa28a37977a142a94bc38b SHA-384 = d32f5f258aeedd355549ae1de7446d5d1ed2857b0ddd6290f6035aa05b06e9372efaf2 7f8cb7199085b79a0c139e5c25 SHA-512 = 53f07f781c8c44e0ede728b13f54c7e8246a5901b408b465147d90c789c59480a56add 76590967d14a4c43691c61da8bfc495afe44825b78ac1cf78f4655b40b Wrlpool = 52296e2be60a11580f136620107e9d9d4bbd483851778a95c9534d8ce607fbca7a37d6 285946520560d9ac37c1b91dba0398774b1fc41dbc524dfb0b4b407100 HAVAL5 = 7c28e864615171a8a55d5800fc5aaf1d2b82a464479cde3040a425ff759f0b06 Tiger = 1981b637eb554fce56f68fb1fa9d37f62f34bd9ffbb58423 RMD128 = ebedcd8261309a4b7208ea02cfc66a68 RMD160 = fb7d78d87a98180a05d3cb05f31c1174b7c01013 AES128a = a93defefad57276dbb72af023da3e2c0 sums-20010918.tar.bz2: BSD = 38644 139 SYSV = 3145 278 CRC = 1356115107 142088 MD5 = ed32689b00d520f8c00ee792bc22bf56 SHA1 = 3548b1cd97aaceb78e04c3b99d51a873e601433d SHA-256 = a9ab500558d7936ec07b9b24a7e16a9f6e8a8a5b69332a8c6b26b7b5a2ad613c SHA-384 = de0201fe362c0a43215505b215f09fb6213c8569d704e79c57cc1a0d16fb313a7c8cf0 2b276747140b5c4a0ee892429e SHA-512 = 347a8c08597a70f99c158b19d7bf0deba33e0363f060a36f2bd67ff14969f36d6e489e 5af6d6ea00fa285d32464bc199f2e3dad2fe34656c50e9dccf8dd2f810 Wrlpool = 6e9f2e9e49a7e6093da1575a3a76f106bd31b6740935fe9d6ef3291951cb128929a671 7066b990a175002d81ca01258af4a286dd556787d55d7f8ebc2050c62c HAVAL5 = 0ad23d13a201030a02449a90086fef3719c0e43c54e88ab81d728876216bf34f Tiger = f900d9eb9cf504f661722b797b38e492a94cd2e791eeaae1 RMD128 = 64359e8223450bccd926f6c6abc346eb RMD160 = dbbf9816d90b3eb6c14928545db39b932e8d5703 AES128a = fa16ddc00642bab4f035d5f5e1af9262 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 27666 invoked from network); 18 Sep 2001 08:51:43 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 18 Sep 2001 08:51:43 -0700 Received: (qmail 32284 invoked from network); 18 Sep 2001 15:51:37 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 18 Sep 2001 15:51:37 -0000 Date: Tue, 18 Sep 2001 17:51:37 +0200 (CEST) From: X-X-Sender: To: Subject: Re: SECURITY: maradns-0.8.20 released In-Reply-To: <20010918065815.A27101@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Sam, I just tried to see if any memleaks existed, therefore I tried the benchmark tool again, always with the same hostname to look for. But I still see a mem leak, as the process still seems to be growing every time I start the benchmar again. I then compiled it with the memleak code activated, and this is what I get: Log: Root directory changed Log: Binding to address 0.0.0.0 Log: Socket opened on UDP port 53 Log: Root privledges dropped Warning: Can not open zone file example.com. Log: All RRs have been loaded DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache of ipv4_pair DNS cache: ipp in ipv4_pair DNS cache: close DNS cache: ipp DNS cache: close DNS cache: ipp DNS cache: close DNS cache: ipp DNS cache: close DNS cache: ipp DNS cache: close DNS cache: ipp DNS cache: close DNS cache: ipp DNS cache: close DNS cache: ipp DNS cache: close DNS cache: ipp DNS cache: close DNS cache: ipp DNS cache 1 DNS hash 2 DNS cache jsip DNS cache 1 DNS hash 2 DNS cache jsip Does this help? Franky On Tue, 18 Sep 2001 aj7kwkp@maradns.org wrote: > > I have released MaraDNS 0.8.20 today. This is a security update, and all > people using the 0.8.x branch of MaraDNS are encouraged to upgrade. > > When doing some tests with the AES engine in MaraDNS, I found that > I inadvertently created a minor security problem with ASCII nulls > in the AES key. Basically, an "out of the box" MaraDNS > configuration had a 1 in 16 chance of the aes key not having a full > 128 bits of entropy, and a 1 in 256 chance of having no entropy at all. > > I also corrected a minor fault in the aes128 hasher (it did not > previously fully follow the spec, since it counted bytes, not > bits), a minor fault with the top-level Makefile (which did not > clean up tools/misc with a make clean), and did some minor manpage > clean-up. > > I have also updated the program to generate cryptographic sums, since the > aes128 hasher had the same security problem. > > Here are the cryptographic sums of the updated files, available at > http://www.maradns.org/download: > > maradns-0.8.20.tar.bz2: > > BSD = 34334 176 > SYSV = 161 351 > CRC = 293245091 179451 > MD5 = ac41248d3e285e90da6b0d8cefab88d5 > SHA1 = 2648ddf94547e8a863eae76fecb309260f29d978 > SHA-256 = e46759201365afff27d5017981b35c7a92bce270e2fa28a37977a142a94bc38b > SHA-384 = > d32f5f258aeedd355549ae1de7446d5d1ed2857b0ddd6290f6035aa05b06e9372efaf2 > 7f8cb7199085b79a0c139e5c25 > SHA-512 = > 53f07f781c8c44e0ede728b13f54c7e8246a5901b408b465147d90c789c59480a56add > 76590967d14a4c43691c61da8bfc495afe44825b78ac1cf78f4655b40b > Wrlpool = > 52296e2be60a11580f136620107e9d9d4bbd483851778a95c9534d8ce607fbca7a37d6 > 285946520560d9ac37c1b91dba0398774b1fc41dbc524dfb0b4b407100 > HAVAL5 = 7c28e864615171a8a55d5800fc5aaf1d2b82a464479cde3040a425ff759f0b06 > Tiger = 1981b637eb554fce56f68fb1fa9d37f62f34bd9ffbb58423 > RMD128 = ebedcd8261309a4b7208ea02cfc66a68 > RMD160 = fb7d78d87a98180a05d3cb05f31c1174b7c01013 > AES128a = a93defefad57276dbb72af023da3e2c0 > > sums-20010918.tar.bz2: > BSD = 38644 139 > SYSV = 3145 278 > CRC = 1356115107 142088 > MD5 = ed32689b00d520f8c00ee792bc22bf56 > SHA1 = 3548b1cd97aaceb78e04c3b99d51a873e601433d > SHA-256 = a9ab500558d7936ec07b9b24a7e16a9f6e8a8a5b69332a8c6b26b7b5a2ad613c > SHA-384 = > de0201fe362c0a43215505b215f09fb6213c8569d704e79c57cc1a0d16fb313a7c8cf0 > 2b276747140b5c4a0ee892429e > SHA-512 = > 347a8c08597a70f99c158b19d7bf0deba33e0363f060a36f2bd67ff14969f36d6e489e > 5af6d6ea00fa285d32464bc199f2e3dad2fe34656c50e9dccf8dd2f810 > Wrlpool = > 6e9f2e9e49a7e6093da1575a3a76f106bd31b6740935fe9d6ef3291951cb128929a671 > 7066b990a175002d81ca01258af4a286dd556787d55d7f8ebc2050c62c > HAVAL5 = 0ad23d13a201030a02449a90086fef3719c0e43c54e88ab81d728876216bf34f > Tiger = f900d9eb9cf504f661722b797b38e492a94cd2e791eeaae1 > RMD128 = 64359e8223450bccd926f6c6abc346eb > RMD160 = dbbf9816d90b3eb6c14928545db39b932e8d5703 > AES128a = fa16ddc00642bab4f035d5f5e1af9262 > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 28220 invoked by uid 1108); 18 Sep 2001 09:46:46 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 18 Sep 2001 09:46:46 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: SECURITY: maradns-0.8.20 released Message-ID: <20010918094646.A28173@artemas.reachin.com> References: <20010918065815.A27101@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from liedekef@pandora.be on Tue, Sep 18, 2001 at 05:51:37PM +0200 > Log: Root directory changed > Log: Binding to address 0.0.0.0 > Log: Socket opened on UDP port 53 > Log: Root privledges dropped > Warning: Can not open zone file example.com. > Log: All RRs have been loaded > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache of ipv4_pair > DNS cache: ipp in ipv4_pair > DNS cache: close > DNS cache: ipp > DNS cache: close > DNS cache: ipp > DNS cache: close > DNS cache: ipp > DNS cache: close > DNS cache: ipp > DNS cache: close > DNS cache: ipp > DNS cache: close > DNS cache: ipp > DNS cache: close > DNS cache: ipp > DNS cache: close > DNS cache: ipp > DNS cache: close > DNS cache: ipp > DNS cache 1 > DNS hash 2 > DNS cache jsip > DNS cache 1 > DNS hash 2 > DNS cache jsip > > Does this help? I assume that you are using the test bed in sqa/testbed as the "zone" for example.com. Is this correct? - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 29308 invoked from network); 18 Sep 2001 12:03:42 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 18 Sep 2001 12:03:42 -0700 Received: from franky (D5E05BE9.kabel.telenet.be [213.224.91.233]) by tartarus.telenet-ops.be (Postfix) with SMTP id 05FEC217871 for ; Tue, 18 Sep 2001 21:03:04 +0200 (CEST) Date: Tue, 18 Sep 2001 21:11:14 +0200 From: Franky Van Liedekerke To: Subject: Re: SECURITY: maradns-0.8.20 released Message-Id: <20010918211114.7425d0af.liedekef@pandora.be> In-Reply-To: <20010918094646.A28173@artemas.reachin.com> References: <20010918065815.A27101@artemas.reachin.com> <20010918094646.A28173@artemas.reachin.com> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 18 Sep 2001 09:46:46 -0700 aj7kwkp@maradns.org wrote: > > I assume that you are using the test bed in sqa/testbed as the "zone" for > example.com. Is this correct? > > - Sam > Nope, I'm using a query for an A-record outside the own nameserver (recursive that is :) I'm not even using any zone files myself. Can I do anything more (greater loglevel, ...) to help find the hole? If anybody else using solaris could try: I just did ./benchmark Awww.telenet.be. 127.0.0.1 and watched as top reported memory increase... Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 29497 invoked from network); 18 Sep 2001 12:23:25 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 18 Sep 2001 12:23:25 -0700 Received: from franky (D5E05BE9.kabel.telenet.be [213.224.91.233]) by tartarus.telenet-ops.be (Postfix) with SMTP id 36291217352 for ; Tue, 18 Sep 2001 21:23:24 +0200 (CEST) Date: Tue, 18 Sep 2001 21:31:33 +0200 From: Franky Van Liedekerke To: Subject: Re: SECURITY: maradns-0.8.20 released Message-Id: <20010918213133.7126841b.liedekef@pandora.be> In-Reply-To: <20010918211114.7425d0af.liedekef@pandora.be> References: <20010918065815.A27101@artemas.reachin.com> <20010918094646.A28173@artemas.reachin.com> <20010918211114.7425d0af.liedekef@pandora.be> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Tue, 18 Sep 2001 21:11:14 +0200 Franky Van Liedekerke wrote: > Nope, I'm using a query for an A-record outside the own nameserver (recursive that is :) I'm not even using any zone files myself. Can I do anything more (greater loglevel, ...) to help find the hole? > If anybody else using solaris could try: I just did > > ./benchmark Awww.telenet.be. 127.0.0.1 > > and watched as top reported memory increase... > btw, als pmap reported increasing heap usage. I also attached here the output from the small script I once wrote (js_test). The output is already much smaller, so that's a good thing :) Also probably some errors are false, but I think some mem leaks still need to be plugged. relevant js_test output: ===>Entering function int mhash_put_data(mhash *hash, js_string *query, js_string *value, uint32 ttl, data (from line 681) not deallocated upon return on line 748 data (from line 681) not deallocated upon return on line 765 data (from line 681) not deallocated upon return on line 803 data (from line 681) not deallocated upon return on line 807 ===>Entering function int query_nameserver(int remote_ip, js_string *query, js_string *bailiwick) { jsip (from line 1196) not destroyed upon return on line 1275 ===>Entering function int recurse_call(int id, int sock, struct sockaddr client, i32_copy (from line 1845) not deallocated upon return on line 1973 local_c (from line 1872) not deallocated upon return on line 1973 i32_copy (from line 1845) not deallocated upon return on line 1984 local_c (from line 1872) not deallocated upon return on line 1984 i32_copy (from line 1845) not deallocated upon return on line 1990 local_c (from line 1872) not deallocated upon return on line 1990 ===>Entering function int launch_thread(int id, int sock, req (from line 2021) not deallocated upon return on line 2054 req (from line 2021) not deallocated upon return on line 2058 req (from line 2021) not deallocated upon return on line 2074 ===>Entering function int add_closer_jsddip(js_string *zone, js_string *ddip, int if_exists) { ipp (from line 2124) not deallocated upon return on line 2168 ipjs (from line 2099) not destroyed upon return on line 2168 ipp (from line 2124) not deallocated upon return on line 2174 close (from line 2095) not deallocated upon return on line 2174 ipjs (from line 2099) not destroyed upon return on line 2174 ipp (from line 2124) not deallocated upon return on line 2185 close (from line 2095) not deallocated upon return on line 2185 ipjs (from line 2099) not destroyed upon return on line 2185 ===>Entering function int add_closer_ipv4pair(js_string *zone, ipv4pair *pair, int if_exists) { ipp (from line 2224) not deallocated upon return on line 2269 close (from line 2211) not deallocated upon return on line 2269 ipp (from line 2224) not deallocated upon return on line 2276 close (from line 2211) not deallocated upon return on line 2276 ipp (from line 2224) not deallocated upon return on line 2288 close (from line 2211) not deallocated upon return on line 2288 ===>Entering function int add_closer_js(js_string *zone, js_string *name, int if_exists) { close (from line 2313) not deallocated upon return on line 2319 close (from line 2313) not deallocated upon return on line 2365 close (from line 2313) not deallocated upon return on line 2372 close (from line 2313) not deallocated upon return on line 2384 close (from line 2313) not deallocated upon return on line 2387 ===>Entering function int add_closer_jsip(js_string *zone, js_string *ipjs, int if_exists) { ipp (from line 2519) not deallocated upon return on line 2559 close (from line 2503) not deallocated upon return on line 2559 ipp (from line 2519) not deallocated upon return on line 2566 close (from line 2503) not deallocated upon return on line 2566 ipp (from line 2519) not deallocated upon return on line 2578 close (from line 2503) not deallocated upon return on line 2578 From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3171 invoked by uid 1108); 19 Sep 2001 07:59:53 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 19 Sep 2001 07:59:53 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: It looks like MaraDNS is *not* leaking Message-ID: <20010919075953.B3132@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i I did some tests in Linux last night, and it looks like MaraDNS is not leaking. Here is the test I did: I set up the testbed which exists in sqa/testbed off of the maradns directory. I set up a recursive server with the IP of 127.0.0.3 I then performed some tests that showed, while MaraDNS grows because the thread library grows, the growing stops after a point, at which point the memory usage of MaraDNS stays constant. Here is the test I performed (the editor of my mailed has added some line feeds): [First, we start up maradns as root in another window, binding maradns to the IP 127.0.0.3] vela 22:13:19 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep nobody 24175 0.1 0.1 1572 640 pts/0 S 22:13 0:00 maradns [We also have a handful of other maradns processes to simulate a string of DNS servers, from the root name server to the example.com nameserver] vela 22:15:10 maradns $ askmara Awww.example.com. 127.0.0.3 [Reply from server snipped for brevity] vela 22:15:22 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep nobody 24175 0.0 0.1 1588 692 pts/0 S 22:13 0:00 maradns nobody 24185 0.0 0.1 1588 692 pts/0 S 22:15 0:00 maradns vela 22:15:26 maradns $ askmara Awww.example.com. 127.0.0.3 [We ask again. Same reply, again removed for brevity] vela 22:15:46 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep nobody 24175 0.0 0.1 3636 696 pts/0 S 22:13 0:00 maradns nobody 24185 0.0 0.1 3636 696 pts/0 S 22:15 0:00 maradns nobody 24192 0.0 0.0 0 0 pts/0 Z 22:15 0:00 [maradns ] [Note that it takes a second for the thread to die off. Note also that the memory use goes up for every single thread, since a thread has a considerable memory overhead] vela 22:15:47 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep nobody 24175 0.0 0.1 1588 692 pts/0 S 22:13 0:00 maradns nobody 24185 0.0 0.1 1588 692 pts/0 S 22:15 0:00 maradns [A second later, memory usage is back at the old level. Next, we ask the DNS query again] vela 22:15:50 maradns $ askmara Awww.example.com. 127.0.0.3 [Again, reply removed for brevity] vela 22:15:58 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep [MaraDNS apprears no larger] nobody 24175 0.0 0.1 1588 692 pts/0 S 22:13 0:00 maradns nobody 24185 0.0 0.1 1588 692 pts/0 S 22:15 0:00 maradns [Next, we send a large number of queries to the DNS server] vela 22:16:00 maradns $ ./maradns-0.8.20/tools/benchmark Awww.example.com. 127.0.0.3 [Query ticker snipped for brevity] Query failed on query number 25615 [We now see that MaraDNS is a little bigger. My theory: This is overhead caused by the threading library spwaning a large number of threads, which grows until it hits a stable point] vela 22:16:27 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep nobody 24175 1.5 0.1 2612 700 pts/0 S 22:13 0:02 maradns nobody 24185 3.3 0.1 2612 700 pts/0 S 22:15 0:02 maradns vela 22:16:31 maradns $ ./maradns-0.8.20/tools/benchmark Awww.example.com. 127.0.0.3 [We do the same thing again: Send a large number of queries] Query failed on query number 23735 vela 22:16:57 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep [MaraDNS has not grown any] nobody 24175 2.6 0.1 2612 700 pts/0 S 22:13 0:05 maradns nobody 24185 4.8 0.1 2612 700 pts/0 S 22:15 0:04 maradns vela 22:16:58 maradns $ ./maradns-0.8.20/tools/benchmark Awww.example.com. 127.0.0.3 [Again, a large number of queries] Query failed on query number 23441 vela 22:17:10 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep [Again, MaraDNS has not grown] nobody 24175 3.7 0.1 2612 700 pts/0 S 22:13 0:07 maradns nobody 24185 6.2 0.1 2612 700 pts/0 S 22:15 0:06 maradns [One last time] vela 22:17:15 maradns $ ./maradns-0.8.20/tools/benchmark Awww.example.com. 127.0.0.3 Query failed on query number 24623 [And, again, MaraDNS has not grown any] vela 22:24:42 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v grep nobody 24175 1.5 0.1 2612 700 pts/0 S 22:13 0:10 maradns nobody 24185 1.6 0.1 2612 700 pts/0 S 22:15 0:09 maradns -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3225 invoked by uid 1108); 19 Sep 2001 08:01:09 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 19 Sep 2001 08:01:09 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MOre on the leaking Message-ID: <20010919080109.C3132@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i If the behavior of MaraDNS with regards to memory leaking is different on Solaris, let me know. Please include usage of ps -aux with the BSD version of 'ps'. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3295 invoked from network); 19 Sep 2001 08:10:45 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 19 Sep 2001 08:10:45 -0700 Received: (qmail 10003 invoked from network); 19 Sep 2001 15:10:46 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 19 Sep 2001 15:10:46 -0000 Date: Wed, 19 Sep 2001 17:10:46 +0200 (CEST) From: X-X-Sender: To: cc: Subject: Re: It looks like MaraDNS is *not* leaking In-Reply-To: <20010919075953.B3132@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sam, your test, was it a recursive test? Because from your example, you always ask for "www.example.com" and that's served locally (non-recursive), right? On Wed, 19 Sep 2001 aj7kwkp@maradns.org wrote: > > I did some tests in Linux last night, and it looks like MaraDNS is not > leaking. > > Here is the test I did: > > I set up the testbed which exists in sqa/testbed off of the maradns > directory. > > I set up a recursive server with the IP of 127.0.0.3 > > I then performed some tests that showed, while MaraDNS grows because the > thread library grows, the growing stops after a point, at which point the > memory usage of MaraDNS stays constant. > > Here is the test I performed (the editor of my mailed has added some line > feeds): > > [First, we start up maradns as root in another window, binding maradns > to the IP 127.0.0.3] > vela 22:13:19 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > nobody 24175 0.1 0.1 1572 640 pts/0 S 22:13 0:00 maradns > [We also have a handful of other maradns processes to simulate a string of > DNS servers, from the root name server to the example.com nameserver] > vela 22:15:10 maradns $ askmara Awww.example.com. 127.0.0.3 > [Reply from server snipped for brevity] > vela 22:15:22 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > nobody 24175 0.0 0.1 1588 692 pts/0 S 22:13 0:00 maradns > nobody 24185 0.0 0.1 1588 692 pts/0 S 22:15 0:00 maradns > vela 22:15:26 maradns $ askmara Awww.example.com. 127.0.0.3 > [We ask again. Same reply, again removed for brevity] > vela 22:15:46 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > nobody 24175 0.0 0.1 3636 696 pts/0 S 22:13 0:00 maradns > nobody 24185 0.0 0.1 3636 696 pts/0 S 22:15 0:00 maradns > nobody 24192 0.0 0.0 0 0 pts/0 Z 22:15 0:00 [maradns > ] > [Note that it takes a second for the thread to die off. Note also that > the memory use goes up for every single thread, since a thread has a > considerable memory overhead] > vela 22:15:47 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > nobody 24175 0.0 0.1 1588 692 pts/0 S 22:13 0:00 maradns > nobody 24185 0.0 0.1 1588 692 pts/0 S 22:15 0:00 maradns > [A second later, memory usage is back at the old level. Next, we ask the > DNS query again] > vela 22:15:50 maradns $ askmara Awww.example.com. 127.0.0.3 > [Again, reply removed for brevity] > vela 22:15:58 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > [MaraDNS apprears no larger] > nobody 24175 0.0 0.1 1588 692 pts/0 S 22:13 0:00 maradns > nobody 24185 0.0 0.1 1588 692 pts/0 S 22:15 0:00 maradns > [Next, we send a large number of queries to the DNS server] > vela 22:16:00 maradns $ ./maradns-0.8.20/tools/benchmark > Awww.example.com. 127.0.0.3 > [Query ticker snipped for brevity] > Query failed on query number 25615 > [We now see that MaraDNS is a little bigger. My theory: This is overhead > caused by the threading library spwaning a large number of threads, which > grows until it hits a stable point] > vela 22:16:27 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > nobody 24175 1.5 0.1 2612 700 pts/0 S 22:13 0:02 maradns > nobody 24185 3.3 0.1 2612 700 pts/0 S 22:15 0:02 maradns > vela 22:16:31 maradns $ ./maradns-0.8.20/tools/benchmark > Awww.example.com. 127.0.0.3 > [We do the same thing again: Send a large number of queries] > Query failed on query number 23735 > vela 22:16:57 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > [MaraDNS has not grown any] > nobody 24175 2.6 0.1 2612 700 pts/0 S 22:13 0:05 maradns > nobody 24185 4.8 0.1 2612 700 pts/0 S 22:15 0:04 maradns > vela 22:16:58 maradns $ ./maradns-0.8.20/tools/benchmark > Awww.example.com. 127.0.0.3 > [Again, a large number of queries] > Query failed on query number 23441 > vela 22:17:10 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > [Again, MaraDNS has not grown] > nobody 24175 3.7 0.1 2612 700 pts/0 S 22:13 0:07 maradns > nobody 24185 6.2 0.1 2612 700 pts/0 S 22:15 0:06 maradns > [One last time] > vela 22:17:15 maradns $ ./maradns-0.8.20/tools/benchmark > Awww.example.com. 127.0.0.3 > Query failed on query number 24623 > [And, again, MaraDNS has not grown any] > vela 22:24:42 maradns $ ps auxw | grep maradns | grep -v mararc | grep -v > grep > nobody 24175 1.5 0.1 2612 700 pts/0 S 22:13 0:10 maradns > nobody 24185 1.6 0.1 2612 700 pts/0 S 22:15 0:09 maradns > > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3433 invoked from network); 19 Sep 2001 08:48:54 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 19 Sep 2001 08:48:54 -0700 Received: (qmail 31932 invoked from network); 19 Sep 2001 15:48:55 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 19 Sep 2001 15:48:55 -0000 Date: Wed, 19 Sep 2001 17:48:55 +0200 (CEST) From: X-X-Sender: To: Subject: Re: MOre on the leaking In-Reply-To: <20010919080109.C3132@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII on solaris, the ps is not BSD, so... but I can give the pmap output (relevant output is heap usage and total mem usage): After starting maradns: total 2168K After doing "benchmark Awww.telenet.be. 127.0.0.1": (Query failed on query number 22625) total 3232K heap usage: 1128K Again the same: (Query failed on query number 36140) total 4928K heap usage: 2824K Again: (Query failed on query number 35470) total 6592K heap usage: 4480K Again: (Query failed on query number 35795) total 8280K heap usage: 6160K Again: (Query failed on query number 36272) total 9984K heap usage: 7864K waiting 5 minutes (for threads to clean up) shows the same heap usage, but a bit less total (which is normal): 9968K So it does seem to be leaking somewhere... Franky On Wed, 19 Sep 2001 aj7kwkp@maradns.org wrote: > > If the behavior of MaraDNS with regards to memory leaking is different on > Solaris, let me know. Please include usage of ps -aux with the BSD > version of 'ps'. > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3579 invoked by uid 1108); 19 Sep 2001 09:11:29 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 19 Sep 2001 09:11:29 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: It looks like MaraDNS is *not* leaking Message-ID: <20010919091129.B3547@artemas.reachin.com> References: <20010919075953.B3132@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from liedekef@pandora.be on Wed, Sep 19, 2001 at 05:10:46PM +0200 It was a recursive test, as far as I know, but I will double check that. (I don't have the computer that I ran the test on right here this second) Thanks for the Solaris report. Time to post to comp.unix.solaris. - Sam [snip. Test report showing that MaraDNS is not growing on Linux] -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 3684 invoked by uid 1108); 19 Sep 2001 09:18:23 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 19 Sep 2001 09:18:23 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Ugh, Solaris is leaking (but Linux isn't) Message-ID: <20010919091823.A3666@artemas.reachin.com> References: <20010919080109.C3132@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from liedekef@pandora.be on Wed, Sep 19, 2001 at 05:48:55PM +0200 [snip of memory usage increasing in a rather alarming way on Solaris with MaraDNS] > So it does seem to be leaking somewhere... Yes, indeed. However, I just checked on the computer which I ran the leak tests on last night, and Linux (redHat 7.1, to be exact) is not exhibitinf this problem. The only thing I can do at this point is to ask for help on comp.unix.solaris or some such. It is possible that the "limit" with threads in Solaris is considerable higher than the limit on Linux. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 4344 invoked by uid 1108); 19 Sep 2001 10:57:45 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 19 Sep 2001 10:57:45 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: What version of Solaris are you running, Frankie? Message-ID: <20010919105745.A4329@artemas.reachin.com> References: <20010919080109.C3132@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from liedekef@pandora.be on Wed, Sep 19, 2001 at 05:48:55PM +0200 > So it does seem to be leaking somewhere... Franky, what version of Solaris are you running? - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 4411 invoked from network); 19 Sep 2001 11:02:01 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 19 Sep 2001 11:02:01 -0700 Received: from franky (D5E05787.kabel.telenet.be [213.224.87.135]) by tartarus.telenet-ops.be (Postfix) with SMTP id 0CC88216FD9 for ; Wed, 19 Sep 2001 20:02:03 +0200 (CEST) Date: Wed, 19 Sep 2001 20:10:13 +0200 From: Franky Van Liedekerke To: Subject: Re: What version of Solaris are you running, Frankie? Message-Id: <20010919201013.2d108e8a.liedekef@pandora.be> In-Reply-To: <20010919105745.A4329@artemas.reachin.com> References: <20010919080109.C3132@artemas.reachin.com> <20010919105745.A4329@artemas.reachin.com> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Solaris 2.8 On Wed, 19 Sep 2001 10:57:45 -0700 aj7kwkp@maradns.org wrote: > > > So it does seem to be leaking somewhere... > > Franky, what version of Solaris are you running? > > - Sam > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 5506 invoked from network); 19 Sep 2001 13:48:37 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 19 Sep 2001 13:48:37 -0700 Received: from franky (D5E05787.kabel.telenet.be [213.224.87.135]) by tartarus.telenet-ops.be (Postfix) with SMTP id 274A221719C for ; Wed, 19 Sep 2001 22:48:37 +0200 (CEST) Date: Wed, 19 Sep 2001 22:56:46 +0200 From: Franky Van Liedekerke To: Subject: Re: Ugh, Solaris is leaking (but Linux isn't) Message-Id: <20010919225646.64ec1f4d.liedekef@pandora.be> In-Reply-To: <20010919091823.A3666@artemas.reachin.com> References: <20010919080109.C3132@artemas.reachin.com> <20010919091823.A3666@artemas.reachin.com> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 19 Sep 2001 09:18:23 -0700 aj7kwkp@maradns.org wrote: > > [snip of memory usage increasing in a rather alarming way on Solaris > with MaraDNS] > > > So it does seem to be leaking somewhere... > > Yes, indeed. However, I just checked on the computer which I ran the leak > tests on last night, and Linux (redHat 7.1, to be exact) is not exhibitinf > this problem. > Sam, I indeed see the same on linux: no leak. But maybe that's because linux emulates threads so when a tread exits, also it's memory gets freed. So maybe the leak is to be found when the thread closes? Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 6061 invoked by uid 1108); 19 Sep 2001 14:46:25 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 19 Sep 2001 14:46:25 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: Ugh, Solaris is leaking (but Linux isn't) Message-ID: <20010919144625.B5944@artemas.reachin.com> References: <20010919080109.C3132@artemas.reachin.com> <20010919091823.A3666@artemas.reachin.com> <20010919225646.64ec1f4d.liedekef@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010919225646.64ec1f4d.liedekef@pandora.be>; from liedekef@pandora.be on Wed, Sep 19, 2001 at 10:56:46PM +0200 > Sam, I indeed see the same on linux: no leak. But maybe that's because > linux emulates threads so when a tread exits, also it's memory gets > freed. So maybe the leak is to be found when the thread closes? Possibly. However, since I can't see the bug, I can't readily fix it. What I can do is have a notice that Solaris is leaking memory like a seive, even though Linux does not have this problem, and that any patch that can fix this problem would be appreciated. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 6113 invoked by uid 1108); 19 Sep 2001 14:47:47 -0700 Sender: aj7kwkp@maradns.org Date: Wed, 19 Sep 2001 14:47:47 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS bug report Message-ID: <20010919144747.C5944@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i [This is in reply to a bug report I got in private mail] Thank you for the bug report. > I have not been able to find where to report bugs. That is why you get > this. This is the place to report bugs, yes. And feel free to report them to the list. > > /Ole > > --- > > Error on http://www.maradns.org/quickstart.html > > * tar -xvIf maradns-*.tar.bz2 > > -I is depreciated. Use -j instead. I will probably change this to -j in a year or so, or make a note in the documentation that newer versions of tar prefer -j. The problem is that too many existing servers in the real world do not work with the 'j' switch of tar. Of course, this is probably the ideal example form, guaranteed to work: bzip2 -cd maradns-*.tar.bz2 | tar xvf - > # make install > ./install.sh > Installing MaraDNS, placing programs in /usr/local/bin/ and > /usr/local/sbin/, > and man pages in /usr/local/man/man1/ and /usr/local/man/man8/ > cp: copying multiple files, but last argument `/usr/local/man/man1/' is > not a directory > Prøv 'cp --help' for mere information. > cp: copying multiple files, but last argument `/usr/local/man/man8/' is > not a directory > Prøv 'cp --help' for mere information. > > (You should make sure the dirs exists) What distribution are you using? The best thing to do is have a "test to see if everything exists, and if not, tell the user to change install.locations". I am actually quite suprised that /usr/local/man does not exist with all distributions. Easy enough to check for, though. > * Test this program with one of the following invocations: > dig @127.0.0.3 example.com > > No. The default config uses 127.0.0.1. Thanks for the bug report. > --- > > From: doc/exmaple_mararc > # This is just to show the format of the file > # Note the this is commented out. Any line that starts with a '#' is not > # read by the parser. Remove the leading '# ' to enable any line that is > # commented out > # csv1["example.com."] = "db.example.com" > > Remove the last # (Else your getting started example does not work). I added that # because the original Debian packager of MaraDNS added it, and I felt it was a little more proper. Then again, it is probably better to have something that works "out of the box". Since there seems to be some controversey with this, I should ask the list what their opinion is. > --- > > When trying to configure for recursive lookup: > > ipv4_alias["localhost"] = "127.0.0.0/8" > recursive_acl = "localhost" > > I get: > > Fatal error: Init_cache() failed > > This is a bad error message. I have no idea what to do to resolve it. > It seems what I needed was: > > root_servers = {} > random_seed_file = "/dev/urandom" > root_servers = {} > root_servers["."] = "osrc" > > Please let the error message tell me what to do. A good example of this is > when random_seed_file is missing: > > Fatal error: random_seed_file must be set if recursive DNS is enabled > > This gives me an idea what to look for. Obscure error messages are certaintly a bug. If you would like to see this resolved, please send me the following information: * The contents of you /etc/mararc file * The contents of any files /in /etc/maradns * The full output MaraDNS generates As you pointed out, I have gone to some trouble to remove obscure error messages with the authoritative portion of the nameserver. Now, I need to remove similiar obscure error messages with the recursive portion of the nameserver. > I have not been able to find any information how to get MaraDNS to be > secondary for a BIND-9 server. In fact I have not been able to find any > information on secondaries and MaraDNS. Is MaraDNS capable of being a > secondary nameserver? Depends on what you mean as a "secondary nameserver". MaraDNS uses the getzone program to obtain zone files via AXFR from other nameservers. This process can certaintly be automated with a cron job. I will add an entry to the FAQ about this. - Sam (ccing the list) -- "Reality is the most perfect vision of God's will" -- Orson Scott Card ----- End forwarded message ----- -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7227 invoked from network); 19 Sep 2001 16:51:09 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 19 Sep 2001 16:51:09 -0700 Received: by home.tange.dk (Postfix, from userid 501) id 0BD4C16D75; Thu, 20 Sep 2001 01:51:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id 06EEE16D74 for ; Thu, 20 Sep 2001 01:51:15 +0200 (CEST) Date: Thu, 20 Sep 2001 01:51:14 +0200 (CEST) From: Ole Tange To: Subject: BUG: CNAME of *.foo not valid Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I have just tried making MaraDNS primary for tange.dk. I use wildcards alot and have: *.tange.dk IN CNAME ns.pi.dk. When using getzone to make the csv1-version the result is rejected by MaraDNS. Warning: Fatal error in zone file tange.dk. (aborting this zone file) on line 9 Line 9 is: C*.tange.dk.|86400|ns.pi.dk. I expect this to be either a bug in getzone or in MaraDNS. /Ole From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 10434 invoked by uid 1108); 20 Sep 2001 08:03:41 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 20 Sep 2001 08:03:41 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.21 released Message-ID: <20010920080341.A10405@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there. I would like to thank Ole Tange and Franky for making this release of MaraDNS possible. Ole, for his invaluable bug reports, and Franky for pointing out that, for reasons that I am not able to troubleshoot and resolve down here in Mexico, MaraDNS is broken on Solaris (it leaks memory like a sieve). The bad news: There is a known issue with MaraDNS having memory leaks when used as a recursive nameserver on the Solaris operating system. This problem does not exist in Linux. Since I do not have ready access to a Solaris box to develop on, I can not resolve this issue. Until a Solaris developer steps up to bat and fixes this for me, I am forced to disable recursive DNS serving under Solaris. I should have ready access to a Solaris again in December, when I return to the United States. I have CDs of Solaris eight up there, in addition to friends with Solaris boxes. Now, the good news. I have updated the example mararc files to be consistant with the documentation. In particular, I now have two "out of the box" working mararc files. One for authoritative name serving, and another for recursive nameserving. I have also updated the installer script to return an error if the directories to put the MaraDNS files in do not exist. In addition, MaraDNS will install all of the MaraDNS documentation in the directory specified by the variable DOCS in install.locations. Finally, I have updated the FAQ, the man pages, the mararc.format documentation, and am working on making separate man pages which describe csv1 zone files and the mararc file. (2001.09.20) And, of course, cryptographic sums in every format imaginable: BSD = 34929 180 SYSV = 60495 359 CRC = 110958817 183740 MD5 = 725baacd0221ba88065c4823136c59f3 SHA1 = a96d8453453c55abff9f84ab65fda7a16507665d SHA-256 = e86e8b7b4f8ae06cb68a7f0dd9a128db4531dec4c51b004649f50a1d9c4bf1ad SHA-384 = e9c6a1ec06912c921e08f8e190d31d4ed0c1e68cb21c9385fa334db6de13676f3b08f328c22c0d0908adec9b2ec3eec2 SHA-512 = 7b007e47c4f1dce65380d788f791f9eab447789e41f18794e5540918d377d6e1aff1f6841d17ae9bdffb2e406a0ddc97ac55fb4d20ed4fe19945d5b0bf6007e9 Wrlpool = abfdcda0d0fc61c75e635022f053137d5539dbfc4813029ee404bbcd90663968105caf481a9b1c2427d942fb48d7c8a23ee36e43a95697b0652813eed4e01fe8 HAVAL5 = 5ff4b8929a837d9cf6013a4796892318a52b77b317835210775fa733ea0cdf9d Tiger = 95b73831b70a4dfbe9cce538cda2139a26719f682eb1427f RMD128 = 48085d2bcb1b4fd63e134f90c5aec69f RMD160 = a7a0152f87656d69d8fa7c6c4a7075bfd110776d AES128a = e53a988b07bab4967d7efa57d625be10 AES160 = 9679e7a60e00662f66eda6efdb535a05bffacce6 AES192 = 41d8294508ae6706207168f2ce13f0ae7d112e40a2274a99 AES224 = fffeb2ec41059aae0e23504ccb850c8c7681fa08920a9d306fb475b5 AES256 = a8799a431d66193ee14b439c98d72c6bb90eef838ea875859be986698a9bb4ac - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12475 invoked from network); 20 Sep 2001 13:55:47 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 20 Sep 2001 13:55:47 -0700 Received: from franky (D5E05886.kabel.telenet.be [213.224.88.134]) by tartarus.telenet-ops.be (Postfix) with SMTP id B4D532173E7 for ; Thu, 20 Sep 2001 22:54:51 +0200 (CEST) Date: Thu, 20 Sep 2001 23:03:02 +0200 From: Franky Van Liedekerke To: Subject: Re: MaraDNS 0.8.21 released Message-Id: <20010920230302.1c152ff8.liedekef@pandora.be> In-Reply-To: <20010920080341.A10405@artemas.reachin.com> References: <20010920080341.A10405@artemas.reachin.com> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Sam, maybe, in a last attempt to locate the possible mem leak, you can try using the program "debauch". It doesn't require recompilation except for the fact that, instead of an infinite loop in MaraDNS.c, you need to make it finite for the program to end (I set it to loop 3 times). Then you can ask a recursive request to the nameserver 3 times (started as "debauch ./maradns -f mararc"), and after that, debauch gives you all the mem allocations that weren't cleeared. Ofcourse there are lot of mem allocations resulting from reading the mararc file, and some from filling the cache, but not all of them can be explained by me. May be worth a try? I'll also ask a collegue of mine to help me track down the mem leaks (if he wants :) Franky On Thu, 20 Sep 2001 08:03:41 -0700 aj7kwkp@maradns.org wrote: > > Hello there. > > I would like to thank Ole Tange and Franky for making this release of > MaraDNS possible. Ole, for his invaluable bug reports, and Franky for > pointing out that, for reasons that I am not able to troubleshoot and > resolve down here in Mexico, MaraDNS is broken on Solaris (it leaks memory > like a sieve). > > The bad news: > > There is a known issue with MaraDNS having memory leaks when used > as a recursive nameserver on the Solaris operating system. This > problem does not exist in Linux. Since I do not have ready access > to a Solaris box to develop on, I can not resolve this issue. Until > a Solaris developer steps up to bat and fixes this for me, I am > forced to disable recursive DNS serving under Solaris. > > I should have ready access to a Solaris again in December, when I > return to the United States. I have CDs of Solaris eight up there, > in addition to friends with Solaris boxes. > > Now, the good news. > > I have updated the example mararc files to be consistant with the > documentation. In particular, I now have two "out of the box" > working mararc files. One for authoritative name serving, and > another for recursive nameserving. > > I have also updated the installer script to return an error if the > directories to put the MaraDNS files in do not exist. In addition, > MaraDNS will install all of the MaraDNS documentation in the > directory specified by the variable DOCS in install.locations. > > Finally, I have updated the FAQ, the man pages, the mararc.format > documentation, and am working on making separate man pages which > describe csv1 zone files and the mararc file. (2001.09.20) > > And, of course, cryptographic sums in every format imaginable: > > BSD = 34929 180 > SYSV = 60495 359 > CRC = 110958817 183740 > MD5 = 725baacd0221ba88065c4823136c59f3 > SHA1 = a96d8453453c55abff9f84ab65fda7a16507665d > SHA-256 = e86e8b7b4f8ae06cb68a7f0dd9a128db4531dec4c51b004649f50a1d9c4bf1ad > SHA-384 = > e9c6a1ec06912c921e08f8e190d31d4ed0c1e68cb21c9385fa334db6de13676f3b08f328c22c0d0908adec9b2ec3eec2 > SHA-512 = > 7b007e47c4f1dce65380d788f791f9eab447789e41f18794e5540918d377d6e1aff1f6841d17ae9bdffb2e406a0ddc97ac55fb4d20ed4fe19945d5b0bf6007e9 > Wrlpool = > abfdcda0d0fc61c75e635022f053137d5539dbfc4813029ee404bbcd90663968105caf481a9b1c2427d942fb48d7c8a23ee36e43a95697b0652813eed4e01fe8 > HAVAL5 = 5ff4b8929a837d9cf6013a4796892318a52b77b317835210775fa733ea0cdf9d > Tiger = 95b73831b70a4dfbe9cce538cda2139a26719f682eb1427f > RMD128 = 48085d2bcb1b4fd63e134f90c5aec69f > RMD160 = a7a0152f87656d69d8fa7c6c4a7075bfd110776d > AES128a = e53a988b07bab4967d7efa57d625be10 > AES160 = 9679e7a60e00662f66eda6efdb535a05bffacce6 > AES192 = 41d8294508ae6706207168f2ce13f0ae7d112e40a2274a99 > AES224 = fffeb2ec41059aae0e23504ccb850c8c7681fa08920a9d306fb475b5 > AES256 = a8799a431d66193ee14b439c98d72c6bb90eef838ea875859be986698a9bb4ac > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12675 invoked by uid 1108); 20 Sep 2001 14:40:00 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 20 Sep 2001 14:40:00 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.21 released Message-ID: <20010920144000.A12664@artemas.reachin.com> References: <20010920080341.A10405@artemas.reachin.com> <20010920230302.1c152ff8.liedekef@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010920230302.1c152ff8.liedekef@pandora.be>; from liedekef@pandora.be on Thu, Sep 20, 2001 at 11:03:02PM +0200 On Thu, Sep 20, 2001 at 11:03:02PM +0200, Franky Van Liedekerke wrote: > > Hi Sam, [and nothing more] Hi Franky! :-) - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12831 invoked from network); 20 Sep 2001 14:52:31 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 20 Sep 2001 14:52:31 -0700 Received: from franky (D5E05886.kabel.telenet.be [213.224.88.134]) by pop3.telenet-ops.be (Postfix) with SMTP id BB5599BB30 for ; Thu, 20 Sep 2001 23:52:31 +0200 (CEST) Date: Fri, 21 Sep 2001 00:00:42 +0200 From: Franky Van Liedekerke To: Subject: Re: MaraDNS 0.8.21 released Message-Id: <20010921000042.0305d464.liedekef@pandora.be> In-Reply-To: <20010920144000.A12664@artemas.reachin.com> References: <20010920080341.A10405@artemas.reachin.com> <20010920230302.1c152ff8.liedekef@pandora.be> <20010920144000.A12664@artemas.reachin.com> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 20 Sep 2001 14:40:00 -0700 aj7kwkp@maradns.org wrote: > [and nothing more] > > Hi Franky! > > :-) > > - Sam Hmmm ... sarcastic, aren't we ;-) From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 12898 invoked by uid 1108); 20 Sep 2001 14:55:58 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 20 Sep 2001 14:55:58 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.21 released Message-ID: <20010920145558.A12880@artemas.reachin.com> References: <20010920080341.A10405@artemas.reachin.com> <20010920230302.1c152ff8.liedekef@pandora.be> <20010920144000.A12664@artemas.reachin.com> <20010921000042.0305d464.liedekef@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010921000042.0305d464.liedekef@pandora.be>; from liedekef@pandora.be on Fri, Sep 21, 2001 at 12:00:42AM +0200 > Hmmm ... sarcastic, aren't we ;-) It's my sense of humor. For better or for worse. Another aspect of my sense of humor is to tell my roomate that Osama Bin Laden is her boyfriend while she was reading an article about him out loud in Spanish the other night. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13522 invoked from network); 20 Sep 2001 16:13:40 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 20 Sep 2001 16:13:40 -0700 Received: by home.tange.dk (Postfix, from userid 501) id C815217925; Fri, 21 Sep 2001 01:13:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id C4A3E16947 for ; Fri, 21 Sep 2001 01:13:46 +0200 (CEST) Date: Fri, 21 Sep 2001 01:13:46 +0200 (CEST) From: Ole Tange To: Subject: BUG: make install Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Version: MaraDNS 0.8.21 # make install gives cp: cannot create regular file `/usr/local/sbin/maradns': text file busy This is because /usr/local/sbin/maradns is already running. If you run rm /usr/local/sbin/maradns before the copy, then this does not happen. /Ole From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13610 invoked from network); 20 Sep 2001 16:28:25 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 20 Sep 2001 16:28:25 -0700 Received: by home.tange.dk (Postfix, from userid 501) id 77D9117927; Fri, 21 Sep 2001 01:28:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id 626B317926 for ; Fri, 21 Sep 2001 01:28:31 +0200 (CEST) Date: Fri, 21 Sep 2001 01:28:31 +0200 (CEST) From: Ole Tange To: Subject: Feature: --version Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Version: MaraDNS 0.8.21 # /usr/local/sbin/maradns --version Fatal error: Usage: mararc [-f mararc_location] For making bug reports --version is a very nice option. If you are smart you include compile flags etc. that can help debugging, so reporters will not have to dig up more informations (uname etc.) /Ole From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 18512 invoked from network); 21 Sep 2001 14:37:23 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 21 Sep 2001 14:37:23 -0700 Received: by home.tange.dk (Postfix, from userid 501) id D9FE2179EE; Sat, 22 Sep 2001 01:37:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id D09B4179E9 for ; Sat, 22 Sep 2001 01:37:16 +0200 (CEST) Date: Sat, 22 Sep 2001 01:37:16 +0200 (CEST) From: Ole Tange To: Subject: Feature: init.d-script Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Here is first version of an init.d-script for maradns. It is neither perfect nor complete, but itworksforme. /Ole #!/bin/bash # # maradns This shell script takes care of starting and stopping # maradns (MaraDNS server). # # chkconfig: 345 55 45 # description: maradns is a Domain Name Server (DNS) # that is used to resolve host names to IP addresses. # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ "${NETWORKING}" = "no" ] && exit 0 [ -f /etc/sysconfig/maradns ] && . /etc/sysconfig/maradns [ -f /usr/local/sbin/maradns ] || exit 0 [ -f /etc/mararc ] || exit 0 RETVAL=0 prog="maradns" start() { # Start daemons. echo -n $"Starting $prog: " /usr/local/sbin/maradns ${OPTIONS} & RETVAL=$? [ $RETVAL -eq 0 ] && touch /var/lock/subsys/maradns echo return $RETVAL } stop() { # Stop daemons. echo -n $"Stopping $prog: " killproc maradns RETVAL=$? [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/maradns echo return $RETVAL } restart() { stop start } reload() { restart return $? } probe() { restart return $? } # See how we were called. case "$1" in start) start ;; stop) stop ;; status) rhstatus ;; restart) restart ;; condrestart) [ -f /var/lock/subsys/maradns ] && restart ;; reload) reload ;; probe) probe ;; *) echo $"Usage: $0 {start|stop|status|restart|condrestart|reload|probe}" exit 1 esac exit $? From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 18892 invoked from network); 21 Sep 2001 16:09:34 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 21 Sep 2001 16:09:34 -0700 Received: by home.tange.dk (Postfix, from userid 501) id EE912179F2; Sat, 22 Sep 2001 03:09:28 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id E4F5E179F1 for ; Sat, 22 Sep 2001 03:09:28 +0200 (CEST) Date: Sat, 22 Sep 2001 03:09:28 +0200 (CEST) From: Ole Tange To: Subject: Bugreport: recursive CNAME Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII It seems CNAME for CNAME does not work when a recursive query is run. ole.tange.dk is an alias for www.tange.dk. www.tange.dk is an alias for ns.pi.dk. ns.pi.dk has address 207.126.112.254 $ host ole.tange.dk localhost (running maradns - auth for tange.dk) Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: ole.tange.dk is an alias for www.tange.dk. $ host ole.tange.dk ns2.pi.dk (running bind - auth for tange.dk) Using domain server: Name: ns2.pi.dk Address: 212.91.134.190#53 Aliases: ole.tange.dk is an alias for www.tange.dk. www.tange.dk is an alias for ns.pi.dk. ns.pi.dk has address 207.126.112.254 So MaraDNS does not return an IP-address. This makes e.g. Lynx fail. /Ole From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 19009 invoked from network); 21 Sep 2001 16:52:43 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 21 Sep 2001 16:52:43 -0700 Received: by home.tange.dk (Postfix, from userid 501) id 82A98179F1; Sat, 22 Sep 2001 03:52:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id 779B3179EE for ; Sat, 22 Sep 2001 03:52:38 +0200 (CEST) Date: Sat, 22 Sep 2001 03:52:38 +0200 (CEST) From: Ole Tange To: Subject: Feature: Server-side indirection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On http://cr.yp.to/djbdns/killa6.html Dan Bernstein mentions Server-side indirection. I find CNAMEs nice, but not quite good enough. It would be nice to have CNAME split into CNAME-A, CNAME-MX, CNAME-whatever, so instead of inheriting all RRs from a certain name you can inherit specific properties. By using Server-side indirection this can be done without sacrificing neither compatibility with other name servers nor reliability. /Ole From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 20409 invoked from network); 22 Sep 2001 03:15:38 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 22 Sep 2001 03:15:38 -0700 Received: from franky (D5E0A38F.kabel.telenet.be [213.224.163.143]) by pop3.telenet-ops.be (Postfix) with SMTP id D0CA89BB36 for ; Sat, 22 Sep 2001 12:15:38 +0200 (CEST) Date: Sat, 22 Sep 2001 12:23:51 +0200 From: Franky Van Liedekerke To: Subject: Re: Feature: init.d-script Message-Id: <20010922122351.708da28b.liedekef@pandora.be> In-Reply-To: References: X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit once signal handling is incorporated, a reload will probably be a hup, but for now, it's a nice script. Ofcourse, it's not solaris material :) On Sat, 22 Sep 2001 01:37:16 +0200 (CEST) Ole Tange wrote: > Here is first version of an init.d-script for maradns. It is neither > perfect nor complete, but itworksforme. > > > /Ole > > #!/bin/bash > # > # maradns This shell script takes care of starting and stopping > # maradns (MaraDNS server). > # > # chkconfig: 345 55 45 > # description: maradns is a Domain Name Server (DNS) > # that is used to resolve host names to IP addresses. > > # Source function library. > . /etc/rc.d/init.d/functions > > # Source networking configuration. > . /etc/sysconfig/network > > # Check that networking is up. > [ "${NETWORKING}" = "no" ] && exit 0 > > [ -f /etc/sysconfig/maradns ] && . /etc/sysconfig/maradns > > [ -f /usr/local/sbin/maradns ] || exit 0 > > [ -f /etc/mararc ] || exit 0 > > RETVAL=0 > prog="maradns" > > start() { > # Start daemons. > echo -n $"Starting $prog: " > /usr/local/sbin/maradns ${OPTIONS} & > RETVAL=$? > [ $RETVAL -eq 0 ] && touch /var/lock/subsys/maradns > echo > return $RETVAL > } > stop() { > # Stop daemons. > echo -n $"Stopping $prog: " > killproc maradns > RETVAL=$? > [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/maradns > echo > return $RETVAL > } > restart() { > stop > start > } > reload() { > restart > return $? > } > probe() { > restart > return $? > } > > # See how we were called. > case "$1" in > start) > start > ;; > stop) > stop > ;; > status) > rhstatus > ;; > restart) > restart > ;; > condrestart) > [ -f /var/lock/subsys/maradns ] && restart > ;; > reload) > reload > ;; > probe) > probe > ;; > *) > echo $"Usage: $0 {start|stop|status|restart|condrestart|reload|probe}" > exit 1 > esac > > exit $? > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 20455 invoked from network); 22 Sep 2001 03:16:08 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 22 Sep 2001 03:16:08 -0700 Received: from franky (D5E0A38F.kabel.telenet.be [213.224.163.143]) by tartarus.telenet-ops.be (Postfix) with SMTP id C2029217B03 for ; Sat, 22 Sep 2001 12:16:08 +0200 (CEST) Date: Sat, 22 Sep 2001 12:24:21 +0200 From: Franky Van Liedekerke To: Subject: Re: Bugreport: recursive CNAME Message-Id: <20010922122421.0b34aeab.liedekef@pandora.be> In-Reply-To: References: X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit confirmed: I tested it as well On Sat, 22 Sep 2001 03:09:28 +0200 (CEST) Ole Tange wrote: > It seems CNAME for CNAME does not work when a recursive query is run. > > ole.tange.dk is an alias for www.tange.dk. > www.tange.dk is an alias for ns.pi.dk. > ns.pi.dk has address 207.126.112.254 > > $ host ole.tange.dk localhost (running maradns - auth for tange.dk) > Using domain server: > Name: localhost > Address: 127.0.0.1#53 > Aliases: > > ole.tange.dk is an alias for www.tange.dk. > > $ host ole.tange.dk ns2.pi.dk (running bind - auth for tange.dk) > Using domain server: > Name: ns2.pi.dk > Address: 212.91.134.190#53 > Aliases: > > ole.tange.dk is an alias for www.tange.dk. > www.tange.dk is an alias for ns.pi.dk. > ns.pi.dk has address 207.126.112.254 > > > So MaraDNS does not return an IP-address. This makes e.g. Lynx fail. > > /Ole > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 6642 invoked by uid 1108); 24 Sep 2001 08:08:26 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 24 Sep 2001 08:08:26 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.22 released Message-ID: <20010924080826.A6603@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i MaraDNS 0.8.22 released. This integrates some bug fixes based on the bug reports I had Friday afternoon before going home and, theirfore, losing internet access. From the changelog: Document reorganization: I am starting to move the formats of the data files to separate man pages. This will make each man page smaller and more convenient to use. Improved CNAME support: MaraDNS now has partial support for star records that point to a CNAME. Less code in the aes directory: I now have a program which generates the AES tables during the build process, since the code to generate those tables is a good deal smaller than the tables themselves. There is no slowdown, since it is a one-time calculation done during the build process. maradns --version (and zoneserver --version) now do the right thing: Print out the version number and exit The installer now removes the zoneserver and the maradns server before installing the new ones to get around the "text file busy" problem. There was a subtle bug with returning "not there" SOA replies and case insensitivity. This bug has now been fixed. This bugfix also needs to be folded back in to the 0.5.xx branch. It is now possible to change the class of the query with the getzone client if possible. Next: Document this new feature. Sums: BSD = 10583 184 SYSV = 59410 368 CRC = 3360763812 187959 MD5 = ca64c0260d1ad331d198edc8554e29ac SHA1 = ca4ba9d5aa849b7b7144969893cb8a30aaf409b3 SHA-256 = 62df81c7a34082d7007faa49eaf2898594e0af9713b53d55ff3fa60a26c3fd9c SHA-384 = bf6722eb4225c56eb69be2b960b66e95f299f7001b4cfb8f78c561b360e205e7c892ecc26bae16568b2ed528d35f0167 SHA-512 = 635dc928b6252826ce18164bcc5ff116a7939cc69b36ecd136f2fb689b5d38630a6dc94ec6d9259fa77113edafcc08c0e69d91ba54530bcc5a244c4c62c7db55 Wrlpool = 8a3d140fd32f1be4046a905a2745f8de4bc201ab6f85577f4e9a8004970b0f9c3dc133782b89c49a6f875b50f8e2743401be5515b1d7861bf44040c0953b3ea6 HAVAL5 = 474acb0d60d309a8fd4d5293c5ec3f64753bd87d51ab7b507fad4f996dec6615 Tiger = f8465a6bfada30c19502e7262c36bac845c3ba72163e14ca RMD128 = ff83379e65b29b8b205530682380626d RMD160 = ea91f42aaf6bb1c9d003e1a56657cc44c1a05e6a AES128a = b500ccdd916a739b42fb354216cfc977 AES160 = 4272e260793e3e5b99238a1b9ad9b5185f9b5068 AES192 = 225b6524b2bd401e6195ec2374db8ca7f39a2c828c5fe8e2 AES224 = fae99f2daab9b5464a1ee96ef7c474b1bc80dfe7ac5b99388fa59396 AES256 = 9a543806a40705ebca772c82b0e05f2c024ed5994789da3ef174f5208974667c - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 6854 invoked from network); 24 Sep 2001 09:06:41 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 24 Sep 2001 09:06:41 -0700 Received: by home.tange.dk (Postfix, from userid 501) id 4598B17E27; Mon, 24 Sep 2001 18:06:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id 39CCD17924 for ; Mon, 24 Sep 2001 18:06:41 +0200 (CEST) Date: Mon, 24 Sep 2001 18:06:41 +0200 (CEST) From: Ole Tange To: Subject: BUG: make install & CNAME Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII $ maradns --version This is MaraDNS version 0.8.22 For usage information, 'man maradns' $ make install ./install.sh The directory /usr/local/man/man5/ does not exist. Please edit the file install.locations by hand. make: *** [install] Error 7 Create the dir before. mkdir -p /usr/local/man/man5/ 2>/dev/null It seems the CNAME fix does not work. From: db.tange.dk Cole.tange.dk.|86400|www.tange.dk. C*.tange.dk.|86400|ns.pi.dk. But: # host ole.tange.dk localhost Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: ole.tange.dk is an alias for www.tange.dk. /Ole From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7141 invoked by uid 1108); 24 Sep 2001 09:45:23 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 24 Sep 2001 09:45:23 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: BUG: make install & CNAME Message-ID: <20010924094523.A7100@artemas.reachin.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from tange@tange.dk on Mon, Sep 24, 2001 at 06:06:41PM +0200 > $ make install > ./install.sh > The directory /usr/local/man/man5/ does not exist. Please edit the file > install.locations by hand. > make: *** [install] Error 7 > > Create the dir before. > mkdir -p /usr/local/man/man5/ 2>/dev/null I think is a better idea to have some form of automagic "if this directory doesn't exist, try this directory" in the "configure" script. What is the directory for man pages when the program is not part of a RPM on Mandrake? Is the directory /usr/local/share/man/manX, where X is the manual section? - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 7189 invoked from network); 24 Sep 2001 09:45:28 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 24 Sep 2001 09:45:28 -0700 Received: (qmail 29603 invoked from network); 24 Sep 2001 16:45:26 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 24 Sep 2001 16:45:26 -0000 Date: Mon, 24 Sep 2001 18:45:26 +0200 (CEST) From: X-X-Sender: To: Subject: Re: MaraDNS 0.8.22 released In-Reply-To: <20010924080826.A6603@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Sam, it's me again :) haven't found the mem leak yet, but I think I pinned it down: each thread seems to alocate 36 bytes which are never freed again. Now I'm going to asume the solaris posix thread libs are leakfree (anybody against this?) so there must be somewhere an allocation of 36 bytes which never gets freed. Any idea which data structure is 36 bytes large? I'm using dmalloc to find the leak, and this is what I've found so far :) Here's the dmalloc output for 1 recursive query: 1001347454: 1273: dblock entry for 32 bytes found on free list 1001347454: 1273: *** alloc: at 'ra=0x1d38c' for 24 bytes, got '0x92b60|s5' 1001347454: 1274: dblock entry for 512 bytes found on free list 1001347454: 1274: *** alloc: at 'ra=0x1d38c' for 259 bytes, got '0xa3200|s5' 1001347454: 1275: dblock entry for 32 bytes found on free list 1001347454: 1275: *** alloc: at 'ra=0x1d38c' for 24 bytes, got '0x92f60|s1' 1001347454: 1276: dblock entry for 512 bytes found on free list 1001347454: 1276: *** alloc: at 'ra=0x1d38c' for 259 bytes, got '0xa2c00|s57' 1001347454: 1277: dblock entry for 32 bytes found on free list 1001347454: 1277: *** alloc: at 'ra=0x1d38c' for 24 bytes, got '0x92f80|s1' 1001347454: 1278: dblock entry for 512 bytes found on free list 1001347454: 1278: *** alloc: at 'ra=0x1d38c' for 259 bytes, got '0xa3000|s5' 1001347454: 1279: need to create a dblock for 128x 64 byte blocks 1001347454: 1279: need 128 dblock-admin slots 1001347454: 1279: need 1 bblocks (8192 bytes) 1001347454: 1279: extending heap space by 8192 bytes 1001347454: 1279: *** alloc: at 'ra=0xff24417c' for 36 bytes, got '0xaa000|s1' 1001347454: 1280: dblock entry for 32 bytes found on free list 1001347454: 1280: *** alloc: at 'ra=0x1d38c' for 28 bytes, got '0x92fa0|s1' 1001347454: 1281: dblock entry for 32 bytes found on free list 1001347454: 1281: *** alloc: at 'ra=0x1d38c' for 24 bytes, got '0x92fc0|s1' 1001347454: 1282: dblock entry for 32 bytes found on free list 1001347454: 1282: *** alloc: at 'ra=0x1d38c' for 25 bytes, got '0x92fe0|s1' Now, as you can see, most calls to alloc are done from 0x1d38c, which corresponds to the js_alloc function (gdb tells me :) But one call seems to come from 0xff24417c, which comes from within a thread call (using /usr/proc/bin/pmap I can see this is), but I don't know exactly why or when (it's always the seventh mem alloc for a recursive thread though). Aaarrggh.... somebody with real debug skills should show me how to do this... Franky On Mon, 24 Sep 2001 aj7kwkp@maradns.org wrote: > > MaraDNS 0.8.22 released. > > This integrates some bug fixes based on the bug reports I had Friday > afternoon before going home and, theirfore, losing internet access. > > From the changelog: > > Document reorganization: I am starting to move the formats of the data > files to separate man pages. This will make each man page smaller and more > convenient to use. Improved CNAME support: MaraDNS now has partial > support for star records that point to a CNAME. > > Less code in the aes directory: I now have a program which generates the > AES tables during the build process, since the code to generate those > tables is a good deal smaller than the tables themselves. There is no > slowdown, since it is a one-time calculation done during the build > process. > > maradns --version (and zoneserver --version) now do the right thing: Print > out the version number and exit > > The installer now removes the zoneserver and the maradns server before > installing the new ones to get around the "text file busy" problem. > > There was a subtle bug with returning "not there" SOA replies and case > insensitivity. This bug has now been fixed. This bugfix also needs to be > folded back in to the 0.5.xx branch. > > It is now possible to change the class of the query with the getzone > client if possible. Next: Document this new feature. > > Sums: > > BSD = 10583 184 > SYSV = 59410 368 > CRC = 3360763812 187959 > MD5 = ca64c0260d1ad331d198edc8554e29ac > SHA1 = ca4ba9d5aa849b7b7144969893cb8a30aaf409b3 > SHA-256 = 62df81c7a34082d7007faa49eaf2898594e0af9713b53d55ff3fa60a26c3fd9c > SHA-384 = bf6722eb4225c56eb69be2b960b66e95f299f7001b4cfb8f78c561b360e205e7c892ecc26bae16568b2ed528d35f0167 > SHA-512 = 635dc928b6252826ce18164bcc5ff116a7939cc69b36ecd136f2fb689b5d38630a6dc94ec6d9259fa77113edafcc08c0e69d91ba54530bcc5a244c4c62c7db55 > Wrlpool = 8a3d140fd32f1be4046a905a2745f8de4bc201ab6f85577f4e9a8004970b0f9c3dc133782b89c49a6f875b50f8e2743401be5515b1d7861bf44040c0953b3ea6 > HAVAL5 = 474acb0d60d309a8fd4d5293c5ec3f64753bd87d51ab7b507fad4f996dec6615 > Tiger = f8465a6bfada30c19502e7262c36bac845c3ba72163e14ca > RMD128 = ff83379e65b29b8b205530682380626d > RMD160 = ea91f42aaf6bb1c9d003e1a56657cc44c1a05e6a > AES128a = b500ccdd916a739b42fb354216cfc977 > AES160 = 4272e260793e3e5b99238a1b9ad9b5185f9b5068 > AES192 = 225b6524b2bd401e6195ec2374db8ca7f39a2c828c5fe8e2 > AES224 = fae99f2daab9b5464a1ee96ef7c474b1bc80dfe7ac5b99388fa59396 > AES256 = 9a543806a40705ebca772c82b0e05f2c024ed5994789da3ef174f5208974667c > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 8370 invoked from network); 24 Sep 2001 13:54:21 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 24 Sep 2001 13:54:21 -0700 Received: by home.tange.dk (Postfix, from userid 501) id 244C617E2A; Mon, 24 Sep 2001 22:54:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id 208DD17DC2 for ; Mon, 24 Sep 2001 22:54:22 +0200 (CEST) Date: Mon, 24 Sep 2001 22:54:22 +0200 (CEST) From: Ole Tange To: Subject: Re: BUG: make install & CNAME In-Reply-To: <20010924094523.A7100@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 24 Sep 2001 aj7kwkp@maradns.org wrote: > > $ make install > > ./install.sh > > The directory /usr/local/man/man5/ does not exist. Please edit the file > > install.locations by hand. > > make: *** [install] Error 7 > > > > Create the dir before. > > mkdir -p /usr/local/man/man5/ 2>/dev/null > > I think is a better idea to have some form of automagic "if this directory > doesn't exist, try this directory" in the "configure" script. > > What is the directory for man pages when the program is not part of a RPM > on Mandrake? Is the directory /usr/local/share/man/manX, where X is the > manual section? Yep: On Mandrake 8.1b /usr/local/share/man/man[1-9n] exists. (Jeez why can't Mandrake just adhere to FHS 2.2? Sec. 4.11.5.2: Manual pages for commands and data under /usr/local are stored in /usr/local/man) /Ole From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 8710 invoked by uid 1108); 24 Sep 2001 15:41:38 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 24 Sep 2001 15:41:38 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.22 released Message-ID: <20010924154138.A8696@artemas.reachin.com> References: <20010924080826.A6603@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from liedekef@pandora.be on Mon, Sep 24, 2001 at 06:45:26PM +0200 Franky, Thanks a lot for the report! The magic number is 36, and I will bet you that I am doing something _wrong_ in MaraDNS that, for whatever reason, the thread library in LInux can automagically clean up. - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 8803 invoked from network); 24 Sep 2001 15:58:25 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 24 Sep 2001 15:58:25 -0700 Received: from D5E0A35E.kabel.telenet.be (D5E0F962.kabel.telenet.be [213.224.249.98]) by tartarus.telenet-ops.be (Postfix) with SMTP id B29EB217284 for ; Tue, 25 Sep 2001 00:58:26 +0200 (CEST) Date: Tue, 25 Sep 2001 01:01:47 +0200 From: Franky Van Liedekerke To: Subject: Re: MaraDNS 0.8.22 released Message-Id: <20010925010147.422dbe77.liedekef@pandora.be> In-Reply-To: <20010924154138.A8696@artemas.reachin.com> References: <20010924080826.A6603@artemas.reachin.com> <20010924154138.A8696@artemas.reachin.com> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.9; i586-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit so you actually can give a meaning to my report? Or can't I just get the magic in the number 36? On Mon, 24 Sep 2001 15:41:38 -0700 aj7kwkp@maradns.org wrote: > > Franky, > > Thanks a lot for the report! > > The magic number is 36, and I will bet you that I am doing something > _wrong_ in MaraDNS that, for whatever reason, the thread library in LInux > can automagically clean up. > > - Sam > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 8930 invoked by uid 1108); 24 Sep 2001 16:18:33 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 24 Sep 2001 16:18:33 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: MaraDNS 0.8.22 released Message-ID: <20010924161833.A8909@artemas.reachin.com> References: <20010924080826.A6603@artemas.reachin.com> <20010924154138.A8696@artemas.reachin.com> <20010925010147.422dbe77.liedekef@pandora.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010925010147.422dbe77.liedekef@pandora.be>; from liedekef@pandora.be on Tue, Sep 25, 2001 at 01:01:47AM +0200 Sorry, I was using an uncommon idiom in the English language. The significance of the idiom "the magic number is XX" in the context of solving a puzzle is that I need to search and find that number to fix this problem. And, yes, I have some understanding of how difficult it is to learn a foreign language, since I am struggling with Spanish myself. - Sam > so you actually can give a meaning to my report? Or can't I just get the magic in the number 36? > > On Mon, 24 Sep 2001 15:41:38 -0700 > aj7kwkp@maradns.org wrote: > > > > > Franky, > > > > Thanks a lot for the report! > > > > The magic number is 36, and I will bet you that I am doing something > > _wrong_ in MaraDNS that, for whatever reason, the thread library in LInux > > can automagically clean up. > > > > - Sam > > > > -- > > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > > > > > Please be aware that anything posted to this list is publically archived. > > > > To unsubscribe to this list, send a blank message to > > list-unsubscribe@maradns.org > > > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 8981 invoked from network); 24 Sep 2001 16:18:54 -0700 Received: from unknown (HELO tartarus.telenet-ops.be) (195.130.132.34) by artemas.reachin.com with SMTP; 24 Sep 2001 16:18:54 -0700 Received: from pop1.pandora.be (eros.telenet-ops.be [195.130.132.42]) by tartarus.telenet-ops.be (Postfix) with SMTP id 982012171FE for ; Tue, 25 Sep 2001 01:18:53 +0200 (CEST) Received: (qmail 5482 invoked by uid 1016); 24 Sep 2001 23:18:53 -0000 Date: Tue, 25 Sep 2001 01:18:53 +0200 From: Christophe Colle To: list@maradns.org Subject: FAQ -- I am using MaraDNS on Solaris, and memory seems to be leaking Message-ID: <20010925011853.E31147@eros.telenet-ops.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hi, I looked for this issue and found that you have an issue with your threads and attributes... When you call pthread_attr_init(&attr); then you must also call a pthread_attr_destroy(&attr); ... So if you add in recursive.c on line 2071 pthread_attr_destroy(&attr); you will see that you fixed this memory leak... Off course, this is a quick and dirty hack/patch, but you must pay a closer look to this routine, because memory is allocated in this routine, but sometimes never freed (a lot of return JS_ERROR before the thread is created...). I guess the best thing to do in the longer run, is to create one instance of the attr, and to never destroy it... Put it in a initialization routine or so.... These are just hints, but I leave the final solution to the Sam, coder of MaraDNS, unless he hasn't the time and wants me to look into this matter... Disregarding the special cases, where you return a JS_ERROR, before the patch I had for a few 1000 queries the following number of lost bytes: /usr/lib//libthread.so.1 290576 functions which allocated the memory: _pthread_attr_init 290556 thr_sighndlrinfo 20 Now I have for a few 10k queries: /usr/lib//libthread.so.1 20 functions which allocated the memory: thr_sighndlrinfo 20 --> memory hole closed... A bit more testing has to be performed to look for other lost bytes... Hope this helps ... cc From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 9069 invoked by uid 1108); 24 Sep 2001 16:24:11 -0700 Sender: aj7kwkp@maradns.org Date: Mon, 24 Sep 2001 16:24:11 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: The !@#$ Solaris memory leak Message-ID: <20010924162411.A9048@artemas.reachin.com> References: <20010925011853.E31147@eros.telenet-ops.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010925011853.E31147@eros.telenet-ops.be>; from colle@krtkg1.rug.ac.be on Tue, Sep 25, 2001 at 01:18:53AM +0200 Chris, Thanks a lot for looking at the issue. I will implement your suggestion for the next release of MaraDNS (in addition to paying close attention to all of Ole's important bug reports) so the Solaris crowd can confirm that I am not doing anything brain-dead with threads. It would be nice if Linux was not so tolerant of these kinds of mistakes with threads, since it makes Solaris very difficult and frustrating for me. I _really_ want MaraDNS to work well with Solaris again. - Sam > > Hi, > > I looked for this issue and found that you have an issue with your > threads and attributes... > > When you call pthread_attr_init(&attr); then you must also call a > pthread_attr_destroy(&attr); ... > > > So if you add in recursive.c on line 2071 > pthread_attr_destroy(&attr); > you will see that you fixed this memory leak... > > Off course, this is a quick and dirty hack/patch, but you must pay a > closer look to this routine, because memory is allocated in this > routine, but sometimes never freed (a lot of return JS_ERROR before > the thread is created...). > > I guess the best thing to do in the longer run, is to create one > instance of the attr, and to never destroy it... Put it in a > initialization routine or so.... These are just hints, but I leave the > final solution to the Sam, coder of MaraDNS, unless he hasn't the time > and wants me to look into this matter... > > > Disregarding the special cases, where you return a JS_ERROR, before > the patch I had for a few 1000 queries the following number of lost bytes: > /usr/lib//libthread.so.1 290576 > functions which allocated the memory: > _pthread_attr_init 290556 > thr_sighndlrinfo 20 > > Now I have for a few 10k queries: > /usr/lib//libthread.so.1 20 > functions which allocated the memory: > thr_sighndlrinfo 20 > > --> memory hole closed... > A bit more testing has to be performed to look for other lost bytes... > > > Hope this helps ... > > cc > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13377 invoked by uid 1108); 25 Sep 2001 08:29:52 -0700 Sender: aj7kwkp@maradns.org Date: Tue, 25 Sep 2001 08:29:52 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Legacy branch and cryptographic sum programs updated Message-ID: <20010925082952.A13331@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, While I did nopt get a chance to work on the current branch of MaraDNS, I was able to back port some bug fixes back in to the "legacy" or "stable" 0.5.xx authoritative-only branch of MaraDNS, resulting in a release of MaraDNS 0.5.30 In addition, I received some aes-hash test vectors from the designer of the aes hash, and have hence fixed some problems my implementation of AES had. Therifore, there is a new release of the summer package. Speaking of sums: sums-20010925.tar.bz2: BSD = 53398 163 SYSV = 8960 326 CRC = 3786585044 166877 MD5 = e3fdc07f2ac5c9ddfb364bf2406df0bd SHA1 = e8620f64c0f7db7581fc167651252ad5cb184840 SHA-256 = f4dbd3f01e570f9ff8f9556d31ccc262880d5254e70e2a5f0b8684bb1f3b166a SHA-384 = 75cdf738031f9cc879e99bacd0cda7b38a325e309b00579a25939d3c5d4ce42f6cd9b2 222b8b16f923c2d42aace112aa SHA-512 = f7349ebd631c6432bed974d586112e35094f7a5b07f77469dbe19bbed9002d0de3c8c5 8faecc7bfaf4f7000e4ce2bd95d8c7d860e8d7ce66ce5d7f6c76e5d45e Wrlpool = 11263f4e97bd61044b239242de6149ebba292bb4621a615407ade6e7d124436fdaf71e 601b0a05290610bf548968b5fb74ee9a837f4a38d5808cf4752ec5a2f7 HAVAL5 = b4b1b7fd59f0fdf43684f08a76dd5a1fc8d118c13c615d3ca14add9520f6cf5c Tiger = b510c48fe27787e66e6277412206bfc95d9410d48fd85406 RMD128 = 5e3a769d1d681a9b74b72c85f136fad3 RMD160 = f6877fb0bc6328abf8ab3de52bf1e6dfd0ee779d AES128b = 5ce76a4e223be3b2ec26f0e1d14cdda7 AES160b = 45634f73038f293fbd6efde48cce2d5a39aaaafc AES192b = ab7c04fd44b849027d4cf5b38161448c503f3cdc44fb0762 AES224b = dbce5c8f3b193cd694adcb07e62d5ecaf3ebdd5f396b65a6a187be62 AES256b = d0b7da63d99297e4ec410a0f74cc9de1dd1755302d5c4ca4689027b462a75f1d maradns-0.5.30-1.src.rpm: BSD = 43677 162 SYSV = 1863 324 CRC = 198170261 165478 MD5 = ca9a7bf142d91ca7894d209ac5ad740e SHA-256 = 77f98a14d8227c0f2cb28cafd77328fd0bf572d7d60768a5bff5c5616d719d34 SHA-384 = f05a7d0a7d7a637f89a2812e5d1adeaf864d51409a3346fcfbf43193fbaa60480eb3d5e400ccd9c7c1d86d804fdd2879 SHA-512 = 9de740ebf371a4ec643d0f0e570b5e83f6aadd1e4cd2c381e53f93709be344ff44321ce7e03d202e90ebc46c725c46af4f6f98bc5b215f43b8bdd833b2c068fc Wrlpool = 4b2bb6dbc8a2aa5766fcfbc15955f20c7c7f99a8c53f87fc9ea86613e9c60a57b7b30664741e8e647258592a2fc2922919d87a4b765db739fbe3d6bc9a2d2065 AES128b = 024c95bacdc79c5bbd66462f5e9e2d9f AES160b = 1d7e32faffa20515d362ae134d0fcaace91254f9 AES192b = c5f715f144ba3ef795cd587c9b0daa9fc7678cb872d1b5c1 AES224b = 8f09261cffda2b9c007aad9f44588a13517c6bf51d2bc26ae0e79b31 AES256b = 37356461781295421e8b188700feaaceaa324c06414a4b6b1f889aa8493fb0dd maradns-0.5.30-1.i386.rpm: BSD = 15899 137 SYSV = 8235 274 CRC = 1582659140 139844 MD5 = 83986f87978333d707ca9ca039c32c1c SHA-256 = 0d212dedf1951db437e2b50e93a302da7cc164727e338ac6b77ba884a1023995 SHA-384 = fa4fa76abd8dd2ee0e76e7136ad1c0e279b8ff395b3b6a227cb0aa1cf9d2fdbb1a2793ee496c89e7f8a0d40f1e864ada SHA-512 = cf61ffb7f630fbb8d0201f608055b4133a0fd99feb9b5b0a17e7785ca02a799ea5a73de5f603b803e0311cf91018b38013a240212371115e3a952f53856c83b1 Wrlpool = d9293db612cd06f3e9fa33f31f7b4a2318b337242fabcacf4c70a14b786ce96a3f74ebbfbae5f3df479c3751524e4159a48fd467da6ae305fe98c00c49cf7e25 AES128b = 2075ea094ad73c95e863de9154afe793 AES160b = f1b06363d3e5c329bf00790b20433dc464f43339 AES192b = 711ab97bdd441a4361ee2b82bf82a32518969c3190b1d6a9 AES224b = d2dfbada5db978fb1908592d3081403acef3f89e3e3e6916eca6a0fd AES256b = e955a19795b1be8d77e1afc345b16f872d2fc6aaf6e1227b3407413a6e907d81 - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 13796 invoked from network); 25 Sep 2001 09:18:18 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 25 Sep 2001 09:18:18 -0700 Received: (qmail 32481 invoked from network); 25 Sep 2001 16:18:19 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 25 Sep 2001 16:18:19 -0000 Date: Tue, 25 Sep 2001 18:18:19 +0200 (CEST) From: X-X-Sender: To: Subject: Re: The !@#$ Solaris memory leak In-Reply-To: <20010924162411.A9048@artemas.reachin.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Sam, it's Christophe, not Chris :) (and he's my collegue who helped me already to get it to compile on solaris) Now for the real reason of this mail: a small bug report: I'm already trying to resolve a number of addresses using maradns. Now I found (at least) one that doesn't seem to be working: mistermail.nl Using bind: > mistermail.nl. Server: bia.telenet-ops.be Address: 195.130.132.18 Non-authoritative answer: Name: mistermail.nl Address: 212.54.36.38 Using maradns: > mistermail.nl. Server: localhost Address: 127.0.0.1 *** localhost can't find mistermail.nl.: No response from server Weird uh? Just to let you know, it's version 0.8.20, might be fixed in newer release... On Mon, 24 Sep 2001 aj7kwkp@maradns.org wrote: > > Chris, > > Thanks a lot for looking at the issue. I will implement your suggestion > for the next release of MaraDNS (in addition to paying close attention to > all of Ole's important bug reports) so the Solaris crowd can confirm that > I am not doing anything brain-dead with threads. > > It would be nice if Linux was not so tolerant of these kinds of mistakes > with threads, since it makes Solaris very difficult and frustrating for > me. > > I _really_ want MaraDNS to work well with Solaris again. > > - Sam > > > > > Hi, > > > > I looked for this issue and found that you have an issue with your > > threads and attributes... > > > > When you call pthread_attr_init(&attr); then you must also call a > > pthread_attr_destroy(&attr); ... > > > > > > So if you add in recursive.c on line 2071 > > pthread_attr_destroy(&attr); > > you will see that you fixed this memory leak... > > > > Off course, this is a quick and dirty hack/patch, but you must pay a > > closer look to this routine, because memory is allocated in this > > routine, but sometimes never freed (a lot of return JS_ERROR before > > the thread is created...). > > > > I guess the best thing to do in the longer run, is to create one > > instance of the attr, and to never destroy it... Put it in a > > initialization routine or so.... These are just hints, but I leave the > > final solution to the Sam, coder of MaraDNS, unless he hasn't the time > > and wants me to look into this matter... > > > > > > Disregarding the special cases, where you return a JS_ERROR, before > > the patch I had for a few 1000 queries the following number of lost bytes: > > /usr/lib//libthread.so.1 290576 > > functions which allocated the memory: > > _pthread_attr_init 290556 > > thr_sighndlrinfo 20 > > > > Now I have for a few 10k queries: > > /usr/lib//libthread.so.1 20 > > functions which allocated the memory: > > thr_sighndlrinfo 20 > > > > --> memory hole closed... > > A bit more testing has to be performed to look for other lost bytes... > > > > > > Hope this helps ... > > > > cc > > > > > > Please be aware that anything posted to this list is publically archived. > > > > To unsubscribe to this list, send a blank message to > > list-unsubscribe@maradns.org > > > > -- > "Reality is the most perfect vision of God's will" -- Orson Scott Card > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 14281 invoked from network); 25 Sep 2001 10:15:02 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 25 Sep 2001 10:15:02 -0700 Received: by home.tange.dk (Postfix, from userid 501) id 0763018752; Tue, 25 Sep 2001 19:15:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id F086D17E2A for ; Tue, 25 Sep 2001 19:15:00 +0200 (CEST) Date: Tue, 25 Sep 2001 19:15:00 +0200 (CEST) From: Ole Tange To: Subject: Re: The !@#$ Solaris memory leak In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 25 Sep 2001 liedekef@pandora.be wrote: > Now for the real reason of this mail: a small bug report: I'm already > trying to resolve a number of addresses using maradns. Now I found (at > least) one that doesn't seem to be working: mistermail.nl > > Using bind: > > mistermail.nl. > Server: bia.telenet-ops.be > Address: 195.130.132.18 > > Non-authoritative answer: > Name: mistermail.nl > Address: 212.54.36.38 > > Using maradns: > > mistermail.nl. > Server: localhost > Address: 127.0.0.1 > > *** localhost can't find mistermail.nl.: No response from server Not confirmed. $ uname -a Linux tigger.tange.dk 2.4.8-19mdksmp #1 SMP Wed Sep 5 15:40:18 CEST 2001 i686 unknown $ maradns --version This is MaraDNS version 0.8.22 For usage information, 'man maradns' (Since there are problems with Solaris, maybe --version should give architechture as well). $ host mistermail.nl localhost Using domain server: Name: localhost Address: 127.0.0.1#53 Aliases: mistermail.nl has address 212.54.36.38 $ host mistermail.nl ns2.pi.dk (BIND) Using domain server: Name: ns2.pi.dk Address: 212.91.134.190#53 Aliases: mistermail.nl has address 212.54.36.38 /Ole --=20 F=E5 virksomheder til at tage softwarepatenter alvorligt: V=E6r med i genfors-projektet. http://ole.tange.dk/swpat/aktier.html From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 14761 invoked from network); 25 Sep 2001 11:38:47 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 25 Sep 2001 11:38:47 -0700 Received: from franky (D5E058AB.kabel.telenet.be [213.224.88.171]) by pop3.telenet-ops.be (Postfix) with SMTP id F37439BC54 for ; Tue, 25 Sep 2001 20:38:48 +0200 (CEST) Date: Tue, 25 Sep 2001 20:38:53 +0200 From: Franky Van Liedekerke To: Subject: Re: The !@#$ Solaris memory leak Message-Id: <20010925203853.7277d2ba.liedekef@pandora.be> In-Reply-To: References: X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit hmmm...true, I just tried it at home on maradns-0.8.20 also, it works here... So I tried it at the failing system again (maybe just a temp timeout from their nameserver?) but nope: it didn't work. Stopping and restarting maradns, and it worked. So there's something weird here... The situation was that I tried resolving 3000 different names by maradns, which resulted in this situation. I'll try to get to this situation again, maybe some strange thing? On Tue, 25 Sep 2001 19:15:00 +0200 (CEST) Ole Tange wrote: > On Tue, 25 Sep 2001 liedekef@pandora.be wrote: > > > Now for the real reason of this mail: a small bug report: I'm already > > trying to resolve a number of addresses using maradns. Now I found (at > > least) one that doesn't seem to be working: mistermail.nl > > > > Using bind: > > > mistermail.nl. > > Server: bia.telenet-ops.be > > Address: 195.130.132.18 > > > > Non-authoritative answer: > > Name: mistermail.nl > > Address: 212.54.36.38 > > > > Using maradns: > > > mistermail.nl. > > Server: localhost > > Address: 127.0.0.1 > > > > *** localhost can't find mistermail.nl.: No response from server > > Not confirmed. > > $ uname -a > Linux tigger.tange.dk 2.4.8-19mdksmp #1 SMP Wed Sep 5 15:40:18 CEST 2001 > i686 unknown > > $ maradns --version > This is MaraDNS version 0.8.22 > For usage information, 'man maradns' > > (Since there are problems with Solaris, maybe --version should give > architechture as well). > > $ host mistermail.nl localhost > Using domain server: > Name: localhost > Address: 127.0.0.1#53 > Aliases: > > mistermail.nl has address 212.54.36.38 > > $ host mistermail.nl ns2.pi.dk (BIND) > Using domain server: > Name: ns2.pi.dk > Address: 212.91.134.190#53 > Aliases: > > mistermail.nl has address 212.54.36.38 > > > > /Ole > -- > Få virksomheder til at tage softwarepatenter alvorligt: > Vær med i genfors-projektet. > http://ole.tange.dk/swpat/aktier.html > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 15348 invoked from network); 25 Sep 2001 13:07:00 -0700 Received: from unknown (HELO pop3.telenet-ops.be) (195.130.132.40) by artemas.reachin.com with SMTP; 25 Sep 2001 13:07:00 -0700 Received: from franky (D5E058AB.kabel.telenet.be [213.224.88.171]) by pop3.telenet-ops.be (Postfix) with SMTP id 57FD69BCB4 for ; Tue, 25 Sep 2001 22:06:56 +0200 (CEST) Date: Tue, 25 Sep 2001 22:07:00 +0200 From: Franky Van Liedekerke To: Subject: Re: The !@#$ Solaris memory leak Message-Id: <20010925220700.02842ec3.liedekef@pandora.be> In-Reply-To: <20010925203853.7277d2ba.liedekef@pandora.be> References: <20010925203853.7277d2ba.liedekef@pandora.be> X-Mailer: Sylpheed version 0.6.2 (GTK+ 1.2.8; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit (reminder: tests done on maradns 0.8.20) hmm... I think I found it: maradns seems to have a problem when forward and reverse dns lookup of a NS do not match, eg: ----> nslookup -qt=ns 12move.nl Non-authoritative answer: 12move.nl nameserver = ns2.worldonline.nl 12move.nl nameserver = ns-1.12move.nl 12move.nl nameserver = ns-2.12move.nl 12move.nl nameserver = ns1.worldonline.nl Authoritative answers can be found from: ns2.worldonline.nl internet address = 195.241.49.33 ns-1.12move.nl internet address = 195.241.77.53 ns-2.12move.nl internet address = 195.241.77.54 ns1.worldonline.nl internet address = 195.241.48.33 ----> nslookup ns-1.12move.nl Non-authoritative answer: Name: ns-1.12move.nl Address: 195.241.77.53 ----> nslookup 195.241.77.53 can't find 195.241.77.53: Non-existent host/domain Now bind seems to work fine for this domain, while maradns gives me sometimes a timeout, and other times (after restart) it works. Same goes for eg. absoluteagency.com (works sometimes???): absoluteagency.com nameserver = DKD.DKD.OT.LT absoluteagency.com nameserver = SECOND.DKD.OT.LT Authoritative answers can be found from: DKD.DKD.OT.LT internet address = 194.176.43.98 SECOND.DKD.OT.LT internet address = 194.176.43.99 nslookup 194.176.43.98 gives dkd.dkd.ot.lt (no capitals). Maybe this causes a problem as well? Same goes for APPLE.EASE.LSOFT.COM : /usr/sbin/nslookup ns.LSOFT.COM Non-authoritative answer: Name: ns.LSOFT.COM Address: 194.52.19.2 /usr/sbin/nslookup 194.52.19.2 Name: ns.lsoft.com Address: 194.52.19.2 Could somebody check these (askmara for 12move.nl, absoluteagency.com, APPLE.EASE.LSOFT.COM) ? I did several restarts and sometimes it works, other times it doesn't. Remember: still talking about maradns-0.8.20, so it could be fixed in a later release. Franky On Tue, 25 Sep 2001 20:38:53 +0200 Franky Van Liedekerke wrote: > hmmm...true, I just tried it at home on maradns-0.8.20 also, it works here... > So I tried it at the failing system again (maybe just a temp timeout from their nameserver?) but nope: it didn't work. Stopping and restarting maradns, and it worked. So there's something weird here... > The situation was that I tried resolving 3000 different names by maradns, which resulted in this situation. I'll try to get to this situation again, maybe some strange thing? > > > > On Tue, 25 Sep 2001 19:15:00 +0200 (CEST) > Ole Tange wrote: > > > On Tue, 25 Sep 2001 liedekef@pandora.be wrote: > > > > > Now for the real reason of this mail: a small bug report: I'm already > > > trying to resolve a number of addresses using maradns. Now I found (at > > > least) one that doesn't seem to be working: mistermail.nl > > > > > > Using bind: > > > > mistermail.nl. > > > Server: bia.telenet-ops.be > > > Address: 195.130.132.18 > > > > > > Non-authoritative answer: > > > Name: mistermail.nl > > > Address: 212.54.36.38 > > > > > > Using maradns: > > > > mistermail.nl. > > > Server: localhost > > > Address: 127.0.0.1 > > > > > > *** localhost can't find mistermail.nl.: No response from server > > > > Not confirmed. > > > > $ uname -a > > Linux tigger.tange.dk 2.4.8-19mdksmp #1 SMP Wed Sep 5 15:40:18 CEST 2001 > > i686 unknown > > > > $ maradns --version > > This is MaraDNS version 0.8.22 > > For usage information, 'man maradns' > > > > (Since there are problems with Solaris, maybe --version should give > > architechture as well). > > > > $ host mistermail.nl localhost > > Using domain server: > > Name: localhost > > Address: 127.0.0.1#53 > > Aliases: > > > > mistermail.nl has address 212.54.36.38 > > > > $ host mistermail.nl ns2.pi.dk (BIND) > > Using domain server: > > Name: ns2.pi.dk > > Address: 212.91.134.190#53 > > Aliases: > > > > mistermail.nl has address 212.54.36.38 > > > > > > > > /Ole > > -- > > Få virksomheder til at tage softwarepatenter alvorligt: > > Vær med i genfors-projektet. > > http://ole.tange.dk/swpat/aktier.html > > > > > > Please be aware that anything posted to this list is publically archived. > > > > To unsubscribe to this list, send a blank message to > > list-unsubscribe@maradns.org > > > > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 16603 invoked from network); 25 Sep 2001 17:53:32 -0700 Received: from unknown (HELO home.tange.dk) (213.237.9.215) by artemas.reachin.com with SMTP; 25 Sep 2001 17:53:32 -0700 Received: by home.tange.dk (Postfix, from userid 501) id 456CD18D8D; Wed, 26 Sep 2001 02:53:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by home.tange.dk (Postfix) with ESMTP id 1E3D418D8C for ; Wed, 26 Sep 2001 02:53:23 +0200 (CEST) Date: Wed, 26 Sep 2001 02:53:23 +0200 (CEST) From: Ole Tange To: Subject: Re: Feature: Server-side indirection In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 22 Sep 2001, Ole Tange wrote: > On http://cr.yp.to/djbdns/killa6.html Dan Bernstein mentions Server-side > indirection. > > I find CNAMEs nice, but not quite good enough. It would be nice to have > CNAME split into CNAME-A, CNAME-MX, CNAME-whatever, so instead of > inheriting all RRs from a certain name you can inherit specific > properties. > > By using Server-side indirection this can be done without sacrificing > neither compatibility with other name servers nor reliability. Server side would also be able to solve the problem of: Dotted decimal IP for NS, CNAME, or MX does not work with some DNS servers simply by creating a host on-the-fly called: host-123.45.67.89.this.domain with the appropriate A-record. /Ole From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 17841 invoked from network); 26 Sep 2001 01:53:52 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 26 Sep 2001 01:53:52 -0700 Received: (qmail 7721 invoked from network); 26 Sep 2001 08:53:51 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 26 Sep 2001 08:53:51 -0000 Date: Wed, 26 Sep 2001 10:53:51 +0200 (CEST) From: X-X-Sender: To: Subject: maradns 0.8.22 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi Sam, next to the pthread_attr_destroy in recursive.c, the Makefile.solaris is the same as the one for linux. Here's what should go in there: # Uncomment the following three lines to get this to compile on Solaris LDFLAGS=-lxnet CC=gcc $(LDFLAGS) -DSOLARIS M="CC=$(CC) -DVERSION=$(VERSION)" Also note the "-D" for the version definition, otherwise it doesn't compile. But the VERSION is also redefined in the server/Makefile so that gives an extra warning there. I'm now trying to see if maradns-0.8.22 behaves also as strange as maradns-0.8.20 for the domains I mentioned in my previous mail. If you want to know how I did the test for 3000 domains, let me know so I can send it to you. Franky From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 18071 invoked from network); 26 Sep 2001 03:42:08 -0700 Received: from unknown (HELO smtp1.pandora.be) (195.130.132.33) by artemas.reachin.com with SMTP; 26 Sep 2001 03:42:08 -0700 Received: (qmail 6996 invoked from network); 26 Sep 2001 10:42:08 -0000 Received: from unknown (HELO eros.telenet-ops.be) ([195.130.132.42]) (envelope-sender ) by hercules.telenet-ops.be (qmail-ldap-1.03) with SMTP for ; 26 Sep 2001 10:42:08 -0000 Date: Wed, 26 Sep 2001 12:42:08 +0200 (CEST) From: X-X-Sender: To: cc: Subject: Re: maradns 0.8.22 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2101138812-452840800-1001500928=:15305" ---2101138812-452840800-1001500928=:15305 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, I just did the test again (with 231 hostnames) and the three names I mentioned work one time, and not the other (restarted maradns for the test each time), while bind always seem to resolve them. 12move.nl: works most of the times absoluteagency.com: sometimes resolves APPLE.EASE.LSOFT.COM: never resolves When restarting maradns and asking for eg absoluteagency.com, it works fine. When doing it in the list of more servers, it sometimes works, sometimes doesn't. I attached the file I use for testing (filename: hosts), and the small script I use also (filename: test) and here's how I run it: cat ~/hosts|xargs -I{} /home/user/test {} >~/output.txt The nslookup (in the test script) uses /etc/resolv.conf and points to a bind server. Most of the timeouts in the output.txt file are because askmara has a small timeout, and the second time the name will resolve just fine. But some hostnames (like the three I mentioned) work like said above. I hope somebody can help me with this, or it might be another case-sensitive bug :) Greets, Franky On Wed, 26 Sep 2001 liedekef@pandora.be wrote: > Hi Sam, > > next to the pthread_attr_destroy in recursive.c, the Makefile.solaris is > the same as the one for linux. Here's what should go in there: > > # Uncomment the following three lines to get this to compile on Solaris > LDFLAGS=-lxnet > CC=gcc $(LDFLAGS) -DSOLARIS > M="CC=$(CC) -DVERSION=$(VERSION)" > > Also note the "-D" for the version definition, otherwise it doesn't > compile. But the VERSION is also redefined in the server/Makefile so that > gives an extra warning there. > > I'm now trying to see if maradns-0.8.22 behaves also as strange as > maradns-0.8.20 for the domains I mentioned in my previous mail. If you > want to know how I did the test for 3000 domains, let me know so I can > send it to you. > > Franky > > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org > > ---2101138812-452840800-1001500928=:15305 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=test Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=test ZWNobyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQplY2hvICQx DQp0PWAvaG9tZS9saWVkZWtlZi9tYXJhZG5zLTAuOC4yMC90b29scy9hc2tt YXJhIEEkMS4gMTI3LjAuMC4xYA0KZWNobyAkdA0KdD1gL3Vzci9zYmluL25z bG9va3VwICQxYA0KZWNobyAkdA0KZWNobyA9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQo= ---2101138812-452840800-1001500928=:15305 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=hosts Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=hosts MTIzaGl0LmNvbQ0KMTJtb3ZlLm5sDQoyd2dsb2JhbC5jb20NCjN4bmlrcy5u bA0KNDI1ZHhuLm9yZw0KNGsuYmUNCjV2b29yMTIuY29tDQo2Yy5jb20NCjcy MHBsYW4ub3ZoLm5ldA0KQWFiZW5yYWEtU2hpcHBpbmcuZGsNCkFhbHN0LmJl DQphYmNkLmJlDQphYmMtZ3JvdXAuYmUNCmFiY29uY2VydHMuYmUNCmFiYy10 cmF2ZWwuYmUNCkEtQi1NLmJlDQphYnNvbHV0ZWFnZW5jeS5jb20NCmFidnYu YmUNCkFCWC5CRQ0KYWNhZGVtaWNzZXJ2aWNlLnNkdS5ubA0KYWNhZGVtaWVh bnR3ZXJwZW4udGVsZW5ldC5iZQ0KYWNhZGVteWFuYWx5dGljYXJ0cy5vcmcN CmFjYi1pbnRlcmlldXIuYmUNCmFjY2VudC5iZQ0KYWNjZy5iZQ0KYWMtY2xl cm1vbnQuZnINCmFjY29uc3VsdGluZy5uZXQNCmFjY291bnRlbXBzLmJlDQph Y2N1cmV2LmNvbQ0KYWNjd291dGVycy5iZQ0KYWNnLmJlDQphY21pcy5iZQ0K YWNtaXMucnUNCmFjb20uYmUNCmFjb21vLmNvbQ0KQWN0ZWJpcy5iZQ0KYWN0 ZWwuYmUNCmFjdGl2YWsuYmUNCmFjdW5pYS5jb20NCmFjdi1jc2MuYmUNCmFj dy5hdA0KYWN3ZWJvLmNvbQ0KYWRhbWFzLmJlDQphZGFtcy5uZXQNCmFkYi5i ZQ0KYWRkLmJlDQphZGVjY28uYmUNCmFkZXJhZ3JvdXAuY29tDQphZG1pbi5h bm9ueW1pemVyLmNvbQ0KYWRyaWVubmUubmZyYW5jZS5jb20NCmFkdWx0ZnJp ZW5kZmluZGVyLmNvbQ0KYWR1bHRzaW5nbGVzLmNvbQ0KYWR2YWx2YXMuYmUN CmFkdmFuY2UtYmFuay5kZQ0KYWR2YW5jZW1lLmNvbQ0KYWR2YW50cmEuYmUN CmFkdm9jYWF0LmJlDQphZHZvY2F0ZW4tYXZvY2F0cy5iZQ0KYWR3b3Jrc3B1 Ymxpc2hpbmcubmV0DQphZWdvbi5iZQ0KYWV4cC5jb20NCmFmbG8uYmUNCmFn YWxldi5iZQ0KYWdlbmRhbWVkaWNhLmJlDQphZ2VudC5iZS5saW5lcm5ldC5j b20NCmFnZW50ZGF0YS5jb20NCmFnZi5iZQ0KYWdvcmFtYWlsLm5ldA0KYWdv cmlhLmJlDQpBR1IuS1VMRVVWRU4uQUMuQkUNCmFpcndhaXIuY28udWsNCmFp cy1hbnR3ZXJwLmJlDQphaXNoLmNvbQ0KYWt6b25vYmVsLmNvbQ0KQWxhcm1j b20uYmUNCmFsYmludHJhLmJlDQphbGNhdGVsLmZyDQphbGNvbS5iZQ0KYWxl cnRzLmFuYW5vdmEuY29tDQphbGVydHMuZXF1aXR5YWxlcnQuY29tDQphbGV0 aGVpYS5iZQ0KYWxmYWxhdmFsLmNvbQ0KYS1saW5lLmJlDQphbGtlbi1tYWVz LmNvbQ0KYWwta28uYmUNCmFsbGNvbW0uYmUNCmFsbGRlY28uYmUNCkFsbGVy Z2FuLmNvbQ0KYWxsZ2VpZXIuYmUNCmFsbGlhLmJlDQphbGxwb3N0ZXJzLmNv bQ0KYWxsc2Vhc29ucy5iZQ0KYWxsdGVjaG5pY3MuYmUNCmFsbWFmaW4uYmUN CmFsb2UucHJvcGFnYXRpb24ubmV0DQphbHBoYW5ldC5iZQ0KYWxwaGFybWEu Y29tDQphbHByby5iZQ0KYWx0YWJhZGlhLml0DQphbHRhdmlzdGEubmwNCmFs dC5jb20NCmFsdGVybmF0aXZlcy1lY29ub21pcXVlcy5mcg0KYWx0aGVhLnRh Y28uY29tDQphbHRuLmNvbQ0KYWx4bmV0LmNvbQ0KYW1hbm8uYmUNCmFtYXpp bmctYWR2ZXJ0aXNpbmcuYmUNCmFtYXpvbi5jb20NCmFtYmFzc2FkZS5iZQ0K YW1icm9naW8uaXQNCmFtY2JlbGdpdW0uYmUNCmFtZXJpY2FuZ3JlZXRpbmdz LmNvbQ0KYW1tLmJlDQphbW1jby5iZQ0KYW1wbmV0LmJlDQphbS5wbnUuY29t DQphbXMuYmUNCmFtd2F5LmNvbQ0KYW15bHVtLmNvbQ0KYW5hbGlzLmJlDQph bmRyb21lLmJlDQphLW5vdm8uY29tDQphbnRvbnkuY2VtYWdyZWYuZnINCmFu dHdlcnBlbi5iZQ0KYW50d2VycGVuLmZpcnN0YWR2aXNlcnMuY29tDQphbnZl cnMuZWxpcy5mcg0KQW55d2hlcmVZb3VHby5jb20NCmFvbC5jb20NCmFwY2ku Y29tDQpBUEVNLkJFDQphcGV4LWF1ZGlvLmJlDQphcG9ydC5ydQ0KYXBwYWxs cmVtb3ZlLmJlDQpBUFBMRS5FQVNFLkxTT0ZULkNPTQ0KYXBwbGlmeTMuYXBw bGlmeS5uZXQNCmFwcGxpZnkuY29tDQphcHBsaXRlay5jb20NCmFwcmlsaWFz aG9wLmNvbQ0KYXByaW0uYmUNCmFwcmlzLmRlDQphcHMubmwNCmFxdWFmaW4u YmUNCmFxdWFwbHVzLmJlDQphcmNoYi5zaW50bHVjYXMud2Vuay5iZQ0KYXJj aGltZWQuY2gNCmFyY2hpcHZiLmNvbQ0KYXJjby5iZQ0KYXJkYXRpcy5jb20N CmFyZS1wcm9qZWN0cy5iZQ0KYXJnZW50YS5iZQ0KYXJnb24ubGlua3pvbmUu Y29tDQphcmdvc25hdi5jb20uYnINCmFyZ291bWwudGlncmlzLm9yZw0KYXJp ZXNwci5iZQ0KYXJpbWNvLmJlDQphcm1hZGEuYmUNCmFybWNoYWlyLm1iLmNh DQphcm0uY29tDQphci1tZWRpYS5iZQ0KYXJteS5taWwuYmUNCkFybXkuTWls LkJlDQphcm4ubmV0DQphcnBudi5iZQ0KYXJyaXNpLmNvbQ0KYXJzZW5hbC5C ZWxnaXVtLlN1bi5DT00NCmFydC1hdC1sYXJnZS5iZQ0KYXJ0YXR0YWNrLmJl DQphcnRlY29uc3RydWN0by5iZQ0KYXJ0ZXNpYWJjLmJlDQphcnRlc2lhc2Vj dXJpdGllcy5iZQ0KYXJ0ZXNpYXNlcnZpY2VzLmJlDQphcnRpYy5iZQ0KYXJ0 aXMtaGlzdG9yaWEuYmUNCmFydG9vcy5iZQ0KYXJ0cy5rdWxldXZlbi5hYy5i ZQ0KYXJ0dmlldy5ubA0KYXJ2YWwuYmUNCmFzYS1hbnR3ZXJwZW4uYmUNCmFz YWR2ZW50dXJlLmNvbQ0KYXNnLWdlbmsuY29tDQphc2hsYW5kLmNvbQ0KYXNp YW5zYnltYWlsLmNvbQ0KYXNpY3MubmwNCmFzbC50bw0KYXNtbC5jb20NCmFz cGZyaWVuZHMuY29tDQphc3Atb25saW5lLmJlDQphc3JvLmt1bGV1dmVuLmFj LmJlDQphc3NlbGJlcmdzLm5ldA0KYXNzdXJheC5iZQ0KYXN0cjAxMTgucnVn LmFjLmJlDQphc3Ryb2xvZ3kuY29tDQphdGxhbnQuYmUNCmF0bGFzY29wY28u YmUNCmF0bGFzLndlYnNpZ2h0Lm5sDQphdG9maW5hLmNvbQ0KYXRvc29yaWdp bi5jb20NCmF0cmF4aXMuYmUNCmF0dGdsb2JhbC5uZXQNCmF0dC5uZXQNCmF0 dHJpdGlvbi5vcmcNCkFVQ09OLkJFDQphdWRpb3Jldm9sdXRpb24uY29tDQph dXNpLmNvbQ0KYXV0bzU1LmNvbQ0KYXV0by1oZXJicnVpay5iZQ0KYXV0b2pl dC5iZQ0KYXV0b3Njb3V0MjQuZGUNCmF1dHNpZGVyLm5ldA0KYXZhY29tLm5l dA0KYXZhdGFyLmFkZHIuY29tDQphdmF5YS5jb20NCmF2ZW50aXMuY29tDQph dmV2ZS5iZQ0KYXZpZHByb25ldC5jb20NCmF2bC5rdWxldXZlbi5hYy5iZQ0K YXZuZXQuY29tDQphd2Jjb21wdXRpbmcubmwNCmF3ZS5iZQ0KYXhhLWJhbmsu YmUNCmF4aWFzLmNvbQ0KYXhpby5ubA0KYXgud2VzdGZhbGVuLmRlDQpheHhl cy1pdC5jb20NCmF6YnJ1Z2dlLmJlDQphemdyb2VuaW5nZS5iZQ0KYXp0ZWsu YmUNCmF6dXIuYmUNCmF6dXJpbnZlc3QuY29tDQphei52dWIuYWMuYmUNCmF6 enVycm8taXQubmwNCg== ---2101138812-452840800-1001500928=:15305-- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 23992 invoked by uid 1108); 27 Sep 2001 08:23:23 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 27 Sep 2001 08:23:23 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: MaraDNS 0.8.23 released Message-ID: <20010927082323.A23942@artemas.reachin.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Hello there, I have released MaraDNS 0.8.23 This version attempts to fix bug reports I received as recently as two days ago. Newer bug reports will be addressed in the next release of MaraDNS. Since I was unable to reproduce the problem with CNAME indirection in my offline simulation of a DNS network (I do not have internet access most of the time down here), I was unable to fix this concern. However, MaraDNS has the following improvments: Star records which point to CNAMEs are now completely supported. Christophe Colle pointed out that the reason MaraDNS was leaking memory when making threads on Solaris was because MaraDNS was not using pthread_attr_destroy. Hopefully, adding this will make MaraDNS not leak on Solaris. Improvment to the "make install" process: The default configuration looks for local man pages in /usr/local/share/man if /usr/local/man doesn't exist. This is to get around some Linux distributions which don't have /usr/local/man Minor security tweak to the routine that generates the 16-bit secure psudo-random number. The AES hasher now correctly generates a 128-version of the hash specified in Bram Cohen's proposed AES hash standard. Thanks to Bram for providing test vectors for the 256-version of the hash. maradns --version now also includes the build system and date Also, it is now mandatory to run "./configure" before running "make". Hopefully, this will not be too much of an inconvenience for people who make packages of MaraDNS. Franky: I hope this version doesn't leak memory in recursive mode on Solaris. Sums: BSD = 36835 184 SYSV = 37199 368 CRC = 3533514747 188349 MD5 = da6360faff7ffebca2b65b83cd521917 SHA1 = 9e92fb91b1f79911aed79e0a63d0eefd2cf585c6 SHA-256 = 89f4614dd685236f2750b68305c69acecf6d1bd5a0d82406e6960a7dc326d087 SHA-384 = 53f85cf182a399ae64c5837b4dfce32e376ff9c735fee69b191fe17cc9694a77f7a5c84299c8ea23340d44360c021129 SHA-512 = e4004fc8be0fdc2560f0c5004e6d75c336bed1cd74c9e346817549a716bf305c638270328d4f7740b69d6e12646bb813fc7fea18630fbd1ba4a32c6c12b5c4b8 Wrlpool = c0574cf0341ddb78759a2a314920b160b02ea9685a45d9b3369d573895f052409c4efb47913763880fdc64e9bbeba3e37b56b80761fb1d8231f644e43b17635f HAVAL5 = ddf8cc3df426b2ef36b3874f213f7eb3905a07eb12441659dd1bec5c85f91f3e Tiger = ae8c4052eaa60aaac09a5283c6ed42b9c1657ef0c318bdba RMD128 = a5c14f544e6cf57341ffd2060b413fbc RMD160 = 614b194cf8aa1f640bdc27880e7903a611b8fc1a AES128b = 478e4b9c38847c8008f935bf408b2e39 AES160b = c77094800873dbb65e8a089ff4124eaf4814dcb6 AES192b = cae0c6c0863dbdc3d0505fd456755a3553cbb33340e94abe AES224b = 599cbc9a8c696e90d07575f2ad646d2a19599c635f78f1050b2df932 AES256b = aefc42f27a97166e6552bb20b7ca8bfd0857d806379e2bba2b71263f4f72e19e - Sam -- "Reality is the most perfect vision of God's will" -- Orson Scott Card From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 24505 invoked from network); 27 Sep 2001 10:01:28 -0700 Received: from unknown (HELO master.sp.unipi.it) (131.114.79.141) by artemas.reachin.com with SMTP; 27 Sep 2001 10:01:28 -0700 Received: from ste by master.sp.unipi.it with local (Exim 2.05 #1 (Debian)) id 15mesm-0000R2-00; Thu, 27 Sep 2001 19:23:32 +0200 Date: Thu, 27 Sep 2001 19:23:32 +0200 From: StE To: list@maradns.org Subject: Bug in MaraDNS on sparc Message-ID: <20010927192332.A1551@master.sp.unipi.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=FL5UXtIhxfXey3p5 X-Mailer: Mutt 0.95.3i --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Hi, ppl! I'm experiencing a problem with Maradns on my Sun Sparc 5 running Linux 2.2.19. The error message is "Fatal error: Init_cache() failed." i'll attach a copy of my mararc file and the output from strace TIA Ste --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=mararc # Example mararc file # The various zones we support # We must initialize the csv1 hash, or things will fail with a # (currently) obscure error message csv1 = {} # This is just to show the format of the file # csv1["example.com."] = "db.example.com" # The address this DNS server runs on. If you want to bind # to all addresses a given machine has, use "0.0.0.0". bind_address = "127.0.0.1" # The directory with all of the zone files chroot_dir = "/etc/maradns" # The numeric UID MaraDNS will run as maradns_uid = 65534 # The (optional) numeric GID MaraDNS will run as # maradns_gid = 99 # The maximum number of processes MaraDNS is allowed to use maxprocs = 64 # Normally, MaraDNS has some MaraDNS-specific features, such as DDIP # synthesizing, a special DNS query ("erre-con-erre-cigarro.maradns.org." # with a TXT query returns the version of MaraDNS that a server is # running), unique handling of multiple QDCOUNTs, etc. Some people # might not like these features, so I have added a switch that lets # a sys admin disable all these features. Just give "no_fingerprint" # a value of one here, and MaraDNS should be more or less # indistinguishable from a tinydns server. no_fingerprint = 0 # Normally, MaraDNS only returns A and MX records when given a # QTYPE=* (all RR types) query. Changing the value of default_rrany_set # to 15 causes MaraDNS to also return the MX and SOA records, which # some registars require. The default value of this is 3 default_rrany_set = 3 # These constants limit the number of records we will display, in order # to help keep packets 512 bytes or smaller. This, combined with round_robin # record rotation, help to use DNS as a crude load-balancer. # The maximum number of records to display in a chain of records (list # of records) for a given host name max_chain = 8 # The maximum number of records to display in a list of records in the # additional section of a query. If this is any value besides one, # round robin rotation is disabled (due to limitations in the current # data structure MaraDNS uses) max_ar_chain = 1 # The maximum number of records to show total for a given question max_total = 20 # The number of messages we log to stdout # 0: No messages, ever (default) # 1: Only startup messages logged # 2: Error queries logged # 3: All queries logged (but not very verbosely right now) verbose_level = 1 # Initialize the IP aliases, which are used by the list of root name servers, # the ACL for zone transfers, and the ACL of who gets to perform recursive # queries ipv4_alias = {} # Various sets of root name servers # Note: Netmasks can exist, but are ignored when specifying root name server # ICANN: the most common and most controversial root name server # http://www.icann.org ipv4_alias["icann"] = "198.41.0.4,128.9.0.107,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,198.41.0.10,193.0.14.129,198.32.64.12,202.12.27.33" # OSRC: http://www.open-rsc.org/ ipv4_alias["osrc"] = "199.166.24.1,205.189.73.102,199.166.24.3,204.80.125.130,207.126.103.16,195.117.6.10,199.166.31.3,199.166.31.250,199.5.157.128,205.189.73.10,204.57.55.100,213.196.2.97" # AlterNIC: http://www.alternic.org/ ipv4_alias["alternic"] = "160.79.129.192,65.2.214.15,160.79.133.70,24.13.64.102,216.99.37.240,199.224.64.190,160.79.133.66,216.99.37.246,216.99.37.247" # OpenNIC: http://www.opennic.unrated.net/ ipv4_alias["opennic"] = "209.21.75.51,216.74.72.7,216.74.72.8,209.21.75.53,209.104.33.250,209.104.63.249" # Pacific Root: http://www.pacificroot.com/ ipv4_alias["pacificroot"] = "204.107.129.2,208.179.42.162,12.28.140.20,204.107.129.10,212.115.192.151,202.76.159.5,209.54.94.3,167.160.132.2" # IRSC: http://www.irsc.ah.net/ ipv4_alias["irsc"] = "203.21.205.2,203.21.205.3,212.234.36.20,212.234.36.19,207.180.91.9,198.199.168.92,207.180.91.10" # TINC: http://www.tinc-org.com/ ipv4_alias["tinc"] = "64.6.65.10,208.128.113.35,212.172.21.254,207.112.147.14,145.89.234.7,209.133.38.16" # Super Root: http://www.superroot.org/ ipv4_alias["superroot"] = "195.117.6.10,199.166.31.3,199.5.157.128,205.189.73.10,199.166.31.250,199.166.24.1,205.189.73.102,199.166.24.3,204.80.125.130,207.126.103.16,204.57.55.100" # End of list of root name server lists # Here is a ACL which restricts who is allowed to perform zone transfer from # the zoneserver program # VERY IMPORTANT: Do not put spaces in the zone_transfer_acl list # Good: zone_transfer_acl = "office,home" # Bad: zone_transfer_acl = "office, home" # Simplest form: 10.1.1.1/24 (IP: 10.1.1.1, 24 left bits in IP need to match) # and 10.100.100.100/255.255.255.224 (IP: 10.100.100.100, netmask # 255.255.255.224) are allowed to connect to the zone server # zone_transfer_acl = "10.1.1.1/24,10.100.100.100/255.255.255.224" # More complex: We create two aliases: One called "office" and another # called "home". We allow anyone in the office or at home to perform zone # transfers # ipv4_alias["office"] = "10.1.1.1/24" # ipv4_alias["home"] = "10.100.100.100/255.255.255.224" # zone_transfer_acl = "office,home" # More complex then the last example. We have three employees, # Susan, Becca, and Mia, whose computers we give zone transfer rights to. # Susan and Becca are system administrators, and Mia is a developer. # They are all part of the company. We give the entire company zone # transfer access # ipv4_alias["susan"] = "10.6.7.8/32" # Single IP allowed # ipv4_alias["becca"] = "10.7.8.9" # also a single IP # ipv4_alias["mia"] = "10.8.9.10/255.255.255.255" # Also a single IP # ipv4_alias["sysadmins"] = "susan,becca" # ipv4_alias["devel"] = "mia" # ipv4_alias["company"] = "sysadmins,devel" # This is equivalent to the above line # ipv4_alias["company"] = "susan,becca,mia" # zone_transfer_acl = "company" # If you want to enable recursion on the loopback interface, uncomment # the relevent lines in the following section # Recursive ACL: Who is allowd to perform recursive queries. The format # is identical to that of "zone_transfer_acl", including ipv4_alias support ipv4_alias["localhost"] = "127.0.0.0/8" recursive_acl = "localhost" # Random seed file: The file form which we read 16 bytes from to get the # 128-bit random Rijndael key. This is ideally a file which is a good source # of random runbers, but can also be a fixed file if your OS does not have # a decent random number generator (make sure the contents of that file is # random and with 600 perms, owned by root, since we read the file *before* # dropping root privledges) # random_seed_file = "/dev/urandom" # The maximum number of elements we can have in the cache. If we have more # elements in the cache than this amount, the "custodian" kicks in to effect, # removing elements at random from the cache (8 elements removed per query) # until we are at the 99% level or so again. # maximum_cache_elements = 1024 # The single root server which we use as a root name server. Eventually, # this will allow there to be multiple root name servers. Currently, however, # only one root nameserver is allowed. 198.41.0.4 is A.ROOT-SERVERS.NET, # Network Solution's Root DNS server. # root_servers = {} # You can choose which set of root servers to use. Current values (set above) # are: icann, osrc, alternic, opennic, pacificroot, irsc, tinc, and # superroot. # root_servers["."] = "osrc" root_servers["."] = "icann" # And that does it for the caching at this point --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=strace execve("./maradns", ["./maradns", "-f", "/etc/maradns/mararc"], [/* 29 vars */]) = 0 uname({sys="Linux", node="corona", ...}) = 0 brk(0) = 0x48ed0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5001a000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 4 SYS_63() = -1 ENOSYS (Function not implemented) fstat(4, {st_mode=S_IFREG|0644, st_size=19507, ...}) = 0 mmap(NULL, 19507, PROT_READ, MAP_PRIVATE, 4, 0) = 0x5001b000 close(4) = 0 open("/lib/libpthread.so.0", O_RDONLY) = 4 read(4, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0N$\0"..., 1024) = 1024 fstat(4, {st_mode=S_IFREG|0644, st_size=96963, ...}) = 0 mmap(NULL, 141704, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x5002a000 mprotect(0x50036000, 92552, PROT_NONE) = 0 mmap(0x5003a000, 77824, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x5003a000 close(4) = 0 open("/lib/libc.so.6", O_RDONLY) = 4 read(4, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0028"..., 1024) = 1024 fstat(4, {st_mode=S_IFREG|0755, st_size=1254604, ...}) = 0 mmap(NULL, 1330376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x5004d000 mprotect(0x50177000, 109768, PROT_NONE) = 0 mmap(0x5017d000, 69632, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0x120000) = 0x5017d000 mmap(0x5018e000, 15560, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5018e000 close(4) = 0 munmap(0x5001b000, 19507) = 0 getpid() = 4160 rt_sigaction(SIGRT_0, {0x5003256c, [], 0}, NULL, 0x50084304, 8) = 0 rt_sigaction(SIGRT_1, {0x50032590, [], 0}, NULL, 0x50084304, 8) = 0 rt_sigaction(SIGRT_2, {0x50032678, [], 0}, NULL, 0x50084304, 8) = 0 rt_sigprocmask(SIG_BLOCK, [RT_0], NULL, 8) = 0 _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xefffe298, 31, (nil), 0}) = 0 getpagesize() = 0x1000 brk(0) = 0x48ed0 brk(0x48f00) = 0x48f00 brk(0x49000) = 0x49000 brk(0x4a000) = 0x4a000 brk(0x4b000) = 0x4b000 brk(0x4c000) = 0x4c000 open("/etc/maradns/mararc", O_RDONLY) = 4 read(4, "# Example mararc file\n\n# The var"..., 1024) = 1024 brk(0x4d000) = 0x4d000 read(4, "sys admin disable all these feat"..., 1024) = 1024 read(4, "tructure MaraDNS uses)\nmax_ar_ch"..., 1024) = 1024 brk(0x4e000) = 0x4e000 read(4, "26.103.16,195.117.6.10,199.166.3"..., 1024) = 1024 read(4, "5.157.128,205.189.73.10,199.166."..., 1024) = 1024 read(4, " We have three employees,\n# Sus"..., 1024) = 1024 read(4, "cl = \"localhost\"\n\n# Random seed "..., 1024) = 1024 read(4, "DNS server.\n\n# root_servers = {}"..., 1024) = 304 setrlimit(0x7 /* RLIMIT_??? */, {rlim_cur=64, rlim_max=64}) = 0 brk(0x53000) = 0x53000 SYS_63() = -1 ENOSYS (Function not implemented) fstat(1, {st_mode=S_IFCHR|0622, st_rdev=makedev(136, 10), ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5001b000 write(1, "Fatal error: Init_cache() failed"..., 63) = 63 munmap(0x5001b000, 8192) = 0 exit(3) = ? --FL5UXtIhxfXey3p5-- From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 24685 invoked from network); 27 Sep 2001 10:34:56 -0700 Received: from unknown (HELO jumper.lonesom.pp.fi) (212.226.133.178) by artemas.reachin.com with SMTP; 27 Sep 2001 10:34:56 -0700 Received: by jumper.lonesom.pp.fi (Postfix, from userid 1000) id 61425619CD; Thu, 27 Sep 2001 20:35:00 +0300 (EEST) Sender: liiwi@jumper.lonesom.pp.fi To: Subject: Re: Bug in MaraDNS on sparc References: <20010927192332.A1551@master.sp.unipi.it> From: Jaakko Niemi Date: 27 Sep 2001 20:35:00 +0300 In-Reply-To: <20010927192332.A1551@master.sp.unipi.it> (StE's message of "Thu, 27 Sep 2001 19:23:32 +0200") Message-ID: <87elos5ygr.fsf@jumper.lonesom.pp.fi> Lines: 23 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.4 (Artificial Intelligence) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii StE writes: > Hi, ppl! > > I'm experiencing a problem with Maradns on my Sun Sparc 5 running Linux 2.2.19. > > > The error message is "Fatal error: Init_cache() failed." > > i'll attach a copy of my mararc file and the output from strace Uncomment this: > # random_seed_file = "/dev/urandom" And this: > # root_servers = {} from mararc. -j From s@s.org Mon Jul 2 22:52:29 2001 Return-Path: Mailing-List: contact list-help@maradns.org; run by ezmlm Delivered-To: mailing list list@maradns.org Received: (qmail 24874 invoked by uid 1108); 27 Sep 2001 10:59:27 -0700 Sender: aj7kwkp@maradns.org Date: Thu, 27 Sep 2001 10:59:27 -0700 From: aj7kwkp@maradns.org To: list@maradns.org Subject: Re: Bug in MaraDNS on sparc Message-ID: <20010927105927.A24849@artemas.reachin.com> References: <20010927192332.A1551@master.sp.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010927192332.A1551@master.sp.unipi.it>; from ste@sp.unipi.it on Thu, Sep 27, 2001 at 07:23:32PM +0200 Ste, Thank you for the bug report. I will make sure that the next version of MaraDNS has a much more helpful error message. - Sam > Hi, ppl! > > I'm experiencing a problem with Maradns on my Sun Sparc 5 running Linux 2.2.19. > > > The error message is "Fatal error: Init_cache() failed." > > i'll attach a copy of my mararc file and the output from strace > > TIA > > Ste > > # Example mararc file > > # The various zones we support > > # We must initialize the csv1 hash, or things will fail with a > # (currently) obscure error message > csv1 = {} > > # This is just to show the format of the file > # csv1["example.com."] = "db.example.com" > > # The address this DNS server runs on. If you want to bind > # to all addresses a given machine has, use "0.0.0.0". > bind_address = "127.0.0.1" > # The directory with all of the zone files > chroot_dir = "/etc/maradns" > # The numeric UID MaraDNS will run as > maradns_uid = 65534 > # The (optional) numeric GID MaraDNS will run as > # maradns_gid = 99 > # The maximum number of processes MaraDNS is allowed to use > maxprocs = 64 > > # Normally, MaraDNS has some MaraDNS-specific features, such as DDIP > # synthesizing, a special DNS query ("erre-con-erre-cigarro.maradns.org." > # with a TXT query returns the version of MaraDNS that a server is > # running), unique handling of multiple QDCOUNTs, etc. Some people > # might not like these features, so I have added a switch that lets > # a sys admin disable all these features. Just give "no_fingerprint" > # a value of one here, and MaraDNS should be more or less > # indistinguishable from a tinydns server. > no_fingerprint = 0 > > # Normally, MaraDNS only returns A and MX records when given a > # QTYPE=* (all RR types) query. Changing the value of default_rrany_set > # to 15 causes MaraDNS to also return the MX and SOA records, which > # some registars require. The default value of this is 3 > default_rrany_set = 3 > > # These constants limit the number of records we will display, in order > # to help keep packets 512 bytes or smaller. This, combined with round_robin > # record rotation, help to use DNS as a crude load-balancer. > > # The maximum number of records to display in a chain of records (list > # of records) for a given host name > max_chain = 8 > # The maximum number of records to display in a list of records in the > # additional section of a query. If this is any value besides one, > # round robin rotation is disabled (due to limitations in the current > # data structure MaraDNS uses) > max_ar_chain = 1 > # The maximum number of records to show total for a given question > max_total = 20 > > > # The number of messages we log to stdout > # 0: No messages, ever (default) > # 1: Only startup messages logged > # 2: Error queries logged > # 3: All queries logged (but not very verbosely right now) > verbose_level = 1 > > # Initialize the IP aliases, which are used by the list of root name servers, > # the ACL for zone transfers, and the ACL of who gets to perform recursive > # queries > ipv4_alias = {} > > # Various sets of root name servers > # Note: Netmasks can exist, but are ignored when specifying root name server > > # ICANN: the most common and most controversial root name server > # http://www.icann.org > ipv4_alias["icann"] = "198.41.0.4,128.9.0.107,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,198.41.0.10,193.0.14.129,198.32.64.12,202.12.27.33" > > # OSRC: http://www.open-rsc.org/ > ipv4_alias["osrc"] = "199.166.24.1,205.189.73.102,199.166.24.3,204.80.125.130,207.126.103.16,195.117.6.10,199.166.31.3,199.166.31.250,199.5.157.128,205.189.73.10,204.57.55.100,213.196.2.97" > > # AlterNIC: http://www.alternic.org/ > ipv4_alias["alternic"] = "160.79.129.192,65.2.214.15,160.79.133.70,24.13.64.102,216.99.37.240,199.224.64.190,160.79.133.66,216.99.37.246,216.99.37.247" > > # OpenNIC: http://www.opennic.unrated.net/ > ipv4_alias["opennic"] = "209.21.75.51,216.74.72.7,216.74.72.8,209.21.75.53,209.104.33.250,209.104.63.249" > > # Pacific Root: http://www.pacificroot.com/ > ipv4_alias["pacificroot"] = "204.107.129.2,208.179.42.162,12.28.140.20,204.107.129.10,212.115.192.151,202.76.159.5,209.54.94.3,167.160.132.2" > > # IRSC: http://www.irsc.ah.net/ > ipv4_alias["irsc"] = "203.21.205.2,203.21.205.3,212.234.36.20,212.234.36.19,207.180.91.9,198.199.168.92,207.180.91.10" > > # TINC: http://www.tinc-org.com/ > ipv4_alias["tinc"] = "64.6.65.10,208.128.113.35,212.172.21.254,207.112.147.14,145.89.234.7,209.133.38.16" > > # Super Root: http://www.superroot.org/ > ipv4_alias["superroot"] = "195.117.6.10,199.166.31.3,199.5.157.128,205.189.73.10,199.166.31.250,199.166.24.1,205.189.73.102,199.166.24.3,204.80.125.130,207.126.103.16,204.57.55.100" > > # End of list of root name server lists > > # Here is a ACL which restricts who is allowed to perform zone transfer from > # the zoneserver program > > # VERY IMPORTANT: Do not put spaces in the zone_transfer_acl list > # Good: zone_transfer_acl = "office,home" > # Bad: zone_transfer_acl = "office, home" > > # Simplest form: 10.1.1.1/24 (IP: 10.1.1.1, 24 left bits in IP need to match) > # and 10.100.100.100/255.255.255.224 (IP: 10.100.100.100, netmask > # 255.255.255.224) are allowed to connect to the zone server > # zone_transfer_acl = "10.1.1.1/24,10.100.100.100/255.255.255.224" > > # More complex: We create two aliases: One called "office" and another > # called "home". We allow anyone in the office or at home to perform zone > # transfers > # ipv4_alias["office"] = "10.1.1.1/24" > # ipv4_alias["home"] = "10.100.100.100/255.255.255.224" > # zone_transfer_acl = "office,home" > > # More complex then the last example. We have three employees, > # Susan, Becca, and Mia, whose computers we give zone transfer rights to. > # Susan and Becca are system administrators, and Mia is a developer. > # They are all part of the company. We give the entire company zone > # transfer access > # ipv4_alias["susan"] = "10.6.7.8/32" # Single IP allowed > # ipv4_alias["becca"] = "10.7.8.9" # also a single IP > # ipv4_alias["mia"] = "10.8.9.10/255.255.255.255" # Also a single IP > # ipv4_alias["sysadmins"] = "susan,becca" > # ipv4_alias["devel"] = "mia" > # ipv4_alias["company"] = "sysadmins,devel" > # This is equivalent to the above line > # ipv4_alias["company"] = "susan,becca,mia" > # zone_transfer_acl = "company" > > # If you want to enable recursion on the loopback interface, uncomment > # the relevent lines in the following section > > # Recursive ACL: Who is allowd to perform recursive queries. The format > # is identical to that of "zone_transfer_acl", including ipv4_alias support > > ipv4_alias["localhost"] = "127.0.0.0/8" > recursive_acl = "localhost" > > # Random seed file: The file form which we read 16 bytes from to get the > # 128-bit random Rijndael key. This is ideally a file which is a good source > # of random runbers, but can also be a fixed file if your OS does not have > # a decent random number generator (make sure the contents of that file is > # random and with 600 perms, owned by root, since we read the file *before* > # dropping root privledges) > > # random_seed_file = "/dev/urandom" > > # The maximum number of elements we can have in the cache. If we have more > # elements in the cache than this amount, the "custodian" kicks in to effect, > # removing elements at random from the cache (8 elements removed per query) > # until we are at the 99% level or so again. > > # maximum_cache_elements = 1024 > > # The single root server which we use as a root name server. Eventually, > # this will allow there to be multiple root name servers. Currently, however, > # only one root nameserver is allowed. 198.41.0.4 is A.ROOT-SERVERS.NET, > # Network Solution's Root DNS server. > > # root_servers = {} > > # You can choose which set of root servers to use. Current values (set above) > # are: icann, osrc, alternic, opennic, pacificroot, irsc, tinc, and > # superroot. > # root_servers["."] = "osrc" > root_servers["."] = "icann" > > # And that does it for the caching at this point > > execve("./maradns", ["./maradns", "-f", "/etc/maradns/mararc"], [/* 29 vars */]) = 0 > uname({sys="Linux", node="corona", ...}) = 0 > brk(0) = 0x48ed0 > mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5001a000 > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) > open("/etc/ld.so.cache", O_RDONLY) = 4 > SYS_63() = -1 ENOSYS (Function not implemented) > fstat(4, {st_mode=S_IFREG|0644, st_size=19507, ...}) = 0 > mmap(NULL, 19507, PROT_READ, MAP_PRIVATE, 4, 0) = 0x5001b000 > close(4) = 0 > open("/lib/libpthread.so.0", O_RDONLY) = 4 > read(4, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0N$\0"..., 1024) = 1024 > fstat(4, {st_mode=S_IFREG|0644, st_size=96963, ...}) = 0 > mmap(NULL, 141704, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x5002a000 > mprotect(0x50036000, 92552, PROT_NONE) = 0 > mmap(0x5003a000, 77824, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0) = 0x5003a000 > close(4) = 0 > open("/lib/libc.so.6", O_RDONLY) = 4 > read(4, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\2\0\0\0\1\0\0028"..., 1024) = 1024 > fstat(4, {st_mode=S_IFREG|0755, st_size=1254604, ...}) = 0 > mmap(NULL, 1330376, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x5004d000 > mprotect(0x50177000, 109768, PROT_NONE) = 0 > mmap(0x5017d000, 69632, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0x120000) = 0x5017d000 > mmap(0x5018e000, 15560, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x5018e000 > close(4) = 0 > munmap(0x5001b000, 19507) = 0 > getpid() = 4160 > rt_sigaction(SIGRT_0, {0x5003256c, [], 0}, NULL, 0x50084304, 8) = 0 > rt_sigaction(SIGRT_1, {0x50032590, [], 0}, NULL, 0x50084304, 8) = 0 > rt_sigaction(SIGRT_2, {0x50032678, [], 0}, NULL, 0x50084304, 8) = 0 > rt_sigprocmask(SIG_BLOCK, [RT_0], NULL, 8) = 0 > _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xefffe298, 31, (nil), 0}) = 0 > getpagesize() = 0x1000 > brk(0) = 0x48ed0 > brk(0x48f00) = 0x48f00 > brk(0x49000) = 0x49000 > brk(0x4a000) = 0x4a000 > brk(0x4b000) = 0x4b000 > brk(0x4c000) = 0x4c000 > open("/etc/maradns/mararc", O_RDONLY) = 4 > read(4, "# Example mararc file\n\n# The var"..., 1024) = 1024 > brk(0x4d000) = 0x4d000 > read(4, "sys admin disable all these feat"..., 1024) = 1024 > read(4, "tructure MaraDNS uses)\nmax_ar_ch"..., 1024) = 1024 > brk(0x4e000) = 0x4e000 > read(4, "26.103.16,195.117.6.10,199.166.3"..., 1024) = 1024 > read(4, "5.157.128,205.189.73.10,199.166."..., 1024) = 1024 > read(4, " We have three employees,\n# Sus"..., 1024) = 1024 > read(4, "cl = \"localhost\"\n\n# Random seed "..., 1024) = 1024 > read(4, "DNS server.\n\n# root_servers = {}"..., 1024) = 304 > setrlimit(0x7 /* RLIMIT_??? */, {rlim_cur=64, rlim_max=64}) = 0 > brk(0x53000) = 0x53000 > SYS_63() = -1 ENOSYS (Function not implemented) > fstat(1, {st_mode=S_IFCHR|0622, st_rdev=makedev(136, 10), ...}) = 0 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x5001b000 > write(1, "Fatal error: Init_cache() failed"..., 63) = 63 > munmap(0x5001b000, 8192) = 0 > exit(3) = ? > > Please be aware that anything posted to this list is publically archived. > > To unsubscribe to this list, send a blank message to > list-unsubscribe@maradns.org -- "Reality is the most perfect vision of God's will" -- Orson Scott Card