From MSands at EPLUS.com Mon Dec 20 14:38:40 2010 From: MSands at EPLUS.com (Mike Sands) Date: Mon, 20 Dec 2010 14:38:40 -0500 Subject: documentation modification Message-ID: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> Not sure if this is the proper forum but I would like to make a suggestion for updating the documentation under the tutorials on maradns.org Under the initial compile and installation document it incorrectly leads you to believe that the make install will install the deadwood piece. "This will install both the binaries and the man pages for 'maradns', 'Deadwood' (MaraDNS 2.0's recursive DNS server), 'askmara', 'duende', 'fetchzone', and 'zoneserver'. In addition, this will (if the files are not already present), install an example /etc/mararc, make the /etc/maradns directory, and place an example zone file (db.example.com) in /etc/maradns. Finally, this will place MaraDNS documentation in /usr/local/doc ; man pages will be placed in /usr/local/man or /usr/local/share/man." This is not really true as I found you have to go into the Deadwood subdirectory and follow the INSTALL.txt document there to complete the installation of the recursive server. Not a big deal but it did throw me off track for a bit and it would be nice if this was called out. Mike Sands ePlus Technology, inc. www.eplus.com The information contained in this electronic transmission and any attachments hereto may be considered proprietary and confidential. Unauthorized distribution of this material to anyone other than the addressed is prohibited. Any disclosure, distribution or use of this transmission for any reason other than their intended purpose is prohibited. From jefsey at jefsey.com Mon Dec 20 17:58:02 2010 From: jefsey at jefsey.com (jefsey) Date: Mon, 20 Dec 2010 23:58:02 +0100 Subject: documentation modification In-Reply-To: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdo m.com> References: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> Message-ID: <7.0.1.0.2.20101220215156.06575c30@jefsey.com> At 20:38 20/12/2010, Mike Sands wrote: >Not sure if this is the proper forum but I would like to make a >suggestion for updating the documentation under the tutorials on maradns.org Sam, Mike and all, when Sam joined his new job he asked not to be sponsored anymore and told he could not develop for maradns anymore. So, he suggested me to start a fork for the particular evolution I have in mind. I considered it, consulted with some friends and decided to taste the water with a real site about a fork I named "alfaDNS" (it keeps the "a-a" sound). . I was definitly blocked for a few months. Now, I can give a few (very few) hours a week to (discuss) this project (http://alfaDNS.org). My target is to support IDNA2008 (RFC 5890 to 5895) in building a dedicated IDNApplication. This means that: - instead of supporting the IDN UTF/ASCII conversion at each application and passing the xn-- converted ASCII labels to the regular DNS system, - I plan to run a single "ML-DNS" local server, accepting UTF domain names from any existing application and resolving them locally. This is faster (direct local service), this is cheaper (one single name server), this is more secure and esier (everything including the root is local) and surer (there is single UTF/ASCII routine on a machine hich resolves to the same IP address what ever the application). This is free from national regulations. This is just a quick scketch, the discussion can be endless. However, this architecture IS now one of the accepted architectural reading of the RFCs that the IAB is now to digest (first IAB RFC on IDNA is pending). The initial prototype changes are very limited : 1. to include a non 0-Z filter in the input and a punycode routine (with error as a default) 2. to inlucde a "xn--" filter in the output and a punycode routine (with error as a default) 3. to discuss the best way to support domain name information 4. to organize a developper's kit supporting minGW, Cygwin and Linux compilation for people (lead users, not necessarily experts) to test, discuss, imagine and document. My first target would be to get people play with it, explore the code and review the architecture in its new environment. Then start designing an associated dn management and registration system to a full multilingual multi-TLD namespace in order to report the IETF through the iucg at ietf.org (internet users contributing group) mailing list I facilitate (http://iucg.org). jefsey morfin From strenholme.usenet at gmail.com Tue Dec 21 20:47:33 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 21 Dec 2010 18:47:33 -0700 Subject: documentation modification In-Reply-To: <7.0.1.0.2.20101220215156.06575c30@jefsey.com> References: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> <7.0.1.0.2.20101220215156.06575c30@jefsey.com> Message-ID: > when Sam joined his new job he asked not to be sponsored anymore > and told he could not develop for maradns anymore. There seems to be some confusion about my current employment status and how it affects MaraDNS. The main way my day job affects MaraDNS is in the fact I haven't had nearly as much time to develop MaraDNS as I did before; working six days a week does that (and, yes, six-day workweeks are a reality in today's economic climate). My plan has been, long before I got hired at my current gig and even long before I even heard of the company I work for today, to no longer add features to MaraDNS once MaraDNS was out the door: http://maradns.blogspot.com/2009/10/every-open-source-developer-grows-up.html The only thing that has changed is that, because of a potential conflict of interest, I have decided it is best to not receive donations for MaraDNS development at this time. And, quite bluntly, since I earn more in my day job in one week than I have earned for my decade of MaraDNS development, I think that's a perfectly fair deal. Let me make this crystal clear: I am still supporting MaraDNS (by answering emails posted to the mailing list when I have time). I am still fixing bugs in MaraDNS and Deadwood. I have not walked away from MaraDNS. Please do not create rumors that MaraDNS is somehow abandoned or dead. Because, unlike what happened with djbdns, my development model does not consist of walking away from the code because I got bored with developing it one day (that day being February 11 2001 with djbdns). Indeed, if you poke around the MaraDNS website, you can see that I have made recent updates to my code, and, as you can see here, I am still posting to the MaraDNS mailing list. - Sam From strenholme.usenet at gmail.com Tue Dec 21 20:56:13 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 21 Dec 2010 18:56:13 -0700 Subject: documentation modification In-Reply-To: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> References: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> Message-ID: > Under the initial compile and installation document it incorrectly leads > you to believe that the make install will install the deadwood piece. OK, if "make install" doesn't install both Deadwood and maradns in MaraDNS 2.0, this is a bug. This is one of the handful of bugs on my MaraDNS TODO list to fix. Other bugs are: 1) There is (or was) an issue with Deadwood resolving urbandictionary.com. The issue has to do with the corner case where each packet Deadwood sees is under 512 bytes in size, but the final reassembled packet is over 512 bytes in size. 2) There is an issue with Deadwood resolving Akamai domains, because, while CNAME records are cached, these cached CNAME records aren't actually used. 3) There is an issue with maradns handling ANY queries that result in a DNS packet larger than 512 bytes in size. MaraDNS does not give a proper "truncated" reply, and it appears the tcp "zoneserver" program can't resolve these names either. 4) The bug discussed above in this mail. When am I going to fix these bugs? Good question; I'm working six-day weeks so it will more likely be later rather than sooner. My rough plan right now is to come out with a bugfix release of MaraDNS + Deadwood once every six months or so. Another thing: I am about to remove MaraDNS 1.2 and MaraDNS 1.0 from the maradns.org DNS server. The support lifetime for these outdated MaraDNS has just ended and, while people are free to continue using these releases, they will not be supported by me (not even to fix security bugs or if they stop resolving google.com tomorrow). MaraDNS 1.3 is still supported for critical security fixes for two more years. -Sam From jefsey at jefsey.com Wed Dec 22 06:22:53 2010 From: jefsey at jefsey.com (JFC Morfin) Date: Wed, 22 Dec 2010 12:22:53 +0100 Subject: documentation modification In-Reply-To: References: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> <7.0.1.0.2.20101220215156.06575c30@jefsey.com> Message-ID: <7.0.1.0.2.20101222121146.064c55c8@jefsey.com> At 02:47 22/12/2010, Sam Trenholme wrote: > > when Sam joined his new job he asked not to be sponsored anymore > > and told he could not develop for maradns anymore. > >There seems to be some confusion about my current employment status >and how it affects MaraDNS. > >Please do not create rumors that MaraDNS is somehow abandoned or dead. If some of my words could have lead to think this, I apologize and I would be happy to use what ever text you would advise to present the use of MaraDNS in the alfaDNS fork. The term of "fork" was used by you. I just follow. I think you were correct. This is because MaraDNS and alfaDNS have not the same architectural understanding of the DNS. * MaraDNS/Deadwood are regular current DNS (let call it "inside" DNS) * while the target of alfaDNS is an "outside" DNS interface, encapsulating MaraDNS, and probably adding new features to that core : classes, groups, IDv6, etc. features xe need and that belong to applied Internet research. If I am incorrectly reading you, we need to clarify. A possibility is to remove your name everywhere, but in the license; instead of provinding links to your site everywhere. Another problem is to keep the documentation synchronized since you have a master and your own program to multi-format it. Enventually we will have this documentation reviewed in taking care of the additions/changes we may introduce. Best jfc From MSands at EPLUS.com Wed Dec 22 08:26:08 2010 From: MSands at EPLUS.com (Mike Sands) Date: Wed, 22 Dec 2010 08:26:08 -0500 Subject: documentation modification In-Reply-To: References: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> <7.0.1.0.2.20101220215156.06575c30@jefsey.com> Message-ID: <2688766582E16041AFB400DD06CDCB7905A83A4F87@EPEXMB02.epgpdom.com> Thanks for the clarification Sam. I admit I was somewhat taken back by the initial response but that appears to have been a miscommunication. I'm glad to hear that maradns is alive and well. -----Original Message----- From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf Of Sam Trenholme Sent: Tuesday, December 21, 2010 8:48 PM To: list at maradns.org Subject: Re: documentation modification > when Sam joined his new job he asked not to be sponsored anymore > and told he could not develop for maradns anymore. There seems to be some confusion about my current employment status and how it affects MaraDNS. The main way my day job affects MaraDNS is in the fact I haven't had nearly as much time to develop MaraDNS as I did before; working six days a week does that (and, yes, six-day workweeks are a reality in today's economic climate). My plan has been, long before I got hired at my current gig and even long before I even heard of the company I work for today, to no longer add features to MaraDNS once MaraDNS was out the door: http://maradns.blogspot.com/2009/10/every-open-source-developer-grows-up.html The only thing that has changed is that, because of a potential conflict of interest, I have decided it is best to not receive donations for MaraDNS development at this time. And, quite bluntly, since I earn more in my day job in one week than I have earned for my decade of MaraDNS development, I think that's a perfectly fair deal. Let me make this crystal clear: I am still supporting MaraDNS (by answering emails posted to the mailing list when I have time). I am still fixing bugs in MaraDNS and Deadwood. I have not walked away from MaraDNS. Please do not create rumors that MaraDNS is somehow abandoned or dead. Because, unlike what happened with djbdns, my development model does not consist of walking away from the code because I got bored with developing it one day (that day being February 11 2001 with djbdns). Indeed, if you poke around the MaraDNS website, you can see that I have made recent updates to my code, and, as you can see here, I am still posting to the MaraDNS mailing list. - Sam From strenholme.usenet at gmail.com Wed Dec 22 10:19:10 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 22 Dec 2010 08:19:10 -0700 Subject: documentation modification In-Reply-To: <7.0.1.0.2.20101222121146.064c55c8@jefsey.com> References: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> <7.0.1.0.2.20101220215156.06575c30@jefsey.com> <7.0.1.0.2.20101222121146.064c55c8@jefsey.com> Message-ID: > If some of my words could have lead to think this, I apologize and I would > be happy to use what ever text you would advise to present the use of > MaraDNS in the alfaDNS fork. MaraDNS uses a 2-clause BSD license. This means you can do pretty much anything you want to with the code, as long as this notice is included somewhere: Copyright (c) 2002-2010 Sam Trenholme and others TERMS Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. This software is provided 'as is' with no guarantees of correctness or fitness for purpose. > The term of "fork" was used by you. I just follow. I think you were correct. > This is because MaraDNS and alfaDNS have not the same architectural > understanding of the DNS. I am, as a courtesy, willing to provide a link to (and even a copy of) "alfaDNS" on this page: http://www.maradns.org/dns_software.html Note that I will provide my own assessment of the state of the software on this page; I've seen a lot of DNS projects with big plans which never happen over the years. Indeed, I have some other DNS servers which otherwise wouldn't have homes on the maradns.org webpage: http://www.maradns.org/download/non-maradns/sdns.tar.bz2 http://www.maradns.org/download/non-maradns/oak-1.2.tar.gz http://www.maradns.org/download/non-maradns/oak-1.4.tar.gz (Note to self: digitallumber.com is now owned by a squatter) http://www.maradns.org/moodns-20021011.tar.bz2 From jefsey at jefsey.com Wed Dec 22 14:49:13 2010 From: jefsey at jefsey.com (jefsey) Date: Wed, 22 Dec 2010 20:49:13 +0100 Subject: documentation modification In-Reply-To: References: <2688766582E16041AFB400DD06CDCB7905A83A4E1D@EPEXMB02.epgpdom.com> <7.0.1.0.2.20101220215156.06575c30@jefsey.com> <7.0.1.0.2.20101222121146.064c55c8@jefsey.com> Message-ID: <7.0.1.0.2.20101222204418.0b38d290@jefsey.com> At 16:19 22/12/2010, Sam Trenholme wrote: >Note that I will provide my own assessment of the state of the >software on this page; I've seen a lot of DNS projects with big plans >which never happen over the years. Absolutely. The project is NOT operational by far, and the target is ONLY experimental at this stage. Actually the ML-DNS concept may be controverted for a while. So I would advise you to NOT link alfaDNS until the project has taken off ands is backed by the community. In the other way, alfaDNS afficionados will acknowledge the MaraDNS contribution : even if they are a few thousands it will already be that. >http://www.maradns.org/download/non-maradns/sdns.tar.bz2 >http://www.maradns.org/download/non-maradns/oak-1.2.tar.gz >http://www.maradns.org/download/non-maradns/oak-1.4.tar.gz >(Note to self: digitallumber.com is now owned by a squatter) >http://www.maradns.org/moodns-20021011.tar.bz2 Thank-you. As I said I personnally have not much time, but this is a project that has to go through. It may take time however. jfc From yarin at warpmail.net Mon Dec 27 13:30:22 2010 From: yarin at warpmail.net (Yarin) Date: Mon, 27 Dec 2010 12:30:22 -0600 Subject: compilation bug fix for bsds Message-ID: <1293474622.11827.1412413863@webmail.messagingengine.com> Hello, Your code fails to compile on some BSDs out of the box. The fix is simple, but I thought it would be nice if you would commit the fix to your code to get it working out of the box for more people. --------------------------------------------------------------------- Open ./MaraDns.h: On what should be line 30 which says "#include ", prepend: #include #include Open ./server/udpsuccess.c, and prepend the same 2 lines before all code (but not comments). --------------------------------------------------------------------- Great software, BTW :-) From yarin at warpmail.net Mon Dec 27 14:19:47 2010 From: yarin at warpmail.net (Yarin) Date: Mon, 27 Dec 2010 13:19:47 -0600 Subject: bug fix: defaulting to the /share dir causes the PREFIX variable to be ignored Message-ID: <1293477587.25662.1412418015@webmail.messagingengine.com> Hello, I noticed that the installation script doesn't respect the use of the /share directory by default, but it does try to if the default directory doesn't exist. The problem is, when it tries to use the /share directory, it stops listening to the PREFIX var, and will only use the default /usr/local. --------- Below, is the part of ./build/install.locations in question, right now --------- # If the directory that MAN1 points to does not exist if [ ! -d $MAN1 ] ; then # Then try this location instead MAN1="/usr/local/share/man/man1" fi # Do the same with the MAN5 and MAN8 directories if [ ! -d $MAN5 ] ; then MAN5="/usr/local/share/man/man5" fi if [ ! -d $MAN8 ] ; then MAN8="/usr/local/share/man/man8" fi --------- Below, is my proposed fix of that part --------- # If the directory that MAN1 points to does not exist if [ ! -d $MAN1 ] ; then # Then try the /share directory instead MAN1="$PREFIX/share/man/man1" fi # Do the same with the MAN5 and MAN8 directories if [ ! -d $MAN5 ] ; then MAN5="$PREFIX/share/man/man5" fi if [ ! -d $MAN8 ] ; then MAN8="$PREFIX/share/man/man8" fi Thank you, ----- Yarin Licht From yarin at warpmail.net Mon Dec 27 16:08:26 2010 From: yarin at warpmail.net (Yarin) Date: Mon, 27 Dec 2010 15:08:26 -0600 Subject: bug fix: defaulting to the /share dir causes the PREFIX variable to be ignored In-Reply-To: <1293477587.25662.1412418015@webmail.messagingengine.com> References: <1293477587.25662.1412418015@webmail.messagingengine.com> Message-ID: <1293484106.26426.1412431995@webmail.messagingengine.com> I forget to mention, I'm not sure about Mandrake, but I know with other distros and *nixes, /doc is also expected to be exclusively in /share too. To satisfy that, this should also be added to block of code: # And with the docs as well if [ ! -d "$PREFIX/doc" ] ; then DOCS="$PREFIX/share/doc/maradns-$VERSION" fi ----- Original message ----- From: "Yarin" To: list at maradns.org Date: Mon, 27 Dec 2010 13:19:47 -0600 Subject: bug fix: defaulting to the /share dir causes the PREFIX variable to be ignored Hello, I noticed that the installation script doesn't respect the use of the /share directory by default, but it does try to if the default directory doesn't exist. The problem is, when it tries to use the /share directory, it stops listening to the PREFIX var, and will only use the default /usr/local. --------- Below, is the part of ./build/install.locations in question, right now --------- # If the directory that MAN1 points to does not exist if [ ! -d $MAN1 ] ; then # Then try this location instead MAN1="/usr/local/share/man/man1" fi # Do the same with the MAN5 and MAN8 directories if [ ! -d $MAN5 ] ; then MAN5="/usr/local/share/man/man5" fi if [ ! -d $MAN8 ] ; then MAN8="/usr/local/share/man/man8" fi --------- Below, is my proposed fix of that part --------- # If the directory that MAN1 points to does not exist if [ ! -d $MAN1 ] ; then # Then try the /share directory instead MAN1="$PREFIX/share/man/man1" fi # Do the same with the MAN5 and MAN8 directories if [ ! -d $MAN5 ] ; then MAN5="$PREFIX/share/man/man5" fi if [ ! -d $MAN8 ] ; then MAN8="$PREFIX/share/man/man8" fi Thank you, ----- Yarin Licht From yarin at warpmail.net Mon Dec 27 16:22:42 2010 From: yarin at warpmail.net (Yarin) Date: Mon, 27 Dec 2010 15:22:42 -0600 Subject: request for added feature be commited: duende pid file Message-ID: <1293484962.30412.1412432231@webmail.messagingengine.com> Mr. Trenholme, I noticed that your duende daemon doesn't save itself a pid file, which makes handling it harder. Specifically, the service scripts included in your latest release, have to do some really hackish things to shut down the daemon. :-( To fix this, I've added a PID file feature to the duende. I figured, all good daemons have it, why doesn't yours? :-) I've successfully compiled and tested the code, and am using it myself, so it's ready to go. Basically, I just added a some chunks near the start of the main() routine, but modified it a hair to accommodate the changes. Besides that, I replaced all of the "argv[1]" occurrences with "argv[exec_argv_offset]" beyond the first for() loop in main(). (Note: I also preserved your formatting style is the new code) Below is the proposed new code for the main() function of the file ./tools/duende.c: int main(int argc, char **argv) { int exit_status; pid_t pid, log_pid; int stream1[2]; /* Used for piping */ int exec_argv_offset = 1; /* Also used to determine PID writing */ if(argv[0] == NULL || argv[1] == NULL) { printf("Usage: duende (--pid=/path/to/file) [program] [arguments]\n"); exit(1); } if(!strncasecmp(argv[1],"--pid=",6)) { if(argv[2] == NULL) { printf("Usage: duende (--pid=/path/to/file) [program] [arguments]\n"); exit(1); } exec_argv_offset = 2; } /* Let children know that duende is running */ if(setenv("DUENDE_IS_RUNNING","1",0) != 0) { printf("FATAL: Unable to set environment variable\n"); exit(1); } /* The parent immediately exits */ if(fork() != 0) exit(0); /* The child becomes a full-fledged daemon */ setpgid(0,0); /* No longer visible in 'ps' without the 'auxw' argument */ /* Write our PID to a file if the user so desires us to */ if(exec_argv_offset == 2) { FILE *fp_pid = fopen(argv[1] + 6,"w"); if(!fp_pid) { syslog(LOG_ALERT,"Fatal writing, to PID file, error\n"); exit(1); } unsigned int local_pid = getpid(); fprintf(fp_pid,"%u",local_pid); fclose(fp_pid); } /* Sysadmins expect HUP to reload, so we set that up */ signal(SIGHUP,handle_hup); signal(SIGTERM,handle_term); signal(SIGINT,handle_term); pid = 0; log_pid = 0; for(;;) { if(pipe(stream1) != 0) { syslog(LOG_ALERT,"Fatal pipe error"); exit(3); } pid = fork(); if(pid == -1) { syslog(LOG_ALERT,"Fatal pid error"); exit(1); } if(pid == 0) { /* Child; this one execs maradns */ close(stream1[0]); /* Dup the standard output */ if(dup2(stream1[1],1) != 1) { syslog(LOG_ALERT,"Fatal dup2 error 1"); exit(4); } /* And the standard error */ if(dup2(stream1[1],2) != 2) { syslog(LOG_ALERT,"Fatal dup2 error 2"); exit(5); } argv[0] = argv[exec_argv_offset]; execvp(argv[exec_argv_offset],argv + exec_argv_offset); /* OK, not found */ printf("duende: %s: Command can't run, terminating\n",argv[exec_argv_offset]); syslog(LOG_ALERT,"Command can't run, terminating\n"); exit(1); } /* Parent */ close(stream1[1]); log_pid = fork(); if(log_pid == 0) { /* Child to syslog all of MaraDNS' output */ argv[0] = "duende-log-helper"; log_helper(argv[exec_argv_offset],stream1[0]); syslog(LOG_ALERT,"log_helper finished, terminating\n"); exit(1); } for(;;) { /* If we got a HUP signal, send it to the child */ if(got_hup_signal == 1) { kill(pid,SIGHUP); got_hup_signal = 0; } /* If we got a TERM or INT signal, send it to the children then exit ourselves */ else if(got_term_signal == 1) { /* XXX: make sure term really stops the children */ kill(pid,SIGTERM); kill(log_pid,SIGTERM); syslog(LOG_ALERT,"got term signal, terminating\n"); exit(0); } sleep(1); if(waitpid(pid,&exit_status,WNOHANG) == pid) { /* If child ended */ handle_child_exited(exit_status,log_pid,pid); close(stream1[0]); break; /* Out of the inner loop; re-start Mara */ } /* If logger terminated */ if(waitpid(log_pid,&exit_status,WNOHANG) == log_pid) { handle_child_exited(exit_status,pid,log_pid); close(stream1[0]); break; /* Out of the inner loop; re-start Mara */ } } } } Thank you, Yarin Licht From bugfood-ml at fatooh.org Mon Dec 27 19:37:57 2010 From: bugfood-ml at fatooh.org (Corey Hickey) Date: Mon, 27 Dec 2010 16:37:57 -0800 Subject: [PATCH] fetchzone.c: fix AAAA records Message-ID: <4D193165.4030709@fatooh.org> Hi, I noticed that fetchzone is concatenating two parts of AAAA records together, without a ':' where it should be. bugfood.fatooh.org. +300 aaaa 2001:470:805b:122cf:30ff:fe10:2dfc: ~ ^^^^^ ...instead of: bugfood.fatooh.org. +300 aaaa 2001:470:805b:1:22cf:30ff:fe10:2dfc: ~ ^^^^^^ This seems to just be a typo in a printf format string. Here's a patch to fix it, assuming I'm not missing something. Thanks, Corey From strenholme.usenet at gmail.com Tue Dec 28 12:06:08 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 28 Dec 2010 10:06:08 -0700 Subject: [PATCH] fetchzone.c: fix AAAA records In-Reply-To: <4D193165.4030709@fatooh.org> References: <4D193165.4030709@fatooh.org> Message-ID: > This seems to just be a typo in a printf format string. Here's a patch > to fix it, assuming I'm not missing something. Corey, It looks like the patch either was not attached or was scrubbed by the listserv software. Could you please try mailing it again, and CC me a copy of the patch (so I can mail it to the list if it is the listserv scrubbing it, and so I can put it on the MaraDNS webpage next week sometime). - Sam From strenholme.usenet at gmail.com Tue Dec 28 12:10:07 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 28 Dec 2010 10:10:07 -0700 Subject: compilation bug fix for bsds In-Reply-To: <1293474622.11827.1412413863@webmail.messagingengine.com> References: <1293474622.11827.1412413863@webmail.messagingengine.com> Message-ID: > Open ./server/udpsuccess.c, and prepend the same 2 lines before all code (but not comments). Unless I can get a proper patch--and by "proper" I mean appropriate #ifdef statements so there is no chance the patch causes problems for people not using BSD--the best way to handle this issue is for me to add an appropriate entry to the MaraDNS FAQ. - Sam From strenholme.usenet at gmail.com Tue Dec 28 12:28:39 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 28 Dec 2010 10:28:39 -0700 Subject: bug fix: defaulting to the /share dir causes the PREFIX variable to be ignored In-Reply-To: <1293477587.25662.1412418015@webmail.messagingengine.com> References: <1293477587.25662.1412418015@webmail.messagingengine.com> Message-ID: > --------- > Below, is my proposed fix of that part > --------- > > # If the directory that MAN1 points to does not exist > if [ ! -d $MAN1 ] ; then > ? ? ? ?# Then try the /share directory instead > ? ? ? ?MAN1="$PREFIX/share/man/man1" > fi > # Do the same with the MAN5 and MAN8 directories > if [ ! -d $MAN5 ] ; then > ? ? ? ?MAN5="$PREFIX/share/man/man5" > fi > if [ ! -d $MAN8 ] ; then > ? ? ? ?MAN8="$PREFIX/share/man/man8" > fi > Replacing the code in place to find where to put the man pages with the above code is a bad idea. Adding the above code, on the other hand, may actually work, but we should still default to /usr/local/share/man/whatever (actually, to make it best, try $PREFIX/man, then try $PREFIX/share/man, then try /usr/local/share/man, then finally try /usr/local/man) As an aside, the only platforms I currently support MaraDNS running on is CentOS 5 and Microsoft Windows. The reason for this is because paths to place files, which quite frankly don't matter except that all the *NIXes should agree on them, are different between Linux and BSD for no particular good reason. The best way to get MaraDNS available for your favorite not-LSB-compliant *NIX is to make a package for your particular distribution. This, of course, has the disadvantage that it requires commitment--said package really needs to be updated whenever I update MaraDNS (which isn't that frequent since MaraDNS is currently frozen) with bug fixes. - Sam From strenholme.usenet at gmail.com Tue Dec 28 12:32:11 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 28 Dec 2010 10:32:11 -0700 Subject: request for added feature be commited: duende pid file In-Reply-To: <1293484962.30412.1412432231@webmail.messagingengine.com> References: <1293484962.30412.1412432231@webmail.messagingengine.com> Message-ID: > To fix this, I've added a PID file feature to the duende. I figured, all good daemons have it, why doesn't yours? :-) > I've successfully compiled and tested the code, and am using it myself, so it's ready to go. Before I even look at your code, I need to know under what license you're releasing this code. I also would like to see this as a patch against the currently existing Duende instead of a rewrite. Take care, - Sam From yarin at warpmail.net Tue Dec 28 13:13:10 2010 From: yarin at warpmail.net (Yarin) Date: Tue, 28 Dec 2010 12:13:10 -0600 Subject: compilation bug fix for bsds In-Reply-To: References: <1293474622.11827.1412413863@webmail.messagingengine.com> Message-ID: <1293559990.6211.1412546375@webmail.messagingengine.com> An FAQ entry would work. Thanks ----- Original message ----- From: "Sam Trenholme" To: list at maradns.org Date: Tue, 28 Dec 2010 10:10:07 -0700 Subject: Re: compilation bug fix for bsds > Open ./server/udpsuccess.c, and prepend the same 2 lines before all code (but not comments). Unless I can get a proper patch--and by "proper" I mean appropriate #ifdef statements so there is no chance the patch causes problems for people not using BSD--the best way to handle this issue is for me to add an appropriate entry to the MaraDNS FAQ. - Sam From yarin at warpmail.net Tue Dec 28 13:35:42 2010 From: yarin at warpmail.net (Yarin) Date: Tue, 28 Dec 2010 12:35:42 -0600 Subject: request for added feature be commited: duende pid file In-Reply-To: References: <1293484962.30412.1412432231@webmail.messagingengine.com> Message-ID: <1293561342.12812.1412546581@webmail.messagingengine.com> Below is a diff patch for ./tools/duende.c as found in your 2.0.01 release of MaraDNS. (labeled as being current on your download page) I'm releasing it under the same standard two-clause BSD license, sorry about not specifying that. 148a149 > int exec_argv_offset = 1; /* Also used to determine PID writing */ 150c151 < printf("Usage: duende [program] [arguments]\n"); --- > printf("Usage: duende (--pid=/path/to/file) [program] [arguments]\n"); 152a154,160 > if(!strncasecmp(argv[1],"--pid=",6)) { > if(argv[2] == NULL) { > printf("Usage: duende (--pid=/path/to/file) [program] [arguments]\n"); > exit(1); > } > exec_argv_offset = 2; > } 166a175,186 > /* Write our PID to a file if the user so desires us to */ > if(exec_argv_offset == 2) { > FILE *fp_pid = fopen(argv[1] + 6,"w"); > if(!fp_pid) { > syslog(LOG_ALERT,"Fatal writing, to PID file, error\n"); > exit(1); > } > unsigned int local_pid = getpid(); > fprintf(fp_pid,"%u",local_pid); > fclose(fp_pid); > } > 196,197c216,217 < argv[0] = argv[1]; < execvp(argv[1],argv + 1); --- > argv[0] = argv[exec_argv_offset]; > execvp(argv[exec_argv_offset],argv + exec_argv_offset); 199c219 < printf("duende: %s: Command can't run, terminating\n",argv[1]); --- > printf("duende: %s: Command can't run, terminating\n",argv[exec_argv_offset]); 209c229 < log_helper(argv[1],stream1[0]); --- > log_helper(argv[exec_argv_offset],stream1[0]); ----- Original message ----- From: "Sam Trenholme" To: list at maradns.org Date: Tue, 28 Dec 2010 10:32:11 -0700 Subject: Re: request for added feature be commited: duende pid file > To fix this, I've added a PID file feature to the duende. I figured, all good daemons have it, why doesn't yours? :-) > I've successfully compiled and tested the code, and am using it myself, so it's ready to go. Before I even look at your code, I need to know under what license you're releasing this code. I also would like to see this as a patch against the currently existing Duende instead of a rewrite. Take care, - Sam From yarin at warpmail.net Tue Dec 28 13:47:52 2010 From: yarin at warpmail.net (Yarin) Date: Tue, 28 Dec 2010 12:47:52 -0600 Subject: bug fix: defaulting to the /share dir causes the PREFIX variable to be ignored In-Reply-To: References: <1293477587.25662.1412418015@webmail.messagingengine.com> Message-ID: <1293562072.16358.1412549277@webmail.messagingengine.com> Alright, here's a diff patch for the ./build/install.location included in your v2.0.01 package of MaraDNS. Released under the two-clause BSD license. 47c47,50 < MAN1="/usr/local/share/man/man1" --- > MAN1="$PREFIX/share/man/man1" > if [ ! -d $MAN1 ] ; then > MAN1="/usr/local/share/man/man1" > fi 51c54,57 < MAN5="/usr/local/share/man/man5" --- > MAN5="$PREFIX/share/man/man5" > if [ ! -d $MAN5 ] ; then > MAN5="/usr/local/share/man/man5" > fi 54c60,63 < MAN8="/usr/local/share/man/man8" --- > MAN8="$PREFIX/share/man/man8" > if [ ! -d $MAN8 ] ; then > MAN8="/usr/local/share/man/man8" > fi ----- Original message ----- From: "Sam Trenholme" To: list at maradns.org Date: Tue, 28 Dec 2010 10:28:39 -0700 Subject: Re: bug fix: defaulting to the /share dir causes the PREFIX variable to be ignored > --------- > Below, is my proposed fix of that part > --------- > > # If the directory that MAN1 points to does not exist > if [ ! -d $MAN1 ] ; then > ? ? ? ?# Then try the /share directory instead > ? ? ? ?MAN1="$PREFIX/share/man/man1" > fi > # Do the same with the MAN5 and MAN8 directories > if [ ! -d $MAN5 ] ; then > ? ? ? ?MAN5="$PREFIX/share/man/man5" > fi > if [ ! -d $MAN8 ] ; then > ? ? ? ?MAN8="$PREFIX/share/man/man8" > fi > Replacing the code in place to find where to put the man pages with the above code is a bad idea. Adding the above code, on the other hand, may actually work, but we should still default to /usr/local/share/man/whatever (actually, to make it best, try $PREFIX/man, then try $PREFIX/share/man, then try /usr/local/share/man, then finally try /usr/local/man) As an aside, the only platforms I currently support MaraDNS running on is CentOS 5 and Microsoft Windows. The reason for this is because paths to place files, which quite frankly don't matter except that all the *NIXes should agree on them, are different between Linux and BSD for no particular good reason. The best way to get MaraDNS available for your favorite not-LSB-compliant *NIX is to make a package for your particular distribution. This, of course, has the disadvantage that it requires commitment--said package really needs to be updated whenever I update MaraDNS (which isn't that frequent since MaraDNS is currently frozen) with bug fixes. - Sam From bugfood-ml at fatooh.org Wed Dec 29 01:52:44 2010 From: bugfood-ml at fatooh.org (Corey Hickey) Date: Tue, 28 Dec 2010 22:52:44 -0800 Subject: [PATCH] fetchzone.c: fix AAAA records In-Reply-To: References: <4D193165.4030709@fatooh.org> Message-ID: <4D1ADABC.9000309@fatooh.org> On 2010-12-28 09:06, Sam Trenholme wrote: >> This seems to just be a typo in a printf format string. Here's a patch >> to fix it, assuming I'm not missing something. > > Corey, > > It looks like the patch either was not attached or was scrubbed by the > listserv software. Could you please try mailing it again, and CC me a > copy of the patch (so I can mail it to the list if it is the listserv > scrubbing it, and so I can put it on the MaraDNS webpage next week > sometime). Must have been scrubbed. I'm attaching 'aaaa.diff' again and pasting it in below. --- tcp/fetchzone.c.orig 2010-08-28 15:37:11.000000000 -0700 +++ tcp/fetchzone.c 2010-12-27 16:26:39.714551535 -0800 @@ -344,7 +344,7 @@ rr.name->string--; rr.name->unit_count++; p = (unsigned short *)get->string; - printf(" +%u aaaa %x:%x:%x:%x%x:%x:%x:%x: ~ \n",rr.ttl, + printf(" +%u aaaa %x:%x:%x:%x:%x:%x:%x:%x: ~ \n",rr.ttl, htons(*(p)), htons(*(p + 1)),htons(*(p + 2)), htons(*(p + 3)), htons(*(p + 4)), htons(*(p + 5)), htons(*(p + 6)), htons(*(p +7))); } Thanks, Corey -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: aaaa.diff URL: From strenholme.usenet at gmail.com Wed Dec 29 03:20:18 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 29 Dec 2010 01:20:18 -0700 Subject: NY Times article on Mexico Message-ID: http://www.nytimes.com/2010/12/29/world/americas/29mexico.html?_r=1&hp Bare-Bones Approach Lets a City Embrace Winter MEXICO CITY ? Homero Aridjis, one of Mexico?s most revered poets, lives in a large home in the hills of this ancient city, with expensive paintings, imported rugs ? and an array of items to help him keep warm, including door-stoppers shaped like snakes, thick wool sweaters, even microwaveable pillows. His home, like nearly every building in this megalopolis of 20 million people, has no central heating. And because concrete is the dominant building material, winter here means an indoor existence with temperatures not far from freezing. ?In the United States, you heat the room or the house,? Mr. Aridjis said. ?In Mexico City, you heat the body.? It is one of the fascinating quirks of Mexico City ? the way Chilangos, as the city?s residents are known ? deal with the weather. Deep in this country?s Aztec roots, there is admiration for submitting to the elements, and it seems to re-emerge every winter with force. It is not simply the lack of central heating that confounds Americans and Europeans in this mountainous city at an altitude of more than 7,000 feet. It is the ubiquity of the cold as well. In expensive restaurants, in grocery stores and museums, in the homes of the poor, middle-class and even the wealthy, a small space heater is often the only thing breathing warm air. Architects say this is partly a matter of economics, but not in the way one might expect. Mexican builders and homeowners have simply grown accustomed to construction without central heating, and with single-pane windows that are especially porous to heat and cold. As a result, insulation materials are profoundly expensive here. Fernando Sandoval, an architect who used to work for Anderson Windows, the American chain, said that given such prices, double-pane glass and central heating could eat up a sixth of the total cost of construction. Few seem to bother. Even the most modern apartments here, with stainless-steel appliances and granite countertops, are often devoid of radiators or thermostats. ?They all say, ?I?d rather have hardwood floors,? ? Mr. Sandoval said. ?Or, ?It?s only going to be cold for a month or a month and a half, I?d rather buy a really nice Italian cashmere sweater.? ? The thing is, winter here lasts more than a month. Temperatures begin dipping into the 40s at night in November, and fall further in December, January and part of February. Rub?n Gallo, a professor at Princeton who edited The Mexico City Reader, a chronicle of the capital, said Mexicans have a hard time admitting this is the case. He likened the contradiction to an essay by Octavio Paz in his book ?Labyrinth of Solitude,? in which the Nobel-prize-winning author described the gap between Mexico?s idealized self-portrait ? as seen in documents like its Constitution ? and the messier, more corrupt routine of daily life. ?We?re always struggling with what Mexico really is,? Mr. Gallo said. ?It?s a slight disconnect between the image and the reality of living in a city that has a mountain climate.? The weather of the region may be getting more extreme as well. For as long as anyone can remember, millions of monarch butterflies have wintered in central Mexico after traveling south, but they were greeted by hail last March. In 3 of the last 10 winters, at least half of the population died as a result of the erratic weather. In this sense, the lack of central heating is a plus. The array of space heaters available at Home Depot here ? short and round, tall and thin, and everything in between ? are sometimes considered better for the environment because they may use less energy than a full home heating system. For many Mexicans, though, the lack of heat has less to do with protecting the environment than with accepting it. Mr. Gallo said that while Americans try to fix the cold, Mexicans rely on fatalism as a means of coping, a sense ?that this is how it?s supposed to be.? Mr. Sandoval offered another take: ?The weather is something you participate in,? he said. ?It?s something that you?re part of.? Mr. Aridjis, the poet, agreed. During a tour of his book-filled, ice-box of a home, he recalled growing up in the state of Michoac?n, near where the butterflies gather. He said he sometimes found ice crystals in the shower, but he also fondly recalled a rhythm of writing by temperature. He would work for several hours until the chill consumed him, then he would step outside to soak in the warming rays of a winter sun. For the Aztecs, the sun gods were among the most revered of the deities, and Mr. Aridjis says it should come as no surprise that access to sunlight dominates any assessment of Mexico City real estate. ?We are a solar people,? he said. ?This is a solar city.? He acknowledged that some found the approach trying. ?I remember when Octavio Paz came from Europe, and he said to me ?this country has the most terrible weather in the world. I hate the cold.? ? But would Mr. Aridjis ever consider changing, adding heat to his home? What if someone offered to replace his windows, and add central heating for free? Mr. Aridjis looked skyward and smiled. ?No,? he said. ?I couldn?t do it.? From strenholme.usenet at gmail.com Wed Dec 29 12:35:30 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 29 Dec 2010 10:35:30 -0700 Subject: compilation bug fix for bsds In-Reply-To: <1293559990.6211.1412546375@webmail.messagingengine.com> References: <1293474622.11827.1412413863@webmail.messagingengine.com> <1293559990.6211.1412546375@webmail.messagingengine.com> Message-ID: Sounds good. If I ever get time, I know that the Duende code has special FreeBSD-only code to log its messages with FreeBSD's default syslog.conf; maybe I could do the same here. As an aside, which particular BSD are you using? FreeBSD? OpenBSD? DragonflyBSD? NetBSD? (Whatever happened to NetBSD being the most portable open-source *NIX clone out there?) I won't be able to do this until next week. - Sam 2010/12/28 Yarin : > An FAQ entry would work. > > Thanks > > ----- Original message ----- > From: "Sam Trenholme" > To: list at maradns.org > Date: Tue, 28 Dec 2010 10:10:07 -0700 > Subject: Re: compilation bug fix for bsds > >> Open ./server/udpsuccess.c, and prepend the same 2 lines before all code (but not comments). > > Unless I can get a proper patch--and by "proper" I mean appropriate > #ifdef statements so there is no chance the patch causes problems for > people not using BSD--the best way to handle this issue is for me to > add an appropriate entry to the MaraDNS FAQ. > > - Sam > > From strenholme.usenet at gmail.com Wed Dec 29 12:41:38 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 29 Dec 2010 10:41:38 -0700 Subject: request for added feature be commited: duende pid file In-Reply-To: <1293561342.12812.1412546581@webmail.messagingengine.com> References: <1293484962.30412.1412432231@webmail.messagingengine.com> <1293561342.12812.1412546581@webmail.messagingengine.com> Message-ID: > Below is a diff patch for ./tools/duende.c as found in your 2.0.01 release of MaraDNS. >(labeled as being current on your download page) Yes, 2.0.01 is the most recent release of MaraDNS. The patch looks good. I presonlly prefer "diff -u" patches (since they provide more context for patch to use in case the code has changed between the time the diff is made and the patch is applied), but this one is perfectly readable and usable. > I'm releasing it under the same standard two-clause BSD license, sorry about > not specifying that. Yep. As an aside, I do have a FAQ entry about adding patches: http://www.maradns.org/faq.html#patch Again, I will make the changes in the next week or so. - Sam From strenholme.usenet at gmail.com Wed Dec 29 12:47:10 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 29 Dec 2010 10:47:10 -0700 Subject: bug fix: defaulting to the /share dir causes the PREFIX variable to be ignored In-Reply-To: <1293562072.16358.1412549277@webmail.messagingengine.com> References: <1293477587.25662.1412418015@webmail.messagingengine.com> <1293562072.16358.1412549277@webmail.messagingengine.com> Message-ID: > Alright, here's a diff patch for the ./build/install.location included > in your v2.0.01 package of MaraDNS. Looks good, but, again, it is better to use "-u" diffs, http://www.maradns.org/faq.html#patch - Sam From yarin at warpmail.net Wed Dec 29 18:04:55 2010 From: yarin at warpmail.net (Yarin) Date: Wed, 29 Dec 2010 17:04:55 -0600 Subject: compilation bug fix for bsds In-Reply-To: References: <1293474622.11827.1412413863@webmail.messagingengine.com><1293559990.6211.1412546375@webmail.messagingengine.com> Message-ID: <1293663895.14493.1412719529@webmail.messagingengine.com> OpenBSD. Yes, I saw that, you have FreeBSD logging to the alert level but everything else to the info level. If you do decide to add that to the FAQ then, I personally don't know about FreeBSDs default logging configuration, but please mention that both OpenBSD and NetBSD write daemon.info logs without problem. :-) Yarin ----- Original message ----- From: "Sam Trenholme" To: list at maradns.org Date: Wed, 29 Dec 2010 10:35:30 -0700 Subject: Re: compilation bug fix for bsds Sounds good. If I ever get time, I know that the Duende code has special FreeBSD-only code to log its messages with FreeBSD's default syslog.conf; maybe I could do the same here. As an aside, which particular BSD are you using? FreeBSD? OpenBSD? DragonflyBSD? NetBSD? (Whatever happened to NetBSD being the most portable open-source *NIX clone out there?) I won't be able to do this until next week. - Sam 2010/12/28 Yarin : > An FAQ entry would work. > > Thanks > > ----- Original message ----- > From: "Sam Trenholme" > To: list at maradns.org > Date: Tue, 28 Dec 2010 10:10:07 -0700 > Subject: Re: compilation bug fix for bsds > >> Open ./server/udpsuccess.c, and prepend the same 2 lines before all code (but not comments). > > Unless I can get a proper patch--and by "proper" I mean appropriate > #ifdef statements so there is no chance the patch causes problems for > people not using BSD--the best way to handle this issue is for me to > add an appropriate entry to the MaraDNS FAQ. > > - Sam > > From yarin at warpmail.net Wed Dec 29 18:08:59 2010 From: yarin at warpmail.net (Yarin) Date: Wed, 29 Dec 2010 17:08:59 -0600 Subject: request for added feature be commited: duende pid file In-Reply-To: References: <1293484962.30412.1412432231@webmail.messagingengine.com><1293561342.12812.1412546581@webmail.messagingengine.com> Message-ID: <1293664139.15454.1412723009@webmail.messagingengine.com> I'll keep that in mind. Looking forward to the updates, Yarin ----- Original message ----- From: "Sam Trenholme" To: list at maradns.org Date: Wed, 29 Dec 2010 10:41:38 -0700 Subject: Re: request for added feature be commited: duende pid file > Below is a diff patch for ./tools/duende.c as found in your 2.0.01 release of MaraDNS. >(labeled as being current on your download page) Yes, 2.0.01 is the most recent release of MaraDNS. The patch looks good. I presonlly prefer "diff -u" patches (since they provide more context for patch to use in case the code has changed between the time the diff is made and the patch is applied), but this one is perfectly readable and usable. > I'm releasing it under the same standard two-clause BSD license, sorry about > not specifying that. Yep. As an aside, I do have a FAQ entry about adding patches: http://www.maradns.org/faq.html#patch Again, I will make the changes in the next week or so. - Sam From yarin at warpmail.net Wed Dec 29 22:20:18 2010 From: yarin at warpmail.net (Yarin) Date: Wed, 29 Dec 2010 21:20:18 -0600 Subject: compilation bug fix for bsds In-Reply-To: <1293663895.14493.1412719529@webmail.messagingengine.com> References: <1293474622.11827.1412413863@webmail.messagingengine.com><1293559990.6211.1412546375@webmail.messagingengine.com> <1293663895.14493.1412719529@webmail.messagingengine.com> Message-ID: <1293679218.13834.1412744531@webmail.messagingengine.com> It looks like you make the man pages and such from the .ej files, so I have a patch for the duende.ej file, adding documentation for the --pid option in the first chunk and mentioning the BSD logging in the second chunk. In case the formatting isn't preserved here, it's also attached. --- ./doc/en/source/duende.ej 2008-09-09 06:40:20.000000000 -0500 +++ ./doc/en/source/duende.ej 2010-12-29 21:07:03.605883241 -0600 @@ -14,14 +14,17 @@ LOG_INFO.

USAGE

-duende child_process [ all subsequent arguments passed on to child ] +duende (--pid=/path/to/file) child_process [ all subsequent arguments passed on to child ]

DETAILS

When duende is invoked, it spawns two processes. In addition to spawning the daemonized child process, duende also spawns a process which reads and logs the standard output of the daemonized process. The -parent process stays alive so as to monitor the daemonized process. +parent process stays alive so as to monitor the daemonized process. If +the optional --pid argument is supplied, duende will write +it's PID to the file specified by the argument. It is an error to supply +the --pid argument without an equal sign and file name.

duende requires a blank directory named /etc/maradns/logger to run. @@ -52,10 +55,11 @@ to duende. All messages created by the child process are sent to syslog() with a priority of LOG_INFO and a "facility" of LOG_DAEMON (daemon.info in /etc/syslog.conf); since daemon.info -messages are not logged by default in FreeBSD, on FreeBSD systems -messages generated by the child process are logged with a priority of -LOG_ALERT and a "facility" of LOG_DAEMON (daemon.alert in /etc/syslog.conf). -Should duende itself encounter an error, it will send +messages are not logged by default in FreeBSD, on and only on FreeBSD +systems, messages generated by the child process are logged with a priority +of LOG_ALERT and a "facility" of LOG_DAEMON (daemon.alert in +/etc/syslog.conf). OpenBSD and NetBSD known to log properly with the +default level. Should duende itself encounter an error, it will send messages to syslog() with a priority of LOG_ALERT.

For example, suppose one invokes duende thusly: released under the two-clause BSD license ----- Original message ----- From: "Yarin" To: list at maradns.org Date: Wed, 29 Dec 2010 17:04:55 -0600 Subject: Re: compilation bug fix for bsds OpenBSD. Yes, I saw that, you have FreeBSD logging to the alert level but everything else to the info level. If you do decide to add that to the FAQ then, I personally don't know about FreeBSDs default logging configuration, but please mention that both OpenBSD and NetBSD write daemon.info logs without problem. :-) Yarin ----- Original message ----- From: "Sam Trenholme" To: list at maradns.org Date: Wed, 29 Dec 2010 10:35:30 -0700 Subject: Re: compilation bug fix for bsds Sounds good. If I ever get time, I know that the Duende code has special FreeBSD-only code to log its messages with FreeBSD's default syslog.conf; maybe I could do the same here. As an aside, which particular BSD are you using? FreeBSD? OpenBSD? DragonflyBSD? NetBSD? (Whatever happened to NetBSD being the most portable open-source *NIX clone out there?) I won't be able to do this until next week. - Sam 2010/12/28 Yarin : > An FAQ entry would work. > > Thanks > > ----- Original message ----- > From: "Sam Trenholme" > To: list at maradns.org > Date: Tue, 28 Dec 2010 10:10:07 -0700 > Subject: Re: compilation bug fix for bsds > >> Open ./server/udpsuccess.c, and prepend the same 2 lines before all code (but not comments). > > Unless I can get a proper patch--and by "proper" I mean appropriate > #ifdef statements so there is no chance the patch causes problems for > people not using BSD--the best way to handle this issue is for me to > add an appropriate entry to the MaraDNS FAQ. > > - Sam > > From strenholme.usenet at gmail.com Thu Dec 30 14:58:33 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 30 Dec 2010 12:58:33 -0700 Subject: compilation bug fix for bsds In-Reply-To: <1293663895.14493.1412719529@webmail.messagingengine.com> References: <1293474622.11827.1412413863@webmail.messagingengine.com> <1293559990.6211.1412546375@webmail.messagingengine.com> <1293663895.14493.1412719529@webmail.messagingengine.com> Message-ID: > OpenBSD. MaraDNS 2.0 (using Deadwood for recursion) is a much better choice for OpenBSD than MaraDN 1.4; the reason is because Deadwood (MaraDNS 2.0's recursive daemon) is non-threaded. MaraDNS 1.4 spawns a thread every time a client asks for a name not in the recursive cache; this kills performance on OpenBSD. The main issue with MaraDNS 2.0 is that it was only released about three months ago so there are still some rough edges in the code which I hope to have time to work on. My most current blog about MaraDNS is here: http://samiam.org/blog/maradns.html Personally, I think the best DNS solution for OpenBSD (if one elects not to use its build of BIND9) is either MaraDNS 2 or your choice of some patched version of DJBdns. Both are excellent software programs; MaraDNS has the advantage that I, the primary author, am still here and am still maintaining the package. [1] Unbound is a good choice if DNSsec is needed. The best list of DNS servers out there is here: http://linuxmafia.com/faq/Network_Other/dns-servers.html This discusses all of the known patched versions of DjbDNS and pretty much any other open-source DNS server. - Sam [1] Yes, it is true that on a personal level I do not like djbdns. My issue with djbdns is that its userbase has had too many rude, annoying fanboys and trolls. Fanboys who tried to cover up [2] djbdns' first security problem when it was found over three years ago. DJB has a responsibility to put a leash on the unprofessional behavior of his more fanatical users; the fact that he has not reflects poorly on his software. This is all a non-issue today; the fact that there are three known security problems in DJB's last release of djbdns and the fact that DJB has stopped maintaining his program nearly a decade ago have taken the wind out of the sails of the arguments to use djbdns. I have a number of rants about djbdns: http://maradns.blogspot.com/search/label/DjbDNS Again, my personal issues aside, djbdns is an excellent program **if you use a patched version like zinq-dnscache**. [2] http://en.wikipedia.org/w/index.php?title=Djbdns&action=historysubmit&diff=159822066&oldid=141354854 From strenholme.usenet at gmail.com Thu Dec 30 15:11:10 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 30 Dec 2010 13:11:10 -0700 Subject: compilation bug fix for bsds In-Reply-To: <1293679218.13834.1412744531@webmail.messagingengine.com> References: <1293474622.11827.1412413863@webmail.messagingengine.com> <1293559990.6211.1412546375@webmail.messagingengine.com> <1293663895.14493.1412719529@webmail.messagingengine.com> <1293679218.13834.1412744531@webmail.messagingengine.com> Message-ID: > It looks like you make the man pages and such from the .ej files, so > I have a patch for the duende.ej file, adding documentation for the > --pid option in the first chunk and mentioning the BSD logging in the > second chunk. Yep. I developed the .ej format back in 2001 because people were telling me I had to use a single document format for all of MaraDNS' documentation. I still use this format today, because it allows me to have a single HTML-like file to make the nroff man pages, HTML document files, as well as plain text files. Thank you for patching the documentation as well as the code. That shows professionalism. - Sam From strenholme.usenet at gmail.com Thu Dec 30 15:24:23 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 30 Dec 2010 13:24:23 -0700 Subject: NY Times article on Mexico In-Reply-To: References: Message-ID: I apologize for sending this to the MaraDNS mailing list. This was a message I intended to send to my wife but, because my wife has a name very similar to "MaraDNS" (which I started years before meeting her), the message got sent to the list instead. - Sam > http://www.nytimes.com/2010/12/29/world/americas/29mexico.html?_r=1&hp From rick at linuxmafia.com Thu Dec 30 16:10:54 2010 From: rick at linuxmafia.com (Rick Moen) Date: Thu, 30 Dec 2010 13:10:54 -0800 Subject: compilation bug fix for bsds In-Reply-To: References: <1293474622.11827.1412413863@webmail.messagingengine.com> <1293559990.6211.1412546375@webmail.messagingengine.com> <1293663895.14493.1412719529@webmail.messagingengine.com> Message-ID: <20101230211054.GN30803@linuxmafia.com> Quoting Sam Trenholme (strenholme.usenet at gmail.com): > The best list of DNS servers out there is here: > http://linuxmafia.com/faq/Network_Other/dns-servers.html > > This discusses all of the known patched versions of DjbDNS and pretty > much any other open-source DNS server. (The referenced page is mine.) Much credit should go to Sam personally for helping provide information that I've used in that page (and also to a number of other people). I'm just a system administrator with a longtime interest in DNS implementations, so I do my best to keep up with the experts. An entry about CurveDNS (forwarder) will soon be added. My page doesn't cover nameservers with no Unix implementations, and I should probably make that fact clearer. From strenholme.usenet at gmail.com Thu Dec 30 16:21:51 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 30 Dec 2010 14:21:51 -0700 Subject: compilation bug fix for bsds In-Reply-To: <20101230211054.GN30803@linuxmafia.com> References: <1293474622.11827.1412413863@webmail.messagingengine.com> <1293559990.6211.1412546375@webmail.messagingengine.com> <1293663895.14493.1412719529@webmail.messagingengine.com> <20101230211054.GN30803@linuxmafia.com> Message-ID: > My page doesn't cover nameservers with no Unix implementations, and I > should probably make that fact clearer. I can't think of an open-source DNS server without a UNIX implementation. - Sam From rick at linuxmafia.com Thu Dec 30 17:17:22 2010 From: rick at linuxmafia.com (Rick Moen) Date: Thu, 30 Dec 2010 14:17:22 -0800 Subject: compilation bug fix for bsds In-Reply-To: References: <1293474622.11827.1412413863@webmail.messagingengine.com> <1293559990.6211.1412546375@webmail.messagingengine.com> <1293663895.14493.1412719529@webmail.messagingengine.com> <20101230211054.GN30803@linuxmafia.com> Message-ID: <20101230221722.GO30803@linuxmafia.com> Quoting Sam Trenholme (strenholme.usenet at gmail.com): > I can't think of an open-source DNS server without a UNIX implementation. As one example, the licence statement for GbDNS states: The GbDns software is entirely written by myself, George Barwood, and is hereby placed in the the public domain. It is free of all restrictions, you may do whatever you wish with it. Without getting into the potential legal issues created by purporting to eradicate the ability of anyone to own a particular property (which is what 'placing in the public domain' claims), otherwise that's close enough to open source for most purposes. Code as written is specific to Microsoft .NET Version 2 or higher. I believe I've come across a few other Windows-specific open source nameservers over the years, but haven't kept track of them. (I'll also mention that my page also documents briefly all known _proprietary_ nameservers for Unix, in a section further down the page.) From jefsey at jefsey.com Thu Dec 30 19:12:47 2010 From: jefsey at jefsey.com (jefsey) Date: Fri, 31 Dec 2010 01:12:47 +0100 Subject: compilation bug fix for bsds In-Reply-To: <20101230211054.GN30803@linuxmafia.com> References: <1293474622.11827.1412413863@webmail.messagingengine.com> <1293559990.6211.1412546375@webmail.messagingengine.com> <1293663895.14493.1412719529@webmail.messagingengine.com> <20101230211054.GN30803@linuxmafia.com> Message-ID: <7.0.1.0.2.20101230233819.0d5390e8@jefsey.com> At 22:10 30/12/2010, Rick Moen wrote: >(The referenced page is mine.) > >Much credit should go to Sam personally for helping provide information >that I've used in that page (and also to a number of other people). I'm >just a system administrator with a longtime interest in DNS >implementations, so I do my best to keep up with the experts. Deep thanks to Rick and Sam for this very usefull list and comments. jfc From yarin at warpmail.net Thu Dec 30 22:24:37 2010 From: yarin at warpmail.net (Yarin) Date: Thu, 30 Dec 2010 21:24:37 -0600 Subject: compilation bug fix for bsds In-Reply-To: References: <1293474622.11827.1412413863@webmail.messagingengine.com><1293559990.6211.1412546375@webmail.messagingengine.com><1293663895.14493.1412719529@webmail.messagingengine.com> Message-ID: <1293765877.25717.1412878831@webmail.messagingengine.com> I'm glad to find out that v1 created on-request threads and glad to hear that v2 doesn't. But actually, I'm already using MaraDNS 2 and the Deadwood resolver you bundled with it; I liked that you separated the server and resolver. Actually, I already decided on MaraDNS because of it's apparent speed, and stronger focus on security, over BIND9, which almost seemed to bloated for the simple things I wanted it for. And early on I decided against djbdns, "personal rants" aside, after finding out that it hasn't really been maintained in a while (besides the various patches), and even in my limited experience, unmaintained = asking for trouble. Unbound looks pretty cool though. Thanks for the info, The comparison list is especially nice. Yarin ----- Original message ----- From: "Sam Trenholme" To: list at maradns.org Date: Thu, 30 Dec 2010 12:58:33 -0700 Subject: Re: compilation bug fix for bsds > OpenBSD. MaraDNS 2.0 (using Deadwood for recursion) is a much better choice for OpenBSD than MaraDN 1.4; the reason is because Deadwood (MaraDNS 2.0's recursive daemon) is non-threaded. MaraDNS 1.4 spawns a thread every time a client asks for a name not in the recursive cache; this kills performance on OpenBSD. The main issue with MaraDNS 2.0 is that it was only released about three months ago so there are still some rough edges in the code which I hope to have time to work on. My most current blog about MaraDNS is here: http://samiam.org/blog/maradns.html Personally, I think the best DNS solution for OpenBSD (if one elects not to use its build of BIND9) is either MaraDNS 2 or your choice of some patched version of DJBdns. Both are excellent software programs; MaraDNS has the advantage that I, the primary author, am still here and am still maintaining the package. [1] Unbound is a good choice if DNSsec is needed. The best list of DNS servers out there is here: http://linuxmafia.com/faq/Network_Other/dns-servers.html This discusses all of the known patched versions of DjbDNS and pretty much any other open-source DNS server. - Sam [1] Yes, it is true that on a personal level I do not like djbdns. My issue with djbdns is that its userbase has had too many rude, annoying fanboys and trolls. Fanboys who tried to cover up [2] djbdns' first security problem when it was found over three years ago. DJB has a responsibility to put a leash on the unprofessional behavior of his more fanatical users; the fact that he has not reflects poorly on his software. This is all a non-issue today; the fact that there are three known security problems in DJB's last release of djbdns and the fact that DJB has stopped maintaining his program nearly a decade ago have taken the wind out of the sails of the arguments to use djbdns. I have a number of rants about djbdns: http://maradns.blogspot.com/search/label/DjbDNS Again, my personal issues aside, djbdns is an excellent program **if you use a patched version like zinq-dnscache**. [2] http://en.wikipedia.org/w/index.php?title=Djbdns&action=historysubmit&diff=159822066&oldid=141354854 From nino80 at gmail.com Fri Dec 31 04:22:59 2010 From: nino80 at gmail.com (n j) Date: Fri, 31 Dec 2010 10:22:59 +0100 Subject: RFC2317-style reverse zone mapping (repost) Message-ID: Seeing that there's a fresh activity on the list and a few other people looking into the code, I decided to repost my post to the list I sent a month ago and see if I get any responses this time. Since it's kind of related to RFC and also related to not rarely used functionality, I believe it might deserve some attention. Unless I got it wrong and MaraDNS actually handles it well :-). Any comment is appreciated. Thanks, -- Nino ---------- Forwarded message ---------- From: n j Date: Wed, Nov 24, 2010 at 12:18 AM Subject: RFC2317-style reverse zone mapping To: list at maradns.org I noticed that maradns doesn't like RFC2317-style reverse zone mappings, i.e. slash character in particular: 0/25.3.2.10.in-addr.arpa ? ?NS ? ?ns.example.com results in: Error: Unexpected character Error is on line 6 in file test.zone context of error: 16/ (closing this file) Error: Problem getting hostname Error is on line 6 in file test.zone context of error: 16/ (closing this file) To be constructive, I found a workaround by modifying csv2_is_alphanum() in Csv2_parse.c to allow slash: /* Match on [0-9a-zA-Z\-\_] */ int csv2_is_alphanum(int32 in) { ? ? ? ?return (csv2_is_alpha(in) || csv2_is_number(in) || ? ? ? ? ? ? ? ? ? ? ? ?in == '-' || in == '_' || in == '/'); } The question is, is this safe to do? Will it maybe cause problems in parsing slash commands (though I haven't noticed any)? Thanks, -- Nino From strenholme.usenet at gmail.com Fri Dec 31 13:22:11 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 31 Dec 2010 11:22:11 -0700 Subject: RFC2317-style reverse zone mapping (repost) In-Reply-To: References: Message-ID: > To be constructive, I found a workaround by modifying > csv2_is_alphanum() in Csv2_parse.c to allow slash: > > /* Match on [0-9a-zA-Z\-\_] */ > int csv2_is_alphanum(int32 in) { > ? ? ? ?return (csv2_is_alpha(in) || csv2_is_number(in) || > ? ? ? ? ? ? ? ? ? ? ? ?in == '-' || in == '_' || in == '/'); > } I wouldn't call a '/' character an "alphanumeric" character, so I think it is better to create another funcion called csv2_is_alphanum_or_slash() Also, please test this change yourself and then post your patch to the mailing list as per the guidelines on posting patches to the mailing list [1]: http://maradns.org/faq.html#patch - Sam [1] For those of you still using UUCP [2], here is the text of that FAQ entry: 15. Is there any process I need to follow to add a patch to MaraDNS? Yes. Here is the procedure for making a proper patch: * Enter the directory that the file is in, for example maradns-1.4.01/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 in question, e.g: vi 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 a patch to the MaraDNS mailing list, along with a statement that you place the contents of the patch under MaraDNS' BSD license. If I find that the patch works well, I will integrate it in to MaraDNS. [2] http://maradns.blogspot.com/2010/05/ok-theres-still-few-people-using-uucp.html From strenholme.usenet at gmail.com Fri Dec 31 14:47:47 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 31 Dec 2010 12:47:47 -0700 Subject: compilation bug fix for bsds In-Reply-To: <1293765877.25717.1412878831@webmail.messagingengine.com> References: <1293474622.11827.1412413863@webmail.messagingengine.com> <1293559990.6211.1412546375@webmail.messagingengine.com> <1293663895.14493.1412719529@webmail.messagingengine.com> <1293765877.25717.1412878831@webmail.messagingengine.com> Message-ID: > But actually, I'm already using MaraDNS 2 and the Deadwood resolver you > bundled with it; I liked that you separated the server and resolver. Separating them removes a lot of annoying corner cases which have caused problems over the years. For example, how do we set the "RA" (recursion available) bit...I have applied countless patches over the years to come up with heuristics which try to give this bit the right value (or, at least, a value which doesn't cause problems with other DNS servers) With MaraDNS 2.0, "RA" is always "0", and, with Deadwood, "RA" is always "1". Simple, clean, and elegant. > early on I decided against djbdns, "personal rants" aside, after finding out > that it hasn't really been maintained in a while (besides the various > patches), and even in my limited experience, > unmaintained = asking for trouble. The argument djbdns advocates make against using an updated DNS server is that djbdns is perfect and doesn't need to be updated. Indeed, in spite of the three known security problems with djbdns, as recently as 2010 we can see people publically declaring djbdns "bug-free": http://tech.slashdot.org/comments.pl?sid=1589160&cid=31547474 It's probably time someone posted to Bugtraq (or file a CVE) that djbdns doesn't catch SIGPIPE, making it trivial for anyone who can connect to a djbdns server via TCP to crash and restart the server; this way it is well known that djbdns has security problems so people update their software instead of deluding themselves that they are secure when they are not. That said, there are maintained branches of djbdns. zinq is a djbdns fork with the major security holes patched, and some other updates (it is possible to compile zinq with "./configure; make", for example): http://freshmeat.net/projects/zinq http://sourceforge.net/projects/zinq/files/ > Unbound looks pretty cool though. Oh, I agree. Unbound is a really great DNS server. It has one "killer feature" which Deadwood does not have: DNSSEC. On the other hand, Deadwood is a 64k binary (on x86) which is a fraction of the size of Unbound; it's a far lighter DNS server. - Sam P.S. Happy new year 2011 everyone!