From alex at digriz.org.uk Mon Jan 5 08:22:20 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Mon, 5 Jan 2009 13:22:20 +0000 Subject: lame servers Message-ID: <20090105132220.GA26015@woodchuck> Hi, The postmaster at work pestered me, the hostmaster, why some DNS lookups were failing (some 1500 a day) that were preventing people from sending mail to particular domains. Digging around on a particular offender (MX lookup for wjh.harvard.edu) I found that there is a lame server entry which causes MaraDNS to respond with a SERVFAIL to the user. Now I understand the real fix is to get medieval on the hostmaster's out there with borked zone files however could someone explain what dangers I have added (cache poisoning?) with the attached patch which seems to work around the issue? Cheers Alex -- Alexander Clouter .sigmonster says: marriage, n.: Convertible bonds. From alex at digriz.org.uk Mon Jan 5 09:19:22 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Mon, 5 Jan 2009 14:19:22 +0000 Subject: lame servers In-Reply-To: <20090105132220.GA26015@woodchuck> References: <20090105132220.GA26015@woodchuck> Message-ID: <20090105141922.GB3869@woodchuck> Hi, * Alexander Clouter [2009-01-05 13:22:20+0000]: > > The postmaster at work pestered me, the hostmaster, why > some DNS lookups were failing (some 1500 a day) that were > preventing people from sending mail to particular domains. > > Digging around on a particular offender (MX lookup for > wjh.harvard.edu) I found that there is a lame server entry > which causes MaraDNS to respond with a SERVFAIL to the user. > > Now I understand the real fix is to get medieval on the > hostmaster's out there with borked zone files however could > someone explain what dangers I have added (cache poisoning?) > with the attached patch which seems to work around the issue? > ...and this time with the patch[1] :-/ Cheers Alex [1] http://stuff.digriz.org.uk/maradns-lame-server-fix.diff -- Alexander Clouter .sigmonster says: Overload -- core meltdown sequence initiated. From strenholme.usenet at gmail.com Mon Jan 5 09:43:19 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 5 Jan 2009 08:43:19 -0600 Subject: lame servers In-Reply-To: <20090105141922.GB3869@woodchuck> References: <20090105132220.GA26015@woodchuck> <20090105141922.GB3869@woodchuck> Message-ID: <7bd685720901050643x79e6eaf2x4c07994dab1ced84@mail.gmail.com> >> Digging around on a particular offender (MX lookup for >> wjh.harvard.edu) I found that there is a lame server entry >> which causes MaraDNS to respond with a SERVFAIL to the user. Thank you for the bug report and the fix. Let me spell out the issue so I can come up with some good SOA test cases to reproduce this bug and make sure your patch fixes it/ Let's suppose we have sub.example.com, and the root servers say this for the nameservers for example.com: example.com. NS ns1.example.net. example.com. NS ns2.example.net. ns1.example.net. A 192.168.1.1 ns2.example.net. A 192.168.1.2 When we query 192.168.1.1 or 192.168.1.2 for sub.example.com, we get this: sub.example.com. NS ns1.example.net. sub.example.com. NS ns2.example.net. sub.example.com. NS ns.sub.example.com. ns1.example.net. A 192.168.1.1 ns2.example.net. A 192.168.1.2 ns.sub.example.com. A 192.168.1.3 And ns.sub.example.com (192.168.1.3) gives us the correct answer. Now, your patch looks good, but I think I will have to add some tests so getting this from 192.168.1.1 or 192.168.1.2 for sub.example.com doesn't put us in an infinite loop--did anyone else read the article detailing exactly why some Zunes crashed December 31st? It was caused by an unintentional infinite loop. sub.example.com. NS ns1.example.net. sub.example.com. NS ns2.example.net. ns1.example.net. A 192.168.1.1 ns2.example.net. A 192.168.1.2 - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From sysadmin at mrgnetwork.com.br Wed Jan 14 14:56:00 2009 From: sysadmin at mrgnetwork.com.br (sysadmin) Date: Wed, 14 Jan 2009 17:56:00 -0200 Subject: Avoid Phishing using DNS Message-ID: <200901141756.00167.sysadmin@mrgnetwork.com.br> Hello, I wrote a little howto about avoid phishing uisng MaraDNS: http://www.mrgnetwork.com.br/wiki/doku.php/en/maradns_phishing Hope that could be useful. Regards, Marlon From alex at digriz.org.uk Thu Jan 15 04:42:44 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Thu, 15 Jan 2009 09:42:44 +0000 Subject: Avoid Phishing using DNS References: <200901141756.00167.sysadmin@mrgnetwork.com.br> Message-ID: * sysadmin [Wed, 14 Jan 2009 17:56:00 -0200]: > > I wrote a little howto about avoid phishing uisng MaraDNS: > > http://www.mrgnetwork.com.br/wiki/doku.php/en/maradns_phishing > > Hope that could be useful. > Bah, you beat me to it. I keep meaning to put together my documentation on how I'm using MaraDNS with MalwareDomains[1] to automate building the zone file, making sure it's safe, and adding a few extras. To remove the issue of false positives (and users grumbling), I include TXT fields in the zone file I create for each entry so that the page they get redirected to also lists why it's blocked; also means I can use a DNS query to see quickly why something is blacklisted. The page they get redirected to is an Apache webserver with mod_proxy, if the user accepts the 'risk', a cookie is set between the client and the web server that tells mod_proxy to permit the request to go through without being blocked; on a per session basis. Since deployment I have heard not a single complaint and it is a completely zero maintenance tool. If anyone is interested, I'll put together a webpage with everything you need to put together your own. Cheers Alex [1] http://malwaredomains.com/?p=288 -- Alexander Clouter .sigmonster says: Illiterate? Write today, for free help! From strenholme.usenet at gmail.com Thu Jan 15 18:51:00 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 15 Jan 2009 17:51:00 -0600 Subject: Avoid Phishing using DNS In-Reply-To: <200901141756.00167.sysadmin@mrgnetwork.com.br> References: <200901141756.00167.sysadmin@mrgnetwork.com.br> Message-ID: <7bd685720901151551y2c4586d3t6101d007bbd603e@mail.gmail.com> > I wrote a little howto about avoid phishing uisng MaraDNS: > > http://www.mrgnetwork.com.br/wiki/doku.php/en/maradns_phishing Thank you very much for writing this howto. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. From strenholme.usenet at gmail.com Thu Jan 15 18:58:37 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 15 Jan 2009 17:58:37 -0600 Subject: lame servers In-Reply-To: <20090105132220.GA26015@woodchuck> References: <20090105132220.GA26015@woodchuck> Message-ID: <7bd685720901151558t2992fe75g2b99857435802b3@mail.gmail.com> > Digging around on a particular offender (MX lookup for wjh.harvard.edu) > I found that there is a lame server entry which causes MaraDNS to > respond with a SERVFAIL to the user. OK, I have looked at this issue. Read that as: I have set up a VMware virtual machine to run CentOS 5.2 from the command line so I can do full development and testing of MaraDNS again (that took a couple of days [1]), then spent a few hours today designing a SQA test that recreates this problem in a reproducible form. Here is what I see: MaraDNS initially sends a SERVFAIL when it sees this kind of borked zone. However, if someone sends a DNS packet to MaraDNS again with the same query, MaraDNS will correctly resolve it. If the SERVFAIL packet is causing problems, the workaround is to stop MaraDNS from sending SERVFAIL when there is an issue like this resolving a domain. Add this to one's mararc file: handle_noreply = 0 This is better for server use (where we're willing to wait longer before resolving domains, and where a DNS timeout is not annoying), but probably not good for desktop use (where people don't like wait 90 seconds for a DNS timeout; it's an old *NIX usability issue). I feel this resolves the issue in question; if there is a reason why this workaround is not acceptable, please let me know. I don't like making changes to the recursive code; it works and is a bit difficult to maintain. - Sam From strenholme.usenet at gmail.com Thu Jan 15 19:00:30 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 15 Jan 2009 18:00:30 -0600 Subject: lame servers In-Reply-To: <7bd685720901151558t2992fe75g2b99857435802b3@mail.gmail.com> References: <20090105132220.GA26015@woodchuck> <7bd685720901151558t2992fe75g2b99857435802b3@mail.gmail.com> Message-ID: <7bd685720901151600s2f4c7e0fo29c8b6edfdcc5ac@mail.gmail.com> I forgot the footnote: [1] I will post a VMware HOWTO on my geek blog [2] in the near future [2] http://maradns.blogspot.com/ [3] [3] OB-alt.sysadmin.recovery reference (an old USENET newsgroup where people got carried away with footnotes) From alex at digriz.org.uk Fri Jan 16 04:42:40 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Fri, 16 Jan 2009 09:42:40 +0000 Subject: lame servers References: <20090105132220.GA26015@woodchuck> <7bd685720901151558t2992fe75g2b99857435802b3@mail.gmail.com> Message-ID: Hi, * Sam Trenholme [Thu, 15 Jan 2009 17:58:37 -0600]: > > [snipped] > > Here is what I see: MaraDNS initially sends a SERVFAIL when it sees > this kind of borked zone. However, if someone sends a DNS packet to > MaraDNS again with the same query, MaraDNS will correctly resolve it. > > If the SERVFAIL packet is causing problems, the workaround is to stop > MaraDNS from sending SERVFAIL when there is an issue like this > resolving a domain. Add this to one's mararc file: > > handle_noreply = 0 > > This is better for server use (where we're willing to wait longer > before resolving domains, and where a DNS timeout is not annoying), > but probably not good for desktop use (where people don't like wait 90 > seconds for a DNS timeout; it's an old *NIX usability issue). > > I feel this resolves the issue in question; if there is a reason why > this workaround is not acceptable, please let me know. I don't like > making changes to the recursive code; it works and is a bit difficult > to maintain. > I'm going to have to grumble :) Have a nosey at the depressing Infoblox report (sections titled 'Do delegations match authoritative NS records?' and 'How many zones have a lame server?'): http://dns.measurement-factory.com/surveys/200710.html I think you are going to have to crack into the recursive code :) The behaviour I saw anyway was that MaraDNS was not trying *all* the nameservers before coming back with SERVFAIL, it would cling to the entries delegated by the 'parent zone'[1] and not ask any of the ones further down the line. I hope that's clear. For us it was not the SERVFAIL that caused the problem, we simply got *no* answer at all, no matter how often we asked. wjh.harvard.edu is really completely unreachable for us with my hack :( From strenholme.usenet at gmail.com Fri Jan 16 12:01:40 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 16 Jan 2009 11:01:40 -0600 Subject: lame servers In-Reply-To: References: <20090105132220.GA26015@woodchuck> <7bd685720901151558t2992fe75g2b99857435802b3@mail.gmail.com> Message-ID: <7bd685720901160901pa1737eau85e4f5941e92a44a@mail.gmail.com> > The behaviour I saw anyway was that MaraDNS was not trying *all* the > nameservers before coming back with SERVFAIL, it would cling to the > entries delegated by the 'parent zone'[1] and not ask any of the ones > further down the line. I hope that's clear. OK, can you think of a test case that can reproduce this behavior? I created a test case that basically duplicated the issue with the Harvard servers. The test case I created was as follows: root: example.net. NS ns1.example.net. example.net. NS ns2.example.net. example.net. NS ns3.example.net. example.net. NS ns4.example.net. ns1.example.net. A 127.0.1.2 ns2.example.net. A 127.0.1.3 ns3.example.net. A 127.0.1.4 ns4.example.net. A 127.0.1.5 ns[1-4].example.net: sub.example.net. NS ns1.example.net. sub.example.net. NS ns2.example.net. sub.example.net. NS ns3.example.net. sub.example.net. NS ns4.example.net. sub.example.net. NS ns.sub.example.net. ns1.example.net. A 127.0.1.2 ns2.example.net. A 127.0.1.3 ns3.example.net. A 127.0.1.4 ns4.example.net. A 127.0.1.5 ns.sub.example.net. A 127.0.1.6 ns.sub.example.net: sub.example.net. NS ns1.example.net. sub.example.net. NS ns2.example.net. sub.example.net. NS ns3.example.net. sub.example.net. NS ns4.example.net. sub.example.net. NS ns.sub.example.net. sub.example.net. A 127.0.1.32 www.sub.example.net. A 127.0.1.33 With this particular setup, the first time we try to resolve www.sub.example.net, we get a SERVFAIL; the second time, the hostname correctly resolves. If you want to see the test case for this particular setup, download the 20080115 snapshot of MaraDNS: http://www.maradns.org/download/1.3/snap/2009/ (maradns-Q-20090115.1.tar.bz2) And look in the directory sqa/regressions/borked_zone If you have any questions about how this script works, let me know. I know it works on a CentOS 5.2 system (you can download a CentOS 5.2 vmware image at http://www.thoughtpolice.co.uk/vmware/ ) The deal is this: Saying "some domains on the internet don't resolve correctly" is not a good enough bug report. It's about as useful as the email someone once sent us when I was working email support for Netcom: "We lost the big bunny". [1] What I need is a test case where one can demonstrate that MaraDNS isn't consistently resolving a domain that BIND can resolve. If you give me a domain that MaraDNS consistently can't resolve again, I might get around to making a test case. Did I mention I'm doing all this support without getting paid? [3] So, yeah, it's not a big priority for me. Since money isn't changing hands, I'm going to ask you to do the lion's share of the work to make a reproducible test case demonstrating this bug. I'm not even going to start think about making changes to the recursive code until we have a test case. - Sam [1] Yes, someone once sent us an email with this content. It ended up being a conversation piece; a lot of speculation about why this email was sent to us was done around the water cooler. We finally decided it was some kids who though we were their parents or some such. [2] [2] I understand you did give a good bug report the first time. I made a test case reproducing the bug and saw a perfectly good workaround with my test case. [3] If you think people will create compelling art, music, movies, software, and other digital content for fun and for free, and that you have a God-given right to pirate any and all content from thepiratebay.com, please stop taking those kinds of drugs. From zilli.daniel at gmail.com Fri Jan 16 21:16:57 2009 From: zilli.daniel at gmail.com (Daniel Zilli) Date: Sat, 17 Jan 2009 09:16:57 +0700 Subject: Avoid Phishing using DNS In-Reply-To: <7bd685720901151551y2c4586d3t6101d007bbd603e@mail.gmail.com> References: <200901141756.00167.sysadmin@mrgnetwork.com.br> <7bd685720901151551y2c4586d3t6101d007bbd603e@mail.gmail.com> Message-ID: <1232158617.6593.11.camel@linux-acsj> Hi, Did anyone find performance issue with this implementation ? Because in theory, for a medium network environment this can become a problem. Imagine that malware list growing and dozens/hundreds of user requesting the server at same time.... I didn't do any test, so I would like to know if someone already did. Anyhow, for tiny and small organisation.. this is a great tool for security issue. Best, Daniel > > I wrote a little howto about avoid phishing uisng MaraDNS: > > > > http://www.mrgnetwork.com.br/wiki/doku.php/en/maradns_phishing > > Thank you very much for writing this howto. > > - Sam > > Note: If you send me a MaraDNS-related support question, I reserve the > right to post your support email to the Mara-DNS mailing list so that > the community at large can examine your issue. MaraDNS security > vulnerability reports, however, will be kept confidential. From alex at digriz.org.uk Sat Jan 17 04:30:53 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Sat, 17 Jan 2009 09:30:53 +0000 Subject: Avoid Phishing using DNS References: <200901141756.00167.sysadmin@mrgnetwork.com.br> <7bd685720901151551y2c4586d3t6101d007bbd603e@mail.gmail.com> <1232158617.6593.11.camel@linux-acsj> Message-ID: * Daniel Zilli [Sat, 17 Jan 2009 09:16:57 +0700]: > > Did anyone find performance issue with this implementation ? Because in > theory, for a medium network environment this > can become a problem. Imagine that malware list growing and > dozens/hundreds of user requesting the server at same time.... > > I didn't do any test, so I would like to know if someone already did. > Anyhow, for tiny and small organisation.. this is a great > tool for security issue. > This is the format[1] of our blacklisting system: ---- ac56 at ipserv0:~$ head /etc/maradns/db.blacklist ghust.gabis.co.kr. A 212.219.138.188 ~ *.ghust.gabis.co.kr. A 212.219.138.188 ~ ghust.gabis.co.kr. MX 0 ids.it.soas.ac.uk. ~ *.ghust.gabis.co.kr. MX 0 ids.it.soas.ac.uk. ~ ghust.gabis.co.kr. TXT 'dnshijack : malware : sandbox.bleedingthreats.net : 2008-03' ~ easweuijintungenfunsa.com. A 212.219.138.188 ~ *.easweuijintungenfunsa.com. A 212.219.138.188 ~ easweuijintungenfunsa.com. MX 0 ids.it.soas.ac.uk. ~ *.easweuijintungenfunsa.com. MX 0 ids.it.soas.ac.uk. ~ ac56 at ipserv0:~$ wc /etc/maradns/db.blacklist 105384 491811 4716037 /etc/maradns/db.blacklist ---- With 20k unique domains blacklisted we[1] have not seen any performance issues. The servers are 2xIntel Xeon's 2.80GHz and there are two servers...I have never seen MaraDNS use more then 0.1% of the CPU and the response is always instantaneous. You should bear in mind, it's never the users workstations knocking out the majority of the DNS requests, where I work 95%+ of the requests we make come from our SMTP servers. Cheers [1] I'm thinking about removing the MX entries, but so far it's not given me any complaints [2] a university with 600 staff and 3000 students -- Alexander Clouter .sigmonster says: If God is One, what is bad? -- Charles Manson From alijawad1 at gmail.com Wed Jan 21 19:13:31 2009 From: alijawad1 at gmail.com (Ali Jawad) Date: Thu, 22 Jan 2009 02:13:31 +0200 Subject: Max Number of records per zone ? Message-ID: Dear All I am using db.example.net zone with entries such as www.google.com. 60.60.60.60 *.com. 11.11.11.11 What is the max number of zones I could use in such a zone file ? From strenholme.usenet at gmail.com Thu Jan 22 10:31:38 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 22 Jan 2009 09:31:38 -0600 Subject: Max Number of records per zone ? In-Reply-To: References: Message-ID: <7bd685720901220731m2ccc6871ha371890827b0a857@mail.gmail.com> There is no practical limit to the number of records one can have in a zone. - Sam Note: If you send me a MaraDNS-related support question, I reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be kept confidential. 2009/1/21 Ali Jawad : > Dear All > I am using db.example.net zone with entries such as > > www.google.com. 60.60.60.60 > *.com. 11.11.11.11 > > What is the max number of zones I could use in such a zone file ? > From sysadmin at mrgnetwork.com.br Sun Jan 25 08:10:44 2009 From: sysadmin at mrgnetwork.com.br (sysadmin) Date: Sun, 25 Jan 2009 11:10:44 -0200 Subject: Avoid Phishing using DNS In-Reply-To: References: <200901141756.00167.sysadmin@mrgnetwork.com.br> (sfid-H20090115-080817-+042.84-1@spamfilter.osbf.lua) Message-ID: <200901251110.44863.sysadmin@mrgnetwork.com.br> Hi Alexander, Sorry the late reply, I miss some mails. > Bah, you beat me to it. I keep meaning to put together my documentation > on how I'm using MaraDNS with MalwareDomains[1] to automate building the > zone file, making sure it's safe, and adding a few extras. > Sorry about that :) > To remove the issue of false positives (and users grumbling), I include > TXT fields in the zone file I create for each entry so that the page > they get redirected to also lists why it's blocked; also means I can use > a DNS query to see quickly why something is blacklisted. > > The page they get redirected to is an Apache webserver with mod_proxy, > if the user accepts the 'risk', a cookie is set between the client and > the web server that tells mod_proxy to permit the request to go through > without being blocked; on a per session basis. > > Since deployment I have heard not a single complaint and it is a > completely zero maintenance tool. If anyone is interested, I'll put > together a webpage with everything you need to put together your own. > Sounds great!! I have interested in your setup. Can you share the material ? Regards, Marlon From alex at digriz.org.uk Sun Jan 25 10:53:10 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Sun, 25 Jan 2009 15:53:10 +0000 Subject: Avoid Phishing using DNS References: <200901141756.00167.sysadmin@mrgnetwork.com.br> Message-ID: * Alexander Clouter [Thu, 15 Jan 2009 09:42:44 +0000]: > * sysadmin [Wed, 14 Jan 2009 17:56:00 -0200]: >> >> I wrote a little howto about avoid phishing uisng MaraDNS: >> >> http://www.mrgnetwork.com.br/wiki/doku.php/en/maradns_phishing >> >> Hope that could be useful. >> > > Since deployment I have heard not a single complaint and it is a > completely zero maintenance tool. If anyone is interested, I'll put > together a webpage with everything you need to put together your own. > Due to popular demand... http://www.digriz.org.uk/dns-malware-blacklisting It's something I knocked together this afternoon and probably has inaccuracies throughout. Let me know if you see anything. Cheers -- Alexander Clouter .sigmonster says: You are in the hall of the mountain king. From sysadmin at mrgnetwork.com.br Tue Jan 27 15:15:50 2009 From: sysadmin at mrgnetwork.com.br (sysadmin) Date: Tue, 27 Jan 2009 18:15:50 -0200 Subject: Avoid Phishing using DNS In-Reply-To: References: <200901141756.00167.sysadmin@mrgnetwork.com.br> (sfid-H20090125-140828-+039.50-1@spamfilter.osbf.lua) Message-ID: <200901271815.51115.sysadmin@mrgnetwork.com.br> > http://www.digriz.org.uk/dns-malware-blacklisting > > It's something I knocked together this afternoon and probably has > inaccuracies throughout. Let me know if you see anything. Nice setup! I don't saw anything wrong, but I'm not a right person to correct a english text, because it is not my "default" language ;) Regards, Marlon From sysadmin at mrgnetwork.com.br Tue Jan 27 21:00:02 2009 From: sysadmin at mrgnetwork.com.br (sysadmin) Date: Wed, 28 Jan 2009 00:00:02 -0200 Subject: "redirect" queries Message-ID: <200901280000.02505.sysadmin@mrgnetwork.com.br> Hi, It's possible setup MaraDNS to point to a specific A record instead return a "server fail" ? For example when a user made a typo in browser www.maradnss.com redirect to a webserver that will show a page with a "typo error message". Regards, Marlon From strenholme.usenet at gmail.com Wed Jan 28 01:32:13 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 28 Jan 2009 00:32:13 -0600 Subject: "redirect" queries In-Reply-To: <200901280000.02505.sysadmin@mrgnetwork.com.br> References: <200901280000.02505.sysadmin@mrgnetwork.com.br> Message-ID: <7bd685720901272232o1c7a0fd2id4c88a755ac0d044@mail.gmail.com> No; it's a commonly requested feature. I might even get around to implementing it some day with Deadwood (the code I'm working on now). Money is always a good thing. Hint hint. :) :) :) - Sam Note: If you send me a MaraDNS-related support question via private email, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. 2009/1/27 sysadmin : > Hi, > > It's possible setup MaraDNS to point to a specific A record instead return > a "server fail" ? > > For example when a user made a typo in browser www.maradnss.com redirect to a > webserver that will show a page with a "typo error message". > > > Regards, > > > Marlon > From arrakistor at gmail.com Wed Jan 28 12:16:54 2009 From: arrakistor at gmail.com (Arrakis) Date: Wed, 28 Jan 2009 11:16:54 -0600 Subject: MaraDNS & NX Domains Message-ID: <49809306.8000304@gmail.com> Is there a way to configure MaraDNS to act like BIND does so when a user requests a non-existent domain we can show them a custom error page? Thank you Arrakis From strenholme.usenet at gmail.com Wed Jan 28 13:19:42 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 28 Jan 2009 12:19:42 -0600 Subject: MaraDNS & NX Domains In-Reply-To: <49809306.8000304@gmail.com> References: <49809306.8000304@gmail.com> Message-ID: <7bd685720901281019y1c521e6ex6f7b262ea5cc607d@mail.gmail.com> No; it's a commonly requested feature. I might even get around to implementing it some day with Deadwood (the code I'm working on now). Money is always a good thing. Hint hint. :) :) :) Note also that there is at least one searchable archive of the MaraDNS mailing list online that will give you an answer to common questions like this one: http://marc.info/?l=maradns-list This will save you time. - Sam Note: If you send me a MaraDNS-related support question via private email, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. 2009/1/28 Arrakis : > Is there a way to configure MaraDNS to act like BIND does > so when a user requests a non-existent domain we can show > them a custom error page? > > Thank you > Arrakis > From alex at digriz.org.uk Thu Jan 29 07:22:36 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Thu, 29 Jan 2009 12:22:36 +0000 Subject: MaraDNS & NX Domains References: <49809306.8000304@gmail.com> Message-ID: * Arrakis [Wed, 28 Jan 2009 11:16:54 -0600]: > > Is there a way to configure MaraDNS to act like BIND does > so when a user requests a non-existent domain we can show > them a custom error page? > Please just use an HTTP proxy server, you also get a stack of other advantages from doing so too. Try to avoid using a transparent proxy (it only breaks things and is not scalable at all) but instead use WPAD files dished out via DNS and DHCP. Cheers -- Alexander Clouter .sigmonster says: Q: What is green and lives in the ocean? A: Moby Pickle. From deutschem at gmx.de Thu Jan 29 11:04:14 2009 From: deutschem at gmx.de (Deutschem) Date: Thu, 29 Jan 2009 17:04:14 +0100 Subject: upstream_server do not work Message-ID: <1233245054.7340.9.camel@md-laptop> hi, i want the following: upstream_servers = {} upstream_servers["."] = "x.x.x.1" upstream_servers["com."] = "x.x.x.2" that do not work ! no, i have no root_servers defined and yes, all upstream servers work fine please help thank you. From strenholme.usenet at gmail.com Thu Jan 29 11:45:29 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 29 Jan 2009 10:45:29 -0600 Subject: upstream_server do not work In-Reply-To: <1233245054.7340.9.camel@md-laptop> References: <1233245054.7340.9.camel@md-laptop> Message-ID: <7bd685720901290845o7b799fd2u9efb160288e76ef3@mail.gmail.com> Which version of MaraDNS? This syntax does work in the 1.2 branch of MaraDNS. - Sam Note: If you send me a MaraDNS-related support question, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. 2009/1/29 Deutschem : > hi, > > i want the following: > > upstream_servers = {} > upstream_servers["."] = "x.x.x.1" > upstream_servers["com."] = "x.x.x.2" > > that do not work ! > > no, i have no root_servers defined > and > yes, all upstream servers work fine > > please help > > thank you. > > From strenholme.usenet at gmail.com Thu Jan 29 12:29:45 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 29 Jan 2009 11:29:45 -0600 Subject: MaraDNS & NX Domains In-Reply-To: References: <49809306.8000304@gmail.com> Message-ID: <7bd685720901290929s79111402ve8a607db8d322d63@mail.gmail.com> > Please just use an HTTP proxy server, you also get a stack of other > advantages from doing so too. True. However, XeroBank has very kindly offered to sponsor adding this feature to MaraDNS, so I should start work on it today. This helps for the cases of people who can't handle WPAD files for whatever reason. > Try to avoid using a transparent proxy (it only breaks things and is not > scalable at all) but instead use WPAD files dished out via DNS and DHCP. Seconded. One of the ISPs here in Mexico uses a Squid transparent proxy and it causes headaches and slows the internet to a crawl at times. - Sam From Deutschem at gmx.de Thu Jan 29 12:39:11 2009 From: Deutschem at gmx.de (Deutschem at gmx.de) Date: Thu, 29 Jan 2009 18:39:11 +0100 Subject: upstream_server do not work In-Reply-To: <7bd685720901290845o7b799fd2u9efb160288e76ef3@mail.gmail.com> References: <1233245054.7340.9.camel@md-laptop> <7bd685720901290845o7b799fd2u9efb160288e76ef3@mail.gmail.com> Message-ID: <20090129173911.187300@gmx.net> -------- Original-Nachricht -------- > Datum: Thu, 29 Jan 2009 10:45:29 -0600 > Von: Sam Trenholme > An: Deutschem > CC: list at maradns.org > Betreff: Re: upstream_server do not work > Which version of MaraDNS? This syntax does work in the 1.2 branch of > MaraDNS. > > - Sam > > Note: If you send me a MaraDNS-related support question, I will > probably not answer your question (giving you one of my form replies > instead), and reserve the right to post your support email to the > Mara-DNS mailing list so that the community at large can examine your > issue. MaraDNS security vulnerability reports, however, will be dealt > with and kept confidential. > > 2009/1/29 Deutschem : > > hi, > > > > i want the following: > > > > upstream_servers = {} > > upstream_servers["."] = "x.x.x.1" > > upstream_servers["com."] = "x.x.x.2" > > > > that do not work ! > > > > no, i have no root_servers defined > > and > > yes, all upstream servers work fine > > > > please help > > > > thank you. > > > > -- NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL f?r nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a From Deutschem at gmx.de Thu Jan 29 12:39:30 2009 From: Deutschem at gmx.de (Deutschem at gmx.de) Date: Thu, 29 Jan 2009 18:39:30 +0100 Subject: upstream_server do not work In-Reply-To: <7bd685720901290845o7b799fd2u9efb160288e76ef3@mail.gmail.com> References: <1233245054.7340.9.camel@md-laptop> <7bd685720901290845o7b799fd2u9efb160288e76ef3@mail.gmail.com> Message-ID: <20090129173930.187290@gmx.net> 1.2.12 -------- Original-Nachricht -------- > Datum: Thu, 29 Jan 2009 10:45:29 -0600 > Von: Sam Trenholme > An: Deutschem > CC: list at maradns.org > Betreff: Re: upstream_server do not work > Which version of MaraDNS? This syntax does work in the 1.2 branch of > MaraDNS. > > - Sam > > Note: If you send me a MaraDNS-related support question, I will > probably not answer your question (giving you one of my form replies > instead), and reserve the right to post your support email to the > Mara-DNS mailing list so that the community at large can examine your > issue. MaraDNS security vulnerability reports, however, will be dealt > with and kept confidential. > > 2009/1/29 Deutschem : > > hi, > > > > i want the following: > > > > upstream_servers = {} > > upstream_servers["."] = "x.x.x.1" > > upstream_servers["com."] = "x.x.x.2" > > > > that do not work ! > > > > no, i have no root_servers defined > > and > > yes, all upstream servers work fine > > > > please help > > > > thank you. > > > > From strenholme.usenet at gmail.com Thu Jan 29 13:02:32 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 29 Jan 2009 12:02:32 -0600 Subject: upstream_server do not work In-Reply-To: <20090129173930.187290@gmx.net> References: <1233245054.7340.9.camel@md-laptop> <7bd685720901290845o7b799fd2u9efb160288e76ef3@mail.gmail.com> <20090129173930.187290@gmx.net> Message-ID: <7bd685720901291002u69cf3fc9q507cf9dcef099cdf@mail.gmail.com> > 1.2.12 >> > upstream_servers = {} >> > upstream_servers["."] = "x.x.x.1" >> > upstream_servers["com."] = "x.x.x.2" >> > >> > Doesn't work Use 1.3.07.09; this will fix your problem: http://www.maradns.org/download/1.3/1.3.07.09/maradns-1.3.07.09.tar.bz2 http://sourceforge.net/projects/maradns - Sam Note: If you send me a MaraDNS-related support question, I will probably not answer your question (giving you one of my form replies instead), and reserve the right to post your support email to the Mara-DNS mailing list so that the community at large can examine your issue. MaraDNS security vulnerability reports, however, will be dealt with and kept confidential. From hellfroze at gmail.com Thu Jan 29 13:45:51 2009 From: hellfroze at gmail.com (h3) Date: Thu, 29 Jan 2009 10:45:51 -0800 Subject: zoneserver logging of originating IP Message-ID: <3b1323220901291045l3c2aef52k83da83d35c0d3892@mail.gmail.com> In trying to troubleshoot some issues with secondaries that are not managed by me, it would be helpful to know the IP address axfr requests are coming from, but all I see in the logs (regardless of the verbose_level setting in mararc) is something like this: Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Root directory changed Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Socket opened on TCP port 53 Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Root privileges dropped Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Awaiting data on port 53 Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Message received, processing Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Awaiting data on port 53 Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Message received, processing Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Awaiting data on port 53 Jan 28 16:20:58 kuromi /usr/sbin/zoneserver: Log: Message received, processing How can I get zoneserver to log the IP address of the request? I even spent some time trying to get zoneserver to work with xinetd since there were some cryptic messages that this works but no implementation details were provided and I had no success - any pointers on that front? Thanks, Harry From deutschem at gmx.de Fri Jan 30 05:24:21 2009 From: deutschem at gmx.de (Deutschem) Date: Fri, 30 Jan 2009 11:24:21 +0100 Subject: upstream_server do not work In-Reply-To: <7bd685720901291002u69cf3fc9q507cf9dcef099cdf@mail.gmail.com> References: <1233245054.7340.9.camel@md-laptop> <7bd685720901290845o7b799fd2u9efb160288e76ef3@mail.gmail.com> <20090129173930.187290@gmx.net> <7bd685720901291002u69cf3fc9q507cf9dcef099cdf@mail.gmail.com> Message-ID: <1233311061.7339.0.camel@md-laptop> Yes, the new version do that job. thank you. Am Donnerstag, den 29.01.2009, 12:02 -0600 schrieb Sam Trenholme: > > 1.2.12 > > >> > upstream_servers = {} > >> > upstream_servers["."] = "x.x.x.1" > >> > upstream_servers["com."] = "x.x.x.2" > >> > > >> > Doesn't work > > Use 1.3.07.09; this will fix your problem: > > http://www.maradns.org/download/1.3/1.3.07.09/maradns-1.3.07.09.tar.bz2 > > http://sourceforge.net/projects/maradns > > - Sam > > Note: If you send me a MaraDNS-related support question, I will > probably not answer your question (giving you one of my form replies > instead), and reserve the right to post your support email to the > Mara-DNS mailing list so that the community at large can examine your > issue. MaraDNS security vulnerability reports, however, will be dealt > with and kept confidential.