From s@s.org Mon Nov 05 16:09:11 2001 From: e8mhpsznamq001@sneakemail.com (Sam Trenholme) To: list@maradns.org Subject: Some changes with maradns.org (Due to me working out the Sendmail setup on my Laptop, some people may have received this message more than once. I apologize for the duplicate messages) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, there, First of all, due to some problems with the ISP I was using, I lost the MaraDNS.org domain this last weekend. Thankfully, Remco Rijnders, the person who is hosting the mirror www3.maradns.org has agreed to host the web pages again. However, I (Remco has _nothing_ to do with this) have decided that, since he is doing me an incredible favor by hosting the web page, that I will not bug him with bringing the mailing list online again. Hence, no mailing list until December or January, when I leave Mexico and have a chance to set up a server in the states that can host the mailing list. In addition, I need to change my email addresses (maradns.org and samiam.org are currently web-only domains). To contact me, use the email address in the headers of this message. I will, probably tomorrow, release an 0.8.29 release of MaraDNS which will have no changes beside documentation which reflects the changed status of maradns.org (different bug reporting mechanism, etc.). In addition, I am changing the focus of MaraDNS' development. I am going to do a fairly major clean up of the recursive.c code, becuase it is pretty messy, and I feel too buggy right now. I do not plan on releasing an 0.8.30 release of MaraDNS (which should have a cleaned up recursive.c) until Decemner 1, 2001. Again, I would like to thank everyone on this mailing list for their interest in MaraDNS. - - Sam -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE75yIRC+jWrh5h/KYRAu43AJ49mm1QxaJbQqP20RQwAotPz+FzpQCfeooa l6zvmZ5NC8noteIVXrB37w0= =RqK/ -----END PGP SIGNATURE----- From s@s.org Tue Nov 06 15:38:02 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: The mailing list is up again Again, Remmy saves the day. We now have the maradns mailing list up and active again. The only change is that the interface to the mailing list is different: Requests to be added or removed from the mailing list are now sent to list-request@maradns.org instead of list-subscribe@maradns.org. As before, mail is sent to the list by sending mail to list@maradns.org. The old mailing list was an EZMLM mailing list, and the current mailing list is a SmartList mailing list. SmartList is part of the procmail package (http://www.procmail.org). - Sam From s@s.org Wed Nov 07 08:10:04 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: No need to resubscribe As a clarification, I have copied over the list of subscribers to the new mailing list, so there is no need to resubscribe. From s@s.org Thu Nov 08 08:29:28 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.29 released After four hours of work last night, I foind out why the custodian was having so many problems. Basically, the hashing core of MaraDNS can not handle elements being removed from the hash. So, to fix this problem, I need to revamp the hashing core. I plan on having a MaraDNS release with a redone hashing core this coming Monday. Until then, I have done a handful of bandaid fixes which increase the amount of records MaraDNS can process and remove from the cache before MaraDNS terminates with a segment violation. In addition, I have updated the documentation which describes the new procedures for subscribing to the mailing list, added some scripts which stress-test the custodian (this is how I found the bugs with the hashing core), and made some other fixes to the hashing core. Here is a detached PGP signature for the 0.8.29 release of MaraDNS: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA76q0iC+jWrh5h/KYRAmO/AJwOCPwRfx3Po3RXXMbfKpOHfvz5hACfY4eB 2iZ+VohMvk7/NTBMLOzFulQ= =RiKW -----END PGP SIGNATURE----- Since this is an interim release until I can fix the problems with the hashing engine, I am only making this release public on the mailing list. - Sam From s@s.org Sat Nov 10 15:02:29 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.30 released Hello there, Well, first of all, some slightly bad news. Due to the frenzy of greedy lawers the the USA, I have added the legal disclaimer to all of the MaraDNS man pages, and also have it display when MaraDNS starts. Of course, it is possible to conifugre MaraDNS to not display the legal disclaimer--MaraDNS tells the user how to do this when it displays the disclaimer. And now the good news. MaraDNS 0.8.30 has a revamped hasing core, which is a hashing core which can handle recods being added and removed from the hash, unlike the previous hashing core. As a result, the following issues appear to be resolved: * The crashing issues which plagued MaraDNS between 0.8.27 and 0.8.29 * The freezing when in recursive mode which were in releases of MaraDNS between 0.8.xx and 0.8.26 * Host names resolving incorrectly after MaraDNS is run for a while. While I was not able to perform any online tests, my offline tests indicate that this is a more stable release than MaraDNS 0.8.26. In addition, this is the first beta test candidate. I hope to have a beta-test version of MaraDNS released on December 1st. As a result, only essential bug fixes (bugs which are not already mentioned in the BUGS section of the man page) will be resolved. In particular, while I do welcome "such-and-such a host resolves differently than how BIND resolves the host name", such bugs will problably not be fixed until after the MaraDNS 1.0.00 release. Unless of course, some really big internet site (such as www.cnn.com) does not resolve at all with MaraDNS. Yes, I know www.yahoo.com resolves differently than it does with BIND or DjbDNS. I know whatthe fix is, but will probably not apply the fix until after the 1.0.00 MaraDNS release. Speaking of bugs, I found another one in this slow-as-molasses cyber cafe: MaraDNS needs to have a user-configurable timeout when trying to query a nameserver, because there are real-world networks which need more than two seconds to contact a DNS server. I know because I'm on one of them right now. Anyway, here is the detached PGP signature for MaraDNS: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA77aEjC+jWrh5h/KYRAtBVAKCKTxM28U/4YlVojdepniPs+qeW7gCfTkA4 fTbrkGehyfel5Ldy9vmIwqw= =9NJa -----END PGP SIGNATURE----- - Sam From s@s.org Mon Nov 12 07:55:21 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.31 released Hello there, First of all, thank you for all of the bug reports with MaraDNS 0.8.30. This weekend, when I was looking at the source code of MaraDNS, I found some more problems with the new hashing core. Mainly, two problems: * There were some routines in the new hashing core which assumed the old structure of the hashing core. * There was a problem where the new hashing core would allow two elements with the same name in the hash, putting the hash in an bad state. These two issues have been addressed. In addition, I am looking at the bug reports. The crash bugs I have been able to reporduce (with MaraDNS 0.8.31, ugh) by sending a large number of DNS requests of the same hostname, such as ftp.it.debian.org, at the same time. I really appreciate all of the bug reports, and hope that MaraDNS gets stable again soon. The reason for this new instability is because the old MaraDNS structure, while functional, was fundamentally broken, and could only be fixed by revamping some core elements of how records are kept in the cache. Looks like MaraDNS 0.8.32 is going to come out really soon. Here is the PGP signature for MaraDNS 0.8.31: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA77xqSC+jWrh5h/KYRAisnAJ9v//M3QL5iLcp7elAB3eVLtThCcwCfa17k NP8Tz/Vr09Z3IgbuGJzOxXY= =JzNo -----END PGP SIGNATURE----- - Sam From s@s.org Mon Nov 12 08:06:46 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: out-of-bailiwick An out-of-bailiwick record is a record which is not part of a zone. For example, let us suppose we have the following zone file for example.com: Sexample.com.|86400|example.com.|root@example.com.|8|7200|3600|604800|1800 Nexample.com.|86400|dns.example.com. # dns.example.com ########################################### Adns.example.com.|86400|10.1.1.1 P1.1.1.10.in-addr.arpa.|86400|dns.example.com. # gateway.example.com ########################################### Agateway.example.com.|86400|10.1.1.2 P2.1.1.10.in-addr.arpa.|86400|gateway.example.com. Cwww.example.com.|86400|gateway.example.com. Cmail.example.com.|86400|gateway.example.com. Cproxy.example.com.|86400|gateway.example.com. This, of course, is a perfectly valid zone file. However, when perform zone transfers with the getzone client, it will refuse to add the entriy P1.1.1.10.in-addr.arpa.|86400|dns.example.com. to the zone file, since it is not a record what ends in example.com. This is for security reasons. The security problem is this: Let us suppose that akadns.net (yahoo.com's DNS provider) uses MaraDNS, and provides secondary DNS service for anyone any everyone. An evil hacker could change www.yahoo.com's DNS records with a zone like this: Sevil-hacker.foo.|86400|%|hostmaster@%|8|7200|3600|604800|1800 Nevil-hacker.foo.|86400|ns.evil-hacker.foo. Ans.evil-hacker.foo.|86400|10.10.10.10 Awww.yahoo.com|86400|10.10.10.10 If one wishes to have out-of-bailiwick records in their zone file, the zone file needs to be transferred by some other means, such as rcp, or rsync. - Sam From s@s.org Mon Nov 12 15:57:03 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: crash backtraces Christian wrote: |Program received signal SIGSEGV, Segmentation fault. |[Switching to Thread 7176 (LWP 24924)] |0x400a5c41 in free () from /lib/libc.so.6 |(gdb) bt |#0 0x400a5c41 in free () from /lib/libc.so.6 |#1 0x400a5ac3 in free () from /lib/libc.so.6 |#2 0x080506c6 in ?? () |#3 0x0804f130 in ?? () |#4 0x0804f100 in ?? () |#5 0x08056e42 in ?? () |#6 0x08057f3e in ?? () |#7 0x08057379 in ?? () |#8 0x40023eca in pthread_start_thread () from /lib/libpthread.so.0 |#9 0x40023f11 in pthread_start_thread_event () from /lib/libpthread.so.0 Looks like I didn't get a full backtrace. Here are the backtraces I myself have from the two times that MaraDNS crashed on me: #0 __pthread_mutex_lock (mutex=0x958a040f) at mutex.c:99 #1 0x400b7d4d in __libc_free (mem=0x40160f40) at malloc.c:3052 #2 0x080501a9 in js_dealloc (pointer=0x40160f40) at JsStrOS.c:145 #3 0x08053f38 in remove_fila (zap=0x40160f40) at recursive.c:205 #4 0x080543b2 in unlink_rr (fatma=0x0, depth=1) at recursive.c:427 #5 0x08054378 in unlink_rr (fatma=0x8078d50, depth=0) at recursive.c:420 #6 0x08054e92 in mhash_put_data (hash=0x806be88, query=0x8076ea8, value=0x8074610, ttl=10800, authoritative=0, expire=1005591037, datatype=3, rtype=255, action=1) at recursive.c:812 #7 0x08054991 in substring_add_rr (hashp=0x806be88, longjs=0x8075348, offset=64, length=16, ttl=10800, query=0x8076ea8, action=1, datatype=3) at recursive.c:638 #8 0x08055965 in query_nameserver (remote_ip=-1008716505, query=0x8076ea8, bailiwick=0x8076c88) at recursive.c:1273 #9 0x080572df in recurse_call (id=6, sock=11, client= {sa_family = 2, sa_data = "\200\016\177\000\000\003\000\000\000\000\000\000\000"}, query=0x8076ea8, queries_sent=1, glueless_level=0, ipret=0x0) at recursive.c:2076 #10 0x080574ea in recurse_call (id=6, sock=11, client= {sa_family = 2, sa_data = "\200\016\177\000\000\003\000\000\000\000\000\000\000"}, query=0x8076ea8, queries_sent=0, glueless_level=0, ipret=0x0) at recursive.c:2138 #11 0x08056798 in recurse_thread (req=0x8076e88) at recursive.c:1732 #12 0x40029bfd in pthread_start_thread (arg=0x40767c00) at manager.c:262 #13 0x40029cdf in pthread_start_thread_event (arg=0x40767c00) at manager.c:285 And, #0 0x400b734a in chunk_alloc (ar_ptr=0x40160f00, nb=16) at malloc.c:2782 #1 0x400b713a in __libc_malloc (bytes=4) at malloc.c:2714 #2 0x08050166 in js_alloc (unit_count=1, unit_size=4) at JsStrOS.c:36 #3 0x08058612 in add_closer_jsip (zone=0x80748c0, ipjs=0x8083b20, if_exists=1) at recursive.c:2744 #4 0x080582ed in add_closer_jsip_offset (js=0x808a830, offset=31, ipjs=0x8083b20, if_exists=1) at recursive.c:2634 #5 0x08056119 in query_nameserver (remote_ip=-972684875, query=0x808a268, bailiwick=0x808a3e0) at recursive.c:1467 #6 0x0805736b in recurse_call (id=0, sock=0, client= {sa_family = 4880, sa_data = "\026@\000\017\026@\224s6AY}\013@"}, query=0x808a268, queries_sent=0, glueless_level=0, ipret=0x413674e0) at recursive.c:2078 #7 0x08055b3d in query_nameserver (remote_ip=-1052553338, query=0x807bd00, bailiwick=0x807bbe8) at recursive.c:1304 #8 0x0805736b in recurse_call (id=0, sock=0, client= {sa_family = 31428, sa_data = "6AHV\006@ \000\000\000W\000\000"}, query=0x807bd00, queries_sent=2, glueless_level=0, ipret=0x41367950) at recursive.c:2078 #9 0x08057576 in recurse_call (id=0, sock=0, client= {sa_family = 31428, sa_data = "6AHV\006@ \000\000\000W\000\000"}, query=0x807bd00, queries_sent=1, glueless_level=0, ipret=0x41367950) at recursive.c:2140 #10 0x08057576 in recurse_call (id=0, sock=0, client= {sa_family = 31428, sa_data = "6AHV\006@ \000\000\000W\000\000"}, query=0x807bd00, queries_sent=0, glueless_level=0, ipret=0x41367950) at recursive.c:2140 #11 0x08055b3d in query_nameserver (remote_ip=-1019198436, query=0x807d620, bailiwick=0x807a360) at recursive.c:1304 #12 0x0805736b in recurse_call (id=6, sock=11, client= {sa_family = 2, sa_data = "\2009\177\000\000\003\000\000\000\000\000\000\0 00"}, query=0x807d620, queries_sent=0, glueless_level=0, ipret=0x0) at recursive.c:2078 #13 0x08056824 in recurse_thread (req=0x807d600) at recursive.c:1734 #14 0x40029bfd in pthread_start_thread (arg=0x41367c00) at manager.c:262 #15 0x40029cdf in pthread_start_thread_event (arg=0x41367c00) at manager.c:285 - Sam From s@s.org Tue Nov 13 01:15:25 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.32 released I have decided that what the MaraDNS 0.8.32 release, along with current MaraDNS releases in general, needs is a theme song. Considering the current state of MaraDNS, that song is "Don't Crash" by Front 242. Again, I would like to thank everyone with their bug reports for MaraDNS 0.8.30 and 0.8.31. I have been able to reproduce the crashes myself. However, I can not consistently recreate the crashes, and only rarely can recreate the problems offline. Based on the information in the bug reports, however, I found some iffy-looking code which may be the cause of the problems currently plaguing MaraDNS. Hopefully, by listening to "Don't Crash" while releasing the new release of MaraDNS will guarantee that it will, indeed, not crash. In addition, this release has some minor documentation touch-ups. Here is the PGP signature for MaraDNS 0.8.32: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA78KCwC+jWrh5h/KYRAt3aAKCplNDC1iuoEhrL74hYNWHEQ5rPZgCfePn4 x830Vx46GuRSQv0lICJA/j4= =crUR -----END PGP SIGNATURE----- To verify the PGP signature: gpg --verify signature maradns-0.8.32.tar.bz2 Where "signature" is a file with the above signature in it. Note that, if a file has multiple GPG signature, gpg will say that one of the signatures is good, and that the other signatures are bad. The gpg public key is the file "maradns.pgp.key" in the MaraDNS distribution, and has the following key fingerprint: pub 1024D/1E61FCA6 2001-10-31 MaraDNS signing key (Private key is on a laptop) Key fingerprint = D167 252A 18BC D011 7CB4 6CA8 0BE8 D6AE 1E61 FCA6 The fingerprint can be verified with: gpg --fingerprint 1E61FCA6 And, finally, just in case this version of MaraDNS crashes and burns, here is the GPG signature for MaraDNS-0.8.26: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA78Jc8C+jWrh5h/KYRAvSrAKCj6ashjzrQY4jPxg6tt56ydj0FDwCePM19 0ietOBGdDyphnYarg6D4rDI= =SC7x -----END PGP SIGNATURE----- - Sam From s@s.org Tue Nov 13 08:36:19 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.32 is still unstable Well, so much for the Front 242 theory. MaraDNS 0.8.32 is still unstable. I need to create a test case so I can consistantly crash MaraDNS offline before I can hunt down and fix this problem. I may be able to duplicate this bug by creating a series of nameservers which behave like the DNS setup for ftp.it.debian.org (The first nameserver is dead, the second nameserver has a CNAME record for the RR). - Sam From s@s.org Tue Nov 13 16:27:37 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.33 released; I think this one is stable Yipee! No, I'm not talking about the fact that the evil Taliban are no longer in control of Kabul. I am talking about the fact that I found and removed another crasher bug in MaraDNS. (Ironically enough, it was a host with the name attila.bofh.it which I was testing this bug against. Thanks for the kind help, Mr. BOFH) I hope that this is the last crasher bug. Time to cross my fingers. In addition, it looks like sneakemail.com is currently down, so I am not able to see messages posted to the list. Again, I greatly appreciate all of the testing, bug reports, and information that I received from everyone on this list. MaraDNS would not be what it is today without all of your help. If there are more crasher bugs, please let the list know. If sneakemail.com can get up again, I can even see the bug reports. :-) And, oh, the detached sig: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA78blHC+jWrh5h/KYRApZNAJwIH4XrttWyId9Ohdwb4hgfocXClwCffMy9 AWmT5L3WLxPC0c0VHimejaU= =gmoi -----END PGP SIGNATURE----- - Sam From s@s.org Wed Nov 14 11:00:43 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Status of MaraDNS I was in the embarrasing position of not having done my homework in class today. As a result, I have to suspend my wild goose chase of finding each and every nasty bug that MaraDNS has. Hence, there will not be a release of MaraDNS until this coming Monday, or later. I was hoping to have MaraDNS be stable at this point so I could put it on the back burner, but no..... For people sending in crash bug reports, please have verbose_level be at 3, and please send me (in private email) the list of every single query sent before the crash happened. This will help me greatly in finding and fixing the crash problems. - Sam From s@s.org Fri Nov 16 11:35:41 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS update It looks like I am able to consistantly recreate the "Unable to remove element from hash." bug in an offline test suite. Theirfore, I may be able to find and fix this problem this coming weekend. In addition, I will have a new version of askmara in the next release of MaraDNS that is able to generate output in a format compatible with the zone files that MaraDNS uses. - Sam From s@s.org Fri Nov 16 16:59:02 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.34 released; Whack-a-mole once again Well, what do you know! Right now, I feel like as though I am playing whack-a-mole [1] with all of the bugs in MaraDNS (this is what happens when one has to redo the core of the program during the alpha-test cycle). I have managed to whack another one of the moles. In my last message, I pointed out that I was able to make a "crash me" recipe which works in offline mode. The way I managed to have an offline "crash me" recipe was by making copies of all of the RRs that apt-spy contacts, and putting all of the records in an offline zone file. The way this was possible was by revamping askmara (I am revamping more and more of the code, it seems) so that askmara now outputs a short, csv1-compatible format (with the exception of SOA records, which are in an almost-csv1-compatible format). I also have modified getzone so that it can use the new askmara output. And, yes, the old askmara output is still available with a new '-v' flag. I really, really hope that this is the last crasher bug that MaraDNS has, and that MaraDNS is now as stable as a rock. I am getting pretty burnt out on MaraDNS, and really need to put MaraDNS on the shelf so that I can concentrate all my efforts on getting better at Spanish and at actually having a social life down here in Mexico. Here is the current release plan: * Once MaraDNS stabilizes, I will make the stable version available on Freshmeat, Sourceforge, and Ibiblio (Mark my words: Two years from today, of those three, only Ibiblio will still exist) * I will then explain to all the people who ask for features _before_ reading the "UNIMPLEMENTED FEATURES" section of the MaraDNS man page that I will implement the feature they request if and only if they have a sister/daughter/friend who is 1) Young 2) Pretty 3) Female 4) Willing to marry me 5) Able to speak one of Spanish or English. * I will finish up the tutorial, and, if no new nasty bugs crop up in the three years it takes me to write the tutorial, make a beta releas of MaraDNS ready. * I will make the beta release be known on Sourceforge and Freshmeat (if they are still around), Ibiblio, on the linux-audit mailing list (which has expressed an interest in MaraDNS in the past), on the DjbDBS mailing list (yes, MaraDNS is on topic over there), and on Bugtraq (which was the mailing list which really griped that there was no DNS server besides BIND and DjbDNS almost a year ago) * I will fix any any all security holes that people might find (right now, there has only been on security hole found, by a BIND developer, of all people) * I will then release a 1.0 release of MaraDNS. Realisitically, my current plan is the beta release one month after the last crash bug is whacked (hopefully, 0.8.34 has whacked the last crasher), and the 1.0 release one month after that. Again, I appreciate all of the bug reports. Here is the detached PGP sig: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA79bDgC+jWrh5h/KYRAjeuAJ9myTyOU0N68BQVelDKQMtlyiEwpACfS94K I6Jmn6FiaL7EWTeo4iEm7aQ= =H+G3 -----END PGP SIGNATURE----- To verify the PGP signature: gpg --verify maradns-0.8.32.tar.bz2.asc maradns-0.8.32.tar.bz2 - Sam [1] The world is a very big place: This is a game the people play at amusment parks. The onject of the game is to hit all of the wooden "moles" as they come up. Since the moles never stop coming up, the feeling of victory one has by getting rid of one mole is quickly offset by three more moles coming up. From s@s.org Sat Nov 17 09:11:20 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.35 released; memory leaks plugged When I was doing some stress testing with MaraDNS last night, I discovered that MaraDNS was leaking memory. Unfortunatly, I was far too tired to deal with it at the time. So I went to sleep, and had dreams about the 1980s, Depeche Mode, and the MaraDNS memory leaks. I ended up waking up at 4am, and started work on finding and removing the memory leaks. Needless to say, I really need to put this MaraDNS thingy to rest--I hope this is the last MaraDNS bug. I have verified that MaraDNS has no memory leaks whatsoever. On RedHat 7.1, MaraDNS grows until it takes up 2940 K of memory (the VSZ column when 'ps auxw' is run). I assume it grows because the thread library grows after a certain number of threads are spawn. Once it hits the 2940K mark, MaraDNS does not grow any more. Here is the PGP signature for MaraDNS 0.8.35: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA79lPvC+jWrh5h/KYRAl4BAJ9EdNZyZpCovvswdWpFLs9gv8ROLACfb8/Z LjzxhPhtlyGJHIArLQQgMuc= =UHxk -----END PGP SIGNATURE----- To verify the PGP signature: gpg --verify maradns-0.8.35.tar.bz2.asc maradns-0.8.35.tar.bz2 Now and then on the mailing list, I repost the key ID and fingerprint: pub 1024D/1E61FCA6 2001-10-31 MaraDNS signing key (Private key is on a laptop) Key fingerprint = D167 252A 18BC D011 7CB4 6CA8 0BE8 D6AE 1E61 FCA6 The PGP public key is part of the MaraDNS distribution. After making the tarball and PGP sig for the 0.8.35 list, I went to sleep again. I had dreams about returning to the offices of an old job I had at an ISP, and seeing that the offices were smaller. There were only one or two people who were there when I left the job over three years ago in the dream. Oh, another thing, looks like sneakemail is busted again, so I am not able to see bug reports right now. Looks like I will have to look at the mailing list archive on Monday to see if any bug reports came in. - Sam From s@s.org Tue Nov 20 15:07:55 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.35 patch for install.sh problems As I was installing MaraDNS 0.8.35 on a new machine, I discovered that the install.sh script no longer places example maradns configuration files in the right locations. This patch fixes the bug in install.sh: *** install.sh.orig Tue Nov 20 17:03:10 2001 --- install.sh Tue Nov 20 17:04:45 2001 *************** *** 73,80 **** # Place all the documents in $DOCS cd .. cp -r * $DOCS - cd .. - cp 0QuickStart changelog.html maradns.pgp.key $DOCS # If the system in question does not already have configuration files, # place example configuration files in /etc if [ ! -f /etc/mararc ] ; then --- 73,78 ---- *************** *** 85,88 **** chmod 755 /etc/maradns cp example_csv1 /etc/maradns/db.example.com fi ! --- 83,89 ---- chmod 755 /etc/maradns cp example_csv1 /etc/maradns/db.example.com fi ! # Move some docmentation files in the root of the MaraDNS ! # tree in to the location of installed docs ! cd .. ! cp 0QuickStart changelog.html maradns.pgp.key $DOCS From s@s.org Tue Nov 20 15:24:37 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Responses to various messages sent to the list Bernd: As Jakko pointed out, newer versions of MaraDNS have a timeout_seconds feature which allows MaraDNS to function on slow networks. On networks that drop packets, the place to put a patch would be around line 1189 of server/recursive.c. Gerrit: Thank you for the patch. Unfortunatly, I am currently using one of thise !@#$ webmail accounts, and their piece-of-!@#$ attachment handling code ate the patch, making it unrreadable. Please resend the patch as plain text in the body of an email message. As for "Erre con erre cigarro", that is a Spanish tongue twister for children to learn how to say the difficult-to-pronounce "rr" sound. The literal translation is "R and R together, cigarette; R and R together, barrel; The cars quickly roll on the train track". It's an inside joke form the early days of MaraDNS: "Writing a DNS server is easier than saying the rr sound". From s@s.org Tue Nov 20 15:50:04 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: New Q/A added to FAQ The 0.9.00 release of MaraDNS will have this Q/A added to the FAQ. Until then, this information is now on the webpage FAQ: What is the difference between an authoritative and a recursive DNS server? A recursive DNS server is a DNS server that is able to contact other DNS servers in order to resolve a given domain name label. This is the kind of DNS server one points to in /etc/resolve.conf An authoritative DNS server is a DNS server that a recursive server contacts in order to find out the answer to a given DNS query. From s@s.org Mon Nov 26 08:48:07 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Updates Franky: Thanks for the updates on the memory leaks. Looks like I will have to make the 0.9.00 beta release not compile on Solaris w/o modification. My goal for the 1.0.00 release is to have it run w/o bugs on almost all currently maintained OSes: Windows (with cygwin), Macintoshes (MaxOS X), Solaris, Linux, and the BSDs. Gerrit: Thanks for the patch. I am having a hard time getting MaraDNS 0.8.35 to take the patch. Once I can get MaraDNS to take the patch, I will make the patch public. Jakko: Thanks for the patch. I have the patch available here: http://www.maradns.org/download/maradns-0.8.35.cleanup2.patch - Sam From s@s.org Mon Nov 26 11:13:27 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Updates Jakko wrote: > This is what I see with 0.8.35 plain and with my patch on > Debian/unstable when running the tests: > nobody 4337 26.3 55.6 71352 70436 pts/3 S 03:36 1:04 maradns -f /etc/mararc.4 [Jakko is noting that maradns, when using /etc/mararc.4, takes up a ton of memory] As expected. There are over 250,000 records in /var/maradns/db.example.com This is a stress test I use for offline testing to make sure that: * MaraDNS can handle this number of records * That the recursive nameserver can handle going through this many records. - Sam From s@s.org Tue Nov 27 15:35:58 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: How MaraDNS' stores resource records The way MaraDNS stores resource records is via two, yes, two hash tables. One hash table has the authoritative resource records. These are records which are in local csv1 zone files. These records never change once MaraDNS is started, and, as a result, are in a format which is optimized for speed assuming static data. The size of this hash table depends on the number of resource records in zone files. The more resource records, the bigger this cache. In the case of over 250,000 records, this cache can be 70 megs big. The other hash table is the cache. This is dynamic data (the reason for all the bugs between 0.8.27 and 0.8.33 was because I had to redesign the hash to handle dymanic data), and the records in this table constantly change. In addition, all of the records in the cache are linked to a bidirectional linked list, which is used to determine what records to remove once the cache starts filling up. The algoritm which decides to remove records from the cache works like this: * Every time we create a new resource record in the cache, it is placed at the top of the list. * Every time we access a resource record (or a nameserver referral), we move that record to the top of the list. * When we remove records once the cache starts to fill up, we remove the records at the bottom of the list. This dynamic cache will never have more than maximum_cache_elements elements. - Sam From s@s.org Tue Nov 27 16:37:22 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS patch for Cygwin added I have managed to get a modified version of Gerrit's Cygwin patch for MaraDNS to patch cleanly against MaraDNS 0.8.35 (Note: WITHOUT the install.sh patch), and have this modified patch available here: http://www.maradns.org/download/maradns-0.8.35.cygwin.patch I know this patch cleanly patches against MaraDNS 0.8.35, and that the resulting patched program compiles on Linux. However, I do not have a Cygwin platform to test this patch against, and, theirfore, can not verify that this patch works on Cygwin. If someone could verify that this patch allows MaraDNS to compile on Cygwin, I would appreciate it. - Sam From s@s.org Tue Dec 04 15:09:52 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Answer to various mails sent to the list Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Thank you, Gerrit, for confirming that the patch patches cleanly against MaraDNS 0.8.35, and that it compiles on Cygwin. Also, thanks for the report on the fact that Cygwin does not include a libpthread library. To answer Gerrit's questions: > Is there some kind of stub resolver No, MaraDNS does not include a stub resolving library. Glibc, however, has such a library, and MaraDNS, in recursive mode, works quite nicely with glibc's stub resolver. > Huh? The install.sh is still patched with this one? There is a separate patch which fixes the problem with install.sh, which is incompatible with the cygwin patch. I should have made my posting more clear, but, then again, I am spending most of my time working on my Spanish, which can be really strange sometimes. For example, "él me preocupa" means that I worry about him, not that he worries about me. Which constrats with the normal form, such as "él me toca", which means that he touches me. > Can I bind the server to more than one IP address? Enlightment is to be found in the FAQ. Which should probably be better organized (an index of questions before the actual questions), since the FAQ is starting to get big enough that people find it inconvenient to read before asking questions on the list. > askmara tries to ask 127.0.0.3 Early in the development of MaraDNS, I had another DNS caching server running on IP 127.0.0.1. Since the default configuration binds MaraDNS to the IP 127.0.0.3, it is too late in the game to change this. Perhaps for the 1.2 release (in the 1.1 tree). To answer Franky's questions: Since MaraDNS still leaks memory on Solaris (ugh), I need to disable Solaris support in the default setup. Over in the US, leaving implied support for a platform with known bugs is a liability issue. I will make it reasonably easy for it to still compile on Solaris, but the default setup will say "There are known bugs I can not resolve in Solaris right now, so don't build this on Solaris". To answer Richard's suggestion: I think that is a great idea, and is easy to do. I hope to make this happen in the 0.9.00 release, but no promises. Your excellent suggestion has been added to the TODO list. Arjen: The mirror of MaraDNS is invaluable. I like to have redunancy with MaraDNS, and the mirror provides this. The only reason I have not looked at the logs yet is because I am more interested in getting better Spanish right now than in seeing how many people have checked out MaraDNS. - Sam From s@s.org Mon Dec 10 06:56:18 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.99 released; getting closer to beta Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, First of all, I would like to welcome all of the new subscribers to the MaraDNS mailing list. This is generally a low-traffic mailing list, with the lion's share of messages on the mailing list being release announcments of new versions of MaraDNS, and bug reports when new versions of MaraDNS don't work as expected. Right now, MaraDNS is in late alpha-testing. This means that no new features will be added until after the 1.0.00 release, and that the main focus of MaraDNS right now is bug fixes. I have just released MaraDNS 0.8.99. This is a version number jump up from MaraDNS 0.8.35, to refect the fact that this will probably be the last release before the beta 0.9.00 release. From the changelog: Since I found a some potential security problems when working on the MaraDNS-0.9.00 release, I am making this release available which appears to addresses the potential security problems. Changes since 0.8.35: * Jaakko's patch, in a modified form, has been applied. * Documentation touchups. * Askmara timeout increased. * Solaris recursive support dropped until I can get my hands on my Solaris CDs (and a PC to install Solaris on) in January (Solaris still has bugs which do not exist in Linux). * Updated test bed to handle NS referrals which point nowhere * Found and fixed a bug where MaraDNS would not close UDP connections when sendto returned an error * Fixed a problem that mhash_put_data had, where the DNS cache could become inconsistant in certain circumstances. * Fixed two other spots in recursive.c (in two of the add_closer routines) which could have potentially caused inconsistant data in the cache. * Got remove.rng to work again. The detached PGP signature for MaraDNS 0.8.99 is: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Ekl9C+jWrh5h/KYRAtJmAJ9x30VtXbg7hUUyVkC+eLNT+GhNeQCgj7za 0EdfW7qlXnhR1lc1SBhvtLQ= =uyEN -----END PGP SIGNATURE----- To verify the PGP signature: gpg --verify maradns-0.8.99.tar.bz2.asc maradns-0.8.99.tar.bz2 Where maradns-0.8.99.tar.bz2.asc is a file with the above detached PGP signature. Now and then on the mailing list, I repost the key ID and fingerprint: pub 1024D/1E61FCA6 2001-10-31 MaraDNS signing key (Private key is on a laptop) Key fingerprint = D167 252A 18BC D011 7CB4 6CA8 0BE8 D6AE 1E61 FCA6 The PGP public key is part of the MaraDNS distribution, in the file maradns.pgp.key. - Sam From s@s.org Mon Dec 10 09:45:11 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.99 released; getting closer to beta Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit > the link that i supposed (?) to point to the newest release on > http://www.maradns.org/download.html actually points at > maradns-0.8.35.tar.bz2 when it should point at > http://www.maradns.org/download/maradns-0.8.99.tar.bz2 Thanks. I have fixed the link. - Sam From s@s.org Fri Dec 14 09:22:41 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Nasty bug in MaraDNS 0.8.99 found Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Franky pointed out that MaraDNS 0.8.99 is still having nasty crashes, with the "Unable to remove element from hash" message. If helping debugging MaraDNS, please patch MaraDNS 0.8.99 by entering the maradns-0.8.99 directory and typing in patch -p 1 < maradns-0.8.99.zap_debug.patch Where "maradns-0.8.99.zap_debug.patch" is a file with the following patch. This way, I can get an idea of what query MaraDNS is having a hard time removing, so I can fix this problem. This patch is also here: http://www.maradns.org/download/patches/maradns-0.8.99.zap_debug.patch Again, I appreciate everyone's valuable contributions in making MaraDNS an excellent DNS server. - Sam diff -ur maradns-0.8.99/server/recursive.c maradns-0.8.99.zap_debug/server/recursive.c --- maradns-0.8.99/server/recursive.c Sat Dec 8 11:03:20 2001 +++ maradns-0.8.99.zap_debug/server/recursive.c Fri Dec 14 11:11:58 2001 @@ -332,6 +332,9 @@ printf("Unable to remove element from hash.\n"); printf("I thought I fixed this bug. Please report this\n"); printf("to list@maradns.org.\n"); + printf("Please include the following information:\n"); + show_esc_stdout(zap->hash_point); + printf("\n"); exit(1); } From s@s.org Mon Dec 17 09:13:06 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.35a released until I can fix the 0.8.99 issues Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, I am making an interim release of MaraDNS available until I can hunt down and fix the problems that MaraDNS 0.8.99 is having. The release is 0.8.35a, and is simple MaraDNS 0.8.35 with the install-sh and the closeudp patches applied. It has the following PGP signature: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8HiY5C+jWrh5h/KYRAhZeAJwMOGAEqyhc4Dhl/By16YC5eVxSrwCcDRn3 IoaCQtXqBL9wPXD3gB9E0uY= =wMpi -----END PGP SIGNATURE----- Now, I hope to get time to work on debugging MaraDNS 0.8.99 this afternoon, so that I can have an 0.8.99a release (fixing the nasty crashes) available shortly. - Sam From s@s.org Mon Dec 17 16:25:40 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.99a released; time to cross my fingers Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, I think I have found the gremlin which has been causing the stability problems that MaraDNS 0.8.99 has been experiencing. As a result, I am making MaraDNS 0.8.99a available, which is simply MaraDNS 0.8.99 with a 2-line patch applied (see the end of this message). Here is the PGP signature for MaraDNS 0.8.99a: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Hot6C+jWrh5h/KYRAi1/AJ9vUParTrllJIGGz8ZYgOaV5Adl9wCffZEs /csCiWgEVqS3OxDQUjyrf9M= =CF4Q -----END PGP SIGNATURE----- I really appreciate Franky and Jaakko with their invaluable help with finding and (hopefully) fixing this particular bug. - Sam --- maradns-0.8.99/server/recursive.c.orig Mon Dec 17 18:07:39 2001 +++ maradns-0.8.99/server/recursive.c Mon Dec 17 18:11:07 2001 @@ -908,7 +908,8 @@ /* If the action is to overwrite, delete the element that is currently there */ if(action == OVERWRITE || spot_data.datatype == MARA_DNS_NS) { - add_zap = 1; + if(add_zap == 0) + add_zap = 1; /* We also overwrite in the [should never happen] case of the element in question being a MARA_DNS_NS element */ switch(spot_data.datatype) { From s@s.org Tue Dec 18 06:48:11 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS memory usage Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Franky wrote: >but I see the memory grow in usage every time I do my load tests on it. >This does seem to be a prob as well on linux as on solaris. Here is what I see when I run load tests on MaraDNS: * The memory usage starts out around 1.6 or 1.7 megabytes * Each time I run the load tests, the memory usage slowly increases * When the memory usage hits just a hair under three megabytes, memory usage stops growing I have run every numerous memory leak tests on the MaraDNS code, and the conculded that this is a natural result of opening and closing a lot of threads in the MaraDNS code. I would love to have a copy of the test script you are using, Franky. - Sam From s@s.org Tue Dec 18 09:04:33 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS tutorial now online Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Last night, I completed the MaraDNS tutorial which MaraDNS 0.9.00 will include. This tutorial is available online at the following location: http://www.maradns.org/tutorial/ In addition, I have updated the FAQ: http://www.maradns.org/faq.html - Sam From s@s.org Wed Dec 19 09:07:17 2001 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.8.99a is stable Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit I am hereby declaring MaraDNS 0.8.99a stable; feel free to use this for production purposes (but, of course, read the disclaimer, and let me know if you encounter any problems). - Sam From s@s.org Sat Jan 05 13:18:38 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Still on my Christmas holiday Hello, everyone, I apologize for the delay in replying to the list. I have been on a Christmas holiday with my family, who unfortunatly only have AOL for internet access. Despite all of AOL's noise about the evil Microsoft monopoly, does not function at all with Linux. This has forced me to be in a position where, while I am seeing all the mails being sent to the mailing list, I can not reply to any of the mails because I can not do the "port 25" magic to put in a non-private email address in the headers. In addition, I made the mistake of leaving my laptop at my friend's house, which is currently 300 miles (480 kilometers; 9 hours driving) from where I am typing this. In the immortal words of Homer Simpson, DOH! (If my experience with Mexico is an indicator, I would say that just about the entire world has seen The Simpsons). I will not be near my laptop (which all my MaraDNS files, etc.) again until January 2nd or January 3rd. However, I am at least in a position to reply to the emails sent to the mailing list. Wysek (Or whatever your name really is): Your request is the second request I have received for ipv6. Obviously, I am not adding new features until the up and coming 1.0 release, so ipv6 is going to take a while to happen. Patches implementing ipv6, of course, will be appreciated and be posted to the mailing list. Troy: Thanks for the question. I have added this to the FAQ: How do I get MaraDNS to automatically start up at system boot time The procedure for doing this depends, of course, on the exact UNIX or UNIX-like system one is using (yes, boy and girls, MaraDNS has a Windows port). On most Linux systems, this is done by adding the following lines to the file /etc/rc.d/rc.local: /usr/local/sbin/maradns > /dev/null & One of these days, I will add scripts to place in /etc/rc.d/init.d Thomas Seyrat: Thanks a lot for all the work that you have done translating all of the documentation in to French. Nice to see that MaraDNS is no longer a "monoglot" DNS server. I will include these translations in to the next release of MaraDNS. If you get really bored, Thomas, it is also possible to change the language of most of the messages that MaraDNS outputs to standard output. E.g, the following files in the source distribution can be easily enough translated: parse/ParseCsv1_en.h parse/ParseMaraRc_en.h tools/askmara_labels_en.h server/MaraBigHash_en.h server/MaraDNS_en.h tuzona/zoneserver_en.h tuzona/getzone_en.h The translation procedure: One changes the messages in quotes from English to the desired fornign language in question. In addition, Thomas, I have added a link from the main MaraDNS page to your French mirror. David: Thank you for the interest in Kiwi. I am glad that this program is finally being used by someone besides myself. The problem that Kiwi had, and the reason it probably never caught on, is that it is really a single component in a more complicated mail filtering system using procmail or what not. When I was using Kiwi, I was using it in conjunction with a number of Perl scripts. For example: * A perl script which would give people on a "white list" a non-encrypted email address. * Another perl script with a heavy spam filter for "default" email addresses, and email addresses well-known by the spammers (such as my Slashdot email address) * A Perl script for my various internic contacts which deleted all my email except email from @internic/networksolutions/etc. email addresses. * Perl scripts which disabled email addresses which porno spammers found. I discovered that the porn spammers were, in fact, getting email addreses from places which had a good number of people under the age of 18--this sounds like a lawsuit in the making, if you ask me. A new MaraDNS release should be coming out in a week or two; I hope to be able to find out where the memory leak which Franky found is before this release. Ideally, MaraDNS 0.9.00 will finally be released. Anyway, everyone, thank you for your interest in my free software. - Sam From s@s.org Sat Jan 05 13:18:39 2002 From: e8mhpsznamq001@sneakemail.com To: cas@taz.net.au Cc: list@maradns.org Subject: Check out Posadis Craig wrote: >La MaraDNS i looked at about a year ago and it has an even dumber >zonefile format than djbdns (if that's possible). Posadis (http://posadis.sourceforge.net) has support for BIND-style zone files. The syntax is not entirely the same; but the aesticics of the zone file format is fairly close. Posadis, however, does not currently act as a recursive DNS server at this point. In other words Posadis can not resolve any given hostname using a list of root DNS servers. You are actually the first person to complain about MaraDNS' zone file format. It is time to add this as an "unimplmented feature", along with SQL support, ipv6 support, the ability to have some hostnames be resolvable only by some ips, etc. - Sam P.S. MaraDNS now has MacOS X support: http://www.maradns.org/download/patches/maradns-0.8.99a.darwin.patch From s@s.org Sat Jan 05 13:25:16 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: I need to have the Franch Translation public domained to include it Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Thomas Seyrat: I am getting ready to release MaraDNS 0.9.00. Just one request: I need to have a declaration that your French translations are public domain before I can add them to MaraDNS proper. Otherwise, I will simply place them on the maradns.org web page under http://www.maradns.org/fr or some such (unless, of course, you object). Others: I am currently running Franky's tests right now. So far, I am *not* seeing the memory leaks. This could be because they are caused by a race condition when MaraDNS processes multiple queries at the same time; I will perform a second series of tests which run all of the queries at once, to see how MaraDNS handles the load. It looks like I will be able to finish these tests later on tonight. If I don't see the leaks, I will mark Franky's memory leak bug as unreproducable, and release 0.9.00 tomorrow; hopefully with Thomas' translations. If I do see the leaks, the 0.9.00 release will be delayed until I can plug the memory leaks. I am also looking for a job in the San Diego area; I really ought to put MaraDNS on my resumé. - Sam From s@s.org Sun Jan 06 01:07:50 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: OK, I was able to recreate the memory leaks that Franky is seeing Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Franky (and others): I have been able to recreate the memory leaks that you are seeing. The cause looks to be a race condition caused by multiple MaraDNS threads running at the same time. I have a debug log with a list of where all of the unfreed memory was allocated, and will work on getting these leaks plugged. So much for 0.9.00 being released tomorrow. - Sam From s@s.org Sun Jan 06 11:47:39 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: How to make a MaraDNS build which tracks memory leaks Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Thomas: Thanks for the declaration. I have added the Franch documentation to the up-and-coming MaraDNS 0.9.00 release. Franky: To make a MaraDNS build which tracks memory leaks, do the following: * Enter the server/ directory * Do the following: ../tools/leak.change < recursive.c > foo mv foo recursive.c * Edit the makefile so that DEBUG_MEMORY is defined (compile with -DDEBUG_MEMORY) * From the top-level maradns directory make clean ; make debug * When MaraDNS is sent a TERM (default signal kill sends) or INT signal (the signal sent when control-C is pressed), all of the allocated memory in recursive.c will output to standard output. From s@s.org Sun Jan 06 12:11:00 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.00 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, I think I have found what was causing the memory leaks which Franky has been seeing, so I am releasing MaraDNS 0.9.00 which should fix this issue. This is the first "beta quality" release of MaraDNS; at this point the only changes between this and the 1.0.00 release will be critical bug fixes. From the changelog: Plugged some memory leaks in the recursive code. Added Thomas Seyrat's Franch translation of the documentation Completed the tutorial Fixed bug where the zoneserver needed the mararc file specified to start. Updated documentation Here is the PGP signature for this release of MaraDNS: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8OKvbC+jWrh5h/KYRAjUMAJ0WJqr1FSm8XlrEJOHtVcY18DJyywCfcd9S Iz6iTr4l1dR4ffDOj0HLltw= =2EVe -----END PGP SIGNATURE----- For people using 0.8.99a, at the bottom of this letter is a patch which (hopefully) addresses the memory leak issues. If I don't get any bug reports in two days, I will make this release more public (Freshmeat, ibiblio, etc.). To patch, enter the maradns-0.8.99a directory and enter: patch -p 1 < ../maradns-0.8.99a.memleak.patch - Sam --- maradns-0.8.99a/server/recursive.c Mon Dec 17 16:16:55 2001 +++ maradns-0.9.00/server/recursive.c Sun Jan 6 09:58:48 2002 @@ -2234,6 +2234,8 @@ return JS_SUCCESS; cleanup: + if(local_c_head != NULL) + unlink_closer(local_c_head); js_destroy(copy); cleanup_nojs: js_destroy(lower); From s@s.org Thu Jan 10 16:51:44 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: SECURITY: MaraDNS 0.9.01 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, When performing an audit on the DNS compression code, I found a nasty security hole, which affects both the 0.5.xx and the 0.9.xx branches of MaraDNS. Impact of security hole: DOS; a single carefully formed DNS packet can cause MaraDNS to be unresponsive. I have released both MaraDNS 0.9.01 and MaraDNS 0.5.31, which address this security issue. In addition, MaraDNS 0.9.01 has some other enhancments over MaraDNS 0.9.00: Fixed security problem with the compression code which I found when performing an audit on the code. Other cleanup of the compression code. Updated the French documentation. Added some more information to the MaraDNS tutorial. Added (currently untested) Darwin (a.k.a. MacOS X) support. Here are the PGP signatures: MaraDNS-0.9.01.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8PjKiC+jWrh5h/KYRAoLmAKCpGwaVwGz2uimqPLZ1CPHigsqHqwCfWaw2 0JlA54/tCAiwoZiAHtB1KjA= =eLID -----END PGP SIGNATURE----- MaraDNS-0.5.31.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8PjO8C+jWrh5h/KYRAtzbAKCPlohW/o1qpK/r6nHk+KYKm5VtjACgjw6/ JV+KlD4C29813dy9Jq1tzHo= =j8co -----END PGP SIGNATURE----- And, the security patch is at the bottom of this message. - Sam --- maradns-0.9.00/dns/Compress.c Tue Oct 16 17:44:46 2001 +++ maradns-0.9.01/dns/Compress.c Thu Jan 10 15:15:41 2002 @@ -204,7 +204,7 @@ int decompress_dname(js_string *compressed, js_string *uncompressed, int *place, int *uplace) { - int lcount = 0,psave = 0; + int lcount = 0,psave = 0,no_forward; unsigned char toread,read; @@ -245,13 +245,14 @@ not rendered in the uncompressed string, increment place */ if(psave == 0) psave = *place + 2; + no_forward = *place; /* Repoint place to point to where compression pointer points. Pointedly. */ if(*place <= compressed->unit_count + 2) *place = ((*(compressed->string + *place) & 0x3f) << 8) | *(compressed->string + *place + 1); /* Security: No look-ahead compression */ - if(*place - 2 > psave) + if(*place >= no_forward) return JS_ERROR; toread = *(compressed->string + *place); } From s@s.org Fri Jan 11 11:59:24 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: When using threads, Linux lies about memory usage Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, One thing to keep in mind when recording the memory usage of MaraDNS, particularly on Linux systems, is that /proc//status is a lying bastasd when it comes to memory usage and threads. In addition "ps auxw" lies about memory usage. The real information on memory usage can be found from /proc//statm. This measues memory usage in 1k pages; the format of the data is: size total program size resident size of in memory portions shared number of the pages that are shared trs number of pages that are 'code' drs number of pages of data/stack lrs number of pages of library dt number of dirty pages For example, here is what a MaraDNS process looks like before running a stress test which spawns a lot of threads: 149 149 122 23 0 126 27 And here is the real memory usage while "ps -auxw" claims that the program is taking up nearly 200 megs: 301 301 131 29 0 272 170 As we can see, the program is only taking up three megs or so; "ps auxw" and /proc//status are lying to us. Thankfully, /proc//statm tells us the truth. More information on the Linux /proc file system: http://www.linuxhq.com/kernel/v2.2/doc/proc.txt.html - Sam From s@s.org Fri Jan 11 12:48:56 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Request: If anyone has Max OS X, see if MaraDNS 0.9.01 compiles Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello again, MaraDNS 0.9.01, in addition to the security update, also has tenative support for Darwin (a.k.a. Mac OS X). If anyone has a Max OS X machine sitting around, I would appreciate it if they could make sure that MaraDNS 0.9.01 compiles on Max OS X out of the box (bzip -cd maradns-0.9.01.tar.bz2 | tar xvf - ; cd maradns-0.9.01 ; make) I appreciate any help here, - Sam From s@s.org Mon Jan 14 17:51:12 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Response to various emails sent to the list Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Andrey: I am not sure what you are trying to ask; the version number of MaraDNS can be seen by invoking 'maradns -v'; the files that the MaraDNS distribution contains can be seen at http://www.maradns.org/download/maradns-0.9.01 Thomas: I would appreciate Mac OS X access when it is feasable; I may also be able to get Darwin shell access from my friend however. Christian: One of the problems with writing technical documentation about a subject which I have studied intimately for nearly a year is that it is sometimes hard to get a sense of how to explain certain concepts plainly; I am curious which parts of the documentation are the most difficult to understand. As for the forest of formats: casual notes about various technical details are in text format; the man pages are in troff format (using the man macros); and the tutorial is in HTML format. The FAQ is in all three formats; the "native" format for the FAQ is HTML (using only a subset of HTML tags). The html2ascii script (in the tools/misc directory) converts the HTML to the ASCII used in faq.txt; and the faq2man script (in the tools/ directory) converts the HTML in the FAQ in to man-page troff format. I am thinking about another format which can handle graphs; because I would like (if I can get around to it) to have documentation on the internal data structures that MaraDNS uses. This would be best explained using graphs. Also: Thank you for the German translations; I assume that these translations are under the same license as the rest of MaraDNS (e.g. Public Domain); and that there are no objections to making these translations part of MaraDNS proper. In addition, I assume that Christian's patches to the documentation is also under the public domain. If this is not the case, please let me know right away. Franky: Let me get back to you on the memory usage issues. If MaraDNS does, in fact, use that much memory, it is because the pthreads library is very wasteful with how it manages memory. In that case, it is time for the Linux kernel developers to make a pthreads implementation which does not use up so much memory; the whole point of threads is that multiple processes use the same memory pool. - Sam From s@s.org Wed Jan 16 01:15:10 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.02 released; streamlined documentation Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, In response to the request from people translating the documentation for there to be a more streamlined documentation format, I have created a new XMLish format called "EJ"; and have hack together some perl and shell scripts which convert from the "EJ" format to *roff man pages, to HTML documents, and to text. The new document organization has different folders for each language (English and French, so far). In each language directory, there is a "source" directory, which contains the source files for the various documents in all of the other directories, with the exception of files in the misc/ directory. The source/ directory contains mainly the ej sources for various files; it also has some files which are the ej sources refer to--the ej format has an tag which can embed the contents of another file. This means that a change to, say faq.embed, immediately changes all other documents which refer to the faq with a couple of make commands in a couple of directories. In addition to the source directory, each language-specific folder (e.g. "doc/en") contains documents generated from the source files. The only documents without source files in the source/ directory is the folder misc; this directory mainly contains a mix of technical notes. No user-level documentation is in the misc directory. The language-specific folder, the man/ directory, and the tutorial/ directory all have makefiles. Running 'make' in any of these directories will update all of the "compiled" documentation for that directory. Make needs to be run three times to update all of the documentation currently. Hopefully, this revision to the document structure will make translation of the MaraDNS documentation easier. PGP sig for maradns-0.9.02.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8RT/vC+jWrh5h/KYRAizoAJ9FNBzz0M9f2f2LBvGKAuNH1NE+kQCdH68m cK6gSquWf6Yz7i3OGTxIcsI= =uTWT -----END PGP SIGNATURE----- - Sam From s@s.org Thu Jan 17 12:19:05 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.03 released; integrating Christian's patches Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, When releasing MaraDNS 0.9.02, I neglected to integrate Christian's patches. Which is why I am releasing MaraDNS 0.9.03; this is simply MaraDNS 0.9.02 with some more documentation updates. In addition, it is now possible to compile MaraDNS 0.9.03 so that she outputs German-language error messages. I have also fixed a couple of bugs in the ej2man and ej2html scripts. No changes have been made to anything besides the documentation system. Here is the PGP sig for the maradns-0.9.03.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8RzA2C+jWrh5h/KYRAo5gAKCHrDEeXvVvGoZjRy8N4EvMRWL09wCfatvP PnKkRDSijHUtDeUEHZG5C4w= =ZDCy -----END PGP SIGNATURE----- - Sam From s@s.org Thu Jan 17 13:13:13 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Errors in the MaraDNS 0.9.03 release Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Some minor notes on the 0.9.03 release: The default locale is German, not English for the compiled binary. To fix this, run this from the maradns-0.9.03 directory before compiling MaraDNS: ./locale.en The changelod incorrectly states that 2001 is the year that MaraDNS 0.9.02 was released. The year is actually 2002. None of these errors warrants a 0.9.04 release. - Sam From s@s.org Fri Jan 18 01:12:05 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.04 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Well, my ears are still ringing after going to an Aerosmith concert (not my style, usually, but my sister was going), but I still have managed to get another MaraDNS release out the door. This is MaraDNS 0.9.04; the changes: * MaraDNS now actually compiles on Solaris "out of the box". Still does not install or run out of the box, alas, but this is a start. MaraDNS dumps core on me after giving me a "libthread panic: cannot create new lwp : dumping core (PID: 1515 LWP 2)" message. * MaraDNS *should* now compile on Darwin now. That version, at least, runs "out of the box" (Sun's versions of UNIX have always been a real pain to port to by comparison) * Another bug fix to the ej2man script; the ej stuff looks good enough for all of the MaraDNS documentation. Speaking of EJ, I have already received one email stating that I may have been better off using an already-created format. I know some people would have preferred that the MaraDNS documentation went in another direction. I chose my own format because: * I wanted something that is almost HTML. HTML may not be perfect, but it has the advantage of being almost universally known. * I wanted something which people would not have to load all kinds of third-party libraries to parse. The EJ scripts merely require a Perl5 interpreter to run; and are included with the MaraDNS distribution. * I wanted something what would generated nroff man page source which is more or less in the same style as the nroff source which I made by hand before converting everything over to EJ. PGP sig of maradns-0.9.04.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8R9TkC+jWrh5h/KYRAptHAKCHeYEvmr2pLHXcSB/TV55FnjSwvwCgpRdW rxyXIqQgeNPU6s9aVL7UWE4= =+sk5 -----END PGP SIGNATURE----- - Sam From s@s.org Mon Jan 21 17:51:34 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.05 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit MaraDNS 0.9.05 has been released. This is the first release which will compile *and* run on a Solaris system "out of the box". I have done a considerable revamp of the build structure; it is now more flexible and can handle diverse UNIX variants better. In addition, I have added a system bootup startup script, which can start, stop, and restart MaraDNS. This script is, on a system using RedHat's particular system startup directory structure (/etc/rc.d has the system startup files, /etc/rc.d/init.d has the actual system startup scripts, and /etc/rc.d/rc[35].d have symlinks for what to start up at runlevels 3 and 5), automatically installed when "make install" is selected. PGP sig of maradns-0.9.05.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TMRyC+jWrh5h/KYRAkvSAJ47ngJ2iolrSo7Xtq4rqIEinRwN0wCeM3KD QxW7rMPvvScZeoRIcoGpzZo= =OuPu -----END PGP SIGNATURE----- - Sam From s@s.org Tue Jan 22 23:48:43 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.06 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit I have released MaraDNS off to the world. This release has a new feature: It is now possible to, during runtime, see the number of threads MaraDNS thinks she has allocated, and, if MaraDNS is compiled with 'make debug', the amount of memory that MaraDNS uses. To enable these debug messages, add the following line to your mararc file: debug_msg_level = 3 To find out the number of threads that MaraDNS thinks she is using, send a TXT query of "numthreads.maradns.org" to the server, e.g: vela 23:45:16 maradns $ askmara Tnumthreads.maradns.org. # Querying the server with the IP 127.0.0.3 Tnumthreads.maradns.org.|730110|Number threads running: 0 To find our how much memory various routines that call js_alloc have allocated, send a TXT query of "memalloced.maradns.org" to the server, e.g: vela 23:45:25 maradns $ askmara Tmemalloced.maradns.org. # Querying the server with the IP 127.0.0.3 Tmemalloced.maradns.org.|730110|Memory allocated: 64078 In addition, I fixed a bug in the startup script, where the script would send itself a SIGKILL signal, making it not able to correctly restart the MaraDNS process. PGP sig for maradns-0.9.06.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8TmWRC+jWrh5h/KYRAjzgAKCdc11oOptJbjio8f2HOH0G3LR5sQCfRxbl jZGwdxXhk97GTHh+Bp5kS/w= =1fxy -----END PGP SIGNATURE----- - Sam From s@s.org Thu Jan 24 00:37:25 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS and memory Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Franky, Thank you for your comments. Your findins confirm what I have suspected all along: MaraDNS is not leaking memory by not free()ing allocated memory. What is happeneing here is caused by the fact that MaraDNS uses a large number of threads; in fact MaraDNS uses a thread for every single recursive query. Sometimes, the threads can take a minute or longer to "die off". Now, when a lot of threads are open, it looks like MaraDNS may be taking up a lot of memory. The reason I say "may be" is because there are two different mechanisms which the Linux kernel uses to report the memory usage of a running process; one claims that MaraDNS is not taking up too much memory, and the other claims that MaraDNS is an absolute pig when it comes to memory usage. Regardless, there is little I can do to change this situtation, except for making fundamental structural changes to MaraDNS (making it use a state machine instead of a multithreaded model); it is too late in the beta cycle to do that. What I can do, however, is have MaraDNS not spawn a thread if the data is already in the cache; this will significantly lower the number of threads that MaraDNS creates and the possible assosciated problems threads entail. This is one thing about Linux that is very annoying; its at times very "hackish" and unpolished behavior. Documentation is at times very incomplete; by the time documentation is made available, it is out of date, even for supposibly "stable" kernels. I can not say what is going on with the threads on Linux because the hackers who wrote thread support were too lazy to document what they did; or, if they did, the documentation is impossible to find, being under http://www.some.edu/~somename/some.real.obscure.path/doc.html. I can understand why FreeBSD and Solaris advocates rightly give Linux a hard time for adding new features so quickly, they do not have time to give Linux that polish that other unices have. Then again, I am currently using a winmodem to connect to the internet; FreeBSD certaintly has no support for this modem, and Solaris will probably never support such software. Solaris, in addition, has a default environment which is downright painful to use compared to a modern GNU/Linux environment. All of the unices suffer from an arrogant userbase. I used to blame Solaris for being this way; true, but, then again I never could get hired at a Linux startup since I did not have the youthful arrogance those startups demand. There is much truth to the old alt.sysadmin.recovery adage that "All operating systems suck". - Sam From s@s.org Thu Jan 24 01:03:04 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.07 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit MaraDNS 0.9.07 is out the door. This release has changed the special queries to obtain runtime information on MaraDNS' status. The queries used to be (in askmara format) Tmemalloced.maradns.org. and Tnumthreads.maradns.org. The queries are now Tmemusage., Tnumthreads., and Tcache-elements. Again, to enable these debug messages, add the following line to your mararc file: debug_msg_level = 3 In addition, I have added a makefile target which compiles on systems without flock() support. This release looks to compile fine on Cygwin; however, I can not test this because the default Cygwin installation which I have refuses to compile a program thusly: $ cat > foo.c main() { printf("Hello, World!\n"); } $ cc -o foo foo.c Next: Bug Thomas so I can verify that MaraDNS compiles on Mac OS X. - Sam From s@s.org Fri Jan 25 00:55:12 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.08 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit I introduce MaraDNS 0.9.08 to the big bad world. You know what I spend too much of my time doing, being the unemployed bum that I am. Reading and posting to slashdot.org. Of course, when I was an employed bum, I was also spending far too much time reading and posting to slashdot.org. Slashdot, despite all of its flaws, seems to be, alas, a constant in my life. Perhaps what I need to do is become a hermit and live in a shack somewhere in the mountains contemplating the nature of God. Of course, I should probably release MaraDNS 1.0 first. MaraDNS will not have the perfection and glory of God, of course, but it will be something that will be stable. Then again, since MaraDNS is being developed at a pace typical of software libre, MaraDNS 1.0 has a very mythical aspect right now. Unlike many software libre projects, MaraDNS is being actively developed, however. Of course the number of lines changed in the the actual DNS code between MaraDNS 0.9.07 and 0.9.08 is precisely 0 (the only updates are documentation updates), one may have the impression that perhaps the MaraDNS development team is releasing MaraDNS at a frantic pace merely to disorient the core users (the saps here on this mailing list), or to increase the "activity percentile" for MaraDNS on SourceForge. The truth is a little different, of course. MaraDNS 0.9.08 is my last "stable" release of MaraDNS. Releases after this will begin making some changes to the recursive engine to fix a long-standing bug where CNAME records will not correctly resolve in the case where: * The record is a CNAME record * The record, in fact, points to an A record * Something happened, alas, which made MaraDNS unable to get the A record attached to the CNAME record. In this case, MaraDNS will not resolve the record in question until the CNAME record is removed from the MaraDNS cache. Fixing this problem requires some subtle, but definite changes to the recursive core; I wanted to have a MaraDNS that compiles on the major players out there (verified to work hassle-free on Solaris and Mac OS X; probably compiles hassle-free on a properly installed Cygwin setup) before making changes that can possibly give us the mess we had between 0.8.27 and 0.8.33. - Sam From s@s.org Fri Jan 25 01:34:39 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS PGP signatures Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit MaraDNS PGP signatures are no longer included in MaraDNS announcments which I send to the mailing list. Instead, they are placed in the MaraDNS download directory. Both the gz and the bz2 compressed form of the files are signed, where the detached PGP signature is filename.asc. For example, the detached PGP signature for maradns-0.9.08.tar.gz is: http://www.maradns.org/download/maradns-0.9.08.tar.gz.asc These signatures are signed with the same PGP key that I have been using since MaraDNS 0.8.30 or so. The PGP public key file is the file maradns.pgp.key in the top-level directory of MaraDNS distributions. The fingerprint for this key is: Key fingerprint = D167 252A 18BC D011 7CB4 6CA8 0BE8 D6AE 1E61 FCA6 The key can be imported as follows: cat maradns.pgp.key | gpg --import Once the key is added to one's keyring, it can verify signatures as follows: gpg --verify maradns-0.9.08.tar.gz.asc maradns-0.9.08.tar.gz The fingerprint can be verified by typing in gpg --fingerprint maradns In addition, I make the signatures part of the release notes for each MaraDNS file I upload to SourceForge. - Sam From s@s.org Fri Jan 25 22:22:29 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS RPM files now available Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit I have made some RPMs of MaraDNS 0.9.08 available on the MaraDNS web site. There is both a source-code RPM; and a binary RPM which was built on a RedHat 7.1 box. Note that, during the process of making a binary RPM from a source code rpm, the program will ask you to overwrite some files. Just say "yes". - Sam From s@s.org Sun Jan 27 19:09:36 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.09 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit This is a stable release of MaraDNS; the only changes between this release and MaraDNS 0.9.08 are as follows: * The documentation is updated; the mararc manual page now documents the debug_msg_level function. In addition, there is a new document which describes the DNS data structures which I wanted to write before making the minor changed needed to fix a CNAME bug which pops up in certain unusual circumstances. * The build directory now has a .spec file and a patch file which allows a RPM to be made from the tarball. I am calling this the "Roland" release; (named after the TR909 drum machine) this release has already been uploaded to sourceforge and will be uploaded to ibiblio. - Sam From s@s.org Sat Feb 02 01:05:50 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Fixing MaraDNS memory bugs Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, everyone, I am getting reports on the field that MaraDNS is, in certain circumstances, using an excessive amount of memory still; one report is that a machine was thrashing pretty hard after running MaraDNS for two or three days. This is obviously a serious bug, and one which needs to be addressed. One of the problems is that ps auxw gives incorrect information when displaying information about memory usage with multithreaded applications. For example, I demonstrate here a case where "ps auxw" claims that Mozilla (another multithreaded application) is using 34 megs of memory, when, in fact, the memory usage is only 10 megs: vela 00:35:57 maradns $ free -m total used free shared buffers cached Mem: 343 321 22 0 73 158 -/+ buffers/cache: 89 254 Swap: 129 0 129 vela 00:36:02 maradns $ ps auxw | grep mozilla set 8573 9.8 6.4 34088 22844 ? S 00:35 0:04 /usr/lib/mozilla/mozilla-bin set 8577 0.0 6.4 34088 22844 ? S 00:35 0:00 /usr/lib/mozilla/mozilla-bin set 8578 0.0 6.4 34088 22844 ? S 00:35 0:00 /usr/lib/mozilla/mozilla-bin set 8579 0.0 6.4 34088 22844 ? S 00:35 0:00 /usr/lib/mozilla/mozilla-bin set 8587 0.0 6.4 34088 22844 ? S 00:35 0:00 /usr/lib/mozilla/mozilla-bin set 8616 0.0 0.2 1704 716 pts/3 S 00:36 0:00 grep mozilla vela 00:36:11 maradns $ ps auxw | grep mozilla vela 00:36:26 maradns $ free -m total used free shared buffers cached Mem: 343 310 32 0 73 157 -/+ buffers/cache: 79 264 Swap: 129 0 129 The official Linux documentaion has no information on this particular issue. As a result, I can not point to a given documtation page and say "See, this page proves that memory usage with 'ps auxw' and multithreaded applications lies". The closest thing to an official word on the subject is as follows, from Xavier's notes included with older releases of the pthreads library: - Threads share pretty much everything they should share according to the standard: memory space, file descriptors, signal handlers, current working directory, etc. [...] - The stacks for the threads are allocated high in the memory space, below the stack of the initial process, and spaced 2M apart. Stacks are allocated with the "grow on demand" flag, so they don't use much virtual space initially (4k, currently), but can grow up to 2M if needed. However, while there is no official word on the subject, there are some places on the internet where people assert that ps auxw lies: http://mail.gnome.org/archives/gnome-list/2000-December/msg00287.html http://home.t-online.de/home/Moestl/faq.html At this point, I will ignore bug reports which say "ps auxw says MaraDNS uses too much memory"; 'ps auxw' is a lying bastard. However, I will take bug reports which say "MaraDNS is using so much memory, my system is trashing" bug reports very seriously. There are some possibilities here: * MaraDNS, in fact, has a memory leak (isn't freeing allocated memory in certain circumstances). This can be confirmed by compiling MaraDNS with 'make debug' then seeing the amount of allocated memory by sending a "Tmemusage." query ('dig memusage. txt' with the dig tool) to a MaraDNS process. If the number is over 500,000, and the number of cache elements is 1024 or less, we have a leak. It is simply a matter of recreating then plugging the memory leak. * It is possible that I am still not properly closing threads on non-Linux oses. Thankfully, thanks to the work and generosity of Jaakko and Thomas, I have access to Solaris and Max OS X machines which I can test, find, and debug these kinds of issues on. The days of needing to treat some OSes like second-class citizens by disabling recursion are gone. Anyway, I hope to find and fix this issue soon; this is one of the two known bugs which is stopping MaraDNS from becoming a 1.0 release. - Sam [As an aisde, I would prefer to be able to post messages to this list using simple HTML (, ,

,

, and ) since I find ASCII quite ugly; what kind of Mail clients are people using on the list?] From s@s.org Sat Feb 02 13:14:49 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Weird logs and zonetransfers Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit > since i haven't had > the time to transfer all the zonefiles > to my secondary one it logs every query as a bad query. why is that? Since the DNS packets look like legitimate requests for the A record for heffaklump.x-pl0re.org and www.x-pl0re.org respectivly, my gut instinct tells me that these log messages are being generated because a DNS server is being sent a request for a hotname for a domain that it does not have information for, which results in MaraDNS checking to see if the IP requesting the query is authorized to perform recursion. Since the IP isn't, it send out a "permission denied" packet and logs it as a "bad query". As it turns out, both 194.236.118.54 and 217.208.75.23 do not generate this error condition; since they are returning NS replies, they also are not running in recursive mode. >server1 : primary for domain1.com and domain2.com, secondary for >domain3.com and domain4.com >server2 : primary for domain3.com and domain4.com, secondary for >domain1.com and domain2.com Simple enough to set up: * Set up the zone transfer ACL on server1 to allow server2 to make zone transfers (e.g. zone_transfer_acl = "10.1.2.3" in the mararc file) * Set up the zone transfer ACL on server2 to allow server1 to make zone transfers * Have a cron tab on server1 which runs a getzone for domain3.com and domain4.com * Have a cron tab on server2 which runs a getzone for domain1.com and domain2.com Or, alternativly, use SCP, which is better since the zone will preserve their spacing and formatting. About the HTML issue: I won't do any HTML until I have a setup which automagically converts HTML in to ASCII; this way the people with Evolution, Pine, Mulberry, and proper MUTT setups can render the HTML; people with other mail setups or who just prefer ASCII over HTML don't need to bother; what I will do is have two lists, one which simply blasts the mail "as is"; the other which ASCIIfys the HTML and blasts the mail as it. Perhaps a third mailing list for people who prefer 40-column ASCII over 80 column ASCII (perhaps people are using Commodore 64s to read this list). I prefer simple HTML because it separates form from content; this allows people more flexibility with the form in which they can view a given set of content; plain ASCII forces the form which someone views a given message. HTML, before Netscape went crazy with proprietary tags, was originally about this; it was people who were under the impression that HTML could arrange how things actually appeared to the end user, and the resulting flagrant abuse of inline images, the TABLE tag, the excessive use of Java Script which resulted in the mess HTML is in today. With my web mail client, normal 80-column ASCII text looks ugly; it ends up looking roughly like this: Hello, this is an example of some text which looks perfectly decent on a standard 80-column mail client looking like doggy doo-doo on my webmail client. I need to make columns no more than 55 columns wide for it to decently render. You can see why I would prefer simple HTML. - Sam From s@s.org Fri Feb 08 11:32:38 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS progress on Solaris Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello everyone, I am trying to run a reasonable test environment for MaraDNS on Solaris. However, Solaris' incompatibilities with the development environment which a free UNIX system has have been bogging me down. While MaraDNS 0.9.09 does compile and run fine as an authoritative nameserver with Solaris, running it as a recursive nameserver causes it to crash in short order, e.g: libthread panic: cannot create new lwp : dumping core (PID: 4810 LWP 2) stacktrace: 0 It is almost as if Solaris only allows a process to spwawn a certain number of threads; more than that and Solaris does not want to function. This appears to be a Solaris bug: http://mailman.eng.auburn.edu/pipermail/veritas-ha/2001-April/000437.html Which *may* be fixed by the following patch: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F106542&zone_32=libthread%20panic%3A%20cannot%20create%20new%20lwp As a result, I will assume: * That this is a Solaris specific bug * That this partciular demon does not come up in Solaris 8 * That, since I do not have a Solaris 8 machine to work with (Jaakko's machine runs Solaris 7), the issues Franky is seeing are Solaris 8 specific; I obvioulsy can not address them until I get a computer to install my Solaris 8 CDs on. So, I have a question for the list: Should I delay the 1.0 release until I get a Solaris 8 machine to deal with these issues with, or should I, for the time being, disable recursion on Solaris unless MaraDNS is compiled with "make debug"? - Sam From s@s.org Mon Feb 11 17:16:37 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.10 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit I have released MaraDNS 0.9.10 This is a testing release of MaraDNS; I have made a some changes which, while fixing bugs, may introduce new bugs. From the changelog: Fixed bug of case where there is a CNAME record, and something happened when trying to get an A record for the CNAME record. Previously, MaraDNS would think the CNAME record had no A record until the CNAME record was purged from the cache. Now, MaraDNS is smart enough to store CNAME records with an A record of "a 'no such host' reply was found when we looked for an A record"; and CNAME records without any corresponding A record only stay in the cache for 30 seconds. If data is already in the cache for a given record, and the data has not expired, then there is no need to spawn a thread to process the record; now MaraDNS no longer does this. This should result in greater stability and less memory usage, since many operating systems do threads poorly. askmara now can have a user-defined timeout compile flags changed from -g to -O2 (2001.02.11) In addition, this release introdices another bug: 'make debug' no longer compiles MaraDNS with debugging enabled; I hope to fix this with a patch in one or two days. - Sam From s@s.org Mon Feb 11 18:42:24 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.11 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On the coattails of MaraDNS 0.9.10, I have released MaraDNS 0.9.11 This is a bugfix release of MaraDNS 0.9.11. From the changelog: Fixed bug where CNAME records obtained from the cache would not work with stub resolvers, since the code changed the question in the question section of the reply. ´make debug´ now works again. - Sam From s@s.org Wed Feb 13 21:58:36 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: I found a good link about thread programming Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit As I was surfing the web today, I found a good link about thread programming: http://www-106.ibm.com/developerworks/linux/library/l-rt7/?Open&t=grl,l=252,p=mgth Hopefully, I can use this information (in particular, the usage of pthread_join()) to minimize the memory usage excessive threads generate. Coupled with the 0.9.11 improvments, which minimize the number of threads created, this will hopefully resolve the issues with threads taking up too many resources with MaraDNS. In addition, I have made MaraDNS 0.9.11 available on SourceForge. I will make a .gz of MaraDNS 0.9.11 available tomorrow, if no problems with 0.9.11 are reported between now and then. - Sam From s@s.org Fri Feb 15 13:49:39 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.11 is now considered stable Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Since I have not received any bug reports about MaraDNS 0.9.11, and since MaraDNS 0.9.11 has no problems with the stress tests in the SQA suite, I am no longer marking MaraDNS 0.9.11 as an "unstable" release. It is, as far as I can tell, as stable as any other caching/recursive release of MaraDNS. As a result, I have made an announcment about MaraDNS 0.9.11 on Freshmeat, and have uploaded MaraDNS 0.9.11 source files to both SourceForge and to Ibiblio. If there are any problems found with MaraDNS 0.9.11 which do not exist in MaraDNS 0.9.09, speak now or forever hold your peace. With regards to the problems people are seeing because MaraDNS is generating so many threads, i have added the following to the "BUGS" section of the MaraDNS manual: MaraDNS spwawns a new thread for every single recursive DNS request when the data in question is not in MaraDNS´ cache; this makes MaraDNS an excellent stress tester for pthread implementations. Many pthread implementations can not handle this kind of load; symptoms include high memory usage and termination of the MaraDNS process. Resolving this issue would require an almost complete rewrite of MaraDNS' recursive code. A rewrite of the recursive code is needed eventually for other reasons: * The code has hard-wired assumptions that DNS is only done on ipv4 * The code is not nearly as compact nor as elegent as i would like it to be * Changes and additions were made to the data structures on an ad-hoc basis, since I started writing the recursive code without a fully clear idea what was needed to make a usable recursive nameserver This will not happen until MaraDNS 2.0; in the meantime, I think it is more important to add SQL support, BIND zone file support, and limited IPV6 support. Better TCP support will come after the rewrite; the recursive code also assumes that all queries are done over UDP. Of course, features will not be added until after the 1.0 release; MaraDNS has been under a feature freeze for about seven months now. My current plan is to audit critical sections of the code which are "at the frontlines" in terms of security, and then make a MaraDNS 1.0 release. The audit will consist, among other things, of more throughly documenting how exactly the recursive DNS server works; the easier I make the code to read, the easier it will be for me to audit it. - Sam From s@s.org Mon Feb 18 17:54:58 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Cc: info@ipal.net Subject: Administrativa: ipal.net has a broken spam filter Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Mr. Phil Homewood, It is impossible to have you be subscribed to the mailing list if you continue to use ipal.net for your internet needs; ipal.net has a broken spam filter which filters out legitimate traffic: : host vega.ipal.net[209.102.192.80] said: 555 : Client host rejected: This network is blocked due to SPAM - Contact your ISP - ARIN-DIALTONEINTERNET-2 Now, this message is useless. An attempt to contact phil@IPAL.NET, who is responsible for this broken spam filter, was fruitless; it is impossible for me to find out which spam list webconquest may be on; much less work on getting webconquest off of said list. If you insist on using such an ISP for your connection needs, please be aware that you are losing a significant amount of legitimate mail in an overzealous, and ultimately futile effort, to filter out spam. I have removed phil-maradns@ipal.net from the mailing list; I do not appreciate having Remmy, who has very generously provided both this mailing list and the web page for MaraDNS, being called a spammer. He is not. Thank you for your time and understanding, - Sam From s@s.org Mon Feb 18 18:11:23 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Cc: info@ipal.net Subject: Sorry about that Phil Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Phil, It seems that I have made an error; the person responsible for this is Phil Howard; who is the owner of the ipal.net domain. The similarity to your name and the fact that I despise being labelled a spammer, after all the effort (http://kiwispam.sourceforge.net) I have gone to fight spam led me to make an error. Please accept my humble apologies. Now, I need to see if I can contact Phil Howard and get him to fix his spam filter. I saw, a few months ago on Google, that he was looking for a decent spam list; looks like he chose the wrong one. Christian: I can not recreate the becket.becket.net concern, but will analize the compressed packet to see what went wrong. In addition, I would appreciate the output of a security auditing tool; but would prefer if I could have a URL to download the tool with myself (as long as doing so is not piracy, of course). Splint can not handle the MaraDNS code; the pthread header file causes it to terminate with a fatal error. - Sam From s@s.org Tue Feb 19 09:49:11 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Fighting spam Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello, everyone, It seems like we have been having some problems with delivering email to the list due to overzealous spam filters. Now that these filters have been corrected so that email can be delivered to the list again, it is probably a good time to discuss spam filtering techniques. My last project before MaraDNS, Kiwi (http://kiwispam.sourceforge.net), was a spam filter, when used in conjunction with some other scripts, which removed 95-98% of the spam from my inbox. Kiwi is different from other spam filters; it is based on the same premise that Sneakemail is based on, namely that the key to getting rid of spam is making sure that the spammers do not get one's email address. Kiwi did this by adding an encrypted token which had a very short encrypted message, such as "this email address was sent out in a personal mail on March 9, 1999" or "this email address was generated with the short encrypted message 'sldot' (short for slashdot)". This script was used in conjunction with an outgoing mail filter which did the following: * For email sent to people I know, the outgoing email filter changed the from: email address to a secret, unfiltered email address. * For email sent to people I had a working releationship with, the outgoing email filter changed the from: email address to my work email address. * For everyone else, the email address was one that timed out after 90 days. In order to have an email address to fill out web forms with, register software with, put on my whois contacts info, and so on, the program could also encrypt a simple five-letter message, which could very tersely describe how this email address was made available. In addition, it was possible to encrypt a timestamp which indicated that the email address in quesiton was posted to usenet. I also had some perl scripts which were crude versions of what spamasassin does: they looked at the email and determined if it looked like spam or not. If it looked vaguely like spam, the email was placed in a special spam mailbox. These scripts were used for email address which I wanted to keep, but were on spammer's email distribution lists. This is a system which I used in some form for four years (until I was no longer in a position to have my own domain which could receive email), and this program not only essentially eliminated all of the spam my inbox received, it also gave me a lot of insight of where spammers are getting their email addresses from. First of all, spammers love harvesting email addresses from Usenet. It got so bad, I had to add a feature to my kiwi software so that it would send all email sent to addresses posted to Usenet through a heavy "spamasassin" filter, and disable Usenet email addresses after two weeks. Second of all, spammers love harvesting email addresses from the web, but only in places where there are a lot of email addresses. The email address I had available on Slashdot was a spam magnet. Once, I made an email address available on the www.crypto.com list of crypto software available; within 24 hours of my email address being placed on this web page, I was receiving pornographic spam. The email address which I had available on one of those high school alumni web pages also received the occassional pornographic spam. I had a special web page which would encrypt the IP of where someone got my email address; this was used so that I could determine where spammers are doing their web harvesting. This email rarely got spam; when it did, I would post to news.admin.net-abuse.email where the email address was harvested; the apache logs of who accessed this particular web page were permanently stored. Spammers also like sending email to whois contact email addresses; it got so bad that I had to make a special spam filter for these addresses that _only_ accepted email from email addresses which would send legitimate "your domain has been updated" traffic (as I recall, anything@internic.net and anything@netwiz.net, since I manage my domains through netwiz). Looking back, it was probably a little overzealous to time out email which I sent myself to people I knew. I rarely had a spammer try to email me using an email address that was in the from: line of an email I sent out; the only times they did was when the email in question was mirrored on a web page. When I set up a spam filtering system again, I will have email sent to people I don't know be an encrypted form of the email address I sent the email to; if any of these emails starts getting spam, I will simply disable the address in question. Otherwise, the address will be unfiltered. Email address which are made available on web forums and other web pages will will have a lot of email addresses need to be run through a spamasassin-type filter; or simply require a three-way interaction for people to send email: 1. Someone sends email to, say, a Slashdot email address 2. They get an autoreply: In order to send me email, please send mail to this address; where "this address" is a special email address which is an encrypted form of their from: address 3. They can now send email to the special address. In case they are a spammer, the email adress can be disabled. Spammers are well aware of the existance of some filters and blacklists; for example, at first a bcc: filter (e.g. My email address has to be in a To: or Cc: line) could eliminate all spam. Spammers starting learning that this was a fairly common filter; as a result, once broadband became available, some spammers went to the trouble of putting in a "To: victim@email.address.foo" header. Spammers also know that a lot of people are on blacklists such as the RBL; the RBL was an extremely inefficient spam filter. An open mail relay spam filter would probably be more effective; spammers like sending email through open relays. A DUL filter is somewhat effective, but a lot of UNIX power users like using a local copy of postfix/sendmail/qmail to send out email; a better solution is to make a DUL ip 1 point in a spamasassin filter. The fact that most spmmers are sleaze balls is well known. I once was told that spammers use forged credit card numbers (generated, for example, by a program which generates legit-looking bogus CC numbers) to sign up ISP accounts; they would get 20 or 30 accounts and spam from wach one until that particular account was cancelled; then they would spam from the next ISP account they had with that ISP. In fact, the RBL was very effective in this case. The suits, according to my source, felt that a system which checked to see if a given credit card number was valid was too expensive, and decided to not implement it. My source warned them that they would be blacklisted. And, as it turned out, they ended up on the RBL. After a couple of months of this, the suits woke up and smelled the coffee, implemented a system which did not make it trivial for spammers to make bogus CC numbers, and the company was taken off the RBL. Spam, alas, is a fact of life on today's internet. Thankfully, it can be filtered easily enough if one takes care to keep their "real" email address secret; http://www.sneakemail.com can be used for public email addresses (it is currently a free service). I hope this helps people develop effective spam filters. ObMaraDNS: The first step of the auditing process is for me to make sure the code which needs to be audited displays no warning when compiled with -Wall. I am almost done with the process; I should be releasing a MaraDNS 0.9.12 today or tomorrow which compiles all the code "to be audited" using -Wall without warning. - Sam From s@s.org Tue Feb 19 23:37:13 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: As seen on TV: MaraDNS 0.9.12 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit As seen on TV, MaraDNS is now a newer, shinier, bigger, and better. Namely, MaraDNS 0.9.12. The main change is that any and all files that I will audit before MaraDNS 1.0.00 will now compile with -Wall enabled with the compile flags. Anyway, get it at MaraDNS.org; or at the MaraDNS sourceforge page. Interesting note: If I got rid of all of the documentation (except for the man pages), I could make the .bz2 file under 200k big, and the .gz file under 260k big. However, I am not going to do this; one of my pet peeves is programs which force one to be online in order to look at the documentation. And, what happens if one needs to look at the docs and the web page with the documentation is down? Worse yet is program which require one to purchase a book to get decent documentation. Which is why I will never take a job at O'Reilly; they make great books, yes, but I don't want to force one to have to buy an O'Reilly book to figure out how to use MaraDNS. I wonder how much space I could save by removing all comments and documentation. And, yes, I have seen more than one open source project with no comments in the source code, and no other documentation. If that was the direction I wanted MaraDNS to go, I would submit her to the obfuscated C programming contest instead of making her available for anyone's enjoyment on the MaraDNS web page and on SourceForge. - Sam From s@s.org Wed Feb 20 00:14:51 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Spam; MaraDNS' features Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit [Snip. The problems with private black lists] As it turns out, MaraDNS is an offender with regard to private black lists; MaraDNS has a feature which allows the DNS server to refuse to query machines with certain IP addresses or on certain subnets. In the default confiuration files, two sets of DNS servers which I know to be DNS servers for spam-friendly interests are blacklisted. As a result, everyone who installs MaraDNS and uses the default configuration will blacklist these particular DNS servers (by IP, no less). Even if both ISPs reform, each and every MaraDNS user will have to update their configuration files. > My goal is to have an authoritative, non-recursive, DNS server which can > simultaneously handle a high query rate (2000+ per second) as well as a > high update rate (2+ per second). MaraDNS is designed to have a next-to-zero update rate; I make changes to zone files about one a month, if even the frequently. As a result MaraDNS needs to be restarted and is a bit slow loading zone files; it takes her a minute or two to load 350,000 resource records. MaraDNS does not even have support for using the HUP signal to relad the zone file; MaraDNS needs to be killed and restarted. On the other hand, MaraDNS is, as it turns out, the fastest authoritative DNS server out there; she is about 3 times as fast as DjbDNS and twice as fast as BIND. This is not accidental; I designed the internal data structures to need as little conversion as possible from raw UDP DNS packets; getting a given RR is essentially a hash lookup and sewing the records together in to the outgoing DNS packet. Yes, the structures do support round robin rotation; I could probably speed things up by removing round robin support. The only DNS server I know of that can handle fast updates is DjbDNS; you have pointed out some of the problems with this particular approach. The way to handle fast updates and fast response rates using "off the shelf" programs is to have a fast recursive DNS server in front of a tinydns server; the recursive server will cache data from the tinydns server. The current data structure of the authoritative DNS server is designed to be static; in particular, each element in the aothoritative structure which has a corresponding A record (NS, MX, and CNAME records) directly points to the memory address of the A record. The cache data, of course, is designed a little differently so that it can handle elements being removed and added constantly; however elements in the cache do have the corresponding A records. They are still legal DNS packets, of course. The data structures are described in quite some detail in the doc/en/source/data_structures.ej document; to view this file, look at it using an HTML browser (e.g. 'lynx -force-html -dump data_structures.ej | less'), or use the ej2txt utility ('../../../tools/ej/ej2txt data_structures.ej | less'). Remove linefeeds in the single quoted UNIX commands. - Sam From s@s.org Fri Feb 22 12:21:24 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Responses to emails recently sent to the list Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Franky: Thaks for the report that MaraDNS mysteriously freezes after being run for a while. I can not reproduce this problem using the offline stress tests; I will see if using your lists of 10000 host names can reproduce this problem. In addition, my very light using of MaraDNS on my laptop has not caused this to crop up. If anyone else is seeing MaraDNS freeze, please let me know. Right now, I am working on the auditing of the MaraDNS code; I will suspend that if this is a recurrent problem. As for storing CNAME records in the cache, MaraDNS will store a CNAME in the cache for the period of time specified in the TTL of the CNAME of the record; the only exception being the case where MaraDNS was unable to get any record at all. DNS has a special "this record does not exist entry"; when the A record corresponding to a CNAME record gets this reply MaraDNS will store the CNAME. The minimum TTL for a record in MaraDNS' cache is five minutes; this is because shorter TTLs are problamatic. Mole: MaraDNS does not support syslog(), much less SNMP calls (and considering the last rish of SNMP security bugs, this may be a good thing). I am adding this fact to the MaraDNS man page for the next rlease. Auditing progress: The decompression code really ought to be redone in a cleaner form, which will be simpler to understand and audit; since the DNS decompression code is the first significant piece of code which processes an incoming DNS packet. From s@s.org Mon Feb 25 02:13:08 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.13 released; hanging issue resolved Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit The opposite of love is not hate. It is indifference. I am, by and large, indifferent to the fault of Windows, expcept when said faults are shoved in my face (e.g. people sending me Word documents which make OpenOffice crash and which none of the other word openers can read at all). However, I am definitely not indifferent to the faults of UNIX, which exists today by and large as Linux. The fact that Linux is the future of UNIX (well, OK, Linux and Mac OS X) is etched in stone with SUN's recent announcments. SUN is always the /last/ company to pick up on a trend. They were the last to release a SYSV UNIX (Solaris), and they are the last to fully embrace Linux. Scott has now worn a Penguin costume and embraced Linux with gritted teeth. That in mind, I was looking at the UNIX-haters archives today. My gripes with UNIX are in many ways very different than the gripes of the UNIX haters, which are circa 1990 or so. One thing very interesting about these gripes is that they remind me of the gripes of many Linux people against Windows; pointing out certain bugs and saying "See! This means that XXX OS completely sucks!". This is not a valid argument. Then again, I agree that UNIX is just too !@#$ arcane for the end user; that UNIX has a very weak security model; that X is far too bloated; and that tar until about a year ago would destroy a tar file if someone typed in "tar cf foo.tar" instead of "tar xf foo.tar" was the kind of bug that a properly designed OS should plain simply not have. My main objection to Windows is very simple: It is not free (/libre/) and open; if Microsoft GPLed Windows and a decent development environment for it, I would install Windows in a heartbeat. Yes, there are other minor annoyances about it; the only one that matters is the lack of /libertad/. And, no, I can't use AtheOS or any of the other small bit players; my laptop has exotic enough hardware (Winmodem; NeoMagic chipset) that the only OS besides Windows that can effectively use the hardware on this thing is Linux. Which is why I have to bug people on this list for accounts on Solaris and OS X machines to test MaraDNS on. My objection to UNIX is that it is a 30-year-old OS; that is 30 years of cruft. No sane person should have to learn TROFF to write a manual for a program, but that is /exactly/ what Linux makes me do. Too much inertia and no benevelent dictator to improve things. The only hope UNIX has of mattering on the desktop lays with Steve Jobs and Mac OS X; ironic that BSD survives as SYSV slowly dies. The pundits of ten years ago stated that BSD was the past; that SYSV was the only UNIX that mettered. UNIX is more likely to have people using 10-year-old tools with it. Why is it that I can send my mother, my sister, my dear friends in Mexico, and just about everyone /except the UNIX crowd/ email with formatting which is not from the stone age? I am not talking about shoving closed standards like Real Audio or Shockwave flash down people's throat either. I am talking about using an open standard which have been codefied over six years ago as RFC1866. An open standand everyone /except the UNIX weenies/ can accept without problem. I guess the UNIX weenies will not accept any new technology which was invented after 1985. As a disclaimer: there are no "UNIX weenies" on this list. MaraDNS was invented well after 1985; I have seen UNIX weenies justify the existence of what a sane person would call a bug in BIND: The bug where BIND would never remove elements from the cache until their TTL expired. This particular weenie was under the delusion that it is more important to "honor the TTL of a RR" than to not have a process use 1 gig of ram if someone give the DNS server too many different queries. Another thing: There seems to be a genral hatred of threads among the UNIX community. Alan Cox is reported saying "Threads are for people too dumb to design state machines". Perhaps because UNIX did not have threads in 1985. As a result, there has been little effort for Linux to get threads right. As a result, as Franky has seen, MaraDNS has this way of hanging if more than 100 or so threads are open at the same time. The fix is simple: MaraDNS now has a hard limit of 100 threads being open simultaneously. MaraDNS will refuse to start if someone asks MaraDNS to be allowed to spawn more threads. This will, alas, break some MaraDNS configuration files, but I hope the error message which MaraDNS pops out is clear enough so people can fix their mararc files. I also fixed a bug where debug_msg_level could only be changed if recursion was enabled. Here is the detached GPG signature for maradns-0.9.13.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8egIfC+jWrh5h/KYRAg1DAKCSlrormAJtelaySODvdWM9besBbQCePjMk XK/WSq7uCgkHYVg3PoKv80g= =Ny1L -----END PGP SIGNATURE----- To verify: gpg --verify maradns-0.9.13.tar.bz2.asc maradns-0.9.13.tar.bz2 The public key is in the top-level MaraDNS directory, and has the following fingerprint (try 'gpg --fingerprint MaraDNS'): D167 252A 18BC D011 7CB4 6CA8 0BE8 D6AE 1E61 FCA6 Interesting thought about free software: Now that NA has dropped PGP support, the only maintained PGP implementation is GPG; this shows the strength of /software libre/. Anyway, have fun with the new release! - Sam From s@s.org Mon Feb 25 12:58:47 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: What if Mariana Torres became my wife? Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit [Christian asked about an OS with a better security model] As it turns out, that OS with a better security model is right under our noses; it is called Linux. "man 2 capset" is the ticket. There is also the EROS project at http://www.eros-os.org/; however that code is going to take a while to be usable (if it will ever happen; free software projects have this annoying of mysteriously dying). The problem with using capset is that I have just changed my application from being a cross-platform UNIX application to being a Linux-only application. Quite frankly, I think all of the other Unixes should close the Linux capset() capabilities; Linux is, for better IMHO, the leading UNIX right now. Solaris and AIX, of course, are more scaleable at the high end. Linux, however, is catching up while the old "big iron" Unixes are standing still. [And a nice discussion about "What would we do if Bill Gates GPLed Windows"] You know, the nature of these discussions is akin to asking "What would I do if Mariana Torres (The actress, not the tennis player) decided to marry me?" Well, I would have a beautiful girl as a wife; however I think it would be a challenge to have a wife who every guy on the street wanted to get together with. And, of course, her fame, such as it is, may get in the way of us doing things together in public. If Bill Gates GPLed Windows and Office (which is about as likely to happen), the de facto standard of desktop computing would finally be open and free. Spyware would quickly cease to be a problem because people would, in very short order, post patches which stop the nefarious spyware activities. I am sure the code is messy and difficult to maintain, of course. Then again, it is probably readable enough that people would be able to to fix the most obnoxious security holes. I am sure that I would switch from Linux to Windows were this to ever actually happen. I would suddenly be able to run a lot of programs which I currently can not run on Linux; and I would be more "in sync" with the desktop computers that most people use. As for free software on Windows, anything of importance has been ported there, including MaraDNS (via cygwin). In fact, I recently downloaded and installed Mozilla 0.9.8 on a Windows machine I am using so that I could disable those annoying pop up ads. [The HTML email rant and Christian's reply] Posting that particular rant felt good; I feel that I finally articulated in a reasonable manner one of the biggest annoyances I have with a lot of the UNIX mind set. Of course, the fact that normal UNIX text email looks like garbage on my particular webmail account does not help. Christian, I feel that you have posted one of the most reasonable arguments, as such arguments go, against HTML mail. I personally can not speak on behalf of third world countries; however I believe that there are people on this list still using shell accounts to get on the internet (please pipe up if you are one of these people). I know that in the one developing country I have visited, Mexico, they have plenty of internet access; it, however, is paid for by the hour (between one and three dollars an hour), and is accessed via Windows machines in cyber cafes. Everyone there that I emailed, without exception, uses a webmail account to access email. Email, as it turns out, is the only really reasonable way to keep in touch with people down there. Phone calls are expensive, especially going out from Mexico, and postal letters take a month to get delivered. Anyway, here is a GPG sig for maradns-0.9.13.tar.gz (note the .GZ): -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8egIiC+jWrh5h/KYRAmM2AJ48HPnvKhaeUMUCv7d54RDYQ3TUhQCfbD8G YmJyVYmQ2ZzGnoBJVjgBhS0= =oT1z -----END PGP SIGNATURE----- If anyone at all is still seeing the freeze ups, please let me know. If you do encounter a freeze up, here are some things to check: * See if you can still get the version number of MaraDNS by sending a TXT query for "erre-con-erre-cigarro.maradns.org" to the MaraDNS server (e.g. "dig @127.0.0.3 erre-con-erre-cigarro.maradns.org txt" or "askmara Terre-con-erre-cigarro.maradns.org. 127.0.0.3"). * See if MaraDNS is up against the wall in terms of the number of threads open; MaraDNS on Linux does not answer queries once the thread limit is reached. This can be done by a "ps auxw | grep maradns | wc -l" or, to simply see the processes "ps auxw | grep maradns". * See if there is a large UDP send-Q for the MaraDNS process in question; this indicates that MaraDNS is not even listening for UDP requests, or that MaraDNS is getting requests faster than she can process them. To see this, run "netstat -na". A MaraDNS instance without a UDP send queue will look like this: udp 0 0 127.0.0.3:53 0.0.0.0:* One with a send queue will look like this: udp 65520 0 127.0.0.3:53 0.0.0.0:* In the meantime, I am closing the freeze up bug; the next release will start the rewrite of the DNS decompression code. I need to get this right; the decompression code is the "front line" in terms of validating a DNS packet and making sure that there is not invalid, potentially exploit creating data there. I hope to get MaraDNS 1.0 out soon; having a program perpetually in a code freeze gets frustrating after eight months. - Sam From s@s.org Tue Feb 26 13:42:58 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Documentation format; threads; freezeing bug; charting tools; etc. Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit The freeze up bugs: Thanks for the report. I obviously have to open this bug up again. One thing I don't want to do with MaraDNS is do what I call the "KDE phenomena". This is where, instead of fixing bugs, the developers instead threw out the old code and develop a new code base. There was a problem where older versions of Kmail would stop working after some day in early 2001 (or was it september of 2000); instead of fixing the bug, the KDE development team told people that they should just be using a new version of Kmail. I am sure that Linus Torvalds had every intention of releasing Linux 1.0 in 1992. It did not get released until 1994; getting something as complicated as a kernel to be reasonable stable is not easy. Especially when the bugs are not readily reproducable, as these mysterious freeze up bugs are. Needless to say, I have not seen them myself; but I am only using MaraDNS for casual web surfing. The stress tests which I run myself on MaraDNS aren't reproducing the bugs; perhaps it is time to change the stress tests. Threads: I know a lot of people in the UNIX community do not like using threads; they feel that development with threads can cause a lot of bugs to pop up which would not otherwise pop up. The decision to use threads came after a lot of thinking on the subject; the problem is that it is very difficult to design and implement a state machine which can handle recursive DNS queries is extremely difficult, due to the downright yuky nature of recursive DNS. DNS, looking back, was poorly designed in many ways. Ideally, DNS should be replaced by -something better-; I have been doing a lot of thinking in the last two days what exactly that "something better" would be. DNS is what happens when a committee tries to design a format which pleases everyone. DNS was designed so that it is fairly easy to design a program which can be run on the command line to find the IP for a given host name; I was able to develop the debug.hostname tool which does precisely this in a single afternoon. However, going from this to a program which implements DNS as a state machine is not trivial. I wanted something that would do recurisve queires and would work; I felt that trying to do this as a state machine would have been taken too much time. As, as it turned out, after five months, I had a working recursive DNS server. And have been spending another eight months fixing the bugs. The documentation language: I just wrote a long rant on this subject, which, in my better judgment, I have deleted. I probably could have written ej2docbook and docbook2ej filters in the time it took for me to write that rant. I like EJ because I have full control over the format; if I need to add a tag to it, I can without going through a standards committee. The solution for people who like a different format is to write a tool which translates to and from that format. A single unified format, by nature, can not possibly please everyone. ej2your_favortite_format and your_favorite_format2ej is the best I can do. Charting tools: I feel the best way to implement this is to have a program which reads log messages from the standard input, and puts them in a log file specific for the logging tool in question. I get the feeling that I will end up being in the position of dissapointing someone if I choose, say, MRTG instead of syslog. An open ended system which makes it easy to add a tool to convert MaraDNS's data to your_favorite_charting_tool is the best solution. And, yes, it is more important to fix the bugs right now than to implement a charting tool. HTML email: Dr Richard Felker has another excellent objection to HTML mail. In fact, his objection is well supported here: http://www.linuxfreemail.com/faq.html It is really nice to see that the level of discussion is far better than the junk I see on Usenet and Slashdot. It is sad to see posts I make (I am "Kiwi" there), which I did not feel were particularly profound, get modded up. It is nice to see this getting discussed in a reasonable manner. Flames are the worst impediment to a reasonable discussion which may actually change someone's mind. I will send HTML email to all my webmail using and AOL friends; and text email to people using UNIX tools. Everyone is happy and end of story. - Sam From s@s.org Wed Feb 27 21:10:28 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Plans for the next MaraDNS release Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit The next release of MaraDNS will deal with two issues which people have brought up here. First of all, yes the EJ format is a little strange; a lot of people are more comfortable working in a format they already know, such as docbook. Since EJ and docbook are, in many ways, very similar, it should be a simple matter to make docbook2ej and ej2docbook filters. Docbook is, as far as I can tell, the closest thing to a SGML-based standard documentation format. Or, perhaps, I will make ej2linuxdoc and linuxdoc2ej filters (I get the sense that Linuxdoc is docbook with Linux-specific extensions). Naturally, I don't know that much about docbook; however, www.linuxdoc.org or (possibly) www.docbook.org should have the information I am seeking. The problem with TeX based systems (LaTeX; gnu's Info format, etc.) is that I would have to install TeX on my laptop to look in those kinds of systems; my hard disk is not as big as I would like. Second of all, I am glad that MaraDNS is a free software project. I have been on proprietary software projects where I say "there is this bug; I think it is pretty serious and it needs to be fixed" and they say "We need to realease this software by such-and-such a date; and do not have time to deal with your bug". Free software does not have that kind of pressure; if, say, Posadis gets released first, it does not really harm me. At this point, it looks like MaraDNS is pretty darn stable. I can use it for personal web browsing needs without having to worry about MaraDNS blowing up on me or being unable to resolve a web site I may want to visit; I am sure MaraDNS would be stable enough for a small business, or, for that matter, any size business where someone would "bounce" (restart) her when the rare hang happens. That said, it isn't good enough for me to make it a 1.0 release yet. We are still seeing MaraDNS hang in the stress tests. I really can not find the cause of this until I am able to reproduce the hang; I get the feeling that a rare race condition is causing the cache to be currupted. MaraDNS has a structure where this kind of corruption will generally not cause MaraDNS to crash (leading to a potential security hole); but it can cause MaraDNS to hang (Denial of Service; but those are far less serious). What I will do, then, is attempt to set up Franky's test so that I can run them offline; this may give me the ability to find a set of conditions which consistantly reproduces the hang. This kind of "finding a needle in a haystack" work is not fun; but it needs to be done. When I made MaraDNS public, I made a committment to the internet community that MaraDNS 1.0 would be a reality, and that MaraDNS 1.0 would be a stable and secure DNS server. I have seen too many free software projects be silently abadoned before a 1.0 release is ever a reality; I feel that that kind of software devlopment is irresponsible. - Sam From s@s.org Sun Mar 03 11:08:38 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.14 released; debug.hostname rewritten Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit MaraDNS 0.9.14 has been released. The main change is a rewritten debug.hostname, which should be able to resolve more real-world hostnames; I should be able to use this new tool to make a offline mirror of Franky's test. Hopefully, I will come up with a test which reproduces the hangs that Franky is occassionally seeing. - Sam From s@s.org Wed Mar 06 13:25:18 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Jaakko has just re-packaged MaraDNS, so guess what I do Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Since Jaakko has just repackaged MaraDNS, it was my dutiful obligation to release yet another release of MaraDNS out to the world. Which I have done. My mission to keep Jaakko less than current with the Debian package is one of continued vigilance. Speaking of which, I would like to include the Debian-specific meta-data used for making the Debian package of MaraDNS available as part of the MaraDNS suite; just as I include a RPM spec file there. MaraDNS 0.9.15, alas, does not fix the latest in the "MaraDNS freezes after a while" bugs which have been discovered. What it does have, however is better tools for making an offline test suite which may hopefully reproduce the problems in question; so that I can find and fix the offending code in question. Askmara has a new option which allows people to send out queries without asking for recursion. The installer is fixed so that it doesn't overwrite old MaraDNS startup scripts. There is only one minor change to the actual maradns server: It now has a thread limit of 200 instead of 100; and if the limit is exceeded, MaraDNS now resets the limit to 200 instead of terminating with a fatal error. There are also some minor FAQ updates, which answer the question about Python integration posed to this list; and which correctly answer the question about MaraDNS on Cygwin again. Here is the PGP signature for maradns-0.9.15.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8hoVeC+jWrh5h/KYRAvVLAJ9U26wHMqKG+Cr4QwmuqX9P4MyIMACbBSFu 156V84PcEWB1QQFF5RDddu8= =3pZ5 -----END PGP SIGNATURE----- Anyway, I am glad to see MaraDNS is getting more users, and I hope to get the last few bugs fixed soon. - Sam From s@s.org Thu Mar 07 12:55:03 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Helping me with MaraDNS freeze-ups Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit I appreciate all of the offers of support with regard to the freeze up bug we are currently seeing in MaraDNS. That in mind, here are some things which may help. First of all, make sure your /etc/mararc file has a verbose_level of three, this is done with a line like this in the mararc file: verbose_level = 3 Also make sure the output of MaraDNS is beging logged somewhere; the start up scripts will do this for you. When a freeze up happens: * See if you can still get the version number of MaraDNS by sending a TXT query for "erre-con-erre-cigarro.maradns.org" to the MaraDNS server (e.g. "dig @127.0.0.3 erre-con-erre-cigarro.maradns.org txt" or "askmara Terre-con-erre-cigarro.maradns.org. 127.0.0.3"). * See if MaraDNS is up against the wall in terms of the number of threads open; MaraDNS on Linux does not answer queries once the thread limit is reached. This can be done by a "ps auxw | grep maradns | wc -l" or, to simply see the processes "ps auxw | grep maradns". * See if there is a large UDP send-Q for the MaraDNS process in question; this indicates that MaraDNS is not even listening for UDP requests, or that MaraDNS is getting requests faster than she can process them. To see this, run "netstat -na". A MaraDNS instance without a UDP send queue will look like this: udp 0 0 127.0.0.3:53 0.0.0.0:* One with a send queue will look like this: udp 65520 0 127.0.0.3:53 0.0.0.0:* * Send me the MaraDNS logs in personal email. Again, I appreciate all of the help people are giving me with this issue. I am also, myself, working on making an offline database which I hope will consistantly reproduce this bug. Once I can reproduce it, it will be easy enough to fix. - Sam From s@s.org Tue Mar 12 14:48:26 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.16 release Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit The more I use Linux, the more appealing Windows looks. I think the main reason that Windows users complain so bitterly about Windows is because, well, they are bitter Windows user. I, on the other hand, am a much more enlightened life form. Namely, I am an enlightened Linux user. Which give the the privledged position of complaining about Linux. The subject of today's rant is Unicode. Basically, Windows has been, for all intents and purposes, there with regards to using Unicode to encode any important piece of information. In fact, they use the 16-bit version of Unicode, which is a more compact representation of languages which do not use western script. BeOS had Unicode support from the get-go. Java's virtual machine uses Unicode for all internal strings. Plan 9 and Inferno, Unix's sucessors, have great Unicode support, using the UTF-8 encoding. In fact, it is only the free *nix clones which are still holding on to the bad 'ole pre-Unicode days. I should probably explain what Unicode is, so that I no longer sound like one of those middle management types which uses a lot of buzzwords without understanding what they really mean (insane people do the same thing; perhaps there is a correlation). Unicode is the ASCII of the 21st century. Just as ASCII is a standard which describes how to map binary numbers to numbers, letters, and symbols in the English language, Unicode is a standard which describes how to map binary numbers to numbers, letters, and symbols in to just about any real-world human language. Using the same encoding, someone can have English, Spanish, Esperanto, Japanese, Chinese, Korean, Tibetan, and text in just about any other language that exists. It is the only viable long-term solution for multi-lingual document storage. In particular, with UNIX filesystems which do not have any metainformation about files, it is better to use one encoding which can represent any language without trouble. Unicode has several way of representing its symbol set. UCS-2 (or UCS-16) are way of representing symbols using multiple bytes per character. UTF-8 is a way of representing non-ASCII Unicode characters by using multiple hi-bit characters; ASCII characters do not change when using UTF-8 encoding. With UNIX systems, and their dependence on ASCII, UTF-8 is the only really practical way of bringing Unicode to UNIX. So, people have been working really hard on making UTF-8 a reality on Linux. And, in the spirit of free software, Linux is not ready for a seamless conversion to UTF-8 yet. I know; I just did such a conversion on my Linux laptop. After having to write UTF8to8859-1 and 8859-1toUTF8 wrappers for the two legacy command-line applications which use 8859-1 encoding (ispell and compjuga); I discovered that GTK 1.2.x has no UTF-8 support whatsoever. Thankfully, GTK 2.0.x does, but GTK 2.0 just came out. What it comes down to is that I have to recompile all my applications using the GTK 2.x kit to get GUI UTF-8 support. Until then, filenames with non-English characters in them (I have a directory called 'español') look butt-ugly in my GUI applications. In addition, groff has very poor utf-8 support; it only accepts iso 8859-1 in *roff source files. The story is, apparently, the author of Groff lost interest in the program a long time ago, and there is no one who knows the Groff internals well enough to make the transition to UTF-8. Well, at least MaraDNS has been converted to UTF-8. This was far more trouble than I thought it would be. In addition, I have fixed a bug in debug.hostname where certain hostnames would not resolve with it. Hopefully, I will be able to reproduce the freeze that I know is there, but that is not consistantly reproducable. Here is the GPG sig for maradns-0.9.16.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8jn43C+jWrh5h/KYRArSVAJ0R3EfqOTL3acipsmRKTd60lhrQzQCgoZuJ mr/jDU6Uw5Ug5ZwI0s5je9I= =rz7B -----END PGP SIGNATURE----- - Sam From s@s.org Tue Mar 12 15:03:47 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: More on 0.9.16 In addition to the changes I already mentioned, I have also updated the MaraDNS FAQ to answer any questions recently posed to this list; and imporved the example files and documentation where people were confused. This hopefully will make MaraDNS easier to use for the next person who picks it up. - Sam From s@s.org Wed Mar 13 11:57:02 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: How to unsubscribe from the list Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit For other people who wish to unsubscribe to the list, and joined the list before November, what happened was that we had to change the server the mailing list was hosted on; as a consequence, the method for unsubscribing has changed. The old method was to send an unsubscribe request to list-unsubscribe@maradns.org; the current method is to send a request to list-request@maradns.org with "unsubscribe" as the subject line. I have a feeling that I will need to repost this once MaraDNS starts catching on; people start sending unsubscribe requests to the mailing list once the traffic picks up. - Sam From s@s.org Thu Mar 14 00:44:16 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: OK, someone can actually use that particular feature Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit >The machine uses my ISPs dns servers as its primaries. Unfortunatly, this does not work with the present version of MaraDNS. I have thought about implementing this in MaraDNS; it merely requires me to have maradns request recursion from a remote DNS server when performing a recursive query; and making sure that MaraDNS only queries the "upstream" server. (There is the possibility of a nasty feedback loop if MaraDNS accepted and followed NS referrals when sending out queries with the recrusion bit on). The only reason I have not implemented it is because of user-interface issues; the /easiest/ way for me to implement it is to have it so what are called the "root_servers" in the mararc file not actually be root servers when MaraDNS is used in this manner; instead they are whatever-name-servers-we-are-contacting-which-in-turn-contact-the- actual-root-name-servers. I didn't want to fall in to the BSD trap: where things are not what they say they are, such as SIGHUP being used to reload configuration files, simply because the programmer is too lazy to correctly name things. I think "upstream_servers" is an appropriate monkier; just have MaraDNS barf if both "root_servers" and "upstream_servers" are set. - Sam From s@s.org Thu Mar 14 11:16:35 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.17; MaraDNS can now be used in "tunneling" mode Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit (I actually released this last night, but immediately after uploading the files and updating the web page, my ISP decided to die on me. I went to sleep. Waking up, my ISP has come back to life) MaraDNS 0.9.17 has a new feature. Which is strange, considering that MaraDNS is supposed to be in a code freeze. However, the feature in question is one that was trivial to add (in fact, the lion's share of the work involved testing and documenting this new feature); it is also a very useful feature, allowing Stan to have the setup he desires with MaraDNS. To explain this in more detail, a DNS query has a "recursion desired" bit. When this is turned on, a DNS query is asking the remote server permission to have it recursively ask other DNS servers for the answer to a question. When this is turned off, a DNS query is asking for the remote DNS server not to query other DNS servers. Now, the reason why you are seeing MaraDNS "freeze up" is not because of some obscure bug with DNS (as I just learned this morning) causing MaraDNS to freeze up. What you may be seeing is your ISP's DNS cache losing entries. The reason you are seeing this is because, with BIND, when sending a request with a DNS packet saying "I do not want recursion"; BIND will give you the answer, but /only if the answer is in the remote server's DNS cache/. So, when the remote server's DNS cache starts clearing out, it may appear, to the user using MaraDNS incorrectly in this matter, that MaraDNS is, after a while, losing entries, because those entries are no longer in the remote DNS server's cache, causing MaraDNS to not get the answers she is looking for. However, this freeze up will only happen when the MaraDNS server, for whatever reason, can not contact the real root servers; usually the DNS server in question will give out a list of root servers (OK, almost root servers) when it does not have the answer in the cache. This, however, is not the desired behavior when using this particular setup. What I have done is this: added a new variable upstream_servers. This works just like root_servers. The only difference is that upstream_servers is what one uses when contacting other recursive name servers, such as one's ISP DNS servers. root_servers is used for contacting, well, the root name servers. In addition, I have fixed some more bugs in debug.hostname; at this point, it looks like it can sucessfully resolve hostname without getting stuck in a loop with troublesome hostnames. Anyway, GPG sig for maradns-0.9.17.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8kHbZC+jWrh5h/KYRAuv4AJ0aOyVIUoVTrGsulmGjazutJICuwQCeMkCP nKpgegdNvSJLM14AmK2pHOY= =PWv+ -----END PGP SIGNATURE----- Since gpg is almost impossible to use, here is how to add the MaraDNS key to your keyring and verify MaraDNS against its pgp signature: To verify: gpg --verify maradns-0.9.17.tar.bz2.asc maradns-0.9.17.tar.bz2 Where maradns-0.9.17.tar.bz2.asc is the above signature. To add the MaraDNS gpg key to your keyring: cat maradns.pgp.key | gpg --import Where "maradns.pgp.key" is the pgp key in the top level MaraDNS directory. To verify the fingerprint of this gpg key: gpg --fingerprint MaraDNS Which should output: Key fingerprint = D167 252A 18BC D011 7CB4 6CA8 0BE8 D6AE 1E61 FCA6 - Sam From s@s.org Wed Mar 20 14:39:57 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS specifications Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit The specifications and list of supported RRs for MaraDNS can be found by looking at the following man pages: man maradns man csv1 These man pages can also be found in doc/en/man/ off of the maradns top-level directory. The bugs section of the maradns man page, in particular, discusses the level of RFC support that MaraDNS has. - Sam From s@s.org Mon Mar 25 13:22:50 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.18 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit This is a minor update; the main reason I am making this public is because it has been over q week since the last MaraDNS release. From the changelog: Fixed a bug in askmara where non-ASCII characters were not properly replaced by escape sequences. Updated EJ documentation tools so that they can now generate webpages in the same format as the web pages on www.maradns.org. GPG sig of maradns-0.9.18.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8n5FHC+jWrh5h/KYRAlMDAJ91iEKr5hS1/355mfwWJRyHkinzsQCfSlDv 0VOjIrPtEj6xE5ze5VMrd2k= =3Uxe -----END PGP SIGNATURE----- - Sam From s@s.org Thu Mar 28 14:10:06 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS can now be in the main Debian (unstable) tree Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit It looks like the powers that be in Debian have decided that cryptographic code can now be part of the main Debian tree: http://lwn.net/2002/0328/a/deb-crypto.php3 As a result, it looks like MaraDNS does not have to relegated to non-US any more. Of course, I have gone to some effort to make the crypto code that is in MaraDNS not usable for anything besides a secure psudo-random number generator. Instead of using AES, it uses a Rijndael variant which can not be decrypted using standard AES libraries; any and all code which could run this variant in the "decrypt" direction has been removed. The code is no more cryptographic than code which implements SHA1. Yes, it is possible to use SHA1 code as an engine for a stream cipher, and, yes, it is possible to write code which runs SHA1 in the decrypt direction. [1] However, this alone does not make SHA1 cryptographic code. At this point, MaraDNS no longer needs to be given second class treatment just because she has some code which some feel may be cryptographic code. - Sam [1] http://www.cosic.esat.kuleuven.ac.be/nessie/workshop/submissions/shacal.zip From s@s.org Sun Mar 31 23:32:41 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.90 to be released shortly Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hello there, Since we are coming closer to the MaraDNS 1.0.00 release, I have decided to shortly release MaraDNS 0.9.90; this will hopefully be one of the last pre-1.0.00 releases of MaraDNS. First of all, I have decided that unicode support is very important for MaraDNS. As a result, I have changed the zone file format so that, instead of using ASCII characters to represent the kind of resource record a given domain node has, MaraDNS will use Unicode characters. The only Unicode encoding that MaraDNS 0.9.90 will support is UTF-8; I hope to have UCS-16 support ready before MaraDNS 1.0.00. The following Unicode symbols will be used to represent various resource records: U263A (Smiling face): A resource records U2709 (Envelope): MX resource records U261E (Hand poinging right): NS records U2621 (Caution sign): SOA records U2620 (Skull and crossbones): CNAME Records U2623 (Biohazard symbol): A6 records U2703 (Hand qith victory symbol): AAAA records This, of course, will require users upgrading to change their zone file format. In the grand tradition of free software, not only will I not document how to change the zone file format, I will not include a script to transition the zone files over either. One, of course, is free to RTFM (HTH), but, of course, I will make the language in the documtation as obtuse as possible. I plan on publishing a book on how to use MaraDNS; this is how I will get paid to developed free (libre) software. This kind of quality care is an old BSD tradition. Anyway, MaraDNS 0.9.90 is not on the web page yet; I still have some details to work out until the new version can be made available. Look for it later on this week. - Sam From s@s.org Tue Apr 02 02:13:45 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: OK, I'm back Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit First of all, I have decided to hold off the MaraDNS 0.9.90 release because of D Richard Felker's objections; nothing of that nature will be released (or announced) on dates besides April 1st. As it turns out, one can put UTF-8 (or just about any other silly binary data) in the host names in zone files; I feel it is up to the user to decide what level of RFC compliance they want with their domain names. Second of all, while the following guide is geared to Debian users, it is the best all-around guide I have fond on the 'net for updating a Linux system to use UTF-8: http://melkor.dnp.fmph.uniba.sk/~garabik/debian-utf8/howto.html Thirdly, wuth regard to making MaraDNS more effective when someone has a large number of domains, all with the same data; I have already received a similar version of this request. I call this idea the "default zone" idea, and the idea is to have a "default" zone. This default zone allows one to have records like "www." or "mail.". Basically, when there is a record for "www.foo.example.com" and "www.", we use the "www.foo.example.com" record. But if they ask for "www.example.com" and we don't have a "www.example.com" record, but do have a "www." record, we give them the "www." record as if it were the record for "www.example.com". This idea has two advantages: 1) It allows large ISP to add new domains without needing to mess with their DNS server. 2) It saves memory Naturally, we can not have both recursive (or upstream) nameserving and a default zone enabled. The amount of work it would take me to do this: Roughly three hours, including documenting the feature. The reason I have not implemented it yet is because we are right now in bug fixing hell; there is a fairly nasty freeze-up bug which only very rarely happens when recursive nameserving is being performed in certain high-stress circumstances. Franky has seen it at least twice in stress testing. I can't reproduce this bug yet, much less fix it; I can't hit 1.0 until I find and fix this bug. It is fixing these kinds of bugs which separate the real software from the hacks. I don't want to add feaures until after 1.0; simplicity, stability, and security come first. In terms of adding a default domain, the easiest way would probably be to hack the parser to allow stars at the end of domain names (www.*, etc.); and then to hack MaraDNS.c to look for stars there. The code which looks for a star record starts around line 2409 of MaraDNS.c. A star record in internally stored as '_' in place of the domain length label; the make_starlabel function converts a raw DNS request so that the first label becomes a star label. In other words, make_starlabel makes "www.foo.example.com" "*.foo.example.com". There is another function, named bobbit_starlabel (named after John Wayne Bobbit, who became famous after his wife cut off his penis) which converts a label like "*.foo.example.com" in to "*.example.com". Probably the solution is to have another "make_starlabel" function which makes something like "www.foo.example.com" "www.foo.example.*", and a corresponding bobbit_starlabel. - Sam From s@s.org Tue Apr 02 14:09:20 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: UTF-8; read RFC2044 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline UTF-8, as described so that software devlopers can understand and use it, is described in RFC2044: http://www.ietf.org/rfc/rfc2044.txt I belive that this RFC is superceded by a newer RFC; basically, the original UTF-8 specification allows multiple bitstreams translate to the same Unicode value. The updated specification only allows the shortest possible UTF-8 sequence which can represent a given Unicode code point to be valid. - Sam From s@s.org Wed Apr 03 11:24:25 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Zone transfers Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline MaraDNS, in an attempt to follow the traditional UNIX philosophy of having separate programs doing different tasks, the serving of zones so that BIND can gets zones from a MaraDNS server is handled by the separate program zoneserver. Please be sure to be running zoneserver. - Sam From s@s.org Thu Apr 04 22:33:18 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: More on zone transfers Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Hello, For me to resolve the issues that maradns@ke.kiev.ua is having, I will need the following information sent, either to me or on the list: * A copy of your mararc file * A copy of the zone file you can not transfer Please send these items to me. If you feel the data is confidental, send it to me in private email. - Sam From s@s.org Fri Apr 05 18:53:44 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: zoneserver _is_ compatible with BIND 9.2.0 and BIND 9.1.3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline First of all, I do not have the name of the person with the email address maradns@ke.kiev.ua; I do not like anonymous identities. If you have a good reason for keeping your name secret, please let us know. Otherwise, please let us know at least your first name. I am having no problem using BIND 9.2.0 nor BIND 9.1.3 to transfer zones from MaraDNS' zoneserver. If you continue to have problems with this, we will need a copy of _all_ your configuration files to help you. This includes: * Your /etc/named.conf file which BIND uses * The output when running 'named -g' * Your mararc file * Any zones you wish to have forwarded Again, if you wish to keep these zones private, please send it to just me in private mail. If you are using the large example.com zone which the sqa testbed generates, do *not* send that via email. I am attaching a (long) session where I sucessfully used zoneserver to transfer a zone to BIND 9.2.0 and BIND 9.1.3. Please send a similiar verbose session when reporting that you are not able to transfer zones using BIND and MaraDNS' zoneserver. Anything less verbose will be ignored; it works for me. "No existe el fichero o el directorio" is "No such file or directory" in Spanish. - Sam Here is the session: [root@vela /tmp]# rm /etc/named/example.bk rm: cannot remove `/etc/named/example.bk': No existe el fichero o el directorio [root@vela /tmp]# cat /etc/named/example.bk cat: /etc/named/example.bk: No existe el fichero o el directorio [root@vela /tmp]# cat /etc/mararc.6 # Example mararc file # The various zones we support csv1 = {} csv1["example.org."] = "db.example.org" #csv1["example.com."] = "db.example.com" # The address this DNS server runs on # bind_address = "127.0.0.3" bind_address = "127.0.0.6" # The directory with all of the zone files chroot_dir = "/var/maradns" # chroot_dir = "/home/set/maradns/zone" # The numeric UID MaraDNS will run as maradns_uid = 99 # The maximum number of processes MaraDNS is allowed to use maxprocs = 64 # simulate network lag #debug_response_delay = 1 # 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 = 2 # 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 # Here is a ACL which restricts who is allowed to perform zone transfer from # the zoneserver program # 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 = {} # 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 = {} # 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" #zone_transfer_acl = "192.168.42.0/24" zone_transfer_acl = "127.0.0.1/8" [root@vela /tmp]# cat /var/maradns/db.example.org # Zone file for example.com (example file) # See 'doc/csv1.format' for detailed help on the format of this file # The SOA record must be first, followed by all authoritative NS records # for this zone. Sexample.org.|86400|example.org.|hostmaster@example.org.|19771108|7200|3600|604800|1800 Nexample.org.|86400|ns2.example.org. # Some 'IN A' records Ans2.example.org.|86400|127.0.0.6 # A CNAME record Ccname.example.org.|86400|www.example.com. # Another record Atest.example.org.|300|127.240.240.240 # NS delegation # Error handling testing Aexample-com.example.org.|86400|127.0.0.4 # A 'PTR' record which, while marked as unauthoritative, allows this # program to work with nslookup when bound on IP 127.0.0.6 P6.0.0.127.in-addr.arpa.|1234|ns2.example.net. [root@vela /tmp]# cat /etc/named.conf /* * Copyright (C) 2000, 2001 Internet Software Consortium. * * Permission to use, copy, modify, and distribute this software for any * purpose with or without fee is hereby granted, provided that the above * copyright notice and this permission notice appear in all copies. * * THE SOFTWARE IS PROVIDED "AS IS" AND INTERNET SOFTWARE CONSORTIUM * DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL * INTERNET SOFTWARE CONSORTIUM BE LIABLE FOR ANY SPECIAL, DIRECT, * INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING * FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, * NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION * WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ /* $Id: named.conf,v 1.15 2001/01/11 20:42:09 gson Exp $ */ options { #pid-file "/etc/named/named.pid"; query-source address 127.0.0.10; notify-source 127.0.0.10; listen-on port 53 { 127.0.0.10; }; #recursion yes; #notify yes; }; zone "." { type hint; file "/etc/named/root.hint"; }; zone "example.org" { type slave; masters { 127.0.0.6; }; file "/etc/named/example.bk"; }; [root@vela /tmp]# maradns -f /etc/mararc.6 & [1] 8417 THIS SOFTWARE IS PROVIDED BY THE AUTHORS ''AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. To not display this message, add the follwing to your mararc file: hide_disclaimer = "YES" Log: Root directory changed Log: Binding to address 127.0.0.6 Log: Socket opened on UDP port 53 Log: Root privledges dropped Log: All RRs have been loaded [root@vela /tmp]# zoneserver -f /etc/mararc.6 & [2] 8418 [root@vela /tmp]# Log: Root directory changed Log: Socket opened on TCP port 53 Log: Root privledges dropped [root@vela /tmp]# ./named-linux-bin -g Apr 05 18:26:23.942 starting BIND 9.2.0 -g Apr 05 18:26:23.945 using 1 CPU Apr 05 18:26:23.954 loading configuration from '/etc/named.conf' Apr 05 18:26:23.979 no IPv6 interfaces found Apr 05 18:26:23.980 not listening on any interfaces Apr 05 18:26:23.985 /etc/rndc.key:1: unknown option '9843u2983yriufhewqwf' Apr 05 18:26:23.985 /etc/rndc.key:2: unexpected token near end of file Apr 05 18:26:23.985 couldn't add command channel 127.0.0.1#953: unexpected token Apr 05 18:26:23.985 ignoring config file logging statement due to -g option Apr 05 18:26:23.986 running Apr 05 18:26:23.996 transfer of 'example.org/IN' from 127.0.0.6#53: ignoring out-of-zone data Apr 05 18:26:24.181 zone example.org/IN: transfered serial 19771108 Apr 05 18:26:24.182 transfer of 'example.org/IN' from 127.0.0.6#53: end of transfer Apr 05 18:26:24.182 zone example.org/IN: sending notifies (serial 19771108) Apr 05 18:26:32.588 shutting down Apr 05 18:26:32.591 exiting [root@vela /tmp]# cat /etc/named/example.bk $ORIGIN . $TTL 86400 ; 1 day example.org IN SOA example.org. hostmaster.example.org. ( 19771108 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) NS ns2.example.org. $ORIGIN example.org. cname CNAME www.example.com. example-com A 127.0.0.4 ns2 A 127.0.0.6 $TTL 300 ; 5 minutes test A 127.240.240.240 [root@vela /tmp]# rm /etc/named/example.bk rm: remove `/etc/named/example.bk'? y [root@vela /tmp]# named -g Apr 05 18:50:50.081 starting BIND 9.1.3 -g Apr 05 18:50:50.084 using 1 CPU Apr 05 18:50:50.096 loading configuration from '/etc/named.conf' Apr 05 18:50:50.107 the default for the 'auth-nxdomain' option is now 'no' Apr 05 18:50:50.131 no IPv6 interfaces found Apr 05 18:50:50.134 not listening on any interfaces Apr 05 18:50:50.143 ignoring config file logging statement due to -g option Apr 05 18:50:50.148 running Apr 05 18:50:50.158 transfer of 'example.org' from 127.0.0.6#53: ignoring out-of-zone data Apr 05 18:50:50.163 transfer of 'example.org' from 127.0.0.6#53: end of transfer Apr 05 18:50:57.131 shutting down Apr 05 18:50:57.139 exiting [root@vela /tmp]# cat /etc/named/example.bk $ORIGIN . $TTL 86400 ; 1 day example.org IN SOA example.org. hostmaster.example.org. ( 19771108 ; serial 7200 ; refresh (2 hours) 3600 ; retry (1 hour) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) NS ns2.example.org. $ORIGIN example.org. cname CNAME www.example.com. example-com A 127.0.0.4 ns2 A 127.0.0.6 $TTL 300 ; 5 minutes test A 127.240.240.240 From s@s.org Tue Apr 16 23:47:19 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.19 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Working with Ivavov in private mail, we determined what was causing his problem. Basically, when MaraDNS is bound to more than one interface, MaraDNS will not always send a reply out with the same IP that received the request. This confuses BIND9. I have added an entry to the FAQ which addresses this concern. In addition, I have added a filter which somewhat converts the documentation from the ej format to Docbook. Not very good docbook, mind you, since tags are not properly closed, but good enough that jm can make HTML from Docbook made by this filter. While I do plan on improving this filter, the improvments will be done after MaraDNS 1.0 is released. Here is the detached GPG sig for maradns-0.9.19.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8vRXrC+jWrh5h/KYRAhxGAJ0TWQTFC8vqqu8Z2IOdMpmf3POgfACfXiZ/ AnapwdMAtoWvt89gieSOWFM= =5FV7 -----END PGP SIGNATURE----- Plans for the next release: Make the minimum TTL for CNAME entries in the cache user-configurable; this way difficult-to-resolve hostnames which use CNAME chains such as "news.com.com" will stay in the cache longer. I will probably also make the global minimum TTL user-configurable. - Sam From s@s.org Tue Apr 16 23:52:59 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Change in mailing list policy Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline I have asked Remco Rijnders, the person hosting this list (and hosting samiam.org and maradns.org), to change the mailing list policy so that only subscribers can post to the list. If a non-subscriber posts to the list, the message is forwarded to me, and I can forward the message to the list myself. This will hopefully eliminate the spam that this mailing list has been getting; implementing this policy on the old mailing list got rid of the spam problem there. I would like to thank Remco for making this change. - Sam From s@s.org Mon Apr 22 18:23:19 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Thanks for the patch Ivanov Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Ivanov, Thanks for the patch! I will integrate the patch in to the next release of MaraDNS; however I do need a declaration that the patch is public domain before I can do this. Thank you for your contribution. - Sam From s@s.org Mon Apr 22 22:47:17 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.20 coming out soon; hopefully tomorrow Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Thank you for the public domain declaration; I will be releasing a 0.9.20 release of MaraDNS soon which incorporates this patch soon. In addition, the next release of MaraDNS will have a user-definable minimum TTL; this is useful for people on slow connections who want a faster reply with some sites. For example, news.com.com takes a long time to resolve over a dialup; the minimum_ttl will keep it in the cache longer. - Sam From s@s.org Wed Apr 24 05:40:54 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.20 out Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline First of all, I made some modifications to Ivanov's proposed patch. The main one is that, instead of showing a localized time, MaraDNS's log shows a UNIX time stamp. It is easy enough to make this human-parsable, e.g.: #!/usr/bin/perl while(<>) { if(/Timestamp: (\d+)/) { $lt = localtime($1); s/Timestamp: (\d+)/Timestamp: $lt/; } print; } It is not MaraDNS' job to do this conversion. Making a human-readable timestamp is trickyier than Ivanov's patch implies; there are a lot of internationalization issues which I feel a simple, ideally high-security DNS server should not deal with. Or, maybe, that I am simply too lazy to deal with. For future reference, here is the procedure for making a proper patch: * Enter the directory that the file is in, for example maradns-0.9.20/server * Copy over the file that you wish to modify to another file name. For example "cp MaraDNS.c MaraDNS.c.orig". * Edit the file MaraDNS.c * After editing, do something like this: diff -u MaraDNS.c.orig MaraDNS.c > maradns.patch * Make sure the modified version compiles cleanly * Send that patch to the mailing list In addition, the minimum TTL is now user-configurable. I have not fully tested it, but will do so after going to bed. I have not fully tackled on the hard issues yet; Franky's hard-to-reproduce freeze ups still is an issue. In addition, I am having problems with MaraDNS returning "Server failure" when asked to resolve "news.com.com"; I have changed MaraDNS to log where the routine which outputs the server fila is called so I can narrow down what is causing this. One of these days, MaraDNS will come out. - Sam From s@s.org Wed May 01 14:55:06 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: An argument against using docbook Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline OK, that does it. MaraDNS will now /never/ use docbook as her documentaiton format: http://linuxtoday.com/news_story.php3?ltsn=2002-05-01-019-26-SC-RH - Sam From s@s.org Thu May 02 05:13:52 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.21 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline MaraDNS 0.9.21 released; this is a minor bugfix release. I fixed a bug which previous versions of MaraDNS had; now MaraDNS can have a separate minimum TTL for CNAME records as opposed to A records. In addition, I have updated the FAQ to address MaraDNS' UNIXy timestamps, including supplying a small Perl script to make the time stamps human-readable; and have added a tool which is a simple "stub" DNS server which converts all requests for A records in to time stamps. This is used for testing purposes; perhaps I should make a similiar program which does the following: * Respond to all A requests with the IP the DNS server is bound to (this DNS server, of course, would have to forbid binding to "0.0.0.0") * Respond to all MX requests by saying "name in MX name"; where the A record for name will have the IP in question. Not suitable for anything fancy, but good enough for people with cable modems who want to have a domain without needing to configure anything except the IP the DNS server is on. Post-1.0 methinks. Anyway, it is at you freidnly local maradns.org web site PGP sig for MaraDNS-0.9.21.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA80ShAC+jWrh5h/KYRAgnvAKCib5iVPxpMCJblYNR3ZnO9wHXN5QCdGdym WqMNpZIU5VtidWOAmOLPS+0= =lW1D -----END PGP SIGNATURE----- - Sam From s@s.org Thu May 02 13:26:08 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS and RFC822 dates Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline I will not make a patch which has MaraDNS output RFC822 dates part of the main tree; I am willing to have it be available separately on the MaraDNS web site, however. The reason I don't like RFC822 dates is because: * They are difficult to have scripts parse. * They are too America-centric; I feel that this date format is a subtle form of cultural imperialism. * It is a 5-line Perl script to convert the timestamp format, and I do include the Perl script in question with the MaraDNS distribution. - Sam From s@s.org Thu May 02 15:04:02 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Timestamp conversion can also be donw with awk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline For Ivanov, who doesn't have Perl on his server, this timestamp conversion can also be done with awk, e.g: maradns | awk ' /Timestamp/{ gsub(/Timestamp: ([0-9]+)/, strftime("%a, %d %b %Y %H:%M:%S",$2),$0)} {print}' >> /var/log/wherever I have included all of this information in the FAQ. This goes back to the "Do we hand them a fish or teach them how to fish?" argument. If open source devlopers keep handing people fish, the users will continue to expect more and more fishes. If, however, we teach them how to fish, they will learn how to become open source developers. There are just not enough open source developers out there to hand every single open source user a fish. To quote Linus Torvalds, "show me the code"; people who request features but do not provide real patches will be ignored or told "no". I have already explained how to correctly make patches; this information has been added to the FAQ. This information I am giving does not just apply to MaraDNS; people who get involved with other open source projects will be told more or less the same thing, or will be ignored. I hope this information helps the aspiring open source devlopers here; the sooner they learn the ropes, the sooner they can become members of the open source development community. - Sam From s@s.org Thu May 02 15:30:54 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Timestamp conversion can also be donw with awk Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >I must repatch every new MaraDNS version now (to make RFC time in >it.... ) No, you do not. Patch is smart enough to apply the same patch, even if the area to patch has moved around in the source code. I showed you how make a patch with diff. Once a patch is made with diff, one can patch with patch, e.g: patch < some.diff If using RPMs, the patch can be included with the source file. Sigh. Ivanov, I don't think you are listening to me. Why should I listen to you if you are not listening to me? I am now filtering all mail from Ivanov on my mail account; I have better things to do with my time than to deal with people who keep asking for features and who keep not doing anything to make these features available. Ivanov, I know English is hard for you to read, but please read what I write. That fact that you do not means that you do not respect me. I do not listen to people who do not respect me. - Sam From s@s.org Thu May 02 15:46:37 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Cc: maradns@ke.kiev.ua Subject: Administriva: Ivanov has been taken off of the MaraDNS mailing list Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Hello everyone, I hate to do this, but I feel that Ivanov is not making productive contributions to MaraDNS. He is posting things which result in flame wars on the mailing list. As a result, I have reluctantly taken him off of the mailing list and have added him to people who can not send mail to me. He is free to try to resubscribe to the list; however if he continues in his previous behavior I may have to permanently ban him. This is a step I only take after serious consideration; unfortunatly, MaraDNS is something for which I am not being paid, and there is a risk that I will abandon the project altogether if I have to deal with people who act in that manner. I do apologize for overreacting to the Docbook security hole yesterday; I guess I have been getting pretty frustrated and expressing my frustration in inappropriate ways. While there are things about the Docbook format I do not like--I feel that it is too complicated--I understand that it is quickly becoming the standard documentation format for Linux projects. - Sam From s@s.org Thu May 02 16:08:23 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Yes, Sean, I will accept a patch from you Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline OK, Sean, I will accept the patch from you; however it needs to be a feature that someone can turn on and off in the mararc file. To add a new switch to the mararc file, add the switch it parse/ParseMaraRc.c. Be sure to increment KEYCOUNT by one. Once this is done, the code which reads in switches from the mararc file is in server/MaraDNS.c (in main()), and would look something like this: /* Determine the maximum time to wait for a remote server (in seconds) */ use_rfc822_timestamp = 0; if(js_qstr2js(kvar_query,"use_rfc822_timestamp") == JS_ERROR) harderror(L_KVAR_Q); if(read_kvar(kvar_query,verbstr) == JS_SUCCESS) { use_rfc822_timestamp = js_atoi(verbstr,0); if(use_rfc822_timestamp != 0 && use_rfc822_timestamp != 1) { harderror("use_rfc822_timestamp must have a value of 0 or 1"); } } Once that is done, look for L_TIMESTAMP in the source code; those are the places which generate the time stamp in question. Sean, I now have a lot of respect for you now that you mentioned that you wrote Blackbox. This is the first time I have had to deal with people who ask for features and complain when I say "No"; and do not create correct patches when I request a patch. Do not think I am happy kicking Ivanov off of the list. I am not. I do not want to become another Dan Bernstien; I do listen to people's suggestions but, after a point, it becomes too much for what is nothing more than a project I do in my spare time. I am publically doing this because I do feel that I am accountable for my actions. I do have compassion for Ivanov's position of not having perfect English; I was acutely aware of people's annoyances people people had with my less-than-perfect Spanish when I was down in Mexico. However, I really wish he would make an effort to read the documetation before asking for features on the list. There are obviously some cultural things about open source and how people ask for features he has not come to understnad yet; hopefully my kicking him off of the list will teach him a lesson he needs to learn. - Sam From s@s.org Thu May 02 23:48:31 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Docbook Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Before anything else, I would like to thank everyone here for all of their kind words and for their support; I don't mind things getting a little heated because it is better to have a place to let off steam than to have tempers flare up until someone stops helping open source out in a fit of rage. >If people who spend far more time than I do creating documentation >believe those formats are better to use, then I say they should use o >them ... and they should write the documents for programmers who don't >have the time to learn how to be a document writer just to write a >few documents. This is the thing which I find strange about Docbook; if it is such a good format to write documents in, why hasn't someone written an entry-level tutorial for it. One of the things I liked about HTML (before the Netscapization of it) was that it was really a very simple format, and that there were excellent online tutorials on the web which walked you through writing an HTML document. By compasison, Docbook's tutorials are incomplete, or throw me in the deep end all at once. I feel that all this complexity really gives me nothing. I think a format this complicated should be more extensible. Docbook likes to have ideas sematically arranged; one does not have seomthing in italics, but has something be a title, an expresion or word in a foreign language (I don't think Docbook actually supports this, but this is a case where one does want to use italics), or something that needs emphasis. However, each series of documents has their own sets of ideas to express. For example, a DNS document will often times have example hostnames; one can not define an "example hostname" tag in Docbook with making a docbook variant that is not Docbook. My imaginary perfect documtation format would have no tags, per se, but would allow people to define their own tags. Using a format far simpler than a SGML or XML DTD. My imaginary format would have "tagnames" and "tagactions". The tag names would be things like or , the tag actions would be things like or . It would not attempt to create its own language for defining what the tag actions do; tag actions would always be type setting actions and would be added to the underlying programming language on an as needed basis. The EJ documentation format has a handful of simple typesetting actions; unlike Docbook, the format uses tags which directly define how the documtation is typeset. While this does make making indexes a little harder, I don't feel the complexity of a format with about 400 tags instead of the 29 EJ currently has is worth it. Now, with this many tags, one would expect that docbook would have a large number of underlying typesetting commands. However, anything more complicated than what HTML 2.0 can generate is generally delegated to embedded postscript/png images. Now, I am the first to admit that I can very well be wrong here. I am sure there are places where a document format with 400 tags makes sense; I am sure this kind of complexity is needed for O'Reilly and their extensive collection of documents. There was once a very enlightened post on Slashdot where the person said that programmers, being the arrogant lot they are, like to reinvent the wheel; they always like taking pot shots at what other programmers have already done, and redo it themselves, often times not as well. Hopefully I did not make this mistake when I invented the EJ document format. One of the problems the open source development is facing is a complete lack of standardization with document formats. The only thing that is really standard is *roff man pages; writing in *roff is painful (I finally learned to do a reasonable job of it with MaraDNS; I've been playing with *roff on and off for seven years). As a result, a lot of projects don't have any man pages at all; Jaakko's original man pages for MaraDNS were actually written with POD, Perl's internal documentation format, and only converted to *roff. When I originally documented MaraDNS, I standardized on three formats: Plain text, simple HTML, and *roff man pages.[1] I felt that all three of these formats were, despite their flaws, in widespread enough use that anyone with reasonable UNIX skills would be able to see a document in one of these formats and know right away how to grok the format in question. It was a bit of a shock to me to see that people did not like this state of affairs with the documentation. In hindsight, the original pre-EJ documentation did have a number of problems. But I don't think those problems had as much to do with the format the documentation was in as to do with the fact that I just placed more and more stream-of-consciousness notes in the doc/misc directory until it became a real mess. There was no sense of organization; people translation the documtation had no idea how to prioritize what was most important to translate; and had to deal with three different formats. Converting all of the core documents to the EJ format has done a lot to make life easier; the main benefit is that the documents are now better ordered. All of the source files which should be translated when translating MaraDNS' documtation are now in a single directory; there is no longer a need to translate the same text multiple times since EJ automigically handles the placing of text which is used in more than one place. Since EJ does translate to standard formats which almost anyone can grok (the previously mentioned ASCII text, HTML, and *roff for man pages), I hope that people new to MaraDNS have no problem finding and taking advantage of the documentation. I can see why people want a new standard way of documenting open source projects for the 21st century; one of the problems with open source is that we don't have a Bill Gates who can dictate to use what that format is. We can only go by rough consensous. For many years the GNU project tried to get people to use infodoc; that ultimately failed. TeX, for better or for worse, only found widespread use for articles in scientific journals. Docbook may end up having the same fate as GNU's infodoc and TeX: being relegated to a niche market. It is, of course, also very possible that Docbook will become the new standardized format. It is better to have standards than for the open source users to need dozens of tools, one per project to read the documentation for that project. This standard also means that people only need to learn how write documents for open source once. This is getting too long; I think I need to start a weblog or something. - Sam [1] This "use the lowest common denominator" philosophy is present throught MaraDNS; I deliberately only write scripts in Bash and Perl, and require no Perl for anything critical to the running of MaraDNS. I also deliberately use a simple style of C programming that minimizes the number of compilers which will have problems with the MaraDNS source; seeing that I only had problems porting MaraDNS to Solaris (which is always a royal pain to port to), I think I have succeeded. From s@s.org Fri May 03 00:18:35 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Dan Bernstien Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >I do read the things [Dan Bernstien] says with interest, and have >been known to study his code The stuff that Dan wrote about DNS was invaluable when I was working on MaraDNS. I actually stole a number of his ideas: The idea of using a simple-to-parse zone file; the idea to generate an A record from a dotted decimal IP (e.g, someone asks for the A record for the host name '1.2.3.4' and MaraDNS will generate an A record with the value '1.2.3.4' on the fly); and the way I randomize the query ID and query source port. That said, I used to have more respect for him than I do now. I supported him on the Namedroppers mailing list when no one else was supporting what I felt were legitimate objections he had. Despite this, he did not remember me for supporting him; when I announced MaraDNS on Bugtraq he had a hissy which was obviously nothing more than jealously that there a now another DNS server in "competition" with MaraDNS. Rather childish. I understand why he felt that way; when I first discovered Posadis I initally felt the same way, but knew that Posadis could only help MaraDNS. If nothing else, I can tell people "Go use Posadis" when they ask that MaraDNS have such-and-such a feature. I wonder how many of the people asking for SQL support have asked the Posadis developer for the same thing. I haven't looked at Dan's code, except in some isolated cases where I have already implemented the feature in question in MaraDNS. I am a bit nervous that looking at his code will "contaminate" MaraDNS in a legal sense; it is important that MaraDNS is, as much as possible, a "clean room" implementation. I also appreiate Richard pointing out that I can overreact; it is certaintly true. I need to learn to killfile people who rub me the wrong way; it will stop me from having hissies on the mailing list. I do feel that the discussion of new features is appropriate; however I have *probably* heard it before; look at the "UNIMPLEMENTED FEATURES" and "BUGS" section of the MaraDNS man page. - Sam From s@s.org Fri May 03 01:36:02 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Docbook Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Phil wrote: >[MaraDNS' EJ documentation] sounds like something that should >be its own project. Well, I see things like the EJ documentation format and the JS string library as things which I will carry with me from one project to the next; since MaraDNS is public domain [1] I can not use tools such as autoconf or the standard system startup scripts. As a result, I have been building up an entire infastructure; the JS string library came in to being for my last project (Kiwi; which failed [2] because it was too hard to use). I think that EJ will be used in my next project (either a rewrite of MaraDNS, a really advanced anti-spam setup, or some OSS project that the 'net, by consensus, feels is needed the way people on Bugtraq demanded a new DNS server implementation about a year ago). I feel weird about calling a bunch of Perl scripts a "real" project. In addition EJ's bugs are getting harder and harder to fix. I would need to completely rewrite it to make it "production quality" piece of software; the current code is really a prototype. I also have developed a lot of SQA test cases for DNS servers when writing MaraDNS; perhaps I should document what I have done there so other DNS implementers can use my code to test their software. Speaking of next projects, I really need to buckle down and do the things which MaraDNS needs to become 1.0; MaraDNS is starting to get stale for me. - Sam [1] There are a lot of people with possibly viable objections to a public domain license; my next project will probably have a BSD-style license. [2] Failure is a releative term in open source; I realized that I was going to a lot of effort documenting and what not a project that no one besides myself was using. The general reaction was that I was going to way too much effort just to keep spam out of my inbox. From s@s.org Sat May 04 15:11:49 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.22 released; 1.0.00 release plans Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline I have just released MaraDNS 0.9.22. First of all, I have been talking with Ivanov in private email; I explained to him that he is welcome to join the MaraDNS mailing list again, as long as he does not constantly badger me for new features. He told me that he doesn't want his name mentioned anywhere in MaraDNS; I have honored his request by removing any reference to him. Since he did make his improvments (particuarily the IP logging) public domain, I will continue to use his improvments. I do appreciate Ivanov's contributions to MaraDNS; as I told him in private mail, his contributions are still valid. In addition, I now have a definite release schedule for MaraDNS 1.0.00. I will stay in the 0.9.xx cycle until the following two issues are addressed: 1. The decompression code needs to be written to 1) Be able to easily have definitions for new RRs with compressed dlabels be added 2) Perform some anal integrity checks for the packets and reject anything which fails the integrity check. 2. Franky's freeze ups. This one is a "ghost" issue; no one besides Franky has seen the error; Franky only sees it when doing really heavy stress testing and then only occassionally. What I will do to satisfy myself that this one is unreproducable is design a test bed based on real world data; the debug.hostname tool has already gotten the raw real-world data. Baiscally, have 256 different instances of MaraDNS, each with its own subset of real-world DNS data. After these two issues are addressed (I will work on the decompession code first since that work will more likely result in bugs popping up), I will start a 0.99.x or a 0.9.9x cycle; these will be release candidates which I will make as public as possible. I will then deal with whatever bugs are found out "In the wild". Once 0.9.90 is released, it will take about three weeks for 1.0.00 to be released unless show-stopper bugs show up in the testing. A show stopper bug is: * Any security issue * Anything which causes MaraDNS to crash or hang * Any case where MaraDNS can not satisfactorily resolve an important host name, such as www.cnn.com, www.yahoo.com, or news.com.com * Significant loss of functionality which previous versions of MaraDNS had. Other bugs will be deferred until after 1.0.00. I estimate that I will have a 0.9.9x release out before June 1st. - Sam From s@s.org Sun May 05 03:11:58 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS freeze-ups Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >But I also remembered somebody else on the list also seeing >his maradns dying ont him, so I might not be the only one. What he was seeing was the consequence of using his ISP's servers as if they were the root name servers. Things would work well for a while, but then when the ISP's name servers were removing stuff from their cache, it would appear that MaraDNS was dying. When I added the "upstream server" feature, his problem went away; what you are seeing is different, and is still unresolved. - Sam From s@s.org Sun May 05 04:18:50 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: MaraDNS freeze-ups Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >I'll try to start the new tests asap. Make sure that debug_msg_level is set to 4 and that verbose_level is set to 3; I'd like a log if you see the freeze-ups again. - Sam From s@s.org Sun May 05 06:07:13 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Some facts about Cinco de Mayo Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Cinco de Mayo (literally translated: May 5th) is one of these holidats which is slowly becoming a bigger and bigger American holiday. It is originally a holiday in Mexico; but with an ever-expanding Hispanic population in the US, more and more people here are celebrating this holiday. I am sure I can have more than my fill of Mariarchis (whose costumes and baritone guitars I love) and beautiful Spanish-style dancers today. Some facts about this holiday: * Cinco de Mayo honors a battle won in Puebla, Mexico, on May 5, 1862, against the French. * The French actually won the war, and only left Mexico because, as I recall, it was getting too expensive to have forces so far away. * It is not independence day for Mexico; that falls on September 16th. * With the exception of Puebla, this holiday is actually celebrated much more in the US than in Mexico. Yes Mexicans, I mean Puebla, Puebla, Mexico, but anyone who knows that also knows what Cinco de Mayo is really about; I am also aware that Fuerte Guadalupe and Fuerte Loreto were not in Puebla at the time of the battle, but those forts are certaintly within city limits these days. And, if you know enough about Mexico to know about Fuerte Guadalupe's relation to Puebla's city boundary, I could use your help translating MaraDNS in to Spanish. Speaking of MaraDNS, I should mention that I have just uploaded MaraDNS 0.8.23; the changes are: * Fixed bug where the startup script put MaraDNS in a different location than where the install script places it by default. * Updated the .spec file so that I can make RPMs of the newer version. * RPMs are now up-to-date again. ¡Happy Cinco de Mayo! - Sam From s@s.org Sun May 05 15:01:44 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Docbook Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >Ok, you've made me a liar, Sam. I wasn't going to say >anything else about DocBook...But, DocBook allows you to >do just this [make custom tags], and is one of the reasons >it is so popular among nerdy types. True enough. What I was thinking of was a quote from the page http://www.docbook.org/tdg/en/html/ch05-x.html: "If You Change DocBook, It's Not DocBook Anymore!" I had the impression that there were forces which would not be happy with anything less than true blue DocBook; when I saw that quote, it game me the impression that DocBook with a custom DTD would not make those forces happy. - Sam From s@s.org Sun May 05 15:13:46 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Mara problems with long records (+patch) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Tomasz, Thank you very much for the patch. I will integrate this patch in to the next version of MaraDNS. What I will do is make those limits be definied in the MaraDNS.h file; and make sure that increasing the limits does not result in excessive memory usage (e.g. All of the strings which are defined are freed up; I think they are but it has been a while since I touched that part of the MaraDNS code). Until then, I have placed your patch on the MaraDNS web page here: http://www.maradns.org/download/patches/longrecord.patch - Sam From s@s.org Sun May 05 15:23:09 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Adding new record types Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >What about making KEY record standard? It would >save from gymnastic with Other type. True enough; unfortunatly, MaraDNS is currently frozen, and I am trying to minimize the amount of stuff I add before MaraDNS 1.0.00 is released in a month or two (hopefully; Free software is nortorious for always being behind schedule). Also, I don't want to give the impresison that I support DNSSEC; MaraDNS would essentially have to be rewritten to support the NXT record type. Actually, I would not support NXT; I feel that grafting things like this on to DNS make DNS needlessly complicated; the underlying protocols are things which people are deathly afraid of replacing with new, better things. Instead, the IETF keeps grafting more and more things to these 20-year-old protocols until what we get is an ugly monstrosity. Back in 1982, it was possible to turn off NCP for one day, and have someone say "We are using TCP now. If you don't support TCP by the end of this month, you will no longer be on the ArpaNET". I really wish that it was possible to do something like that today. There is a reason that BIND was the only DNS server for many, many years. - Sam From s@s.org Sun May 05 15:49:14 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS and long records Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline One last thing about long RRs: MaraDNS does not support DNS-over-TCP; any DNS packet which is longer than 512 bytes can not be handled by MaraDNS. While I believe that the KEY packet posted here is under 512 bits long; it is feasible to make a longer key which breaks the 512-byte rule. Posadis (http://posadis.sourceforge.net/) is another DNS server which does support DNS-over-TCP. I do not know if Posadis has support for the KEY record type (either directlr or indirectly). Also, last time I looked, Posadis does not support recursion using the root name servers; it does, I believe, support using one's ISP name servers to resolve a record. - Sam From s@s.org Mon May 06 14:21:54 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS and TCP Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >Why? Current implementation does not handle TCP, but is this >permanent design limit? The best way to handle TCP is probably to ditch the zone server, and replce it with a MaraDNS TCP listening daemon which will allocate its own memory for storing authoritative zones and its own cache. This won't be done before MaraDNS 1.0, of course. - Sam From s@s.org Mon May 06 16:49:55 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Mara problems with long records (+patch) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >Look carefully, this might have an off-by-one error in the first >chunk. Probably not; the Js string library allocates an extra three bytes per string to minimize the dame of these kinds of things. That said, I have updated the patch which is on the server. Thank you for the heads up, - Sam From s@s.org Tue May 07 02:30:10 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Twisted's DNS server Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >Btw. Another DNS server can be found among >Twisted. twisted.names is part of Twisted framework, >from twistedmatrix.com. Currently twisted.names is in >sorry state, but potential is plentiful. Thank you for the pointer; I have added a pointer on my list of other DNS servers. Speaking of that list, I am on the verge of putting MooDNS on the list of abandoned DNS servers. With all due respect for Michael Wolf, it looks like MooDNS is something he threw together over a single weekend and then promptly lost interest in. Such is the nature of open source. I think the only really active open source DNS server projects right now are BIND, Posadis, and MaraDNS. Pdnsd has stabled down and meets all of its goals; it is an excellent recursive-only DNS server, especially for people on dialup connections. Posadis keeps getting better and better. As does BIND; BIND now (finally!) has the ability to delete records from the cache /before/ their TTL expires. DjbDNS, of course, is an excellent DNS server, but it not quite /software libre/. MaraDNS and BIND are currently the only functioning /software libre/ recursive and authoritative DNS servers; I am sure that Posadis will soon enough be fully recursive. - Sam From s@s.org Tue May 07 16:22:17 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Quickstart + timeout on dig Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Find out which IP MaraDNS is bound to. As root: netstat -nap | grep maradns You will see something like this: udp 0 0 127.0.0.3:53 0.0.0.0:* 722/maradns The information in the fourth column ("127.0.0.3:53") tells you the IP (and port number) the MaraDNS process is bound on. That is the IP you wish to run askmara against, e.g: askmara Awww.yahoo.com. 127.0.0.3 If the IP is 127.0.0.3 If that does not work, please post your /etc/mararc file to the list so we can resolve your issue. If it is private, send it to me in private email. - Sam From s@s.org Tue May 07 16:50:24 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: The idea I have for a new patch/feature. Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >before anyone jumps to tell me to make my own patches The context of the person who I jumped on was very specific: The person demanded that I change certain features of MaraDNS or make certain minor modifications. He demonstrated that he has sufficient C coding skills to make these changes himself. I asked him to make his own patches. He did not comply with this request and continued to demand that I change MaraDNS to his liking. The normal reaction of an open-source devloper is to deny that the feature requested is valid, e.g. "Why would anyone want that?" or "That is a stupid feature". My reaction was a little more civilized: "Show me the code". That said, implementing certain engineering features requires a discussion before implementing said feature. I was reading on a web log [1] last night that one of open source's disadvantages is that it is hard to have whiteboard discussions where people discuss ideas with each other. As a result, most open source copies other software. E.G. Linux is a clone of UNIX; KDE is (more or less) a clone of Windows, and so on. That said, I don't want MaraDNS to become a clone of BIND. Your feature is very similiar to adding SQL support. Let me explain. MaraDNS already has a system for: * Getting data from an arbitrary location. * Caching that data for a user-defined period of time. * Giving the cache data to the DNS stub resolver. What I am talking about, of course, is the recursive cache. Basically, the part of the MaraDNS code to study the most is the "query_nameserver" routine in server/recursive.c. This is a long, and somewhat ugly, routine which: * Queries a remote DNS server for a given piece of information. * Places the data from the query in to MaraDNS' cache. Query_nameserver has the following arguments: int remote_ip: The IP of the remote address to contact js_string *query: This is a JS string object [2] which is a raw DNS query. From my data_structures document [3]: For example, what is in human readable form as "www.maradns.org" is in the following form in DNS "over the wire" packets: [binary 3] www [binary 7] maradns [binary 3] org [binary 0] Where [binary number] is a single byte with a value of number. If one were to look at a DNS packet requesting "www.maradns.org" with a hex dump utility, one would see something like this: 03 77 77 77 07 6D 61 72 61 64 6E 73 03 6F 72 67 00 ? w w w ? m a r a d n s ? o r g ? In addition to have the domain label for www.maradns.org, the hash index string also has a two-byte indicator what what kind of resource records one wishes. A resource record is the kind of information one wishes to have for a given name, such as www.maradns.org. [Snip. I assume that you know what a RR is already] In a raw DNS query, a resource record type is a big endian two byte value which is appended to the domain label for the query. MaraDNS' hash uses, as a hash index, a raw binary domain label followed by a 2-byte resource record type. As a result, an A query for www.maradns.org is indexed thusly (using our hypothetical hex dump program again): 03 77 77 77 07 6D 61 72 61 64 6E 73 03 6F 72 67 00 00 01 ? w w w ? m a r a d n s ? o r g ? ? ? A MX request for maradns.org, which a mailing program would send in order to find out which mail server to send email with a suffix of @maradns.org to, is indexed thusly: 07 6D 61 72 61 64 6E 73 03 6F 72 67 00 00 0F ? m a r a d n s ? o r g ? ? ? js_string *bailiwick: This tells us what the bailiwick is. This is a security feature; a given server can only change the data for resource records which they have the authority to change. If your file system can be completely trusted,you can ignore this parameter. The data_structures.ej document describes how records are stored in the cache; the modified query_nameserver routine needs to store new data in the cache using the format. Be sure to lock the cache before any cache-changing action; be sure to unlock the cache when done. query_nameserver needs to be thread safe; don't change anything global w/o locking it first. - Sam [1] http://www.joelonsoftware.com/articles/FiveWorlds.html [2] The JS string library is pretty much fully documented. Look in doc/en/misc/js-manpages. To view these documents (in case "less" does not automagically do the right thing): nroff -man file.3 | less (or nroff -man file.3 | more) [3] Look at doc/en/source/data_structures.ej; this can be looked at by using: lynx -dump --force-html data_structures.ej | less From s@s.org Tue May 07 18:16:11 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: The idea I have for a new patch/feature. Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >When I type askmara Aww4.janus.com. 127.0.0.1 (the >offending site) she comes right back though with the answer. The problem is that the record in question has a TTL of 0, which confuses some stub resolver. I have added a workaround which will be incorperated in the next release of MaraDNS. Until then, at the end of this message is a patch which can be patched against the MaraDNS source code as follows: cd maradns-0.9.23/ patch -p1 < the.patch.file make make install The patch file is at the end of this message; patch is smart enough to discard everything up to the actual patch. - Sam --- maradns-0.9.23/server/recursive.c Thu May 2 04:40:37 2002 +++ maradns-0.9.24/server/recursive.c Tue May 7 18:07:23 2002 @@ -883,7 +886,13 @@ else data->expire = time(0) + ttl; } - data->ttl = ttl; + /* Thanks to Hugo Vanwoerkom for pointing out that Aww4.janus.com. + doesn't reaolve in Mozilla; it has a TTL of 0 (ugh), which + confuses stub resolver libraries */ + if(ttl > 30) + data->ttl = ttl; + else + data->ttl = 30; /* Create a js_string object to store the raw binary answer */ if((new=js_create(value->unit_count + 1,value->unit_size)) == 0) { From s@s.org Tue May 07 18:25:16 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Getting ww4.janus.com to resolve Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline The patch which works around the ww4.janus.com bug can also be downloaded here: http://www.maradns.org/download/patches/maradns-0.9.23.hugo.patch I have verified that this patch resolves Hugo's issue. Usage instructions included with the patch. - Sam From s@s.org Wed May 08 03:43:56 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.24 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline MaraDNS 0.9.24 released. This is a bugfix release, addressing two minor concerns: * The problem with resolving ww4.janus.com and other hosts with a ttl of 0 (MaraDNS handles these hosts just fine, but some stub resolvers can't handle seeing a RR with a TTL of 0) * MaraDNS now much more gracefully handles long RRs; and gives a helpful error message if a given RR is too long. In addition, there is some documentation and header files which describe the new decompression code in place; I am getting ready to actually reimplement the DNS decompressor; this release still uses the old decompressor. - Sam From s@s.org Wed May 08 07:24:00 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Patch: news.com.com compression problem fixed Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline I have finally gotten to the bottom of the news.com.com compression problem. There were times when the compression would go past the end of the string; this would result in inconsistant behavior with the compression. This is why I could not recreate the compression error when compressing news.com.com on its own; the behavior was dependent on what data was in the string before. Keep in mind that there were no security impleications with this error; the compression code goes to great care to make sure it is impossible to change memory that is out of bounds. While the workaround which has been around since 0.9.23 makes this a non-issue for all practical purposes, it is still good to fix this bug once, and hopefully, for all. For people on webmail accounts who can not reliably copy patches which are not MIME attachments, a copy of this patch is here: http://www.maradns.org/download/patches/ To patch, enter the maradns-0.9.24 directory and run this command: patch -p1 < maradns-0.9.24.compress.patch Where maradns-0.9.24.compress.patch is a file with the following patch; patch is smart enough to ignore text leading up to the patch: --- maradns-0.9.24/dns/Compress.c Wed Feb 20 14:13:58 2002 +++ maradns-0.9.25/dns/Compress.c Wed May 8 06:47:03 2002 @@ -457,7 +457,7 @@ int dname_len = 0,psave = 0, counter, wascompressed, dlen, no_forward; /* Markers for comparing this uncompressed label with previous labels */ - int compare_left, compare_right, comparelen; + unsigned int compare_left, compare_right, comparelen; unsigned char toread,read; @@ -540,6 +540,14 @@ compare_right++; comparelen--; } + + /* Make sure we don't flub compressing names like + "news.com.com" */ + if(compare_left >= compressed->unit_count) { + counter++; + goto outerloop; + } + /* Determine how long the next domain-label is, following compression labels as needed. */ comparelen = *(compressed->string + compare_left); @@ -567,7 +575,7 @@ This will happen if the compressed string has terminated, but the uncompressed string has *not* terminated. */ - if(comparelen != *(uncompressed->string + compare_right)) { + if(comparelen != *(uncompressed->string + compare_right)) { counter++; goto outerloop; } @@ -576,7 +584,7 @@ dlen++; } while(comparelen > 0); /* If we have gotten to this point, we can have the length - label in the compressed string actuallt be a compression + label in the compressed string actually be a compression pointer */ wascompressed = 1; if(*cplace >= compressed->max_count) @@ -610,9 +618,11 @@ while(read <= toread) { /* Overflow protection */ if(*place <= uncompressed->unit_count && - *cplace <= compressed->max_count) + *cplace < compressed->max_count) { *(compressed->string + *cplace) = *(uncompressed->string + *place); + compressed->unit_count = *cplace; + } else return JS_ERROR; read++; From s@s.org Wed May 08 07:34:40 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Hugo's mail Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >I want to see that mara resolves all requests, yet I >see none with verbose level=3. You're probably not using MaraDNS to resolve these queries; what does the file /etc/resolv.conf have to say? >I thought I got that with 0.9.23 also. >What am I supposed to see? Aww4.janus.com.|30|64.57.180.196 as opposed to Aww4.janus.com.|0|64.57.180.196 Subtle difference; one should resolve nicely with Mozilla; the other will not. - Sam From s@s.org Thu May 09 00:13:11 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: getzone and host names Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >It looks like it should be fairly trivial (for me) to write a patch >to getzone so that it can accept either an IP address -or- a real >host name as the server to fetch a zone transfer from. Yep. Look around line 68 of tuzona/getzone.c; check to see if it is a DDIP (dotted decimal IP); if not do the gethostbyname thing. - Sam From s@s.org Thu May 09 01:38:37 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.25 released Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline MaraDNS 0.9.25 has been released. This is a bugfix release; I have finally found and fixed the news.com.com problems, hopefully once and for all. I normally don't have releases this close together, but this one is pretty critical (albeit not a security release) and I want MaraDNS to be as bug-free as possible before monkeying with the decompression code. I will have a release for the 0.5.xx series out shortly; this is a bug which needs to be fixed there. I know that almost no one is using the 0.5.xx series; but I feel that it is important to continue supporting this version for the foreseeable future. In addition, I have written a document describing some of the functions that the new decompressor will have. Next: Implement the new shiney ultra-paranoid security aware decompressor. The reason I'm rewriting it is because the decompressor is the first really complicated process that processes a DNS packet; it is "at the front lines" in terms of MaraDNS' security. - Sam From s@s.org Thu May 09 05:05:09 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Do **not* use 0.9.25; use 0.9.26 instead Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline I made an error making a variable unsigned which should be signed in MaraDNS 0.9.25 (and in the patch for MaraDNS 0.9.24). This completely broke DNS compression. Fixed; MaraDNS 0.9.26 released on the heels of 0.9.25 as a result. Patch follows for people who ended up downloading 0.9.25 - Sam --- maradns-0.9.25/dns/Compress.c Wed May 8 06:47:03 2002 +++ maradns-0.9.26/dns/Compress.c Thu May 9 04:53:39 2002 @@ -457,7 +457,8 @@ int dname_len = 0,psave = 0, counter, wascompressed, dlen, no_forward; /* Markers for comparing this uncompressed label with previous labels */ - unsigned int compare_left, compare_right, comparelen; + unsigned int compare_left, compare_right; + int comparelen; unsigned char toread,read; From s@s.org Thu May 09 05:21:33 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Re: ww4.janus.com -- plot thickensd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline >And the requests are 5 seconds apart. Why is that? Because the stub resolver your are using assumes that the UDP packet dropped on the ground after 5 seconds. This has nothing to do with MaraDNS, except that she diligently tries processing the packet in question when the second packet is received 5 seconds later. >I thought the timeout value was 2secs? The timeout is for a single DNS query; there are about 15 root servers and 15 .com servers, so it takes 15 or 16 queries before MaraDNS gives up; which can take half a minute when the per-server timeout is 2 seconds. - Sam From s@s.org Thu May 09 15:27:21 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: OK, I'm responding to everything at once Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Since my mail user agent consists of vi and sendmail (Programs like mutt and pine are for wussies), I will respond to everything at once. --- Hélène: Looks like you have gotten a little lost there. Time to get out the map. In other words, I think the best place for you to start is with the MaraDNS tutorial; there are versions of it in both English and French: http://www.maradns.org/tutorial/tutorial.html (English) http://www.maradns.org/tutorial/fr/tutorial.html (French) >Why do I have this warning message ? It means that there is not a zone file for example.org, or that MaraDNS can not open up the zone file for example.org. To troubleshoot: * What is the chroot_dir in your /etc/mararc file? * What does the line that says csv1["example.org."] look like? * Is there a corresponding filename? >Is the use of askmara the same for authoritative and recursive >servers? Yes, it is. >Could I use a recursive server without an authoritative server in my >network? Yes, you can. >In both cases, what is the procedure to make it work? Read the tutorial (see above for the links) --- Hugo asks: >What/where is a stub resolver? A stub resolver is the part of a program which wishes to resolve a hostname. In order to do this, a stub resolver typically looks at /etc/resolv.conf to determine which DNS servers to query, then querys the DNS server in question. It's the part of Mozilla which sends queries to MaraDNS and the part of other browsers which calls gethostbyname(), which subsequently sends queries to MaraDNS. --- [Snip. Discussion of the timestamp format] You know, I am going to add a variable to the mararc file called "timestamp_format" which can change the timestamp format. I didn't realize that this was going to become a religious issue; the only reasonable solution is to have it support UNIX timestamps, UNIX timestamps without a clue for the newbies, and US-centric human-readable timestamps. --- [The problem with a previously perfectly good hostname not resolving any more] I need to make a very high verbose level which will show MaraDNS sending out each and every query in the resolution of a hostname to get to the bottom of this one. --- In private mail, someone informed me that they are still using the 0.5.xx branch. Which means 0.5.32, with the fixed compress code, will come out real soon now; as soon as I feel comfortable that the 0.9.26 compression code is bug-free. - Sam From s@s.org Fri May 10 02:45:12 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.5.32 released Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hello there, MaraDNS 0.5.32 has been released; this is an update to the authoritative-only branch. The only change is that I have copied over the Compressed.c file from the new release to the authoritative-only release. The compression API is still identical; the only change is that the new version is less buggy and more readable. It is currently available here: http://www.maradns.org/download/maradns-0.5.32.tar.bz2 The PGP sig is: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA825PyC+jWrh5h/KYRAoMeAJ43dESgLpXBtz1aIOx+4R8KqjdgIQCfTZRO 94gNZ5n463IHVCCLTWO4tIQ= =n/pM -----END PGP SIGNATURE----- - Sam From s@s.org Fri May 10 05:26:18 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: DNS 0.5.32 released Content-Type: text/plain; charset=utf-8 Content-Disposition: inline >To summarize: this is bad :) Agreed. However, I have not had a chance to look at this; I am too busy dealing with the !@#$ timestamp issue right now. I hope that people do not bring up any other religious issues on this mailing list; these things take time to address properly; time I could be spending looking at the serious bugs. I've seen DSL routers do the same: give out the wrong DNS answer to a given DNS query. - Sam From s@s.org Fri May 10 05:56:20 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.27 released Content-Type: text/plain; charset=utf-8 Content-Disposition: inline >Then skip this religious thingie ;) Too late; I've already done the code. It hasn't been a good night; I had to decrypt some obfuscated javascript which a spammer put in a web page (convert the offending JS in to Perl and run the coded HTML through the Perl interpreter). That said, I just made Sean's task much easier. MaraDNS 0.9.27 now has a new mararc variable, called "timestamp_type", which takes a numeric argument. When it has a value of 0 (the default if it is not defined), it shows "Timestamp" followed by a raw UNIX time stamp. When it has a value of 1, it shows just the raw UNIX time stamp. When it has any value, it goes back to the default value. The code for doing this is in server/timestamp.c; I have gone to some trouble to make it trivial to add new timestamp types for people who do not like either one of these timestamp formats. Patches for new types will be gladly accepted. No RPMs made; this has too narrow of a focus for me to do anything else. Next: Have a new verbose level of 4 which basically tracks everything the recursive server is doing. I hope to be able to get 1.0.00 out ASAP. Now is not a good time to ask for new features. I really do not want to deal with 15 issues like the timestamp issue before releasing 1.0.00. Minor doc cleanup: I have alphabetically sorted the mararc variables in the mararc man page. GPG sig for maradns-0.9.27.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA828CmC+jWrh5h/KYRAvwYAJ0asp5i0P8fHIO3DUFrGlI7Egbd2ACeLZU2 dhzUX4Ee+RR87MhhJsFvm0A= =wtel -----END PGP SIGNATURE----- - Sam From s@s.org Mon May 13 12:17:33 2002 Return-Path: Received: from spring.webconquest.com (EHLO mail.webconquest.com) (66.33.48.187) by mta581.mail.yahoo.com with SMTP; 13 May 2002 06:47:05 -0700 (PDT) Received: by mail.webconquest.com (Postfix, from userid 508) id 3771A17A3B; Mon, 13 May 2002 09:37:09 -0400 (EDT) Old-Return-Path: Delivered-To: list@maradns.org De: e8mhpsznamq001@sneakemail.com A: list@maradns.org Asunto: MaraDNS 0.9.28 released Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Message-Id: <20020513134716.9227BAE0E@vela.invalid> Fecha: Mon, 13 May 2002 06:47:16 -0700 (PDT) Resent-Message-ID: Resent-From: list@maradns.org X-Mailing-List: archive/latest/358 X-Loop: list@maradns.org List-Post: List-Help: List-Subscribe: List-Unsubscribe: Precedence: list Resent-Sender: list-request@maradns.org Resent-Date: Mon, 13 May 2002 09:37:09 -0400 (EDT) Content-Length: 671 This is a debug release; the only change between this version and MaraDNS 0.9.27 is the addition of a lot more debugging information which is visible when verbose_level is set to 4; every time the recursive nameserver looks at something in the cache, or adds or removes something from the cache, the action performed is logged. This is in response to Franky seeing signs that the cache may be getting currupted; this level of debugging will tell us the memory addresses and hash indices of the problematical data. To enable, here is what the relevent line in /etc/mararc should look like: verbose_level = 4 This data also gives hints with regard to problem hostnames; however the debugging information is not geared for that kind of debugging; this is where the debug.hostname tool becomes useful. PGP sig for maradns-0.9.28.tar.bz2: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA837fvC+jWrh5h/KYRAiW9AJ46zsWUvHksikHkG8udjYG8OnChAgCghaug inuDBKUWwXepT3Q5N4jdMHQ= =TeVY -----END PGP SIGNATURE----- - Sam From s@s.org Mon May 13 12:34:52 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: For Franky and Kemal (I will assume that Kemal, the zone contact for kolaymail.com is the person who sent me email from that domain; if I am in error, please let me know...and please give me your real first name and home page URL if you have one) Franky: Thank you for the bug report; now I know where to hunt and fix that particular bug. Kemal: This is the third request I have received for some kind of regular expression engine to resolve host names. Perhaps I should hack something together in Perl which does precisely this; however such a design is not part of the design I had in mind for MaraDNS 1.0. The problem is that MaraDNS is designed to be /fast/ for a small number of RRs [1]; and just as fast for a large number of RRs--the only penalties for having many RRs with MaraDNS' current design is larger memory usage and slower startup time. The problem with a regex search tool is that it needs to look at each RR one by one until it can find a match. This is O(N) (where N is the number of resource records in a DNS cache) instead of O(1) (MaraDNS' current scheme). The best way to handle something like this, I believe, is to use a btree to store RRs and have a way of having records which cover all records between two ortographically sorted names. Time to dust off a book on data structures, or work out how the btree would work in my head. - Sam [1] RR: Resource Record From s@s.org Wed May 15 17:25:41 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.29 released I have released MaraDNS 0.9.29. This is a simple bugfix release; it should fix the problems Franky saw resolving ALASKA.NET. As Franky finds new bugs, I will fix them; it looks like the new logging makes getting to the cause of problems he sees much easier. In addition, I have made it even easier to have MaraDNS support new timestamp formats. I know that I have been pretty stubborn about this. I have my resons to be stubborn. MaraDNS is ever so slowly gaining in popularity. Right now, I am unemployed (yay the dot-com crash) and am not going to school. As a result, I do have time to indulge people's requests for things like customizable time stamps. However, in the near future I will be either employed or going to school. In this economy, going to school is looking more and more likely; there are just about no jobs in the tech sector. In both cases, my time will be much more restricted; I want a stable 1.0 release out before I get really busy again so that I can concentrate on my schoolwork (or job, if a miracle happens). As a result, I am trying to teach people how to fish instead of constantly giving them fish after fish. I can hand out fishes today, but that will very soon change. For MaraDNS to be sustainable, it has to reach a point that Mutt, the GIMP, and other releases have reached: It has to be something that can grow and change without my complete intervention. I will still be a contributer, and I will still help people understand the code. However, I will (hopefully) not be the only one that is making changes to the source code. I have made it /incredibly/ easy to have MaraDNS support new timestamp formats. Look at server/timestamp.c; I comment on exactly how to add new timestamp formats. The Linux kernel is great, not because of Linus' work, but because of the internet community when submitted countless patches to the kernel which Linus incorporated in to the kernel. Apache is great because it is the release that the most developers submitted patches to. That said, I think it takes a long time before a software project reaches a critical mass where its existance is not tied to one developer. I am not sure that Python is something that would sustain itself if Guildo was hit by a bus; I think Perl would probably sustain itself without Larry. FVWM is obviously sustaining itself withour Rob in the scene, but I do not feel that the post-Rob chages are as good as Rob's work; they break old fvwm1 configuration files and were not as stable as FVWM1 last time I looked at FVWM2 (back in 1996 or so). Yes, I appreciate the fact the FVWM is still being maintined. Does MaraDNS have a community big enough that she can sustain herself without me? Right now, no. I think this will become possible when and if MaraDNS 2.0 comes out. - Sam From s@s.org Thu May 16 14:24:30 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: communication between MaraDNS and other OS resolvers >'cause looks like Windows 2000 based DNS servers don't >refresh ns IPs when talking to Mara. I am not sure what you mean when you say "refresh NS IPs". The closest thing I can think of is that MaraDNS, when being run as a recursive server, does not have NS records in the authority section. This is allowed in the standards; there was a discussion about this about a year ago in the dnsop mailing list because Microsoft's DNS server exhibits the same behavior when acting as an authoritative DNS server. Dan Bernstien's does the same thing, for what it is worth. - Sam P.S. Franky, thanks for the bug reports. I am at a loss as to why MaraDNS is confused by the MX request for ALBATROS.BE; it is a straightforward MX record to resolve. I have not had a chance to look at the other bug reports yet. From s@s.org Thu May 16 14:45:14 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: MaraDNS unresponsive under load OK, I have had a chance to look at the bug where MaraDNS is unresponsive underload. I have actually seen the same thing myself; once the number of threads is the same as maximum number of threads, MaraDNS is a fish out of water until the load on her decreases. Then again, the number of threads that you see running is not that high. I will add some more debug information, seeing if the thread starts and what not, for the next release. I will also see if I can get to the bottom of the ALBATROS.BE bug also. - Sam From s@s.org Thu May 16 15:02:10 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: communication between MaraDNS and other OS resolvers Here is what I am seeing with the domain astrocorp.com: * All of the .com name servers have the same name server for this domain, namely 208.250.62.43 and 64.105.57.2. * The TTL for these name server records is two days; if the update has been done less than two days ago, then the old IPs are still in some DNS caches out there. * MaraDNS ignores the TTL of a name server record; she always keeps NS records in the cache for precisely one day (less if the DNS server in question is processing a lot more DNS records than cache space available; MaraDNS has an algorithm which intelligently removes unused records from the cache) * My MaraDNS server here resolves the A record for astrocorp.com as 208.250.62.43: [See if the name in question is already in the cache] Timestamp: 1021586134 Looking for \011astrocorp\003com\000\000\001 in cache Timestamp: 1021586134 \011astrocorp\003com\000\000\001 not found in cache [It isn't; perhaps we have the nameservers for astrocorp.com in the cache] Timestamp: 1021586134 Looking for \011astrocorp\003com\000\000\374 in cache (NS referral) [We don't; see if we have the name servers for .com in the cache] Timestamp: 1021586134 Looking for \003com\000\000\374 in cache (NS referral) Timestamp: 1021586134 \003com\000\000\374 found at 0x8071b30 [We do have the .com nameservers in the cache; copy that data in a thread-safe manner] Timestamp: 1021586134 Making cpoint copy of \003com\000\000\374 at 0x8071b30 [Ask one of the .com servers what the ip for astrocorp.com is] Timestamp: 1021586134 Querying DNS server with ip 192.26.92.30 for \011astrocorp \003com\000\000\001 with bailiwick \003com\000\000\374 [The .com server gives us the IP of two nameservers to contact] Timestamp: 1021586134 Adding \011astrocorp\003com\000\000\374 to cache at 0x808f 740 (jsip) Timestamp: 1021586134 Adding \011astrocorp\003com\000\000\374 to cache at 0x808c 6c8 (jsip) Timestamp: 1021586134 Adding \011astrocorp\003com\000\000\374 to cache at 0x808c cf8 (js) Timestamp: 1021586134 Adding \011astrocorp\003com\000\000\374 to cache at 0x808c db8 (js) [See if the data is in the cache now] Timestamp: 1021586134 Looking for \011astrocorp\003com\000\000\001 in cache Timestamp: 1021586134 \011astrocorp\003com\000\000\001 not found in cache [It isn't; perhaps we now have a nameserver for astrocorp.com in the cache] Timestamp: 1021586134 Looking for \011astrocorp\003com\000\000\374 in cache (NS referral) [We do.] Timestamp: 1021586134 \011astrocorp\003com\000\000\374 found at 0x808f740 [Copy that data over in a thread-safe manner] Timestamp: 1021586134 Making cpoint copy of \011astrocorp\003com\000\000\374 at 0x808f740 [Ask 208.250.62.43 what the address for astrocorp.com is] Timestamp: 1021586134 Querying DNS server with ip 208.250.62.43 for \011astrocor p\003com\000\000\001 with bailiwick \011astrocorp\003com\000\000\374 [The information is given to MaraDNS, which she adds to the cache] Timestamp: 1021586134 Adding RR/psudo-NXDOMAIN \011astrocorp\003com\000\000\001 to cache at 0x808d4c0 Timestamp: 1021586134 Looking for \011astrocorp\003com\000\000\001 in cache Timestamp: 1021586134 \011astrocorp\003com\000\000\001 found in cache (RR) at 0x 808d4c0 - Sam From s@s.org Fri May 17 05:04:21 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.30 released; bugfix release Hello there, I have released MaraDNS 0.8.30; this is a bugfix-only release which resolves the problems Frank was seeing resolving ALBATROS.BE. In addition, I have added some more logging at log level four, so that we may be able to get to the bottom of the temporary freeze-ups that Franky saw. I plan on rewriting the decompresser soon; I want to have a release candidate for 1.0 before June 1st. - Sam From s@s.org Fri May 17 14:05:02 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: MaraDNS 0.9.30 released; bugfix release Franky wrote: >Elements in the cache where even decreasing when doing the fourth test, >which is really weird... What I'm seeing, looking at tour logs, is that query_nameserver is failing for mysterious reasons; something has happened to the cache which makes query_nameserver very quickly fail. I now need to hack query_nameserver so that it gives out verbose error messages every time the routine exits; once I do that, I will make a patch available so that we can see why it is failing. I am glad that, at this point, MaraDNS is stable enough that I can (finally!) start tackling these kinds of issues. - Sam From s@s.org Sun May 19 00:42:59 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.31 released; bugfix release MaraDNS 0.9.31 released; bugfix release. This release fixes two bugs which Franky has reported: 1) I have plugged up the potential to have leaking sockets 2) Askmara now does a case-insensitive comparison when determining whether to "comment out" a RR. In addition, I now have more verbose logging (as per the patch posted here) when the verbose level is set to four. Finally, I have begun work on the new decompression code; there is not actual (albeit non-compiled, much less tested) code. As for the other bugs Franky has reported: 1) I'm impressed that you caught that MaraDNS does spawn a thread when a record which is the same except for the case is in the cache. When I wrote that code, I was just too lazy to properly perform a case-insensitive search, justifying my action with "Most DNS queries are done in all-lower case". 2) The custodian erases 1% of the records when the cache fills up. As a consequence, there can be a 1-2% variance in the size of the cache. The .25% variance Franky sees is within acceptable parameters. I need to see a 5% growth in the memory used after the cache is filled before I can consider it a memory leak. 3) I was sloppy about the log writing code in the various add_closer_* routines. I will, for the next release, make it more clear when someone is making a new record altogether, and when someone is merely adding a record at the end of the linked list for another record. Naturally, the custodian nukes all records in a linked list. 4) I appreciate your support Sean, and agree that I need to get a 1.0 release out the door. Right now, MaraDNS is a nice little lightweight DNS server ideal for small home networks and the like. However, I plan, after 1.0 is released, to implement a method to make it easy for people to write scripts which will use MaraDNS as a caching front end for SQL queries, file queries, or any other data which someone may wish to convert to DNS data. Once this is done, MaraDNS will have a "killer feature" which will make BIND-based enterprises give MaraDNS a serious look. I want MaraDNS to be rock stable for those people. - Sam From s@s.org Sun May 19 01:16:44 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: MaraDNS 0.9.31 released; bugfix release Content-Type: text/plain; charset=utf-8 Content-Disposition: inline >There is always the war between small, simple, lightweight and >enterprise, features, flexibilty. I hope mara stays on the >former and not the latter I think we can have our cake and eat it here. When I say "enterprise", I mean "this thing can handle the kind of load a .com name server can handle". Which MaraDNS can do here and now (as an authoritative-only server if there aren't too many records in the cache). The simpler the code is, the more load the code can handle, as a general rule. I am a strong proponent of the UNIX way: A series of simple, leightweight applications. This is why the zone server is a separate application than the main server. The only reason the authoritative and recursive server are the same is because some small shops need to use the same IP for both; and because it is sometime desirable to force the office's recursive server to resolve certain records a certain way. I guess we are close enough to 1.0.00 to discuss my next plan: Having a system where the recursive server, instead of sending a DNS query to fill the cache with, sends out a special TCP query which is easy to write a server to process. I was thinking something like this: ">>>" from client to server; "<<<" from server to client >>> ¿Entiendes FácilMariana/0.1? <<< Si, entiendo FácilMariana/0.1 >>> Awww.maradns.org. <<< 10.1.2.3 - Sam From s@s.org Sun May 19 04:04:48 2002 From: e8mhpsznamq001@sneakemail.com To: liedekef@pandora.be Subject: OK, time to hunt down the memory leak Franky, Try patching 0.8.31 against this patch and see where the leak is. This debugging information only works when maradns is built with "make debug"; hitting CNTL+C when running maradns lists all of the unfreed memory. Try this with a tiny cache, like 64 elements, so anything fishy sticks out like a sore thumb. Or, I should see if I can recreate this offline. This kind of stuff *was* fixed in the late 0.8.xx series; I am surprised this gremlin is showing up again. - Sam --- maradns-0.9.31/server/recursive.c.orig Sat May 18 21:56:06 2002 +++ maradns-0.9.31/server/recursive.c Sun May 19 04:00:29 2002 @@ -302,7 +302,7 @@ return 0; /* Allocate memory */ - if((new = js_alloc(1,sizeof(fila))) == 0) + if((new = js_alloc_DEBUG(1,sizeof(fila),"js_alloc num 1")) == 0) return 0; /* The next record is whatever is at the top right now */ @@ -555,7 +555,7 @@ if(offset < 0 || length < 1) return JS_ERROR; /* Create the temporary string used for comparision purposes */ - if((compare = js_create(length + 1,1)) == 0) + if((compare = js_create_DEBUG(length + 1,1,"js_create num 1")) == 0) return JS_ERROR; if(js_substr(longjs,compare,offset,length) == JS_ERROR) { js_destroy(compare); @@ -589,7 +589,7 @@ if(offset < 0 || length < 1) return JS_ERROR; /* Create the temporary string used for comparision purposes */ - if((compare = js_create(length + 1,1)) == 0) + if((compare = js_create_DEBUG(length + 1,1,"js_create num 2")) == 0) return JS_ERROR; if(js_substr(longjs,compare,offset,length) == JS_ERROR) { js_destroy(compare); @@ -622,7 +622,7 @@ } /* If they do not match, pweform a case-insensitive search */ if(ret == 0) { - if((lower = js_create(shortjs->unit_count + 1,1)) == 0) { + if((lower = js_create_DEBUG(shortjs->unit_count + 1,1,"js_create num 3")) == 0) { js_destroy(compare); change_rtype(shortjs,qtype_short); return JS_ERROR; @@ -682,7 +682,7 @@ int check_case_of_answer(js_string *uindata, js_string *query, int offset) { js_string *copy; int result; - if((copy = js_create(query->unit_count + 3,1)) == 0) + if((copy = js_create_DEBUG(query->unit_count + 3,1,"js_create num 4")) == 0) return JS_ERROR; if(js_copy(query,copy) == JS_ERROR) { js_destroy(copy); @@ -730,7 +730,7 @@ return JS_ERROR; /* Create and set the value of the substr that we will put the value in */ - if((sub = js_create(length + 1,1)) == 0) + if((sub = js_create_DEBUG(length + 1,1,"js_create num 5")) == 0) return JS_ERROR; if(js_substr(longjs,sub,offset,length) == JS_ERROR) { js_destroy(sub); @@ -771,7 +771,7 @@ return JS_ERROR; /* Make a string which holds just the domain name label */ - if((sub = js_create(len + 1,1)) == 0) + if((sub = js_create_DEBUG(len + 1,1,"js_create num 6")) == 0) return JS_ERROR; if(js_substr(js,sub,offset,len) == JS_ERROR) { js_destroy(sub); @@ -807,9 +807,9 @@ int in_bailiwick(js_string *host, js_string *bailiwick) { js_string *get,*b_lower; int result; - if((get = js_create(host->unit_count + 3,1)) == 0) + if((get = js_create_DEBUG(host->unit_count + 3,1,"js_create num 7")) == 0) return JS_ERROR; - if((b_lower = js_create(bailiwick->unit_count + 3,1)) == 0) { + if((b_lower = js_create_DEBUG(bailiwick->unit_count + 3,1,"js_create num 8")) == 0) { js_destroy(get); return JS_ERROR; } @@ -894,7 +894,7 @@ mhash_e spot_data; /* Create a structure for putting the rr data in */ - if((data = js_alloc(1,sizeof(rr))) == 0) + if((data = js_alloc_DEBUG(1,sizeof(rr),"js_alloc num 2")) == 0) return JS_ERROR; if(rlog_level >= 4) { @@ -954,7 +954,7 @@ data->ttl = 30; /* Create a js_string object to store the raw binary answer */ - if((new=js_create(value->unit_count + 1,value->unit_size)) == 0) { + if((new=js_create_DEBUG(value->unit_count + 1,value->unit_size,"js_create num 9")) == 0) { js_dealloc(data); return JS_ERROR; } @@ -976,7 +976,7 @@ /* Note that rtype is *always* 255 */ if(datatype == MARA_DNS_NEG || rtype != 255) { - if((new_query = js_create(query->unit_count + 1,1)) == 0) { + if((new_query = js_create_DEBUG(query->unit_count + 1,1,"js_create num 10")) == 0) { js_dealloc(data); js_destroy(new); return JS_ERROR; @@ -993,7 +993,7 @@ js_destroy(new); return JS_ERROR; } - if((zap_query = js_create(query->unit_count + 1,1)) == 0) { + if((zap_query = js_create_DEBUG(query->unit_count + 1,1,"js_create num 11")) == 0) { js_destroy(new_query); js_dealloc(data); js_destroy(new); @@ -1290,7 +1290,7 @@ ns_domain[0] = 0; /* Allocate memory for some strings */ - if((indata = js_create(512,1)) == 0) { + if((indata = js_create_DEBUG(512,1,"js_create num 12")) == 0) { if(rlog_level >= 4) { write_lock(); show_timestamp(); @@ -1299,7 +1299,7 @@ } return JS_ERROR; } - if((uindata = js_create(2048,1)) == 0) { + if((uindata = js_create_DEBUG(2048,1,"js_create num 13")) == 0) { if(rlog_level >= 4) { write_lock(); show_timestamp(); @@ -1309,7 +1309,7 @@ js_destroy(indata); return JS_ERROR; } - if((outdata = js_create(512,1)) == 0) { + if((outdata = js_create_DEBUG(512,1,"js_create num 14")) == 0) { if(rlog_level >= 4) { write_lock(); show_timestamp(); @@ -1668,7 +1668,7 @@ corresponding A records always. If they want a non-A record, we still need to add the A record to the cache */ /* Determine the IP that the CNAME record points to */ - if((jsip = js_create(256,1)) == 0) { + if((jsip = js_create_DEBUG(256,1,"js_create num 15")) == 0) { if(rlog_level >= 4) { write_lock(); show_timestamp(); @@ -1840,7 +1840,7 @@ } /* This string is used to pass arguments to add_closer_jsip */ - if((jsip = js_create(6,1)) == 0) + if((jsip = js_create_DEBUG(6,1,"js_create num 16")) == 0) goto cleanup; /* Start looking at the additional records. See which ones are IPs @@ -2250,7 +2250,7 @@ *ipret = 0; /* See if we have to do case-insensitive searching */ - if((lower = js_create(query->unit_count + 3,1)) == 0) + if((lower = js_create_DEBUG(query->unit_count + 3,1,"js_create num 17")) == 0) return JS_ERROR; if(js_copy(query,lower) == JS_ERROR) goto cleanup_nojs; @@ -2310,7 +2310,7 @@ } /* Allocate memoey for the 'copy' string */ - if((copy = js_create(257,1)) == 0) + if((copy = js_create_DEBUG(257,1,"js_create num 18")) == 0) goto cleanup_nojs; /* Look for query in cache */ @@ -2589,7 +2589,7 @@ write2read_lock(); } - if((local_c = js_alloc(1,sizeof(closer))) == 0) { + if((local_c = js_alloc_DEBUG(1,sizeof(closer),"js_alloc num 3")) == 0) { read_unlock(); goto cleanup; } @@ -2600,7 +2600,7 @@ local_c->zap = NULL; /* Not on zap list */ switch(cpoint->datatype) { case RR_A: - if((i32_copy = js_alloc(1,sizeof(uint32))) == 0) { + if((i32_copy = js_alloc_DEBUG(1,sizeof(uint32),"js_alloc num 4")) == 0) { read_unlock(); goto cleanup; } @@ -2614,7 +2614,7 @@ goto cleanup; } jstr_copy = cpoint->data; - jstr_copy = js_create(jstr_copy->unit_count + 1,1); + jstr_copy = js_create_DEBUG(jstr_copy->unit_count + 1,1,"js_create num 19"); if(js_copy == 0) { read_unlock(); goto cleanup; @@ -2634,7 +2634,7 @@ } if(cpoint->next != NULL) { local_c_save = local_c; - if((local_c = js_alloc(1,sizeof(closer))) == 0) { + if((local_c = js_alloc_DEBUG(1,sizeof(closer),"js_alloc num 5")) == 0) { read_unlock(); goto cleanup; } @@ -2698,7 +2698,7 @@ if(js_has_sanity(glueless_query) == JS_ERROR) goto cleanup; if((glueless_query = - js_create(glueless_query->unit_count + 2,1)) == 0) + js_create_DEBUG(glueless_query->unit_count + 2,1,"js_create num 20")) == 0) goto cleanup; if(js_copy(local_c->data,glueless_query) == JS_ERROR) { js_destroy(glueless_query); @@ -2955,11 +2955,11 @@ argument. */ /* Create the req data structure */ - if((req = js_alloc(1,sizeof(dnsreq))) == 0) + if((req = js_alloc_DEBUG(1,sizeof(dnsreq),"js_alloc num 6")) == 0) return JS_ERROR; /* Create the 'copy' js_string */ - if((copy = js_create(query->unit_count + 3,1)) == 0) { + if((copy = js_create_DEBUG(query->unit_count + 3,1,"js_create num 21")) == 0) { js_dealloc(req); return JS_ERROR; } @@ -2989,7 +2989,7 @@ } /* Return a "server fail" error message if we can not spawn a thread. We need to synthesize a header to do this */ - if((synthesized_header = js_create(24,1)) == 0) { + if((synthesized_header = js_create_DEBUG(24,1,"js_create num 22")) == 0) { return JS_ERROR; } if(js_adduint16(synthesized_header,id) == JS_ERROR) { @@ -3050,11 +3050,11 @@ mhash_e spot_data; /* Allocate the memory for a new spot on the dnscache hash */ - if((close = js_alloc(1,sizeof(closer))) == 0) + if((close = js_alloc_DEBUG(1,sizeof(closer),"js_alloc num 7")) == 0) return JS_ERROR; /* Allocate the memory for the IP we will put on the hash */ - if((ipjs = js_create(6,1)) == 0) { + if((ipjs = js_create_DEBUG(6,1,"js_create num 23")) == 0) { js_dealloc(close); return JS_ERROR; } @@ -3079,7 +3079,7 @@ /* Fill up the "close" structure */ close->num_elements = 1; close->datatype = RR_A; - if((ipp = js_alloc(1,sizeof(uint32))) == 0) + if((ipp = js_alloc_DEBUG(1,sizeof(uint32),"js_alloc num 8")) == 0) goto cleanup; *ipp = ip; close->data = ipp; @@ -3176,7 +3176,7 @@ mhash_e spot_data; /* Allocate the memory for a new spot on the dnscache hash */ - if((close = js_alloc(1,sizeof(closer))) == 0) + if((close = js_alloc_DEBUG(1,sizeof(closer),"js_alloc num 9")) == 0) return JS_ERROR; /* Make sure the raw zone is of the right rtype */ @@ -3189,7 +3189,7 @@ /* Fill up the "close" structure */ close->num_elements = 1; close->datatype = RR_A; - if((ipp = js_alloc(1,sizeof(uint32))) == 0) + if((ipp = js_alloc_DEBUG(1,sizeof(uint32),"js_alloc num 10")) == 0) goto cleanup; *ipp = ip; close->data = ipp; @@ -3287,13 +3287,13 @@ js_string *new, *zone_copy; /* Allocate the memory for a new spot on the dnscache hash */ - if((close = js_alloc(1,sizeof(closer))) == 0) + if((close = js_alloc_DEBUG(1,sizeof(closer),"js_alloc num 11")) == 0) return JS_ERROR; - if((new = js_create(name->unit_count + 1,1)) == 0) { + if((new = js_create_DEBUG(name->unit_count + 1,1,"js_create num 24")) == 0) { js_dealloc(close); return JS_ERROR; } - if((zone_copy = js_create(zone->unit_count + 1,1)) == 0) { + if((zone_copy = js_create_DEBUG(zone->unit_count + 1,1,"js_create num 25")) == 0) { js_dealloc(close); js_destroy(new); return JS_ERROR; @@ -3409,7 +3409,7 @@ return JS_ERROR; /* Make a string which holds just the domain name label */ - if((sub = js_create(len + 4,1)) == 0) + if((sub = js_create_DEBUG(len + 4,1,"js_create num 26")) == 0) return JS_ERROR; if(js_substr(js,sub,offset,len) == JS_ERROR) { js_destroy(sub); @@ -3450,7 +3450,7 @@ return JS_ERROR; /* Make a string which holds just the question */ - if((sub1 = js_create(len1 + 4,1)) == 0) + if((sub1 = js_create_DEBUG(len1 + 4,1,"js_create num 27")) == 0) return JS_ERROR; if(js_substr(js,sub1,offset1,len1) == JS_ERROR) { js_destroy(sub1); @@ -3462,7 +3462,7 @@ } /* Make a string which holds just the answer */ - if((sub2 = js_create(len2 + 4,1)) == 0) { + if((sub2 = js_create_DEBUG(len2 + 4,1,"js_create num 28")) == 0) { js_destroy(sub1); return JS_ERROR; } @@ -3502,9 +3502,9 @@ js_string *zone_copy; /* Allocate the memory for a new spot on the dnscache hash */ - if((close = js_alloc(1,sizeof(closer))) == 0) + if((close = js_alloc_DEBUG(1,sizeof(closer),"js_alloc num 12")) == 0) return JS_ERROR; - if((zone_copy = js_create(zone->unit_count + 1,1)) == 0) { + if((zone_copy = js_create_DEBUG(zone->unit_count + 1,1,"js_create num 29")) == 0) { js_dealloc(close); return JS_ERROR; } @@ -3531,7 +3531,7 @@ /* Fill up the "close" structure */ close->num_elements = 1; close->datatype = RR_A; - if((ipp = js_alloc(1,sizeof(uint32))) == 0) { + if((ipp = js_alloc_DEBUG(1,sizeof(uint32),"js_alloc num 13")) == 0) { js_destroy(zone_copy); goto cleanup; } @@ -3630,10 +3630,10 @@ ddip_len = strlen(ddip); /* Initialize the js string objects */ - if((zone_js = js_create(zone_len + 3,1)) == 0) + if((zone_js = js_create_DEBUG(zone_len + 3,1,"js_create num 30")) == 0) return JS_ERROR; - if((ddip_js = js_create(ddip_len + 1,1)) == 0) { + if((ddip_js = js_create_DEBUG(ddip_len + 1,1,"js_create num 31")) == 0) { js_destroy(zone_js); return JS_ERROR; } @@ -3807,9 +3807,9 @@ /* Set up the root nameserver. */ - if((rootns = js_create(256,1)) == 0) + if((rootns = js_create_DEBUG(256,1,"js_create num 32")) == 0) return -3; - if((rootns_zone = js_create(256,1)) == 0) { + if((rootns_zone = js_create_DEBUG(256,1,"js_create num 33")) == 0) { js_destroy(rootns); return -4; } From s@s.org Sun May 19 04:28:17 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: MaraDNS 0.9.31 released; bugfix release >So there is a hit the first time a request for an >item not in the cache is made and after that the cache >answers the call without making a network request to >the other server? This would be ok. If there is >network traffic for every request I suspect admins >will not look kindly on this. It would be cached. Basically, the idea is to use the recursive code, but to send data over this special TCP connection whenever something is not in the cache. It wouldn't be used to resolve cnet or yahoo; it is only used as a go-between between, say, the DNS server and the SQL server or the big file server. All of the TCP traffic would be on a LAN in most cases. >My other comment is that one app sharing code is >more efficient in terms of execution speed and memory >usage than if you split that code into pieces. True enough; I'm thinking the traditional UNIX way, not like an embedded developer, however. Even back in the 1970s, when computers were extremely slow by today's standards, UNIX programs were very inefficiently fork()ing and using shell scripts where every line of the script would fork() one or more programs. The win is that the code is more easily customized, easier to keep secure, and more bug free. From where I am sitting, if I make the SQL support something general purpose like this, I don't have to deal with the people who want to connect to PostgresSQL instead of MySQL. If Slashdot is any indication, that kind of thing is a holy war that would make a Fundamentalist proud; the last thing I want is to be put in the middle of yet another holy war. Dents tried to do this sort of thing with loadable modules. Alas, it ended up being too hard to implement in the real world, so the developer abandoned the project before it was really usable. All of this is post-1.0 anyway; just pie in the sky stuff at this point. - Sam From s@s.org Sun May 19 16:15:02 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.32 released; debugging release I found out last night that MaraDNS' code which tracks memory leaks no longer works. As a result, I have rewritten the code; it now is a simple extension to the code which tracks the memory usage. Playing around, I think I am recreating the leak Franky is seeing. While the memory usage is artifically inflated when a lot of threads are open, if I don't open up any threads and wait a coupld of minutes, I can still see a slow increase in the memory usage. If anyone else wants to see the leaks, here is how to get MaraDNS to show where the leaked memory is being allocated ('$' here simulates the Linux shell prompt): $ cd maradns-0.9.32 $ cd server $ ../leak.change recursive.c > foo $ mv foo recursive.c $ cd .. $ make debug One of these days, I want to learn how to use an editor better than vi; while vi is an excelletn editor, the dual mode never really felt right to me. I need something that is free, can run on a text terminal, and has UTF-8 support. 'mined' looks like it has some promise. Or perhaps I should learn emacs. Then again, Lisp never felt right to me either. Yes, I know, a discussion of editors is a religious one. Like discussing which database MaraDNS should use when I add SQL support to MaraDNS. - Sam From s@s.org Mon May 20 02:00:03 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Responses to stuff sent recently to the list Franky wrote: >And still the question remains about the js_alloc not being a >js_alloc_DEBUG in the function js_create_DEBUG ... Fixed in the 0.9.33 branch I am working on; however this means that every single js_create will be listed twice when listing the unfreed memory. Sean wrote: >I was a long time vi user (I learned vi abut 2 weeks after >I learned what unix was) and switched to emacs a year ago. Yeah, it is looking more and more like vi and emacs are the only two really viable editors out there. What has happened is that UTF-8 has made all of the editors out there obsolete; editors not currently maintained are suddenly useless. Vim, the vi clone I use, has UTF-8 support. Emacs, I am sure, has UTF-8 support also. mined (an old minix editor) has been updated to have utf-8 support. nano, a libre pico clone, does not have uutf-8 support. Going through the source, I found that the editor makes "one byte, one character" assumptions all over the place; updating this editor to support utf-8 would require an almost complete rewrite. Getting back to MaraDNS, there is a time when ipv6 will be the standard on the internet. Which is why it is important to give MaraDNS ipv6 support for the 1.2 release; otherwise there will come a day when MaraDNS will be obsolete. - Sam From s@s.org Mon May 20 11:24:25 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: The memory leak hunt continues Just to keep people updated, I am still hunting down one particular memory leak. It occurs when there are several RRs in a RR chain; for some reason not all the RRs in the chain are properly cleaned up. I was up all night slowly getting more information on this; I need to help my sister get files from her digital camera today. After I am done helping her, I will continue hunting down this leak. - Sam From s@s.org Tue May 21 12:14:49 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.33; bugfix release MaraDNS is out to the world. No real changes, except that it looks like the memory leaks are no more. My informal testing shows no increase in memory usage after doing 8000 queries when the cache is filled. In addition, a bug in askmara is now fixed. Askmara is now smart enough to make sure the answer she gets is the same one that she asked for. MaraDNS now refuses to send a UDP packet to the bogus IPs 255.255.255.255 and 0.0.0.0. Some other bug fixes which I forgot about. - Sam From s@s.org Wed May 22 02:09:02 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Common misconceptions about DNS There is a common misconception about DNS floating around that it is up to the DNS servers serving a given domain, such as example.com, to tell all the other DNS servers in the world when a change happenes to one of the host names in the domain. The idea is that such a change is somehow propagated through the internet is very common. It is also incorrect. DNS was designed in the bad old days of the internet. The days when the backone of the internet was a 56k link. The days when 5 minute timeouts for telnets were needed; a timeout any shorter would prematurely disconnt someone. As a result, it uses caching to store data. However, an ISP's DNS servers do not cache the information about, say, www.maradns.org, until someone asks the ISP's DNS server about maradns.org. At which point, the ISP server will find the DNS server for maradns.org, find out the IP for maradns.org, and also be told how long to cache that data. Clear as mud? Let me word that differently. Some enlightened person on the internet wants to find out more about MaraDNS. So, they whip out Mozilla and decide to go to maradns.org to find out more about this wonderful (newly nearly bug-free [TM]) piece of software. Now, before they can go to maradns.org, they need to find out where maradns.org is on the net. Which requires a rather ugly process called DNS. A process so ugly that most people's home computers don't even bother with this process. Instead, they ask their friendly local ISP's DNS servers where they could find maradns.org on this here internet thingy. So, the home computer asks the ISP's DNS server "Hey, where the heck is MaraDNS org". At this point, the first thing the ISP's DNS server does is look in their cache. "Hmmm, did someone recently ask about maradns.org?" asks the ISP's DNS server. Well, how about that, no one recently asked about MaraDNS. "Oh dear; I have to find where it is on the internet now. Oh, God, please not let this be a host name with out-of-bailiwick name servers." So, to make a long sorid story short, eventually the ISP's DNS server hooks up with the authoritative DNS servers for maradns.org. You know, getting the answer straight form the horses mouth and all that. So, the ISP's DNS server saunters down to the maradns.org name server and asks where it could find maradns.org. The process goes like this: ISP DNS server: Hey, where can I find maradns.org? maradns.org DNS server: It's at 66.33.48.187; remember that for one day. This means now that, for the next 24 hours the ISP's DNS server will reemember that maradns.org can be found at 66.33.48.187. This way, the ISP's DNS server doesn't need to bug the maradns.org DNS server about where maradns.org can be found. So, what happens if maradns.org has a sudden change of address. Well, while maradns.org's DNS server will give everyone the correct new address, there will be a lot of DNS servers out there which will remember the old address for maradns.org for 24 hours. Because of this, people will be knocking on the wrong door until the ISP's DNS server realizes its postit note about where maradns.org can be found (so that Mr. ISP DNS server doesn't have to go through the sordid process of bugging Ms. maradns.org DNS server again) is out of date; forcing Mr. ISP DNS server to get his lazy butt up out of his desk, find Ms. MaraDNS, and ask her about the whereabouts of maradns.org again. Now, notice something about this entire process. Ms. MaraDNS did not have to do anything but answer Mr. ISP DNS server. Ms. MaraDNS did not have to play the gossip game, where she had to tell all her friends where maradns.org can be found, so that those friends can tell their friends, and so on. Why waste her time being a gossip when all she has to do is sit around and answer questions that various ISP's and other recursive DNS servers ask her? There. Now hopefully I have purged the idea about DNS records somehow propagated from everyone's head. That just ain't how it works. - Sam From s@s.org Wed May 22 15:31:41 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Patch Franky, Seems like great minds think alike; follows is what I have already done with the 0.9.34 tree. (Yes, I shouldn't have the socket open too long. Deferred until post-1.0.00, due to pre-1.0.00 lazyness) As for the improved spammers handling, I think that will also be deferred until post-1.0.00. As to the compiler warnings, that is something I need to fix before 1.0.00. - Sam (not looking forward to rewriting the decompressor, but understanding why it has to be done) diff -ur maradns-0.9.33/parse/ParseMaraRc.c maradns-0.9.34/parse/ParseMaraRc.c --- maradns-0.9.33/parse/ParseMaraRc.c Tue May 21 04:04:46 2002 +++ maradns-0.9.34/parse/ParseMaraRc.c Wed May 22 15:05:11 2002 @@ -969,6 +969,8 @@ if(!error) *errorret = 0; + js_close(file); + return JS_SUCCESS; } diff -ur maradns-0.9.33/server/recursive.c maradns-0.9.34/server/recursive.c --- maradns-0.9.33/server/recursive.c Tue May 21 08:41:39 2002 +++ maradns-0.9.34/server/recursive.c Tue May 21 15:49:27 2002 @@ -1394,10 +1394,10 @@ /* Create a UDP client socket */ if((s = socket(AF_INET,SOCK_DGRAM,0)) == -1) { - if(rlog_level >= 4) { + if(rlog_level >= 2) { write_lock(); show_timestamp(); - printf("Failure creating socket\n"); + printf("WARNING: Failure creating socket\n"); write_unlock(); } goto cleanup; From s@s.org Fri May 31 03:21:17 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: MaraDNS 0.9.34 released >Sam, I mailed you two typo's in the recursive.c file as well, so >I'll mail them to the list until the next version comes out? Well, I have just put the next version up on the webpage, and it does fix these typos. I appreciate the contribution, though. You may also observe that some of other things you asked for have been implemented in this version of MaraDNS. Time to upload to sunsite, sourceforge, and announce on freshmeat. - Sam From s@s.org Sun Jun 02 03:18:56 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Various web log systems out there While I am steadily working on the 0.8.35 release (I am about 1/2 done writing the new decompression code), I would like to present a brief comparison of some web log systems out there. The things I don't like about Slashcode boil down to the following: * No IP logging with anonymous accounts. This allows twits to come in as an anonymous coward and post petty little "You're fat and have a small penis"-style [1] posts with no accountability. IP where people post anonymously should be made public. * Moderation should be anonymous. People have the right to mod people down, but should be held accountable for their actions. * The editors are the only one who can post new journal entries. Slashcode is, essentially, a fancy web log. Yes, people can comment on the postings, and, yes, other people can moderate the commented postings. However, Slashcode does not give people enough accountability for their actions; nor does it allow the story submission process to be open. I think Scoop is much better done; moderations to posts are public. "Fat and small penis"-style posts can be modded down to zero, at which points the posts are completely zapped. There are no anonymous accounts; people are accountable for what they say. The community decides which posts make the front page. Live journal is also an excellent system; its problem is that the whole structure of Live Journal encourages cliques. The disadvantage of all these systems is that they are inefficient; one of these days I will code up a system which uses scripts to make static HTML pages with journal entries; a simple cgi system can be used to handle comments people may have on my postings. It is far too easy for one of these SQL-based journal systems to be overloaded; I think, given one year and a good C coder, it would be possible to make a web server optimized for journalling faster then greased lighting. Then again, I am not pretentious enough to think that millions of users will rush in to comment on my web page. As Usenet continues to slowly die off, these kinds of web communities will take their place. I believe that Slashdot was the first really sucessful post-usenet web community; I was still a Usenet junkie when Slashdot was slowly gaining popularity. I think Usenet has a lot of serious problems; its time has come and gone. - Sam [1] For the record, while eating too much mac-n-cheeze and not doing enough walks to the beach has caused me to gain more weight than I would like to have, I am still not fat. And, yes, that part of me is "bigger than average". From s@s.org Sun Jun 02 05:45:57 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: Re: Various web log systems out there >Hmm, what does this have to do with maradns? Oh, nothing. I've noticed, Richard, that you are starting to be overwhelmed by the amount of postings this list is getting. I would not be offended if you unsubscribe from the list; I do not consider it rude for someone to want to unsubscribe from a mailing list when the traffic starts to pick up. I know a lot of software projects have this idea that, if you are using the software, you must be subscribed to the mailing list. MaraDNS is not one of those software projects: A usual MaraDNS upgrade gets about 300 downloads, and the list has about 50 people on it. No one who uses MaraDNS is any kind of obligation to listen to my rants. If one wants announce-style postings only, one can subscribe to the Sourceforge updates. I almost always do a sourceforge update when I release a new version of MaraDNS. Any new release which I consider significantly meaningful is also announced on Freshmeat; one can get really low traffic by subscribing to the Freshmeat announce for MaraDNS. I feel that Usenet was at its best when the topic started to drift; such postings are an important part of building an on-line community. It's not like one will miss out on anything before 1.0 is released. The kind of discussion that endusers find interesting--What features will be incorporated in to the next release--is not really viable until I get 1.0.00 out in the big bad world. The mailing list doesn't quite have the critical mass to start up the kinds of interesting discussions which make the list fun to subscribe to for the people in on the discussion, and annoying to everyone else on the list; but I think it will have that kind of critical mass in a year. I consider these kinds of "bar room" discussions positive discussions; flame wars are negative discussions. A lot of development lists, by having such a narrow focus, degenerate in to having far more flame wars than legitimate discussions. Just my two cents. That said, I do want to get some kind of formal weblog system up; if MaraDNS was not currently taking up all of my coding energies I could do something in a day or two. Do people feel it is worth it for me to make www.samiam.org a simple weblog (blog) so that I no longer have a need to use the MaraDNS mailing list as a sounding board? Keep in mind that coding this can take as long as a week; I do not have the ability to use one of the SQL-based "weblog in a box" systems and feel unconfortable with anything that does something besides generate static HTML pages (I will worry about a comment section later). - Sam - Sam From s@s.org Sun Jun 02 06:39:53 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: [MARA-CHAT] I've figured out a workaround I have figured out a workaround to the problem of myself (and possibly others) posting things here which may not be of interest of MaraDNS users (until I can get the blog set up). Should have thought of it sooner, but I'm in a coding frenzy and half-asleep. The answer is simple: Have special subject beginnings. The ones I propose are: [MARA-CHAT]: Chatty stuff not directly related to MaraDNS [MARA-ANNOUNCE]: Announcement of a new MaraDNS release [MARA-DEVEL]: Development-related concerns (such as a bug report or a feature request) While this is not ideal, since people will tend to not change the subject line when making a reply, it will allow people who wish to keep up with the forefront of MaraDNS without getting their mailbox cloberred to set up procmail recipies or what not to separate the chatty stuff from the important stuff. ObMaraDNS: The new decompression code is coming along nicely. Are people interested in downloading the half-completed new code? Not very glamourous stuff (it just does what the old decompression code did in a much better and more flxible manner), but some people like being on the bleeding edge just for the sake of being on the bleeding edge. - Sam (Hey, I enjoy the chatty stuff, but can see where it annoys people sometimes) From s@s.org Sun Jun 02 06:50:17 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: [MARA-DEVEL] MaraDNS snapshot uploaded I have uploaded a snapshot of MaraDNS; this is a pre-release of the 0.9.35 code base which will use the new decompression code. Some points: * This snapshot release thinks it is MaraDNS 0.9.35, but it is really a "CVS head" release somewhere between 0.9.34 and 0.9.35 * The actual DNS server still uses the old decompressor; the new decompressor is not ready for prime time yet. * The sha1sum of this snapshot is: f3ab13b8b23d94aaf5c29d502c33c96962272338 It can be found here: http://www.maradns.org/maradns-current.tar.bz2 - Sam From s@s.org Sun Jun 02 17:28:51 2002 From: e8mhpsznamq001@sneakemail.com To: list@maradns.org Subject: [MARA-DEVEL] Re: Various web log systems out there [I'm tagging the "developer related" because this list really needs an archive] Joe Cooper wrote: Sam, if you'd like, I'll be happy to setup a dummy list for archiving the mara list and make it searchable. It would provide archives by date/thread/author/subject and a search form. If you have an existing archive of messages, give me a link where to download and I'll import them. I respond: Joe, this is exactly what the list needs! Right now, the list is not being archived :-(. While the traffic is small enought that I have been able to add questions asked here to the FAQ easily enough, I fear that will soon no longer be the case. I am going back to school tomorrow (!!!) and will be much more busy. I will make your archive the official MaraDNS archive. I have all of the postings from the original MaraDNS mailing list (the one which existed until November, 2001); I also have all of my postings between November 2001 and now archived. Unfortunatly, I have not archived most postings from other people between November and now. I really appreciate this kind of help; it gives me more time to think about making MAraDNS have the best code it can have. Off-Topic: My quick and dirty web log: --8<--8<--8<--8<-- #!/bin/bash # The top of the blog web page cat blog.head > ~/tmp/blog.page.html # Add all of the indivual entries; the blogs directory # where each blog entry is HTML in a file with a numeric # filename; newer blogs have bigger numbers for entry in $( ls ~/blogs | sort -nr | tail -10 ) ; do # Each blog entry may have its own HTML header and # footer, such as a frame to put the blog entry in # or a picture of the blogger (a.k.a. Live Journal) cat blog.entry.head >> ~/tmp/blog.page.html cat $entry >> ~/tmp/blog.page.html cat blog.entry.footer >> ~/tmp/blog.page.html done # The bottom of the blog web page cat blog.footer >> ~/tmp/blog.page.html --8<--8<--8<--8<-- - Sam