From toag at izsr.de Mon Mar 2 05:50:49 2009 From: toag at izsr.de (Tim-Ole Alexander Golz) Date: Mon, 2 Mar 2009 11:50:49 +0100 Subject: Mara does not resolve ncs.gov Message-ID: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> Hi, there, I have two Maradns installed as internal DNS with forwarding for external addresses: ipv4_alias = {} ipv4_alias["icann"] = "198.41.0.4,128.9.0.107,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,198.32.64.12,202.12.27.33 " ipv4_alias["osrc"] = "82.198.193.1 199.166.24.1,205.189.73.102,199.166.24.3,207.126.103.16,195.117.6.10,205.189.73.10,204.57.55.100,213.196.2.97 " ipv4_alias["alternic"] = "160.79.129.192,24.6.78.12,160.79.133.70,65.15.8.202,216.162.42.240,195.224.64.190,160.79.133.66,216.162.42.185 " ipv4_alias["opennic"] = "131.161.247.226,209.151.84.102,64.247.218.140,64.247.218.149,209.104.33.250,209.104.63.249,209.151.84.103,199.175.137.211,207.6.128.246,65.243.92.254 " ipv4_alias["localhost"] = "127.0.0.0/8" ipv4_alias["private"] = "192.168.119.0/24" zone_transfer_acl = "127.0.0.1" recursive_acl = "localhost,private" random_seed_file = "/dev/urandom" root_servers = {} root_servers["."] = "icann" But Mara doesnt resolve ncs.gov: vcontrol.itnotez.de:/etc/maradns# host -v www.ncs.gov Query about www.ncs.gov for record types A Trying www.ncs.gov ... Query failed, 0 answers, status: server failure www.ncs.gov A record not found, server failure vcontrol.itnotez.de:/etc/maradns# host -v ncs.gov Query about ncs.gov for record types A Trying ncs.gov ... Query failed, 0 answers, status: server failure ncs.gov A record not found, server failure The log just says: Mar 2 11:47:00 vcontrol maradns.etc_maradns_mararc: Log: Message received, processing Mar 2 11:47:04 vcontrol maradns.etc_maradns_mararc: Query from: 192.168.119.1 Ancs.gov. Mar 2 11:47:04 vcontrol maradns.etc_maradns_mararc: Log: No reply from remote servers Mara is 1.2.12.04-1etch2 on Debian Etch. Is there a solution for this? I wont install MaraDNS from other sources because I dont want to break the integrity of the aptitude- System; otherwise the server is working well. Thanx a lot in advance! Tim-Ole Golz From toag at izsr.de Mon Mar 2 10:26:32 2009 From: toag at izsr.de (Tim-Ole Alexander Golz) Date: Mon, 2 Mar 2009 16:26:32 +0100 Subject: Mara does not resolve ncs.gov In-Reply-To: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> Message-ID: Hi, all there, sorry, that was my fault - a place somewhere very, very deep in my brain I surely *knew* about the problems with version 1.2.12.04 on Debian Etch - but since I am working on Citrix Xen for that special two Maras I forgot it ... so, usually I had all my other Debianservers fairly updated. I now followed the advisory given by Sam at another place, another time: http://woodlane.webconquest.com/pipermail/list/2007-September/000041.html and now Mara works again like a charm. I apologize for the stupid thread :-( greetings Tim-Ole From strenholme.usenet at gmail.com Mon Mar 2 11:55:33 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 2 Mar 2009 10:55:33 -0600 Subject: Mara does not resolve ncs.gov In-Reply-To: References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> Message-ID: <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> > sorry, that was my fault - a place somewhere very, very deep in my brain I > surely *knew* about the problems with version 1.2.12.04 on Debian Etch Yeah, one of my long-standing annoyances is that Debian ships outdated, buggy versions of MaraDNS. There have been no changes between MaraDNS 1.2.12.04 and 1.2.12.09 except for bug fixes, but Debian's retarded policies mean that "apt-get install" gives you an obsolete version of MaraDNS. I appreciate Debian making MaraDNS available on their list of available software, since it gives MaraDNS more exposure, but if you have an issue with an outdated release of MaraDNS, file a bug with Debian's bug reporting system; if they get enough bug reports, they might actually update to 1.2.12.09. Personally, I don't care for Debian; it has the issues all-volunteer organizations have: Inconsistent release schedules, no clearly-defined EOL date (RHEL/CentOS 5 has one: March 31, 2014), and it covers a lot more than RHEL does, but a lot covered isn't very well-covered. For example, Debian, unlike RHEL, comes with MaraDNS, but the version is an outdated version because there are control freaks who aren't sure that subsequent 1.2.12 releases are bugfix-only changes without looking at the patches themselves, but won't take the time to look at the patches. I will start making RHEL/CentOS packages for MaraDNS (again), since RHEL/CentOS 5 is the primary development platform for MaraDNS. Indeed, I might set up a CentOS repository with MaraDNS, fvwm1, xloadimage, xlock, and xdaliclock (these four "outdated" 1990s Linux GUI programs are an integral part of my MaraDNS development environment) Take care, - Sam From rick at linuxmafia.com Mon Mar 2 12:52:16 2009 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 2 Mar 2009 09:52:16 -0800 Subject: Mara does not resolve ncs.gov In-Reply-To: <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> Message-ID: <20090302175215.GN24345@linuxmafia.com> Quoting Sam Trenholme (strenholme.usenet at gmail.com): > I appreciate Debian making MaraDNS available on their list of > available software, since it gives MaraDNS more exposure, but if you > have an issue with an outdated release of MaraDNS, file a bug with > Debian's bug reporting system; if they get enough bug reports, they > might actually update to 1.2.12.09. Actually, Debian-stable ("lenny") provides MaraDNS 1.3.07.09. The current bug report assumes use of an obsolete branch of Debian. From strenholme.usenet at gmail.com Mon Mar 2 13:04:43 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 2 Mar 2009 12:04:43 -0600 Subject: Mara does not resolve ncs.gov In-Reply-To: <20090302175215.GN24345@linuxmafia.com> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> <20090302175215.GN24345@linuxmafia.com> Message-ID: <7bd685720903021004m4718a24dm9be1693b73441520@mail.gmail.com> > Actually, Debian-stable ("lenny") provides MaraDNS 1.3.07.09. > > The current bug report assumes use of an obsolete branch of Debian. Excellent; since Debian Etch is marked "old stable" I think issues like this will come up less. Is there any kind of estimated EOL timeline for Lenny? - Sam (I actually have a Debian 5.0 server VMware image floating around and maradns.org uses Debian) From rick at linuxmafia.com Mon Mar 2 13:55:28 2009 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 2 Mar 2009 10:55:28 -0800 Subject: Mara does not resolve ncs.gov In-Reply-To: <7bd685720903021004m4718a24dm9be1693b73441520@mail.gmail.com> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> <20090302175215.GN24345@linuxmafia.com> <7bd685720903021004m4718a24dm9be1693b73441520@mail.gmail.com> Message-ID: <20090302185527.GO24345@linuxmafia.com> Quoting Sam Trenholme (strenholme.usenet at gmail.com): > Is there any kind of estimated EOL timeline for Lenny? Not that I know of. People who want deterministic release and EOL schedules on a Debian-family distribution generally move to *buntu. Personally, I've always considered running any incarnation of Debian-stable to be inappropriate, as running (by contrast) Debian-testing with optional access to Debian-unstable packages* is a more satisfactory solution, including on production servers. (The usual objection is that there's not a high guarantee of quality on Testing, but this turns out in practice to seldom cause problems, and in general only minor and easily solved ones, unlike with other commonly encountered rolling distribution branches such as Rawhide or Cooker. I.e., the quarantining script that populates Testing does an adequate job of keeping you just far enough from the bleeding edge for comfort. My opinion, yours for a small fee and disclaimer of reverse-engineering rights.) *If ever curious about how to do this, please ask. It's not very involved. From rick at linuxmafia.com Mon Mar 2 14:09:50 2009 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 2 Mar 2009 11:09:50 -0800 Subject: Mara does not resolve ncs.gov In-Reply-To: <20090302185527.GO24345@linuxmafia.com> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> <20090302175215.GN24345@linuxmafia.com> <7bd685720903021004m4718a24dm9be1693b73441520@mail.gmail.com> <20090302185527.GO24345@linuxmafia.com> Message-ID: <20090302190950.GP24345@linuxmafia.com> I wrote: > Quoting Sam Trenholme (strenholme.usenet at gmail.com): > > > Is there any kind of estimated EOL timeline for Lenny? > > Not that I know of. However, the "Lenny" release notes include this reminder: "Typically only two stable releases are supported at any given time." This is in the context of a note that the Debian Project generally continues security support for one year after a branch's release, as long as there isn't a second stable release within that year. Basically, the normal upgrade from one stable branch to the next is so reliable and in fact automatic, given periodic use of apt-get or aptitide, that the Debian Project feels that you'd remain on an obsolete former stable branch only through going out of your way to apply local policies that are generally against your interest. Or, to put it another way, if you've decided that Debian-stable is the desired amount of distance from the bleeding edge, then for heaven's sake, leave your /etc/apt/sources.list entries pegged to "stable": Don't set them to "etch", thereby sabotaging the intended maintenance regime and deliberately no-downtime upgrade path from one stable branch to the next. From strenholme.usenet at gmail.com Mon Mar 2 14:47:17 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 2 Mar 2009 13:47:17 -0600 Subject: Mara does not resolve ncs.gov In-Reply-To: <20090302190950.GP24345@linuxmafia.com> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> <20090302175215.GN24345@linuxmafia.com> <7bd685720903021004m4718a24dm9be1693b73441520@mail.gmail.com> <20090302185527.GO24345@linuxmafia.com> <20090302190950.GP24345@linuxmafia.com> Message-ID: <7bd685720903021147v6247a78eme010382931558f15@mail.gmail.com> >> Quoting Sam Trenholme (strenholme.usenet at gmail.com): >> >> > Is there any kind of estimated EOL timeline for Lenny? >> >> Not that I know of. > > However, the "Lenny" release notes include this reminder: > > "Typically only two stable releases are supported at any given time." Makes sense. OK, in light of this: * Etch is "out of date" and it's not a surprise that its copy of MaraDNS is out of date. * Debian makes it easy to update from one stable release to the next; people using Etch can (in theory) easily update to Lenny. * Debian stable stays stable but Debian doesn't do what RedHat does: They don't support a given release for seven years. They expect people to update more frequently than that. This is somewhat different from the way RHEL/CentOS do things. To wit: * When RedHat releases a release of RHEL, that release is supported, without any major changes, for seven years. Updates that add new features are done for three years, and security fixes are done for four more years. * Usually, this means little changes for those seven years. During the first three years of support, RedHat adds new features, such as drivers for new hardware for the kernel used by the operating system. For the last four years of support, the only updates are security updates and other minor bigfix-only changes. * This isn't hard and fast. For example, in RHEL 4 and RHEL 5, RedHat has updated Firefox from Firefox 1.5.XX to Firefox 3, since Firefox 1.5 is not compatible with modern websites, RHEL's customers wanted an up-to-date web browser, and it was getting harder and harder to backport security fixes for current versions of Firefox to the 1.5 version of Firefox. I might even look at the Debian 5 VMware image I downloaded yesterday; I mainly downloaded it to fill up some space on a backup DVD I burned yesterday, but also to more easily get Debian running in case someone decides to pay me to more fully support Debian (I also downloaded OpenBSD and Ubuntu server, for the same reasons) To bring this back to topic, people reading my blog will see I'm doing a lot of SQA testing with Deadwood, the code that will, one of these years, become the next-generation recursive resolver for MaraDNS. The code is currently a non-recursive DNS cache; I have just today discovered what looks to be some issues with some elements getting cached, an issue I will work on this week. People can look at the MaraDNS blog to see the work I've been doing: http://maradns.blogspot.com http://www.maradns.org/blog - Sam From rick at linuxmafia.com Mon Mar 2 19:36:51 2009 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 2 Mar 2009 16:36:51 -0800 Subject: Mara does not resolve ncs.gov In-Reply-To: <7bd685720903021147v6247a78eme010382931558f15@mail.gmail.com> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> <20090302175215.GN24345@linuxmafia.com> <7bd685720903021004m4718a24dm9be1693b73441520@mail.gmail.com> <20090302185527.GO24345@linuxmafia.com> <20090302190950.GP24345@linuxmafia.com> <7bd685720903021147v6247a78eme010382931558f15@mail.gmail.com> Message-ID: <20090303003651.GS24345@linuxmafia.com> Quoting Sam Trenholme (strenholme.usenet at gmail.com): > * Debian makes it easy to update from one stable release to the next; > people using Etch can (in theory) easily update to Lenny. It's actually a key part of each Debian release manager's job to make sure that the stable -> stable migration _does_ work smoothly. The release of that new "stable" branch isn't supposed to occur until that has been verified to be the case, among other requirements. (Debian sysadmins should be doing resyncs to the package mirrors every week or two, anyway. So, the stable -> stable switchover happens effectively automatically, the only noticeable difference from other package updates being more new packages downloaded than usual. It's not uncommon to hear a sysadmin say he/she was unaware it happened until days or weeks later, in fact. Local customisations get reapplied, daemons stop and then restart with the new versions, and there's essentially zero downtime: It's a live-production upgrade.) This is a different way of thinking (and of maintaining systems) from what applies with most other distros, and very commonly misunderstood. The Debian Project (for whom I don't speak) does very little to clarify the situation: Part of the reason, I'd speculate, is that most of Debian's 1000+ developers simply don't care about the Stable branch in the first place, as they don't run it. From strenholme.usenet at gmail.com Mon Mar 2 20:56:53 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 2 Mar 2009 19:56:53 -0600 Subject: Mara does not resolve ncs.gov In-Reply-To: <20090303003651.GS24345@linuxmafia.com> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> <20090302175215.GN24345@linuxmafia.com> <7bd685720903021004m4718a24dm9be1693b73441520@mail.gmail.com> <20090302185527.GO24345@linuxmafia.com> <20090302190950.GP24345@linuxmafia.com> <7bd685720903021147v6247a78eme010382931558f15@mail.gmail.com> <20090303003651.GS24345@linuxmafia.com> Message-ID: <7bd685720903021756o6de11b33u438a6f445dce686a@mail.gmail.com> > It's actually a key part of each Debian release manager's job to make > sure that the stable -> stable migration _does_ work smoothly. ?The > release of that new "stable" branch isn't supposed to occur until that > has been verified to be the case, among other requirements. Do they even make sure there are conversion scripts that convert all relevant configuration files from one version of a given daemon to the next version? For example, the BIND 4 -> BIND 8 config file conversion was non-trivial; in addition, I think Apache made some pretty significant changes from Apache 1 -> Apache 2. If Debian even automagically converts configuration files, that's *really* slick. - Sam (Yes, working on Deadwood; I did find an error in the code but the problem I saw earlier today was in my test, not in Deadwood. I'll release a new Deadwood snapshot tomorrow, as I have been doing almost every day these last couple of weeks) From rick at linuxmafia.com Tue Mar 3 02:52:55 2009 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 2 Mar 2009 23:52:55 -0800 Subject: Mara does not resolve ncs.gov In-Reply-To: <7bd685720903021756o6de11b33u438a6f445dce686a@mail.gmail.com> References: <29B12F6E-6D29-4CDB-BFE8-316AE56E94C9@izsr.de> <7bd685720903020855j40bcdce4n11fb275c30bc3460@mail.gmail.com> <20090302175215.GN24345@linuxmafia.com> <7bd685720903021004m4718a24dm9be1693b73441520@mail.gmail.com> <20090302185527.GO24345@linuxmafia.com> <20090302190950.GP24345@linuxmafia.com> <7bd685720903021147v6247a78eme010382931558f15@mail.gmail.com> <20090303003651.GS24345@linuxmafia.com> <7bd685720903021756o6de11b33u438a6f445dce686a@mail.gmail.com> Message-ID: <20090303075255.GV24345@linuxmafia.com> Quoting Sam Trenholme (strenholme.usenet at gmail.com): > Do they even make sure there are conversion scripts that convert all > relevant configuration files from one version of a given daemon to the > next version? Mu. ;-> I can't remember all details, but the general technique does _not_ aspire, in any way, to convert raw conffiles from an old version's data format to an incompatible new implentation's format. Instead, when you first install a package with significant configuration variations, you are prompted (through the services of the debconf[1] utility) for your choices on the basis of which the conffiles get written. debconf stores your answers to those questions in .templates files. When it's necessary to reimplement your configuration in a later and perhaps marginally compatible later version of the package, your answers are reapplied. This is of course not a magic bullet: You can easily have situations where you've directly hacked a system-managed conffile; it's debconf's duty in those cases to inform you of this situation and offer various options to deal with the diffs. However, there's been a strong tendency to ameliorate this category of problem by extracting locally-managed details out of software conffiles as include files (or equivalent) separate from the system-managed main conffile, so that smooth upgrades remain possible while usually avoiding what one might call the .rpmnew / .rpmsave problem. And indeed some changes are such sea changes that they're only arguably the same program at all: > For example, the BIND 4 -> BIND 8 config file conversion was > non-trivial; It was also so very long ago (1997) that neither Debian nor any other *ix even dreamed of handling named.boot to named.conf conversion programmatically. ;-> (Joey Hess didn't even have debconf production ready until around 2000.) > in addition, I think Apache made some pretty significant changes from > Apache 1 -> Apache 2. And that's why apache2 is a different package from "apache" (1.3.x). You can keep your old 1.3.x "apache" packages going, as you go from one stable release to another -- and they'll keep getting security updates and fixes. It won't break; it'll keep running. It won't magically turn into Apache2, which is different software. Eventually, at some point, though, it'll cease to be a supported package, and then you won't get further updates. In the case of the "apache" package, that's going to happen with Debian 6.0 "Squeeze"'s release. See: http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#deprecated (All of the above also applies in one way or another to all Debian-family distributions, such as the *buntu group. E.g., they all use debconf, separately named packages for Apache httpd 1.3.x vs. 2.x, and so on.) [1] http://www.fifi.org/cgi-bin/man2html/usr/share/man/man8/debconf.8.gz From yd at troyer.co.at Fri Mar 6 12:45:53 2009 From: yd at troyer.co.at (Yassen Damyanov) Date: Fri, 06 Mar 2009 19:45:53 +0200 Subject: Too long subdomain string? Message-ID: <49B16151.7070008@troyer.co.at> Hello to all on maradns list, (I apologize if this is not the appropriate place to ask the following question.) I am a happy user of maradns for a long time, and never had any issues... until today. I run maradns as an authoritative DNS server for half a dozen of domains and the following subdoman configuration did not work: adivanshoptest.adivan-is.com. IP.ADD.RE.SS If I cut for example the first character, the line divanshoptest.adivan-is.com. IP.ADD.RE.SS DOES work fine. The version reported by the daemon is: # maradns --version This is MaraDNS version 1.2.12.09 Compiled on a OpenBSD system at Thu Mar 13 10:34:19 MDT 2008 The question is: does anybody know if maradns implies a length limit on a segment of the name entry, or if there is any other reason for this behavior? Your advice would be highly appreciated! Thanks in advance, Yassen -- Yassen Damyanov IT Labs, Ltd. From strenholme.usenet at gmail.com Fri Mar 6 13:46:39 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 6 Mar 2009 12:46:39 -0600 Subject: Too long subdomain string? In-Reply-To: <49B16151.7070008@troyer.co.at> References: <49B16151.7070008@troyer.co.at> Message-ID: <7bd685720903061046h2e7433a7qc7644af0f3e76306@mail.gmail.com> > I run maradns as an authoritative > DNS server for half a dozen of domains and the following > subdoman configuration did not work: > > adivanshoptest.adivan-is.com. IP.ADD.RE.SS > > If I cut for example the first character, the line > > divanshoptest.adivan-is.com. IP.ADD.RE.SS > > DOES work fine. > > The version reported by the daemon is: > > # maradns --version > This is MaraDNS version 1.2.12.09 > Compiled on a OpenBSD system at Thu Mar 13 10:34:19 MDT 2008 Works for me. Using maradns-1.2.12.10: $ cat /etc/mararc # Example mararc file. # This only shows a subset of MaraDNS' features needed to be an # authoritative and recursive name server. Look at # detailed/example_full_mararc for an example showing most of # the features that MaraDNS has. # Note that this example mararc file will not actually do anything # without modification. # Look in the doc/en/examples directory for a working example # authoritative nameserver, and a working recursive nameserver. # The various zones we support # When running in authoritative mode, we must initialize the csv2 hash, # or MaraDNS will be unable to load any csv2 zone files csv2 = {} # This is just to show the format of the file # Note the this is commented out. Any line that starts with # a '#' is not read by the parser. Remove the leading '#' to # enable any line that is commented out # The following line (commented out) tells MaraDNS to look at the # file db.example.net to get the zone for example.net #csv2["example.net."] = "db.example.net" # Naturally, we can have multiple zone files csv2["example.com."] = "db.example.com" # The address this DNS server runs on. If you want to bind # to multiple addresses, separate them with a comma like this: # "10.1.2.3, 10.1.2.4, 127.0.0.1" ipv4_bind_addresses = "127.0.0.4" # The directory with all of the zone files chroot_dir = "/etc/maradns" # If you want to enable recursion on the loopback interface, uncomment # the following line: recursive_acl = "127.0.0.1/8" $ askmara Aadivanshoptest.adivan-is.com. 127.0.0.4 # Querying the server with the IP 127.0.0.4 # Question: Aadivanshoptest.adivan-is.com. adivanshoptest.adivan-is.com. +86400 a 10.11.12.13 # NS replies: # AR replies: $ cat /etc/maradns/db.example.com adivanshoptest.adivan-is.com. 10.11.12.13 > The question is: does anybody know if maradns implies a length > limit on a segment of the name entry, or if there is any other > reason for this behavior? Yes. RFC1034/1035 say a DNS label can only be up to 63 characters long. I do not see this behavior. - Sam Note: I do not answer support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From tony.anselmi at gmail.com Tue Mar 10 05:34:54 2009 From: tony.anselmi at gmail.com (antonio anselmi) Date: Tue, 10 Mar 2009 10:34:54 +0100 Subject: cache flush Message-ID: <223dd7b20903100234j5c672bp9d28a376e12e689d@mail.gmail.com> I set my network to use opendns. I setup a very restrictive option so it blocked even all games sites. Yet for many hours (at least), I could still get games. Then, I rebooted the nodes and immediately games were blocked. So I did the reverse and unblocked games and see the same problem: games stayed blocked for many hours (at least) but were immediately unblocked when I rebooted the nodes. There seems to be some long-term caching going on? How can I periodically flush the cache? thanks for your help From strenholme.usenet at gmail.com Tue Mar 10 10:56:54 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 10 Mar 2009 08:56:54 -0600 Subject: cache flush In-Reply-To: <223dd7b20903100234j5c672bp9d28a376e12e689d@mail.gmail.com> References: <223dd7b20903100234j5c672bp9d28a376e12e689d@mail.gmail.com> Message-ID: <7bd685720903100756q39aef87bk3535a8a4c0027c5c@mail.gmail.com> > How can I periodically flush the cache? You can periodically flush the cache by restarting MaraDNS. - Sam Note: I do not answer support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From KenL at GraphixWizard.com Tue Mar 10 12:23:59 2009 From: KenL at GraphixWizard.com (Ken Lyons - Graphix Wizard/Data-Forms) Date: Tue, 10 Mar 2009 11:23:59 -0500 Subject: cache flush In-Reply-To: <2009-069-11-0-1236697291-016230@gwizfl.org> References: <223dd7b20903100234j5c672bp9d28a376e12e689d@mail.gmail.com> <2009-069-11-0-1236697291-016230@gwizfl.org> Message-ID: <2009-069-11-2-1236698892-001474@gwizfl.org> Don't know if this helps or not..but I have mine restart every 15 minutes... (inittab runs respawn mara... cron kills it's pid) that way any updates to the include files get updated, plus clear the cache. --I use automated script to add/edit dns entries Ken Sam Trenholme wrote: >> How can I periodically flush the cache? >> > > You can periodically flush the cache by restarting MaraDNS. > > - Sam > > Note: I do not answer support requests sent by private email without > being compensated for my time. I will discuss rates if you want this > kind of support. Thank you for your understanding. > > > > From a.anselmi at oltrelinux.com Tue Mar 10 12:08:20 2009 From: a.anselmi at oltrelinux.com (Antonio Anselmi) Date: Tue, 10 Mar 2009 17:08:20 +0100 (CET) Subject: cache flush In-Reply-To: <49B6941F.5070607@GraphixWizard.com> References: <223dd7b20903100234j5c672bp9d28a376e12e689d@mail.gmail.com> <2009-069-11-0-1236697291-016230@gwizfl.org> <49B6941F.5070607@GraphixWizard.com> Message-ID: <42905.85.41.146.93.1236701300.squirrel@krisma.oltrelinux.com> thanks for the hints I tink to use cron in order to stop&start mara 'cos in some circumstances I need to stop all running daemons. is 15 mins timer a reasonable value in your real-life experiences? Antono On Tue, March 10, 2009 17:23, Ken Lyons - Graphix Wizard/Data-Forms said: > Don't know if this helps or not..but I have mine restart every 15 > minutes... > (inittab runs respawn mara... cron kills it's pid) > that way any updates to the include files get updated, plus clear the > cache. > --I use automated script to add/edit dns entries > > Ken > > > Sam Trenholme wrote: >>> How can I periodically flush the cache? >>> >> >> You can periodically flush the cache by restarting MaraDNS. >> >> - Sam >> >> Note: I do not answer support requests sent by private email without >> being compensated for my time. I will discuss rates if you want this >> kind of support. Thank you for your understanding. >> >> >> >> > From KenL at GraphixWizard.com Tue Mar 10 14:49:58 2009 From: KenL at GraphixWizard.com (Ken Lyons - Graphix Wizard/Data-Forms) Date: Tue, 10 Mar 2009 13:49:58 -0500 Subject: cache flush In-Reply-To: <2009-069-12-1-1236701559-029967@gwizfl.org> References: <223dd7b20903100234j5c672bp9d28a376e12e689d@mail.gmail.com> <2009-069-11-0-1236697291-016230@gwizfl.org> <49B6941F.5070607@GraphixWizard.com> <2009-069-12-1-1236701559-029967@gwizfl.org> Message-ID: <2009-069-13-5-1236707651-004041@gwizfl.org> Antonio Anselmi wrote: > thanks for the hints > > I tink to use cron in order to stop&start mara 'cos in some > circumstances I need to stop all running daemons. > > is 15 mins timer a reasonable value in your real-life experiences? > I use two DNS servers both multi homed (per RFC). Haven't had any issues. I set my default TTL's for about 1 hour, (10min for dynadns hosts). And since both servers don't recycle in the same minute..one of them will take all the incoming requests while the other restarts. -- all of 10 seconds. I use a shell script wrapper (trigged from inittab ) on mara, with a -e flag. If a certain file /999-dns-down exists, it just sleeps for 60 seconds and exits instead of running mara. That way I can still shutdown DNS without it respawning or racing. If there are many requests for a dns update in the webadmin (over 30 updates), it can trigger a restart instead of waiting up to 14 minutes for the next batch. Ken > Antono > > On Tue, March 10, 2009 17:23, Ken Lyons - Graphix Wizard/Data-Forms said: > >> Don't know if this helps or not..but I have mine restart every 15 >> minutes... >> (inittab runs respawn mara... cron kills it's pid) >> that way any updates to the include files get updated, plus clear the >> cache. >> --I use automated script to add/edit dns entries >> >> Ken >> >> >> Sam Trenholme wrote: >> >>>> How can I periodically flush the cache? >>>> >>>> >>> You can periodically flush the cache by restarting MaraDNS. >>> >>> - Sam >>> >>> Note: I do not answer support requests sent by private email without >>> being compensated for my time. I will discuss rates if you want this >>> kind of support. Thank you for your understanding. >>> >>> >>> >>> >>> > > > > From a.anselmi at oltrelinux.com Tue Mar 10 14:31:48 2009 From: a.anselmi at oltrelinux.com (Antonio Anselmi) Date: Tue, 10 Mar 2009 19:31:48 +0100 (CET) Subject: cache flush In-Reply-To: <49B6B656.2020107@GraphixWizard.com> References: <223dd7b20903100234j5c672bp9d28a376e12e689d@mail.gmail.com> <2009-069-11-0-1236697291-016230@gwizfl.org> <49B6941F.5070607@GraphixWizard.com> <2009-069-12-1-1236701559-029967@gwizfl.org> <49B6B656.2020107@GraphixWizard.com> Message-ID: <50461.85.41.146.93.1236709908.squirrel@krisma.oltrelinux.com> so your mara start/stop script does remove/touch /999-dns-down it seems a good trick! Antonio On Tue, March 10, 2009 19:49, Ken Lyons - Graphix Wizard/Data-Forms said: > > Antonio Anselmi wrote: >> thanks for the hints >> >> I tink to use cron in order to stop&start mara 'cos in some >> circumstances I need to stop all running daemons. >> >> is 15 mins timer a reasonable value in your real-life experiences? >> > I use two DNS servers both multi homed (per RFC). Haven't had any > issues. I set my default TTL's for about 1 hour, > (10min for dynadns hosts). And since both servers don't recycle in > the same minute..one of them will take > all the incoming requests while the other restarts. -- all of 10 > seconds. > > I use a shell script wrapper (trigged from inittab ) on mara, with a > -e flag. > If a certain file /999-dns-down exists, it just sleeps for 60 > seconds and exits instead of running mara. > That way I can still shutdown DNS without it respawning or racing. > > If there are many requests for a dns update in the webadmin (over 30 > updates), > it can trigger a restart instead of waiting up to 14 minutes for the > next batch. > > > Ken > >> Antono >> >> On Tue, March 10, 2009 17:23, Ken Lyons - Graphix Wizard/Data-Forms >> said: >> >>> Don't know if this helps or not..but I have mine restart every 15 >>> minutes... >>> (inittab runs respawn mara... cron kills it's pid) >>> that way any updates to the include files get updated, plus clear >>> the >>> cache. >>> --I use automated script to add/edit dns entries >>> >>> Ken >>> >>> >>> Sam Trenholme wrote: >>> >>>>> How can I periodically flush the cache? >>>>> >>>>> >>>> You can periodically flush the cache by restarting MaraDNS. >>>> >>>> - Sam >>>> >>>> Note: I do not answer support requests sent by private email >>>> without >>>> being compensated for my time. I will discuss rates if you want >>>> this >>>> kind of support. Thank you for your understanding. >>>> >>>> >>>> >>>> >>>> >> >> >> >> > From strenholme.usenet at gmail.com Tue Mar 10 14:46:48 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 10 Mar 2009 12:46:48 -0600 Subject: Deadwood is now stable Message-ID: <7bd685720903101146g5bb7b6d8n8c58e67fb0d42241@mail.gmail.com> I have letting MaraDNS users that after over a year of development (OK, for most of 2008 that development was put on hold for personal reasons), Deadwood is now stable. Deadwood is the codebase that will (in theory) eventually become MaraDNS' next recursive resolver. Right now, the code does not have recursion (it needs to contact a recursive DNS server, such as the DNS server supplied by your ISP, to answer DNS question). However, it does have the following features MaraDNS does not have: * Thread-free code, which is important for some *NIXes that do not thread very well, and for embedded systems. * The ability to write the cache to and from a file * Full optional compile-time IPv6 support (Please thank Jean-Jacques Sarton for supplying this code) * TCP support provided by a separate helper program, also thread and fork-free (but non-caching) * "resurrection" support: The ability to pull an expired record from cache if it is impossible to contact an upstream DNS server. * A clean, easily maintained, and compact codebase. The code has a strong coding style enforced that makes the code more maintainable and manageable. * Correct handling of CNAME records * Small footprint. When compiled with -Os and stripped, the UDP binary is only about 27k in size; the TCP binary is about the same size. MaraDNS still has the following features that Deadwood does not have: * Full recursive support * TTL aging: MaraDNS reduces the TTLs of records so they are not cached as long until the records expire * Resource record rotation, which works as a crude load balancer Deadwood is available on the MaraDNS download page at http://www.maradns.org/download.html and also at http://www.maradns.org/deadwood Any comments of this program can be sent to the list. I hope people find this program useful. - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. From uwl at mail.com Sun Mar 15 07:21:33 2009 From: uwl at mail.com (a uwl) Date: Sun, 15 Mar 2009 06:21:33 -0500 Subject: maradns-1.2.12.08 can't resolve some names Message-ID: <20090315112133.E544311581F@ws1-7.us4.outblaze.com> Hello All, some days ago I installed the MaraDNS on my FreeBSD box from ports. pkg_info says: root at roo:/usr/local/etc # pkg_info | grep maradns maradns-1.2.12.08_1 DNS server with focus on security and simplicity I have too problems: (1) Sometimes some hosts, for example, www.google.de or cgi.ebay.de or some other hosts can't be resolved. But on second o third attemt the resolution working. As I can see, most (or all?) of these hosts are CNAMEs. (2) One host can't be resolved at all: russland-buecher.ru. I checked out this mailing list archive, but didn't found anything excepting "upgrade to 1.2.12.08" related to Debian. Therefore, I think, I did some configuration error. Sorry if it's a FAQ, but I didn't found a solution for me. Could somebody help me to resolve this issue? Very many thanks in advance! Hier is my config file: root at roo:/usr/local/etc # cat mararc | egrep -v "(^#|^$)" csv2 = {} csv2["dg.home."] = "db.dg.home" ipv4_bind_addresses = "127.0.0.1,192.168.188.3" chroot_dir = "/usr/local/etc/maradns" maradns_uid = 53 maradns_gid = 53 maxprocs = 96 no_fingerprint = 0 default_rrany_set = 3 max_chain = 8 max_ar_chain = 1 max_total = 20 verbose_level = 1 ipv4_alias = {} ipv4_alias["icann"] = "198.41.0.4, 192.228.79.201, 192.33.4.12, 128.8.10.90," ipv4_alias["icann"] += "192.203.230.10, 192.5.5.241, 192.112.36.4," ipv4_alias["icann"] += "128.63.2.53, 192.36.148.17, 192.58.128.30," ipv4_alias["icann"] += "193.0.14.129, 198.32.64.12, 202.12.27.33" ipv4_alias["icann2"] = "198.41.0.4,192.228.79.201,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,199.7.83.42,202.12.27.33" ipv4_alias["opennic"] = "157.238.46.24, 209.104.33.250, 209.104.63.249," ipv4_alias["opennic"] += "130.94.168.216, 209.21.75.53, 64.114.34.119," ipv4_alias["opennic"] += "207.6.128.246, 167.216.255.199, 62.208.181.95," ipv4_alias["opennic"] += "216.87.153.98, 216.178.136.116" ipv4_alias["dg"] = "192.168.188.0/25" recursive_acl = "dg" random_seed_file = "/dev/urandom" root_servers = {} root_servers["."] = "icann2" ipv4_alias["azmalink"] = "12.164.194.0/24" ipv4_alias["hiddenonline"] = "65.107.225.0/24" spammers = "azmalink,hiddenonline" timeout_seconds = 10 CY vladi -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com From strenholme.usenet at gmail.com Mon Mar 16 14:19:10 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 16 Mar 2009 12:19:10 -0600 Subject: maradns-1.2.12.08 can't resolve some names In-Reply-To: <20090315112133.E544311581F@ws1-7.us4.outblaze.com> References: <20090315112133.E544311581F@ws1-7.us4.outblaze.com> Message-ID: <7bd685720903161119g55977ab8uaa842990d6d259db@mail.gmail.com> Thank you for bringing this to our attention. I need to give you some of MaraDNS' history and current development so you can understand what is going on. Back in 2001, I decided that MaraDNS really ought to have recursive DNS resolution, since this was a feature a DNS server should have. So, in the fall of 2001 I wrote all of this code and then Franky and myself did an extensive SQA process to stabilize the code and remove memory leaks from it. The code was quickly written, and resolved most name on the internet decently, but some things were tacked on, such as CNAME resolution. The plan was to rewrite the recursive code later on. Well, being an open source project, no one paid me to do this development, so I made other things in life a higher priority, such as going to the gym, graduating with a degree in computational linguistics magna cum luade, going to Mexico, getting a job and a girlfriend down here, etc. Because of this, the rewrite of the recursive resolver didn't start until late 2007. At the end of 2007 I was able to devote more personal time to this resolver, and had a basic non-recursive DNS cache done by the end of 2007. Life happened in 2008, and this recursive code (code named Deadwood) was on worked on a little this year, but I started using this code for my personal internet use and fixed some bugs I found during this use. At the end of 2008, I was in a position in my personal life where I was able to devote time to this code again, and finally released a stable version of this code a week ago. The code is in a lot of ways better than the original MaraDNS resolver, but doesn't have some features MaraDNS' resolver has, notably it need to use another recursive DNS server to process queries. This Deadwood code will eventually become MaraDNS' next-generation resolver. Right now, recursive resolution just isn't a priority for me and I'm working on other features, such as bona fide WIndows support and making the code modular so that one can make the code bigger or smaller depending on what features are needed. Once I start work on Deadwood's recursive code (no, there is no expected timeline) I will ask people to help me beta-test this code so that we don't have issues like this come up. Basically, there was a window in late 2001 where I paid serious attention to "this obscure site doesn't resolve with MaraDNS" bugs; however the code is written in such a way I had to make a lot of those sites WONTFIX. However, if someone is willing to sponsor MaraDNS development, I am willing to change MaraDNS' roadmap to accommodate the needs of my sponsor. For example, XeroBank recently sponsored adding to MaraDNS the ability to give a synthetic IP when it is impossible to resolve a given host name, or when a given host name does not exist. That said, I do feel a certain responsibility to fix critical (read: *critical*) bugs in MaraDNS. As recently as 2006, I made some changes to MaraDNS code to make it possible for MaraDNS to resolve a popular web site (microsoft.com). My experience is that when MaraDNS can't resolve a host at all, it's probably because there's something broken with the domain. > (1) Sometimes some hosts, for example, www.google.de or cgi.ebay.de or > some other hosts can't be resolved. But on second o third attemt the > resolution working. As I can see, most (or all?) of these hosts are > CNAMEs. Well, they resolve, so I don't consider this a serious as an issue where the host name doesn't resolve at all. However, I will look at these two host names later on this week, since they are both "Alexa top 500" sites (google.de is number 12 on the global Alexa list); if I can demonstrate that MaraDNS can resolve these sites (albeit with difficulty) I will close this bug as WONTFIX (but if you want to talk about sponsoring MaraDNS to fix this bug, we can talk about money in private email). > (2) One host can't be resolved at all: russland-buecher.ru. This site's Alexa rank is somewhere around 1,800,000, so I don't consider this critical. Again, if you want to talk about sponsoring MaraDNS to fix this bug, we can talk about money in private email. I will even list you on the MaraDNS sponsors page: http://www.maradns.org/sponsors.html And even on the front page if the sponsorship offer is generous enough. I encourage people to read my blog, where I talk about all the latest updates to MaraDNS and talk about my unpaid support boundaries: http://maradns.blogspot.com/2009/01/maradns-update-last-one-for-while.html http://maradns.blogspot.com/2009/01/maradns-support-boundaries-linux-rocks.html Basically, I generally only consider the inability to resolve a given host name critical (Read: Important enough for me to fix without being compensated for my time) if it's impossible to resolve the name at all, and if the site is an Alexa top 500 site. You may wish to read this thread to see an example of MaraDNS having a hard time with resolving some host names: http://woodlane.webconquest.com/pipermail/list/2009-January/000234.html I hope this helps people better understand the MaraDNS development process and why it is I'm reluctant to fix "this host does not resolve" bugs without being compensated for my time. - Sam From uwl at mail.com Mon Mar 16 17:33:40 2009 From: uwl at mail.com (a uwl) Date: Mon, 16 Mar 2009 16:33:40 -0500 Subject: maradns-1.2.12.08 can't resolve some names Message-ID: <20090316213340.6B2051CE302@ws1-6.us4.outblaze.com> Dear Samvery many thanks! handle_noreply = 0 looks resolving the CNAME problem. I think the CNAME problem is serious enough. The answer from the resolver may be cached in the proxy server. The CNAME stays unresolvable until some user don't do shift-reload and renews the proxy cache.CYVladi -- Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com From pgoggins at cc.edu Mon Mar 23 16:35:34 2009 From: pgoggins at cc.edu (Patrick Goggins) Date: Mon, 23 Mar 2009 15:35:34 -0500 Subject: Writing a catch-all Message-ID: I've just started using maradns and am trying to write a catch-all so all requests resolve to the same ip. In the mararc file I have: csv2["%."] = "test.zone" in the test.zone file I have: % SOA % email@% 1 10 10 10 10 Testing. FQDN4 10.0.0.50 % FQDN4 10.0.0.50 I startup maradns interactively without any issues but when I try to do a dig for any site it does not resolve the 10.0.0.50 address. ~Patrick From strenholme.usenet at gmail.com Mon Mar 23 17:43:06 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 23 Mar 2009 15:43:06 -0600 Subject: Writing a catch-all In-Reply-To: References: Message-ID: <7bd685720903231443n2fc81624va28014fd7e9dabb8@mail.gmail.com> > I've just started using maradns and am trying to write a catch-all so > all requests resolve to the same ip. Well, you can use csv2_default_zonefile to do this, or you can download and use a program far simpler than MaraDNS to do this: /*Placed in the public domain by Sam Trenholme*/ #include #include #define Z struct sockaddr #define Y sizeof(d) int main(int a,char **b){int i;char q[512],p[17 ]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a>1){a= socket(AF_INET,SOCK_DGRAM,0);struct sockaddr_in d;bzero(&d,Y);d.sin_port=htons(53);*((int *)(p+ 12))=inet_addr(b[1]);d.sin_family=AF_INET;bind( a,(Z*)&d,Y);socklen_t f=511;for(;;){i=recvfrom( a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0){q[7]++;q[ 2]|=128;memcpy(q+i,p,16);sendto(a,q,i+16,0,(Z*) &d,Y);}}}return 0;} (note that this will only work on a 32-bit machine) I have a more readable form of this program (that, yes, will work on a 64-bit machine and what not) which you are free to use here: http://www.samiam.org/software/microdns.html - Sam From pgoggins at cc.edu Mon Mar 23 22:34:12 2009 From: pgoggins at cc.edu (Patrick Goggins) Date: Mon, 23 Mar 2009 21:34:12 -0500 Subject: Writing a catch-all In-Reply-To: <7bd685720903231443n2fc81624va28014fd7e9dabb8@mail.gmail.com> References: <7bd685720903231443n2fc81624va28014fd7e9dabb8@mail.gmail.com> Message-ID: Excellent! Just what I was looking for. ~Patrick -----Original Message----- From: list-bounces at maradns.org [mailto:list-bounces at maradns.org] On Behalf Of Sam Trenholme Sent: Monday, March 23, 2009 4:43 PM To: list at maradns.org Subject: Re: Writing a catch-all > I've just started using maradns and am trying to write a catch-all so > all requests resolve to the same ip. Well, you can use csv2_default_zonefile to do this, or you can download and use a program far simpler than MaraDNS to do this: /*Placed in the public domain by Sam Trenholme*/ #include #include #define Z struct sockaddr #define Y sizeof(d) int main(int a,char **b){int i;char q[512],p[17 ]="\xc0\f\0\x01\0\x01\0\0\0\0\0\x04";if(a>1){a= socket(AF_INET,SOCK_DGRAM,0);struct sockaddr_in d;bzero(&d,Y);d.sin_port=htons(53);*((int *)(p+ 12))=inet_addr(b[1]);d.sin_family=AF_INET;bind( a,(Z*)&d,Y);socklen_t f=511;for(;;){i=recvfrom( a,q,255,0,(Z*)&d,&f);if(i>9&&q[2]>=0){q[7]++;q[ 2]|=128;memcpy(q+i,p,16);sendto(a,q,i+16,0,(Z*) &d,Y);}}}return 0;} (note that this will only work on a 32-bit machine) I have a more readable form of this program (that, yes, will work on a 64-bit machine and what not) which you are free to use here: http://www.samiam.org/software/microdns.html - Sam