From remco at webconquest.com Wed May 23 04:33:02 2007 From: remco at webconquest.com (Remco Rijnders) Date: Wed, 23 May 2007 10:33:02 +0200 (CEST) Subject: [List] Test mail Message-ID: <17243.167.202.196.71.1179909182.squirrel@webmail.xs4all.nl> Just testing From lars at hfk-bremen.de Thu May 24 02:52:08 2007 From: lars at hfk-bremen.de (lars) Date: Thu, 24 May 2007 08:52:08 +0200 Subject: MaraDNS stops resolving In-Reply-To: <464E1492.50307@rogers.com> References: <464E1492.50307@rogers.com> Message-ID: <073C36BE-2E5F-4C8F-BE13-4CBCFE89FA10@hfk-bremen.de> hi, > I'm having an issue with maradns-1.2.12.05 where it will simply > stop responding. > The server just stops accepting connections and stops answering > queries- remote or local. I have the same problem already for a year or so. Mara is up, but stops resolving with that errormessage: May 24 08:36:12 mail maradns.etc_maradns_mararc: Query from: 192.168.115.24 Awww.google.com. May 24 08:36:12 mail maradns.etc_maradns_mararc: Log: No reply from remote servers May 24 08:36:15 mail maradns.etc_maradns_mararc: Log: Message received, processing May 24 08:36:15 mail maradns.etc_maradns_mararc: Query from: 192.168.115.24 Awww.google.com. May 24 08:36:15 mail maradns.etc_maradns_mararc: Log: No reply from remote servers May 24 08:36:49 mail maradns.etc_maradns_mararc: Log: Message received, processing May 24 08:36:49 mail maradns.etc_maradns_mararc: Query from: 127.0.0.1 P160.225.183.76.in-addr.arpa. May 24 08:36:49 mail maradns.etc_maradns_mararc: Log: No reply from remote servers ... and so on ... > To make this much stranger, this happens on all three DNS servers > (all MaraDNS, different Linux builds) at the same time. The > servers are on sequential IPs, in case it's possibly a scan tool > causing this. I have that problem on different debian builds (etch/ sarge) with different mara-versions, 1.2.12.04-1 and 1.2.12.05. it is quite easy to solve with the call of "/etc/init.d/maradns restart" via cron once a day, but on the other hand it is a bit dissatisfactory ... maybe Sam has a good idea? greetings lars From cgrote at memhosp.com Thu May 24 08:14:45 2007 From: cgrote at memhosp.com (Curtis Grote) Date: Thu, 24 May 2007 07:14:45 -0500 Subject: maradns init.d script Message-ID: <200705240714.45441.cgrote@memhosp.com> I have just installed MaraDNS 1.2.12.06 and it is running without any problems. Thanks for a great product! I would like to automate the startup and have seen reference to a startup script 'maradns' to be placed in /etc/init.d, but I cannot find that script anywhere in the package distribution. Could someone please point me in the right direction. Thanks. Curtis Grote Memorial Hospital From kai.hendry at gmail.com Thu May 24 08:16:06 2007 From: kai.hendry at gmail.com (Kai Hendry) Date: Thu, 24 May 2007 13:16:06 +0100 Subject: maradns init.d script In-Reply-To: <200705240714.45441.cgrote@memhosp.com> References: <200705240714.45441.cgrote@memhosp.com> Message-ID: I think there is an init script you could steal from the debian package: http://packages.qa.debian.org/m/maradns.html From cgrote at memhosp.com Thu May 24 08:37:17 2007 From: cgrote at memhosp.com (Curtis Grote) Date: Thu, 24 May 2007 07:37:17 -0500 Subject: maradns init.d script In-Reply-To: References: <200705240714.45441.cgrote@memhosp.com> Message-ID: <200705240737.17969.cgrote@memhosp.com> Thanks for the quick response and the pointer! I found the script in the 'build' folder and it is called 'mara.startup'. Curtis Grote Memorial Hospital On Thursday 24 May 2007 07:16, Kai Hendry wrote: > I think there is an init script you could steal from the debian package: > http://packages.qa.debian.org/m/maradns.html From strenholme.usenet at gmail.com Thu May 24 20:58:20 2007 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 25 May 2007 00:58:20 +0000 Subject: maradns init.d script In-Reply-To: <200705240737.17969.cgrote@memhosp.com> References: <200705240714.45441.cgrote@memhosp.com> <200705240737.17969.cgrote@memhosp.com> Message-ID: <7bd685720705241758t6a4606a8t613638acd7eb5d2e@mail.gmail.com> One site you may want to bookmark is my MaraDNS blog, where I post most MaraDNS updates: http://maradns.blogspot.com/ If you don't want to be spammed with my non-MaraDNS geek projects, go here: http://www.maradns.org/blog/ - Sam From strenholme.usenet at gmail.com Thu May 24 21:13:15 2007 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 25 May 2007 01:13:15 +0000 Subject: MaraDNS stops resolving In-Reply-To: <073C36BE-2E5F-4C8F-BE13-4CBCFE89FA10@hfk-bremen.de> References: <464E1492.50307@rogers.com> <073C36BE-2E5F-4C8F-BE13-4CBCFE89FA10@hfk-bremen.de> Message-ID: <7bd685720705241813q4df779d5y14ab5b60a1349f27@mail.gmail.com> There are a lot of things that may be causing this issue, and it will take a while to troubleshoot and fix. Especially since I don't have internet at home. Basically, here is what MaraDNS does when making a remote DNS query: * MaraDNS launches a new thread * In that thread, MaraDNS binds to a random (crypto-strong random) local UDP port makes a query to a remote DNS server. * MaraDNS uses select() to wait for a reply. * Once MaraDNS gets a reply, MaraDNS then processes the reply. Here is the relevant code: big_unlock(); n = select(maxd,&rx_set,NULL,NULL,&tv); /* OK, we're done waiting for the slow remote DNS server. Lock the * thread again */ do_big_lock(); if(n == -1) /* select error */ { if(rlog_level >= 4) { log_lock(); show_timestamp(); printf("Select error\n"); log_unlock(); } close(s); goto cleanup; } if(n == 0) /* Timeout */ { close(s); if(rlog_level >= 4) { log_lock(); show_timestamp(); printf("Timeout contacting remote nameserver\n"); log_unlock(); } goto minus2; } Now, Lars, when MaraDNS is getting these errors, can you use dig or askmara to make normal DNS queries? For example, @dig @198.41.0.4 www.maradns.org@" or "askmara Awww.maradns.org. 198.41.0.4" (Without the quotes) Why this stops working after a few days is a mystery. I'm going to blame cosmic rays: I will boldly proclaim that this is a Linux kernel bug, and to try another kernel. :) Newer 2.6 kernels can handle threading a lot better then 2.4 kernels, for example. For Michael, I have a patch that will log why we are getting server fail messages. This will help me know if this is the same issue Lars is seeing or not. To apply the patch, enter the maradns-1.2.12.06 directory and type in: patch -p1 < maradns-logerror.patch Where maradns-logerror.patch is attached to this message. - Sam -------------- next part -------------- A non-text attachment was scrubbed... Name: maradns-logerror.patch Type: application/octet-stream Size: 358 bytes Desc: not available Url : http://woodlane.webconquest.com/pipermail/list/attachments/20070525/c8455260/attachment.obj From maradns at agno.net Mon May 28 16:41:54 2007 From: maradns at agno.net (Andrew Agno) Date: Mon, 28 May 2007 13:41:54 -0700 Subject: bind_star_handling with wildcards that match multiple labels In-Reply-To: <7bd685720705141145w1c96c23dkac298e235a907e0@mail.gmail.com> References: <20070426180613.GA1914@andrewagno.com> <200705030527.30763.remco@webconquest.com> <7bd685720705071206r2fb61e77tf0a0b1e1ead51bca@mail.gmail.com> <20070508155150.GB15175@ai.sri.com> <7bd685720705081036w28004152g957553816897bfb2@mail.gmail.com> <20070508182236.GC15175@ai.sri.com> <7bd685720705141145w1c96c23dkac298e235a907e0@mail.gmail.com> Message-ID: <20070528204154.GE7674@ai.sri.com> Sorry I haven't been able to respond before this, but the original problem I had is still present in 1.2.12.06 when I set bind_star_handling=2. That is, with the following mararc and csv2 files, a query for x.y.example.net fails with NXDOMAIN, whereas a query for x.example.net correctly returns 127.0.0.3. mararc: ipv4_bind_addresses = "127.0.0.1" verbose_level=3 chroot_dir = "/tmp/mara/etc/maradns" csv2 = {} bind_star_handling = 2 csv2["example.net."] = "db.example.net" db.example.net: /ttl 60 example.net. NS ns.example.net. ns.example.net. 127.0.0.1 a.example.net. 127.0.0.2 *.example.net. 127.0.0.3 Wildcard CNAME records have the same problems they had before, with bind_star_handling=1: - using *.example.net. CNAME a.example.net. - x.y.example.net won't work - x.example.net works correctly When bind_star_handling=2, all queries that would match the wildcard CNAME return NXDOMAIN. I'm guessing that the CNAME code was not updated at the same time as the A record code, but I haven't really investigated. The following patch fixes wildcard A records for me: --- server/MaraDNS.c 2007-05-28 11:19:58.000000000 -0700 +++ /tmp/MaraDNS-mine.c 2007-05-28 11:26:03.000000000 -0700 @@ -3669,26 +3669,28 @@ if(spot_data.value != 0 && spot_data.datatype == MARA_DNS_LIST) { always_not_there = 4; } + else { + /* Anally strict RFC 1034 section 4.3.3 compliance. If you + * have b.example.com and *.example.com, a.b.example.com does + * *not* match the star record */ + if(bind_star_handling == 2) { + int r; + r = star_collision(lookfor,bighash); + if(r == -1) { + goto serv_fail; + } else if(r == 1) { + udpnotfound(nxstore,header.id,sock,0,origq,0,desires_recursion, + ect,(always_not_there & 3)); + js_destroy(lookfor); js_destroy(origq); js_destroy(lc); + return JS_SUCCESS; + } + } + } if(change_rtype(lookfor,rtype_saver) == JS_ERROR) { goto serv_fail; } } - /* Anally strict RFC 1034 section 4.3.3 compliance. If you - * have b.example.com and *.example.com, a.b.example.com does - * *not* match the star record */ - if(bind_star_handling == 2) { - int r; - r = star_collision(lookfor,bighash); - if(r == -1) { - goto serv_fail; - } else if(r == 1) { - udpnotfound(nxstore,header.id,sock,0,origq,0,desires_recursion, - ect,(always_not_there & 3)); - js_destroy(lookfor); js_destroy(origq); js_destroy(lc); - return JS_SUCCESS; - } - } /* OK, maybe there is a star record "above". In other words, handle the case when they ask for foo.bar.example.com and we have @@ -3696,21 +3698,6 @@ while(bobbit_starlabel(lookfor) > 0) { int rtype_saver = 1; - /* If bind_star_handling is really high, look for any collision - * that breaks RFC1034 section 4.3.3 compliance */ - if(bind_star_handling == 2) { - int r; - r = star_collision(lookfor,bighash); - if(r == -1) { - goto serv_fail; - } else if(r == 1) { - udpnotfound(nxstore,header.id,sock,0,origq,0,desires_recursion, - ect,(always_not_there & 3)); - js_destroy(lookfor); js_destroy(origq); js_destroy(lc); - return JS_SUCCESS; - } - } - if(bind_star_handling >= 1) { rtype_saver = get_rtype(lookfor); } @@ -3735,6 +3722,22 @@ spot_data.datatype == MARA_DNS_LIST) { always_not_there = 4; } + else { + /* If bind_star_handling is really high, look for any collision + * that breaks RFC1034 section 4.3.3 compliance */ + if(bind_star_handling == 2) { + int r; + r = star_collision(lookfor,bighash); + if(r == -1) { + goto serv_fail; + } else if(r == 1) { + udpnotfound(nxstore,header.id,sock,0,origq,0,desires_recursion, + ect,(always_not_there & 3)); + js_destroy(lookfor); js_destroy(origq); js_destroy(lc); + return JS_SUCCESS; + } + } + } if(change_rtype(lookfor,rtype_saver) == JS_ERROR) { goto serv_fail; } From lars at hfk-bremen.de Wed May 30 04:30:23 2007 From: lars at hfk-bremen.de (lars) Date: Wed, 30 May 2007 10:30:23 +0200 Subject: MaraDNS stops resolving In-Reply-To: <7bd685720705241813q4df779d5y14ab5b60a1349f27@mail.gmail.com> References: <464E1492.50307@rogers.com> <073C36BE-2E5F-4C8F-BE13-4CBCFE89FA10@hfk-bremen.de> <7bd685720705241813q4df779d5y14ab5b60a1349f27@mail.gmail.com> Message-ID: <38203999-D9AF-49CA-913B-ED2316F2C40B@hfk-bremen.de> hi, sam, and thanx for the reply. > There are a lot of things that may be causing this issue, and it will > take a while to troubleshoot and fix. Especially since I don't have > internet at home. nice joke ;-) eeh - "really ... ?!" > Basically, here is what MaraDNS does when making a remote DNS query: > (...) > * Once MaraDNS gets a reply, MaraDNS then processes the reply. thanx for the good explanation! > Now, Lars, when MaraDNS is getting these errors, can you use dig or > askmara to make normal DNS queries? For example, @dig @198.41.0.4 > www.maradns.org@" or "askmara Awww.maradns.org. 198.41.0.4" (Without > the quotes) since it happens only occasionally i?ll have to wait for the next time; then I will give it a try and post the result here. > Newer 2.6 kernels can handle threading a lot better then 2.4 kernels, > for example. OK. but i am using 2.6.15-1-686 on both machines. *but* i am using debian on both machines as well *and* the maradns that came with the distribution. maybe it is a problem caused by some dependencies between maradns and the libraries debian is using .. ?! just an idea. greetings lars From jpqojrvg at klabal.net Thu May 31 00:42:49 2007 From: jpqojrvg at klabal.net (Babara) Date: Thu, 31 May 2007 04:42:49 +0000 Subject: myCanadian online drugstore Message-ID: <3YNK8F.20070523033951@127.0.0.5> An HTML attachment was scrubbed... URL: http://woodlane.webconquest.com/pipermail/list/attachments/20070531/f352b222/attachment.htm From bogus@does.not.exist.com Wed May 23 04:33:03 2007 From: bogus@does.not.exist.com () Date: Wed, 23 May 2007 08:33:03 -0000 Subject: No subject Message-ID: verbose_query verbose_query: Whether to verbosely output all DNS queries that the recursive DNS server receives. If this is set to 1, then all recursive queries sent to MaraDNS will be logged. This is mainly used for debugging. In other words, to give me more information, try adding this to your mararc: verbose_query=1 This will make a log of each recursive query MaraDNS spawns. This will, hopefully, make it possible for me to reproduce the concern, once I get a sufficiently verbose log file sent to me in private email. It is also possible to have MaraDNS have a higher logging level after being started. Again, I set this up to make debugging these kinds of problems easier. Basically, try adding something like this to the mararc file: admin_acl = "127.0.0.1" remote_admin = 1 Then, to up MaraDNS' logging level: askmara T9.verbose_level.maradns. Or, for that matter: dig @127.0.0.1 9.verbose_level.maradns TXT To lower the logging level: askmara T0.verbose_level.maradns. dig @127.0.0.1 0.verbose_level.maradns TXT Anyway, I hope to be able to reproduce this bug. Keep in mind, I don't have internet at home and that I don't keep computers running MaraDNS nonstop for days, so I can't see these kinds of issues. It could be a lot of things, and mat not even be MaraDNS' fault. However, people are free to send me verbose log messages to help me get to the bottom of it. - Sam From bogus@does.not.exist.com Wed May 23 04:33:03 2007 From: bogus@does.not.exist.com () Date: Wed, 23 May 2007 08:33:03 -0000 Subject: No subject Message-ID: I have a NS delegation, and MaraDNS is doing strange things. In the case of there being a NS delegation, MaraDNS handles recursive queries and non-recursive DNS queries differently. Basically, unless you use askmara with the -n option, dig with the +norecuse option, or nslookup with the -norec option, MaraDNS will try to recursively resolve the record that is delegated. The thinking is this: A normal recursive DNS query is usually one where one wants to know the final DNS output. So, if MaraDNS delegates a given record to another DNS server, and gets a recursive request for said query, MaraDNS will recursively resolve the query for you. For example, let us suppose we have a mararc file that looks like this: chroot_dir = "/etc/maradns" ipv4_bind_addresses = "10.1.2.3" chroot_dir = "/etc/maradns" recursive_acl = "127.0.0.1/8, 10.0.0.0/8" csv2 = {} csv2["example.com."] = "db.example.com" And a db.example.com file that looks like this: www.example.com. 10.1.2.3 joe.example.com. NS ns.joe.example.com. ns.joe.example.com. A 10.1.2.4 Next, you are trying to find out why www.joe.example.com is not resolving. If you naively send a query to 10.1.2.3 for www.joe.example.com as askmara Awww.joe.example.com. 10.1.2.3 or as dig @10.1.2.3 www.joe.example.com. or as nslookup www.joe.example.com. 10.1.2.3, you will not get any information that will help you solve the problem, since 10.1.2.3 will try to contact 10.1.2.4 to resolve www.joe.example.com. The solution is to run your DNS query client thusly: * Askmara would be run thusly: askmara -n Awww.joe.example.com. 10.1.2.3 * Dig would be run thusly: dig +norecurse @10.1.2.3 www.joe.example.com * Nslookup would be run thusly: nslookup -norec www.joe.example.com 10.1.2.3 This will allow you to see that packets MaraDNS actually sends to a recursive DNS server. As an aside, this particular problem will not happen if MaraDNS is run only as an authoritative nameserver. For future reference, MaraDNS documentation is here: http://www.maradns.org/notes.html - Sam - Sam From bogus@does.not.exist.com Wed May 23 04:33:03 2007 From: bogus@does.not.exist.com () Date: Wed, 23 May 2007 08:33:03 -0000 Subject: No subject Message-ID: relative to BIND9, MaraDNS is 134% faster then BIND9, and a lot faster then BIND9 with LDAP backend, and only marginally second compared to PowerDNS using a bind style config files. The second column seems to be memory usage, MaraDNS seems to use the most, any way to improve this to a comparable level of BIND9? Although with ram/hardware prices going down all the time this might not be that much of an issue, unless you are in a virtual hosting situation with 64M of ram or even 128 might start to matter depending how many zones etc your are planning to host. It looks like they used XEN with 256M of memory allocated. Third column seems to be average CPU usage, MaraDNS appears to be second only to NSD which doesn't do recursion, so that's not a bad result at all. I haven't been able to find any other testing on -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." From bogus@does.not.exist.com Wed May 23 04:33:03 2007 From: bogus@does.not.exist.com () Date: Wed, 23 May 2007 08:33:03 -0000 Subject: No subject Message-ID: dns interference and injections and all that kind of thing. For me the biggest down side to it all is probably going to be the gatekeeper and I don't want to get caught paying increasing amounts of money on top of domains I'm already paying for as popularity increases AKA Verisign tax. So for me it's a "nice idea", but I'm not going to be bothered doing anything about it until something is done about the potential for future abuse. -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." From bogus@does.not.exist.com Wed May 23 04:33:03 2007 From: bogus@does.not.exist.com () Date: Wed, 23 May 2007 08:33:03 -0000 Subject: No subject Message-ID: is crucial that the DNS is absolute reliable. So every evidence that DNS goes wrong is needed to prevent a desaster. Imagin a DNS server that is misconfigured the following way: No recursive queries for MX and therefore answer "Answer: 0" to every MX DNS query but "Answer:1" for A records. In the best case no email can be delivered. In worst case every email is delivered a wrong way (send to the A entry). So I understand the developers of exim that the try to do some sanity checks to avoid such a desaster. On the other hand I do not like such workarounds as exim have. They produce systems with nearly unpreductable behavior. The best efford should be to define and implement better standards. And you are right that this is a corner case. I will bring this point to the exim mailing list. Maybe they can omit the flag checking. > Don't get me started on RFC1912 section 2.2, where the serial number > is supposed to be in a format that is only meaningful if you edit the > SOA serial by hand. > Oh No! You are on the right track to implement what is truly used and what is resonable. > Yes, this would be a useful bit in the header if it was, say RP > (recursion performed) telling you that the query in question was one > processed recursively, and not coming from the local DNS server. > I agree strongly. > I also feel RD is handled wrong in BIND. BIND's handling of RD has > privacy implications: BIND simply doesn't recurse to process a given > query, but if the query is already in the cache, BIND will give you > the query from the cache. > > In MaraDNS, if RD is cleared, MaraDNS will not ever give you any > information from the cache, but will only answer authoritative > queries. > The behavior of maradns seems to me the definitive better choice. I like the security aspects of maradns much. After the last BIND incident our team has put feet on the desks while the other admins get into panic to fix their bind systems. These are the moments when you know for sure that you have choosen the right DNS server. Another of this moments was that I was able to track down this flag issue within some hours. Within the Bind sources I suppose I have been lost. Best regards, Volker -- ==================================================== inqbus it-consulting +49 ( 341 ) 5643800 Dr. Volker Jaenisch http://www.inqbus.de Herlo?sohnstr. 12 0 4 1 5 5 Leipzig N O T - F ? L L E +49 ( 170 ) 3113748 ==================================================== From bogus@does.not.exist.com Wed May 23 04:33:03 2007 From: bogus@does.not.exist.com () Date: Wed, 23 May 2007 08:33:03 -0000 Subject: No subject Message-ID: http://marc.info/?l=maradns-list - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From bogus@does.not.exist.com Wed May 23 04:33:03 2007 From: bogus@does.not.exist.com () Date: Wed, 23 May 2007 08:33:03 -0000 Subject: No subject Message-ID: --- On April 28, 2007, Valkonen warned the Arch Linux maintainers of possible legal action because the (unofficial) Arch User Repository contained scripts to install Ion3 with patches he did not approve of. Later on he did the same with the pkgsrc maintainer of the NetBSD project and the ports maintainer of the FreeBSD project. As of December 12, 2007, the development branch of Ion, along with other software by Valkonen, was pulled from the FreeBSD ports tree, after the author filed a complaint about outdated development releases still being available. Any version of Ion may still be installed from source code on any Unix system with proper libraries and dependencies. --- As it turns out, I completely understand some of his frustration. This is an all-too-common scenario that has happened to me: * I make a release of MaraDNS. * Someone sends me an email about a bug in MaraDNS. * Meanwhile, MaraDNS is packaged in to OpenBSD/Debian/Ubuntu/whatever. * I fix the bug. * The maintainers of the OpenBSD/Debian/Ubuntu/etc. package don't incorporate my bugfix in the version of MaraDNS included with their program. * I get more email about the bug which I have already fixed. Very annoying (but, of course, allowed in the license). I finally resolved it (and the people asking for features and the people asking me to fix problems on unsupported ports of MaraDNS and...) by no longer accepting personal email about MaraDNS, barring "I've found this security problem in MaraDNS" type email. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From bogus@does.not.exist.com Wed May 23 04:33:03 2007 From: bogus@does.not.exist.com () Date: Wed, 23 May 2007 08:33:03 -0000 Subject: No subject Message-ID: should be trying all the NS's before SERVFAIL'ing/giving up surely? Annoyingly, for this bug, I have grumbled to harvard and they have made ns[12]?.harvard.edu now slaves for wjh.harvard.edu and so fixed the issue. There are going to be others, shall I pester the postmaster here for more test cases? :) Cheers [1] so the NS's listed in example.com for wibble.example.com were A, B and C...when asking either of those you would get the answer A, B, C, X and Y as NS's. MaraDNS would never query X and Y who were the ones with the answer. -- Alexander Clouter .sigmonster says: A bug in the code is worth two in the documentation.