From duane at e164.org Sun Sep 16 05:34:22 2007 From: duane at e164.org (Duane) Date: Sun, 16 Sep 2007 19:34:22 +1000 Subject: MaraDNS and NAPTR support Message-ID: <46ECF89E.6070807@e164.org> We (e164.org) are evaluating MaraDNS as a suitable authoritative only name server options. I found it curious to read this note in a prior post: "* Support for the NAPTR record type. I added support for a lot of record types between the 1.2.07 and the 1.2.12 branches, but it seems there is real-world demand for at least one of the record types I did not implement. Note that MaraDNS can support this record type indirectly via the RAW record." I'd have to when this was written that no one had attempted to even try to build a raw NAPTR record as it is almost impossible to do so without doing a zone transfer from a server that already supports this option. -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." From strenholme.usenet at gmail.com Tue Sep 18 16:56:04 2007 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 18 Sep 2007 15:56:04 -0500 Subject: MaraDNS and NAPTR support In-Reply-To: <46ECF89E.6070807@e164.org> References: <46ECF89E.6070807@e164.org> Message-ID: <7bd685720709181356ofe37e85q8cb23335c4e50af0@mail.gmail.com> > We (e164.org) are evaluating MaraDNS as a suitable authoritative only > name server options. Isn't e164 a site devoted to E.164, which is what NAPTR is about. Anyway, I knew I should have added this record during the pre-1.3.07 process. I knew there was a RR type one person wanted added to MaraDNS, and I had every intention of adding it, but never got around to it. Then I decided to stabilize with 1.3.07.01, and since that branch is on a strict "no new features" stage of development, I can't add it to that release of MaraDNS. And, oh, if you want NAPTR in 1.2 (or even 1.0, heaven forbid); forget it. Both of those branches are currently in "critical bugfixes only" mode. The good news is that I have already opened up a 1.2.08 branch for new features since Jean-Jacques Sarto is doing so much to improve the IPV6 support in MaraDNS. The first formal 1.2.08 release will be this Friday, and I should be able to get NAPTR in there by then. Let's see: NAPTR. RR code 35; two 16-bit unsigned numbers; three "character-strings" (thingys where you have a single byte indicating the length of the string, followed by the actural string. No worries; MaraDNS has code to do all of this); and finally a . The is a little tricky, since the compression/decompression library will have to deal with them, but this should not be too hard (I haven't added a new RR to the compression core since 2002 or so). The RFC mandates that this RR not be compressed, but I can write the code to decompress it just in case it does get compressed. OK, looks simple enough. Look for it in 1.3.08 this Friday. And, oh, if NAPTR requires the DNS server to do any of the regular expression stuff and what not, forget it. I'm not about to deal with that kind of code. CNAME was enough of a nightmare; thankfully DJB (and myself) were able to kill A6 and DNAME before they caught on. - Sam From duane at e164.org Tue Sep 18 18:57:18 2007 From: duane at e164.org (Duane) Date: Wed, 19 Sep 2007 08:57:18 +1000 Subject: MaraDNS and NAPTR support In-Reply-To: <7bd685720709181356ofe37e85q8cb23335c4e50af0@mail.gmail.com> References: <46ECF89E.6070807@e164.org> <7bd685720709181356ofe37e85q8cb23335c4e50af0@mail.gmail.com> Message-ID: <46F057CE.9080104@e164.org> Sam Trenholme wrote: > Isn't e164 a site devoted to E.164, which is what NAPTR is about. Kind of... We have been operating an end-user enum registry since 2004, which means people can go and list their phone numbers by way of a verification call/PIN etc and then add SIP and other URL information to their enum records. > And, oh, if you want NAPTR in 1.2 > (or even 1.0, heaven forbid); forget it. Both of those branches are > currently in "critical bugfixes only" mode. I'm not really looking for any version to support it, I just re-evaluate our options from time to time to see if there is a better option out there. > And, oh, if NAPTR requires the DNS server to do any of the regular > expression stuff and what not, forget it. I'm not about to deal with > that kind of code. CNAME was enough of a nightmare; thankfully DJB > (and myself) were able to kill A6 and DNAME before they caught on. No, NAPTR records are decoded by the remote end, there is a lot of extensions to it (such as time of day stuff), but we only support basic information. eg. ;; QUESTION SECTION: ;5.5.3.8.5.5.5.0.0.8.1.e164.org. IN NAPTR ;; ANSWER SECTION: 5.5.3.8.5.5.5.0.0.8.1.e164.org. 600 IN NAPTR 200 10 "u" "E2U+SIP" "!^\\+1800(.*)$!sip:1800\\1 at tf.voipmich.com!" . 5.5.3.8.5.5.5.0.0.8.1.e164.org. 600 IN NAPTR 200 10 "u" "E2U+SIP" "!^\\+1800(.*)$!sip:1641641800\\1 at sip.tollfreegateway.com!" . At this stage you'd have a hard time killing NAPTR records, while no registry supports all numbers in the world, there is a lot of routing information being stored in DNS. One last thing, at the moment we use rsync over SSL for zone transfers etc, because as far as we know there is no option in any DNS server to do secure IXFRs or AXFRs. Any thoughts on this? -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." From babal at via.ecp.fr Thu Sep 20 08:39:12 2007 From: babal at via.ecp.fr (Boris Dores) Date: Thu, 20 Sep 2007 14:39:12 +0200 Subject: resolving debian.ens-cachan.fr Message-ID: <20070920123912.GB2711@via.ecp.fr> Hi everyone, It would seem that maradns cannot resolve debian.ens-cachan.fr anymore (nor any other *.ens-cachan.fr actually). I'm using maradns 1.2.12.04 (stock debian package on etch) as a recursive resolver. The first issued "host debian.ens-cachan.fr" returns: debian.ens-cachan.fr is an alias for webb.ens-cachan.fr. webb.ens-cachan.fr has address 138.231.176.11 Host webb.ens-cachan.fr not found: 2(SERVFAIL) Host webb.ens-cachan.fr not found: 2(SERVFAIL) [1] 11140 exit 1 host debian.ens-cachan.fr And after a few minutes: Host debian.ens-cachan.fr not found: 2(SERVFAIL) [1] 11504 exit 1 host debian.ens-cachan.fr Whereas using a bind server on another machine returns: debian.ens-cachan.fr is an alias for webb.ens-cachan.fr. webb.ens-cachan.fr has address 138.231.176.11 It would seem that maradns gets the correct result as well as a servfail, and caches the servfail for future requests. Indeed, using "host -t NS ens-cachan.fr" wich returns: ens-cachan.fr name server ariane.ens-cachan.fr. ens-cachan.fr name server ns2.nic.fr. ens-cachan.fr name server dufy.aquarel.fr. ens-cachan.fr name server rubis.cri.ens-cachan.fr. "askmara -v Adebian.ens-cachan.fr. 138.231.176.4" (ariane.ens-cachan.fr) returns: Querying the server with the IP 138.231.176.4 Server reply: Query id: 45688 Query type: 1 Opcode: 0 Authoritative: 1 Truncated: 0 Recurs desired: 1 Recurs available: 0 Z data: 0 Result code: 0 Num Questions: 1 Num Answers: 2 Number NS records: 4 Number additional records: 5 Question name: Adebian.ens-cachan.fr. Question type: 1 Question class: 1 AN replies: Record name: Cdebian.ens-cachan.fr. Record type: 5 Record class: 1 Record TTL: 86400 Record length: 20 Data: Cwebb.ens-cachan.fr. Record name: Awebb.ens-cachan.fr. Record type: 1 Record class: 1 Record TTL: 86400 Record length: 4 IP: 138.231.176.11 NS replies: [not shown] AR replies: [not shown] but "askmara -v Adebian.ens-cachan.fr. 192.93.0.4" (ns2.nic.fr) returns: Querying the server with the IP 192.93.0.4 Server reply: Query id: 45688 Query type: 1 Opcode: 0 Authoritative: 0 Truncated: 0 Recurs desired: 1 Recurs available: 0 Z data: 0 Result code: 0 Num Questions: 1 Num Answers: 0 Number NS records: 4 Number additional records: 5 Question name: Adebian.ens-cachan.fr. Question type: 1 Question class: 1 AN replies: NS replies: [not shown] AR replies: [not shown] 192.93.0.4 is obviously misconfigured, but it's not authoritative so that shouldn't be a problem, right ? Attached is the syslog corresponding to the first query with "verbose_level = 4" and "verbose_query = 1". Thanks for any help on this ! -- Boris Dor?s -------------- next part -------------- Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Query from: 10.1.3.11 Adebian.ens-cachan.fr. Sep 20 14:00:25 epi maradns.etc_maradns_recursive: 1190289625:1:debian.ens-cachan.fr. Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\001 in DNS cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \006debian\012ens-cachan\002fr\000\000\001 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\005 in DNS cache (CNAME lookup) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \006debian\012ens-cachan\002fr\000\000\005 not found in cache (CNAME) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: initializing thread Sep 20 14:00:25 epi maradns.etc_maradns_recursive: About to launch thread... Sep 20 14:00:25 epi maradns.etc_maradns_recursive: In thread; ready to begin recursion; Threads in use: 1 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\001 in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \006debian\012ens-cachan\002fr\000\000\001 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \000\000\374 found at 0x807da18 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Making cpoint copy of \000\000\374 at 0x807da18 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 198.41.0.4 for \006debian\012ens-cachan\002fr\000\000\001 with bailiwick \000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809dde8 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c1e8 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c290 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c3e0 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c418 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c450 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c488 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c4c0 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c4f8 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c530 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c588 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c5f0 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c648 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c6b0 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c710 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c768 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c7d0 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \002fr\000\000\374 to cache at 0x809c828 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\001 in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \006debian\012ens-cachan\002fr\000\000\001 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \002fr\000\000\374 found at 0x809dde8 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Making cpoint copy of \002fr\000\000\374 at 0x809dde8 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 193.51.208.14 for \006debian\012ens-cachan\002fr\000\000\001 with bailiwick \002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e0d8 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e540 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e5c8 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e5f0 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e618 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e690 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e740 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e790 (js) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: That's an append Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\001 in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \006debian\012ens-cachan\002fr\000\000\001 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \012ens-cachan\002fr\000\000\374 found at 0x809e0d8 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Making cpoint copy of \012ens-cachan\002fr\000\000\374 at 0x809e0d8 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 81.255.96.225 for \006debian\012ens-cachan\002fr\000\000\001 with bailiwick \012ens-cachan\002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Log: Message received, processing Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Query from: 10.1.3.1 P37.5.127.82.in-addr.arpa. Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding \012ens-cachan\002fr\000\000\374 to cache at 0x809e718 (jsip) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 138.231.110.2 for \006debian\012ens-cachan\002fr\000\000\001 with bailiwick \012ens-cachan\002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Adding RR/psudo-NXDOMAIN \006debian\012ens-cachan\002fr\000\000\005 to cache at 0x809e670 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Sucessfully added \006debian\012ens-cachan\002fr\000\000\005 to cache at 0x809e670 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\001 in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \004webb\012ens-cachan\002fr\000\000\001 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \012ens-cachan\002fr\000\000\374 found at 0x809e718 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Making cpoint copy of \012ens-cachan\002fr\000\000\374 at 0x809e718 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 192.93.0.4 for \004webb\012ens-cachan\002fr\000\000\001 with bailiwick \012ens-cachan\002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 192.93.0.4 for \004webb\012ens-cachan\002fr\000\000\001 with bailiwick \012ens-cachan\002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \006debian\012ens-cachan\002fr\000\000\001 in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \006debian\012ens-cachan\002fr\000\000\001 found in cache (CNAME RR) at 0x809e670 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Ready to terminate thread; threads in use 1 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Log: Message received, processing Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Query from: 10.1.3.11 Uwebb.ens-cachan.fr. Sep 20 14:00:25 epi maradns.etc_maradns_recursive: 1190289625:28:webb.ens-cachan.fr. Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\034 in DNS cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \004webb\012ens-cachan\002fr\000\000\034 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\005 in DNS cache (CNAME lookup) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \004webb\012ens-cachan\002fr\000\000\005 not found in cache (CNAME) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: initializing thread Sep 20 14:00:25 epi maradns.etc_maradns_recursive: About to launch thread... Sep 20 14:00:25 epi maradns.etc_maradns_recursive: In thread; ready to begin recursion; Threads in use: 1 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\034 in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \004webb\012ens-cachan\002fr\000\000\034 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \012ens-cachan\002fr\000\000\374 found at 0x809e718 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Making cpoint copy of \012ens-cachan\002fr\000\000\374 at 0x809e718 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 192.93.0.4 for \004webb\012ens-cachan\002fr\000\000\034 with bailiwick \012ens-cachan\002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 192.93.0.4 for \004webb\012ens-cachan\002fr\000\000\034 with bailiwick \012ens-cachan\002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Log: No reply from remote servers Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Ready to terminate thread; threads in use 1 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Log: Message received, processing Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Query from: 10.1.3.11 @webb.ens-cachan.fr. Sep 20 14:00:25 epi maradns.etc_maradns_recursive: 1190289625:15:webb.ens-cachan.fr. Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\017 in DNS cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \004webb\012ens-cachan\002fr\000\000\017 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\005 in DNS cache (CNAME lookup) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \004webb\012ens-cachan\002fr\000\000\005 not found in cache (CNAME) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: initializing thread Sep 20 14:00:25 epi maradns.etc_maradns_recursive: About to launch thread... Sep 20 14:00:25 epi maradns.etc_maradns_recursive: In thread; ready to begin recursion; Threads in use: 1 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\017 in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \004webb\012ens-cachan\002fr\000\000\017 not found in cache Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \004webb\012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Looking for \012ens-cachan\002fr\000\000\374 in cache (NS referral) Sep 20 14:00:25 epi maradns.etc_maradns_recursive: \012ens-cachan\002fr\000\000\374 found at 0x809e718 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Making cpoint copy of \012ens-cachan\002fr\000\000\374 at 0x809e718 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 192.93.0.4 for \004webb\012ens-cachan\002fr\000\000\017 with bailiwick \012ens-cachan\002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Querying DNS server with ip 192.93.0.4 for \004webb\012ens-cachan\002fr\000\000\017 with bailiwick \012ens-cachan\002fr\000\000\374 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Log: No reply from remote servers Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Ready to terminate thread; threads in use 1 Sep 20 14:00:25 epi maradns.etc_maradns_recursive: Log: Message received, processing From strenholme.usenet at gmail.com Thu Sep 20 14:20:42 2007 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 20 Sep 2007 13:20:42 -0500 Subject: MaraDNS and NAPTR support In-Reply-To: <46F057CE.9080104@e164.org> References: <46ECF89E.6070807@e164.org> <7bd685720709181356ofe37e85q8cb23335c4e50af0@mail.gmail.com> <46F057CE.9080104@e164.org> Message-ID: <7bd685720709201120o1f2bc554lcaf88b0395e25657@mail.gmail.com> > I'm not really looking for any version to support it, I just re-evaluate > our options from time to time to see if there is a better option out there. Well, I have added untested code to the "HEAD" branch of MaraDNS to add NAPTR support. This code has not been tested and can very well be (currently) 100% broken. See the MaraDNS blog for details on getting this version of MaraDNS. > One last thing, at the moment we use rsync over SSL for zone transfers > etc, because as far as we know there is no option in any DNS server to > do secure IXFRs or AXFRs. Any thoughts on this? Yes. Use rsync over ssh. :) Seriously, right now I my plan is to rewrite the recursive code to work better on systems which don't like having a zillion threads: A project I call the "deadwood" project. We can talk about me adding features once that code is underway. Or, you can send me patches and I will integrate them in the "HEAD" branch of MaraDNS. This is what Mr. Sarto is doing; as a consequence MaraDNS is getting better ipv6 support. - Sam From strenholme.usenet at gmail.com Thu Sep 20 14:23:21 2007 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 20 Sep 2007 13:23:21 -0500 Subject: resolving debian.ens-cachan.fr In-Reply-To: <20070920123912.GB2711@via.ecp.fr> References: <20070920123912.GB2711@via.ecp.fr> Message-ID: <7bd685720709201123v5b31e597n7bda611af099c62d@mail.gmail.com> > I'm using maradns 1.2.12.04 (stock debian package on etch) as a > recursive resolver. OK, stop right there. Upgrade MaraDNS now. The only 1.2 version for MaraDNS that I support is MaraDNS 1.2.12.08. Debian has a somewhat silly policy that, once a package is declared "stable", they will basically not update it unless there is a Bugtraq security advisory for the package in question. This policy is a good policy for programs made by pimply-faced 16-year-olds who don't know how to manage a release cycle nor a bugfix-only branch, but doesn't make sense for MaraDNS. As I write this, the Debian's "stable" version of MaraDNS is 1.2.12.04, which is about a year behind in terms of bugfixes. I, annoyingly enough, get bug reports from Debian users telling me about bugs I have already fixed in the 1.2 branch of MaraDNS. Now, to be fair to Debian, their policies do allow me to backport bugfixes to the 1.2.12.04 release of MaraDNS, and the patches do get reviewed by somone else, which minimizes bugfixes introducing new bugs (Yes, I have done that), but there are not enough volunteers to review all of the bugfixes I have made since 1.2.12.04. So, Debian users get stuck with an old, buggy version of MaraDNS. The policy would work if there were enough volunteers to actually review all of my post-1.2.12.04 bugfixes, but the people who created the policy did not take in to account the logistics of volunteer work. - Sam From duane at e164.org Thu Sep 20 14:27:44 2007 From: duane at e164.org (Duane) Date: Fri, 21 Sep 2007 04:27:44 +1000 Subject: MaraDNS and NAPTR support In-Reply-To: <7bd685720709201120o1f2bc554lcaf88b0395e25657@mail.gmail.com> References: <46ECF89E.6070807@e164.org> <7bd685720709181356ofe37e85q8cb23335c4e50af0@mail.gmail.com> <46F057CE.9080104@e164.org> <7bd685720709201120o1f2bc554lcaf88b0395e25657@mail.gmail.com> Message-ID: <46F2BBA0.9060802@e164.org> Sam Trenholme wrote: > Well, I have added untested code to the "HEAD" branch of MaraDNS to > add NAPTR support. This code has not been tested and can very well be > (currently) 100% broken. See the MaraDNS blog for details on getting > this version of MaraDNS. Will try to get and build it and test it as soon as time permit, will give you feed back etc as it comes along. > Yes. Use rsync over ssh. :) I would love to use SSH, but not all servers are under our control so we had to opt for SSL instead :) > Seriously, right now I my plan is to rewrite the recursive code to > work better on systems which don't like having a zillion threads: A > project I call the "deadwood" project. We can talk about me adding > features once that code is underway. Are you talking about limited resource hosting, or embedded devices? > Or, you can send me patches and I will integrate them in the "HEAD" > branch of MaraDNS. This is what Mr. Sarto is doing; as a consequence > MaraDNS is getting better ipv6 support. Would love to if I had the time to do everything on my plate as is ;) -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." From babal at via.ecp.fr Fri Sep 21 18:39:40 2007 From: babal at via.ecp.fr (Boris Dores) Date: Sat, 22 Sep 2007 00:39:40 +0200 Subject: resolving debian.ens-cachan.fr In-Reply-To: <20070920123912.GB2711@via.ecp.fr> References: <20070920123912.GB2711@via.ecp.fr> Message-ID: <20070921223940.GC2711@via.ecp.fr> On Thu, Sep 20, 2007 at 02:39:12PM (GMT+0200), Boris Dores wrote: > It would seem that maradns cannot resolve debian.ens-cachan.fr anymore (nor > any other *.ens-cachan.fr actually). Never mind, it would seem that the latest security updates of glibc magically fixed this too. -- Boris Dor?s From jp at mens.de Sat Sep 22 12:36:23 2007 From: jp at mens.de (Jan-Piet Mens) Date: Sat, 22 Sep 2007 18:36:23 +0200 Subject: [MARA] Another advocacy document written Message-ID: <20070922163623.GA29152@home.mens.de> On Sun Aug 06 2006 at 19:27:32 CEST, Sam Trenholme wrote: > BIND9 is the emacs of DNS servers: It includes everything but the > kitchen sink. This results in a full-featured DNS server that has > about 5,000 features you will never use. I love this. May I quote it as being yours ? -JP From jp at mens.de Sat Sep 22 13:03:10 2007 From: jp at mens.de (Jan-Piet Mens) Date: Sat, 22 Sep 2007 19:03:10 +0200 Subject: Book ideas Message-ID: <20070922170310.GC29706@home.mens.de> I have started working on a book focused primarily on authoritative DNS servers (PowerDNS, MaraDNS, MyDNS) as well as BIND with the SDB back-end and DLZ BIND. The book shall *not* be a "this server is better than that one" but rather an insight into the individual programs, their features, strengths, and perhaps also their weaknesses. I intend to also focus on LDAP and SQL back-ends (where applicable) and concentrate mainly on authoritative servers, only slightly touching on recursive name servers. I've contacted the maintainers of the programs asking whether they know of any books which discuss these programs, and some of them have answered my query. :-) You could help to turn this project into something useful by giving me pointers on which topics (for the individual name server software) you would consider most useful to have included in a book. I'm also open to any ideas you might have or perhaps even wishes for topics. Thank you. -JP -- Jan-Piet Mens http://fupps.com From strenholme.usenet at gmail.com Sat Sep 22 21:29:10 2007 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sun, 23 Sep 2007 01:29:10 +0000 Subject: resolving debian.ens-cachan.fr In-Reply-To: <20070921223940.GC2711@via.ecp.fr> References: <20070920123912.GB2711@via.ecp.fr> <20070921223940.GC2711@via.ecp.fr> Message-ID: <7bd685720709221829o7475a848j3a1110452e03eae5@mail.gmail.com> > Never mind, it would seem that the latest security updates of glibc > magically fixed this too. OK, I apologize for being so rude last Thursday. I was a little overwhelmed and ended up acting a little short. Here is my survival guide for Debian users: * No, I do not support the version of MaraDNS 1.2.12.04 that Debian stable comes with. MaraDNS 1.2 has been, since 1.2.12.04, a "bugfix only" branch, and no new features have been added to this version of MaraDNS. * It is very easy to update the buggy MaraDNS 1.2.12.04 that the Debian package comes with with an updated MaraDNS. * First, download MaraDNS 1.2.12.08 from the MaraDNS download page (http://www.maradns.org/download.html) or from the Sourceforge page (http://sourceforge.net/projects/maradns). * Next, unpack the MaraDNS tarball. For example, if you downloaded the file "maradns-1.2.12.08.tar.bz2", type in this command: tar xvjf maradns-1.2.12.08.tar.bz2 * Enter the maradns-1.2.12.08 directory * Compile MaraDNS 1.2.12.08 with the following commands: ./configure; make * If the above fails, you may need to install the "gcc" and "libc6-dev" packages before being able to compile programs: sudo apt-get install gcc sudo apt-get install libc6-dev * Once MaraDNS is compiled, make sure to stop the MaraDNS daemon: /etc/init.d/maradns stop * Now, replace the outdated MaraDNS program that comes with Debian. From the maradns-1.2.12.08 directory, type in the following command: sudo cp server/maradns /usr/sbin/ * Restart the MaraDNS daemon: /etc/init.d/maradns start At this point, your MaraDNS daemon is now the fully supported version 1.2.12.08 of MaraDNS. If you continue to have the bug or concern after upgrading to 1.2.12.08, please let us know so we can begin to resolve the issue. - Sam From duane at e164.org Sat Sep 22 23:16:52 2007 From: duane at e164.org (Duane) Date: Sun, 23 Sep 2007 13:16:52 +1000 Subject: resolving debian.ens-cachan.fr In-Reply-To: <7bd685720709221829o7475a848j3a1110452e03eae5@mail.gmail.com> References: <20070920123912.GB2711@via.ecp.fr> <20070921223940.GC2711@via.ecp.fr> <7bd685720709221829o7475a848j3a1110452e03eae5@mail.gmail.com> Message-ID: <46F5DAA4.5020306@e164.org> Sam Trenholme wrote: >> Never mind, it would seem that the latest security updates of glibc >> magically fixed this too. > > OK, I apologize for being so rude last Thursday. I was a little > overwhelmed and ended up acting a little short. > > Here is my survival guide for Debian users: Another option might be to copy the debian directory from debian/ubuntu packages and then all anyone has to do is: apt-get install devscripts build-essential fakeroot wget http://www.maradns.org/download/1.2/1.2.12.08/maradns-1.2.12.08.tar.bz2 tar xzvf maradns-1.2.12.08.tar.bz2 cd maradns-1.2.12.08 debuild -us -uc dpkg -i ../maradns-1.2.12.08-1_i386.deb (package name will vary based on arch etc) and that's it, or if you wanted to be super nice you could run a mini deb archive to host/link to the source and you can just apt-get source maradns ;) -- Best regards, Duane http://www.freeauth.org - Enterprise Two Factor Authentication http://www.nodedb.com - Think globally, network locally http://www.sydneywireless.com - Telecommunications Freedom http://e164.org - Because e164.arpa is a tax on VoIP "In the long run the pessimist may be proved right, but the optimist has a better time on the trip." From babal at via.ecp.fr Sun Sep 23 10:41:01 2007 From: babal at via.ecp.fr (Boris Dores) Date: Sun, 23 Sep 2007 16:41:01 +0200 Subject: resolving debian.ens-cachan.fr In-Reply-To: <7bd685720709221829o7475a848j3a1110452e03eae5@mail.gmail.com> References: <20070920123912.GB2711@via.ecp.fr> <20070921223940.GC2711@via.ecp.fr> <7bd685720709221829o7475a848j3a1110452e03eae5@mail.gmail.com> Message-ID: <20070923144100.GD2711@via.ecp.fr> On Sun, Sep 23, 2007 at 01:29:10AM (GMT+0000), Sam Trenholme wrote: > > Never mind, it would seem that the latest security updates of glibc > > magically fixed this too. > > OK, I apologize for being so rude last Thursday. I was a little > overwhelmed and ended up acting a little short. Don't worry, I understand, that's no problem. And anyway you were right, since upgrading (the glibc, not maradns, but that's not really the point) solved the problem. The only minor excuse I had to not have kept my server up to date was that the domain which couldn't be resolved was specifically the debian mirror I use to get packages :( > Here is my survival guide for Debian users: > > * No, I do not support the version of MaraDNS 1.2.12.04 that > Debian stable comes with. MaraDNS 1.2 has been, since 1.2.12.04, a > "bugfix only" branch, and no new features have been added to this > version of MaraDNS. That's a perfectly understandable and reasonable choice. > * It is very easy to update the buggy MaraDNS 1.2.12.04 that the > Debian package comes with with an updated MaraDNS. This, on the other hand, may not be that obvious. I guess it may not be that easy for every one (ok maradns may not be a good example, it's really simple...), and more importantly, I don't think it's a good practice for users to recompile applications by hand instead of using packages whenever it's possible : it's standard, it's faster (of course), cleaner (the most important from my point of view), can be uninstalled, and it's more reliable both for their systems (no dependancy problems) and for developers who then know exactly what users have installed. The good news is that's why backports.org was invented :) I'm willing to provide a backport of maradns for debian etch (unless of course Kai Hendry is willing to do it himself), just like I did last year for sarge, but I had absolutely no time over the last 9 months to do it. I hope I will next week or so. That way, you can keep supporting only 1.2.12.08 (once again, I have nothing against it, it's obviousiously a good choice to save your time), and users can keep installing packages only, while being told to upgrade since it requires really no work and no mess. -- Boris Dor?s From kelp at plek.org Mon Sep 24 20:33:45 2007 From: kelp at plek.org (Travis Cole) Date: Mon, 24 Sep 2007 17:33:45 -0700 Subject: MaraDNS Large Sites? Message-ID: I'm considering deploying MaraDNS for a site that would see around 300 DNS requests per second. The total number of records is small. They are just served many times. I know this isn't huge volume, but it's also not insignificant. We're currently using Bind 9 and I'd like to switch, but I haven't found any info about similar sized production use. I'd appreciate any info. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://woodlane.webconquest.com/pipermail/list/attachments/20070924/6b76387b/attachment.htm