From strenholme.usenet at gmail.com Tue Nov 1 13:22:58 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 1 Nov 2011 11:22:58 -0600 Subject: [MaraDNS list] Deadwood 3.0.04 released Message-ID: I have released Deadwood 3.0.04 today. This release fixes some bugs and has improved documentation. Please read the update guide and the change log [1] for more information. It can be downloaded here: http://www.maradns.org/deadwood/stable/ I plan to work on MaraDNS/Deadwood without sponsorship again one day in December, before the 15th; if I get some sponsorship, I will work on MaraDNS and Deadwood again sooner. My plans are to release the tcc version of Deadwood for Windows (which includes a tiny compiler) and then to release MaraDNS 1.4.07; after that, I will work on the MaraDNS 2.0.04 release. The amount of time this will take depends on how much sponsorship money I get. - Sam [1] http://maradns.org/deadwood/doc/ From strenholme.usenet at gmail.com Tue Nov 8 15:31:53 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 8 Nov 2011 14:31:53 -0600 Subject: [MaraDNS list] Call for donations Message-ID: Unfortunately, I have not received my usual donation yet this month from my usual sponsor. He has told me that it may be difficult for him to make funds available to donate to the MaraDNS cause; I told him to not donate any more than he can freely afford. Without his donation, MaraDNS presently is only getting income from its ads. This income is very minimal and only covers hosting expenses. I am not interested in making the ads more numerous nor in making the ads more obnoxious in order to increase my income; asking for sponsorship has been far more fruitful. Unlike other open source projects, MaraDNS currently does not have income coming from academic or government sources, nor does it benefit from corporate sponsorship. If I can get sponsorship totaling $100 each month, I will be able to continue maintaining both the 1.4 and 2.0 branch with basic bug fixes, supply critical security fixes for the 1.3 branch, as well as providing basic support on this mailing list. If I can get sponsorship totaling $200 each month, I will also be able to supply critical security fixes for the 1.2 and 1.0 branches of MaraDNS, as well as continuing to work on improving Deadwood's recursive resolution (speeding up resolution speed and ensuring that Deadwood is fully ipv6 ready). If I can get sponsorship totaling $300 each month, I will remove the ads from both maradns.org and samiam.org. As soon as a given level of sponsorship ($100, $200, or $300) is reached for a given month, I will inform the mailing list. Anyone who sponsors MaraDNS will have their name listed on the sponsors page at http://maradns.org/sponsors.html (unless they explicitly tell me that they wish their sponsorship to be anonymous), be congratulated on the mailing list, and will be happy knowing their contribution helps make continued MaraDNS development possible. To sponsor MaraDNS, please send a Paypal donation to abiword_bugs at yahoo.com If you wish me to provide a specialized MaraDNS feature, please let me know what you wish in private email and we can discuss rates. - Sam P.S. If you do not want to see sponsorship requests, please unsubscribe from this mailing list. P.P.S. In the case I do not get any more sponsorship, I would still continue to provide basic bug fixes for MaraDNS 2.0 as well as Deadwood, in addition to providing critical security bug fixes for MaraDNS 1.4 and MaraDNS 1.3 (1.3 will only be supported until December 21, 2012). I, alas, would no longer be able to acknowledge bug reports nor provide any other support on the mailing list, and would only work on MaraDNS/Deadwood once a month. From Bradley at NorthTech.US Wed Nov 9 06:56:06 2011 From: Bradley at NorthTech.US (Bradley D. Thornton) Date: Wed, 09 Nov 2011 03:56:06 -0800 Subject: [MaraDNS list] Split Horizon on the horizon? Message-ID: <4EBA6A56.5070602@NorthTech.US> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hey Sam, Have you any current inklings toward the support of Split Horizon capabilities? I ask because I've come across a few instances where this is desirable. Just wondering, when you get a chance. Kindest regards, - -- Bradley D. Thornton Manager Network Services NorthTech Computer TEL: +1.760.666.2703 (US) TEL: +44.203.318.2755 (UK) http://NorthTech.US -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Find this cert at x-hkp://pool.sks-keyservers.net iQEcBAEBAwAGBQJOumpWAAoJEE1wgkIhr9j3MacH/3VhyGRLFw5YEoqp02Ww/Uk0 SSn48KLEu6TLU153Rp8B+l/oMQYKBDqVwiDtA85GRF0ZAdkyq37CqBDdiOIDTpLm hSJZdqrCi+Wze7hB7j5z9jDNHq/jaImLqfWrFdF5uHA0ZpGFEPNLMB9PC7DK+RUT wtxK+T1EqJj4IX3IykzIDkAYREkIpGIFFfO8VIhikjQDJYt2EFUogdEmrgEwBYPu 2Wm/LWxMCKJCfYKWWZCsC5b+sd0JmAHBzPhb1cng4gsl2WTDf3iPAJ93GIk9eHL9 JIWYl+3lbrrcZoULUgxUv35xSn4pC0QNqrLDI6OEAJutHDcyIS3qxLqr4cIzOyY= =1A1Q -----END PGP SIGNATURE----- From strenholme.usenet at gmail.com Wed Nov 9 12:15:09 2011 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 9 Nov 2011 11:15:09 -0600 Subject: [MaraDNS list] Split Horizon on the horizon? In-Reply-To: <4EBA6A56.5070602@NorthTech.US> References: <4EBA6A56.5070602@NorthTech.US> Message-ID: Show me the money and we'll talk. My time has become too valuable for me to continue making substantial contributions to MaraDNS without being fairly compensated. MaraDNS and Deadwood already nicely meet my own needs, so I no longer have a non-financial motivation to work on MaraDNS anymore. - Sam 2011/11/9 Bradley D. Thornton : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > Hey Sam, > > Have you any current inklings toward the support of Split Horizon > capabilities? > > I ask because I've come across a few instances where this is desirable. > > Just wondering, when you get a chance. > > Kindest regards, > > > - -- > Bradley D. Thornton > Manager Network Services > NorthTech Computer > TEL: +1.760.666.2703 ?(US) > TEL: +44.203.318.2755 (UK) > http://NorthTech.US > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Find this cert at x-hkp://pool.sks-keyservers.net > > iQEcBAEBAwAGBQJOumpWAAoJEE1wgkIhr9j3MacH/3VhyGRLFw5YEoqp02Ww/Uk0 > SSn48KLEu6TLU153Rp8B+l/oMQYKBDqVwiDtA85GRF0ZAdkyq37CqBDdiOIDTpLm > hSJZdqrCi+Wze7hB7j5z9jDNHq/jaImLqfWrFdF5uHA0ZpGFEPNLMB9PC7DK+RUT > wtxK+T1EqJj4IX3IykzIDkAYREkIpGIFFfO8VIhikjQDJYt2EFUogdEmrgEwBYPu > 2Wm/LWxMCKJCfYKWWZCsC5b+sd0JmAHBzPhb1cng4gsl2WTDf3iPAJ93GIk9eHL9 > JIWYl+3lbrrcZoULUgxUv35xSn4pC0QNqrLDI6OEAJutHDcyIS3qxLqr4cIzOyY= > =1A1Q > -----END PGP SIGNATURE----- > From maradns at gmail.com Wed Nov 9 14:03:57 2011 From: maradns at gmail.com (Sam Trenholme) Date: Wed, 9 Nov 2011 13:03:57 -0600 Subject: [MaraDNS list] Why I won't use Flattr or another similar scheme Message-ID: Flattr and Kachingle are two proposed systems for giving money to creators of music, art, software, and other digital goods. Flattr was created by one of the people behind The Pirate Bay, which should give one an idea of the mindset behind these two schemes. The thinking is this: You put a small amount of money, such as five dollars, in a fund for compensating digital goods creators. Every time you see a digital good you feel is worth paying for, you click on the "flattr me" or whatever button. At the end of the month, flattr takes the monthly contribution you made, skims off their maintenance fee, then divides up what's left by the number of web sites where you clicked on. So, say, if someone has a $13 monthly piggy bank for flattr contributions, and flattr gets $1, the contributor has $12 set aside for donating to sites. If they click on a single site, that one site gets all $12. If they click on three sites, each sites gets $4. 12 sites, and each site only gets $1. The problem is that flattr doesn't allow the buyer to assign a value to a digital good. In the real world, if someone sees 12 different cups they wish to buy, they will have to pay 12 times as much as they would if they only bought one cup. In the real world, if a buyer of goods becomes greedy and wants more of something, it is the greedy person's bank account which suffers the consequences. The greedy person will now have to work harder to generate more goods and services to pay off their debts. In the flattr world, on the other hand, if the buyer becomes greedy and wants more of something, it is the bank accounts of the creators of digital content that suffer. The greedy flattr user is not motivated to generate goods and services to compensate for the goods and services that they have consumed. Worse yet, the people who do create digital content are given less compensation for the same amount of work, and therefore are less motivated to produce more digital goods. Flattr is not a sustainable viable model for compensating the producers of digital content a fair price for their hard work. If people want to see MaraDNS continue to thrive and flourish, they will need to compensate me for my work. That means a real PayPal donation. Asking me to use flattr or some other unproven idea (such as Bitcoin) instead of making a PayPal donation doesn't cut it. Enough of the excuses. If I don't start getting compensated again a reasonable amount ($100 to $200 a month) for my work on MaraDNS, I will no longer be motivated to work on MaraDNS, except maybe to fix security and other critical bugs a couple of hours once a month. MaraDNS and Deadwood already nicely meet my own needs, so I no longer have a non-financial motivation to work on MaraDNS anymore. - Sam From Bradley at NorthTech.US Thu Nov 10 08:34:09 2011 From: Bradley at NorthTech.US (Bradley D. Thornton) Date: Thu, 10 Nov 2011 05:34:09 -0800 Subject: [MaraDNS list] Split Horizon on the horizon? In-Reply-To: References: <4EBA6A56.5070602@NorthTech.US> Message-ID: <4EBBD2D1.9040807@NorthTech.US> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 um... Sam. Oh, man... I don't know what to say. that kind of caught me absolutely by surprise. I was asking whether you had it in your mind to begin augmenting any features that you found alluring, and it/when you ever got around to it. I didn't ask you if you would begin implementing anything for me. I appreciate what happens in the open source world - especially the shit that I release publicly and freely to everyone in the world! I've never had any issues when I found myself directly, and monetarily, sponsoring your development efforts in the past with regards to La Mara. There were no auspices in my email asking you if you would expand the encompassing bounds of La Mara DNS based upon anything I was prepared to sponsor - As *ALWAYS* in the past, between us, I would have sent you a private email had that been the case. I've been running your software and have contributed several times over the years (financially) to your project, or noble cause, as I have championed it, and as I have seen it to be at times. I asked a simple question and you hit me with that fucking emotional blackmail thang? And, ironically, at a period in time where I was actually thinking of petitioning to commission you in the development of some more additional, specific, particular, functionalities? That's pretty fricken' messed up dude. We've known each other for more than a decade and I get that extremely insulting, and personally offensive response below from you? I dunno Sam. I wholeheartedly support your quest for compensation where development occurs, yet the kick in the groin you just delivered to me is, um..., Personally Offensive. I bid you the most and the best of it Sam. You have personally offended me. And I considered you an online colleague, perhaps friend, and above all, above that. On 11/09/2011 09:15 AM, Sam Trenholme wrote: > Show me the money and we'll talk. > > My time has become too valuable for me to continue making substantial > contributions to MaraDNS without being fairly compensated. MaraDNS and > Deadwood already nicely meet my own needs, so I no longer have a > non-financial motivation to work on MaraDNS anymore. > > - Sam > > 2011/11/9 Bradley D. Thornton : > Hey Sam, > > Have you any current inklings toward the support of Split Horizon > capabilities? > > I ask because I've come across a few instances where this is desirable. > > Just wondering, when you get a chance. > > Kindest regards, > > >> - -- Bradley D. Thornton Manager Network Services NorthTech Computer TEL: +1.760.666.2703 (US) TEL: +44.203.318.2755 (UK) http://NorthTech.US -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Find this cert at x-hkp://pool.sks-keyservers.net iQEcBAEBAwAGBQJOu9LRAAoJEE1wgkIhr9j3mB4H/2s5CCF/x9ulhtZXQS6Oax3z BOyW2loUOQG0coGg7jfznVwHCjzWTetDU7+ml6xS8rEbRwwVeow/t5Mp5vA7IzZV Khb99bj0D5L8AqgisPfK6sy13+FXyVfETENcrVQWmSxtYhezFprSA3IjYpAj5oxB uAYQFGO4v53SyL6yJA4oNUsPIZH05ADJ4gdDDi1rj0SaHGzswgZ09b7tdSOZT5Ow rv3Aj/jW4dNrVhAGhO0OZ+UUCL+oRULoYkH6Tmep5w2tJFFczFHteVAuCMN6rehP J4Ybqq1lGnB3K+xd2ymWhegOvZQg6csnuPEBkIfcq/QjZ6uSURQ3wUSsD8gTPqA= =oeOo -----END PGP SIGNATURE----- From Bradley at NorthTech.US Thu Nov 10 09:59:31 2011 From: Bradley at NorthTech.US (Bradley D. Thornton) Date: Thu, 10 Nov 2011 06:59:31 -0800 Subject: [MaraDNS list] Why I won't use Flattr or another similar scheme In-Reply-To: References: Message-ID: <4EBBE6D3.5060407@NorthTech.US> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 11/09/2011 11:03 AM, Sam Trenholme wrote: > Flattr is not a sustainable viable model for compensating the > producers of digital content a fair price for their hard work. Yes it is. - -- Bradley D. Thornton Manager Network Services NorthTech Computer TEL: +1.760.666.2703 (US) TEL: +44.203.318.2755 (UK) http://NorthTech.US -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Find this cert at x-hkp://pool.sks-keyservers.net iQEcBAEBAwAGBQJOu+bSAAoJEE1wgkIhr9j3fN0IAJGXM6GJieGE6Q3GM7Wy5pNu gfiN7kPYccojfjhq9K1qAoAWHScTZsXDT3CzTs9hlNz+P1Q0yWnZYvVlQ8ea83rR IiiG/9yMiZqFHB9hocpd2to5swloCAMH0SwhGxNXUiTPEpGsX5+2FPLNxYAUa0pz pQHbtOcjkGg49D1Qak8aGTPhiDSBoQPYhXFOZ0N1wKmNf+M5ktabYZACstPVS/wm DxXB2snUAuQ0ZinML3cCYBrvQXMojGsf94cdsU+rr52ErJujvZ1gM/c9F6curnrh 8oNIImwXcGn5kyDQRTqAlaWtCIWolJhs09npun1gUyxAexWXv7siK5b3jGTwr8I= =prBT -----END PGP SIGNATURE----- From dsevilla00 at hotmail.com Thu Nov 10 10:14:18 2011 From: dsevilla00 at hotmail.com (david sevilla) Date: Thu, 10 Nov 2011 08:14:18 -0700 Subject: [MaraDNS list] Split Horizon on the horizon? In-Reply-To: <4EBBD2D1.9040807@NorthTech.US> References: <4EBA6A56.5070602@NorthTech.US>, , <4EBBD2D1.9040807@NorthTech.US> Message-ID: Bradley, if I may jump in, I don't think Sam ever meant to make you feel personally attacked, it's simply that he is seeing his time is better spent on something else (I assume that means his family and job). He was simply being honest about it, but I don't think he was being offensive. I hope you see it that way too. I know in some cases Sam has been ironic and a bit deffensive (with people demanding stuff), but it really doesn't look like it's the case now.anyway, hope you guys have a good day > Date: Thu, 10 Nov 2011 05:34:09 -0800 > From: Bradley at NorthTech.US > To: list at maradns.org > Subject: Re: [MaraDNS list] Split Horizon on the horizon? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > um... Sam. Oh, man... > > I don't know what to say. that kind of caught me absolutely by surprise. > > I was asking whether you had it in your mind to begin augmenting any > features that you found alluring, and it/when you ever got around to it. > > I didn't ask you if you would begin implementing anything for me. I > appreciate what happens in the open source world - especially the shit > that I release publicly and freely to everyone in the world! > > I've never had any issues when I found myself directly, and monetarily, > sponsoring your development efforts in the past with regards to La Mara. > > There were no auspices in my email asking you if you would expand the > encompassing bounds of La Mara DNS based upon anything I was prepared to > sponsor - As *ALWAYS* in the past, between us, I would have sent you a > private email had that been the case. > > I've been running your software and have contributed several times over > the years (financially) to your project, or noble cause, as I have > championed it, and as I have seen it to be at times. > > I asked a simple question and you hit me with that fucking emotional > blackmail thang? And, ironically, at a period in time where I was > actually thinking of petitioning to commission you in the development > of some more additional, specific, particular, functionalities? > > That's pretty fricken' messed up dude. > > We've known each other for more than a decade and I get that extremely > insulting, and personally offensive response below from you? > > I dunno Sam. I wholeheartedly support your quest for compensation where > development occurs, yet the kick in the groin you just delivered to me > is, um..., Personally Offensive. > > I bid you the most and the best of it Sam. You have personally offended > me. And I considered you an online colleague, perhaps friend, and above > all, above that. > > On 11/09/2011 09:15 AM, Sam Trenholme wrote: > > Show me the money and we'll talk. > > > > My time has become too valuable for me to continue making substantial > > contributions to MaraDNS without being fairly compensated. MaraDNS and > > Deadwood already nicely meet my own needs, so I no longer have a > > non-financial motivation to work on MaraDNS anymore. > > > > - Sam > > > > 2011/11/9 Bradley D. Thornton : > > Hey Sam, > > > > Have you any current inklings toward the support of Split Horizon > > capabilities? > > > > I ask because I've come across a few instances where this is desirable. > > > > Just wondering, when you get a chance. > > > > Kindest regards, > > > > > >> > > - -- > Bradley D. Thornton > Manager Network Services > NorthTech Computer > TEL: +1.760.666.2703 (US) > TEL: +44.203.318.2755 (UK) > http://NorthTech.US > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Find this cert at x-hkp://pool.sks-keyservers.net > > iQEcBAEBAwAGBQJOu9LRAAoJEE1wgkIhr9j3mB4H/2s5CCF/x9ulhtZXQS6Oax3z > BOyW2loUOQG0coGg7jfznVwHCjzWTetDU7+ml6xS8rEbRwwVeow/t5Mp5vA7IzZV > Khb99bj0D5L8AqgisPfK6sy13+FXyVfETENcrVQWmSxtYhezFprSA3IjYpAj5oxB > uAYQFGO4v53SyL6yJA4oNUsPIZH05ADJ4gdDDi1rj0SaHGzswgZ09b7tdSOZT5Ow > rv3Aj/jW4dNrVhAGhO0OZ+UUCL+oRULoYkH6Tmep5w2tJFFczFHteVAuCMN6rehP > J4Ybqq1lGnB3K+xd2ymWhegOvZQg6csnuPEBkIfcq/QjZ6uSURQ3wUSsD8gTPqA= > =oeOo > -----END PGP SIGNATURE----- From maradns at gmail.com Thu Nov 10 12:30:05 2011 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 10 Nov 2011 11:30:05 -0600 Subject: [MaraDNS list] Split Horizon on the horizon? In-Reply-To: References: <4EBA6A56.5070602@NorthTech.US> <4EBBD2D1.9040807@NorthTech.US> Message-ID: Well, I don't see an email from Bradley asking to keep it anonymous, so I am very please to tell everyone that Bradley has made a very generous donation to the MaraDNS cause this month. I really appreciate the donation, Bradley. I know I've gotten more acid over the years about MaraDNS, and I apologize for my rude behavior. When I started writing MaraDNS, I was a very different person. I was unmarried, and I had a lot of ideals I no longer have today. Over the years, I have come to understand why the open source ideals make it a lot harder to monetize software development. This is a realization most open source developers come to sooner or later. Most of the time, the developers abandon their project without any discussion with their users. I feel the MaraDNS community deserves better than that, and this is why I have fund raising drives, so that, for a modest amount of money, the MaraDNS community continues to have a DNS server that meets their needs. Anyway, on to the feature request: I would love to do it Bradley. Here's the deal: I'm not sure how long it will take to implement, and I feel it's more important to get all of the bug fixes done so far more readily available to the community. In more detail: * The Deadwood 3.0.04 release broke reject_aaaa and reject_ptr (a couple of features it has so that DNS lookup timeouts don't slow things down with some Linux applications). I have already fixed it, and will release Deadwood 3.0.05 this morning with that fixed. * There's a lot of bug fixes in the current MaraDNS 2 snapshot and it's time to get MaraDNS 2.0.04 out there. * I will then backport some of the bug fixes to the MaraDNS 1 branch and release MaraDNS 1.4.07. After that: * I've gotten a lot of requests for split horizon for MaraDNS over the years. If donations continue next month, I will gladly implement this. There's a lot that needs to be done: First I will need to carefully add code to the fragile csv2 parser to allow split horizon tags for single records. I will also have to add the ability to parse split horizon information in one's mararc file. Once all that is done, I will have to add a split horizon bitmask to each DNS record, and add the code to look at the bitmask and correlate it to the incoming IP. I can do it. I don't think I can do it with only one month's worth of donations, but I can almost certainly do it for IPv4 if I get donations for both December and January. - Sam On Thu, Nov 10, 2011 at 9:14 AM, david sevilla wrote: > > Bradley, if I may jump in, I don't think Sam ever meant > to make you feel personally attacked, it's simply that he is seeing his time is > better spent on something else (I assume that means his family and job). He was simply being honest about it, but I don't think he was being offensive. I hope you see it that way too. I know in some cases Sam has been ironic and a bit deffensive (with people demanding stuff), but it really doesn't look like it's the case now.anyway, hope you guys have a good day >> Date: Thu, 10 Nov 2011 05:34:09 -0800 >> From: Bradley at NorthTech.US >> To: list at maradns.org >> Subject: Re: [MaraDNS list] Split Horizon on the horizon? >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: RIPEMD160 >> >> um... Sam. Oh, man... >> >> I don't know what to say. that kind of caught me absolutely by surprise. >> >> I was asking whether you had it in your mind to begin augmenting any >> features that you found alluring, and it/when you ever got around to it. >> >> I didn't ask you if you would begin implementing anything for me. I >> appreciate what happens in the open source world - especially the shit >> that I release publicly and freely to everyone in the world! >> >> I've never had any issues when I found myself directly, and monetarily, >> sponsoring your development efforts in the past with regards to La Mara. >> >> There were no auspices in my email asking you if you would expand the >> encompassing bounds of La Mara DNS based upon anything I was prepared to >> sponsor - As *ALWAYS* in the past, between us, I would have sent you a >> private email had that been the case. >> >> I've been running your software and have contributed several times over >> the years (financially) to your project, or noble cause, as I have >> championed it, and as I have seen it to be at times. >> >> I asked a simple question and you hit me with that fucking emotional >> blackmail thang? And, ironically, at a period in time where I was >> actually ?thinking of petitioning to commission you in the development >> of some more additional, specific, particular, functionalities? >> >> That's pretty fricken' messed up dude. >> >> We've known each other for more than a decade and I get that extremely >> insulting, and personally offensive response below from you? >> >> I dunno Sam. I wholeheartedly support your quest for compensation where >> development occurs, yet the kick in the groin you just delivered to me >> is, um..., Personally Offensive. >> >> I bid you the most and the best of it Sam. You have personally offended >> me. And I considered you an online colleague, perhaps friend, and above >> all, above that. >> >> On 11/09/2011 09:15 AM, Sam Trenholme wrote: >> > Show me the money and we'll talk. >> > >> > My time has become too valuable for me to continue making substantial >> > contributions to MaraDNS without being fairly compensated. ?MaraDNS and >> > Deadwood already nicely meet my own needs, so I no longer have a >> > non-financial motivation to work on MaraDNS anymore. >> > >> > - Sam >> > >> > 2011/11/9 Bradley D. Thornton : >> > Hey Sam, >> > >> > Have you any current inklings toward the support of Split Horizon >> > capabilities? >> > >> > I ask because I've come across a few instances where this is desirable. >> > >> > Just wondering, when you get a chance. >> > >> > Kindest regards, >> > >> > >> >> >> >> - -- >> Bradley D. Thornton >> Manager Network Services >> NorthTech Computer >> TEL: +1.760.666.2703 ?(US) >> TEL: +44.203.318.2755 (UK) >> http://NorthTech.US >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.10 (GNU/Linux) >> Comment: Find this cert at x-hkp://pool.sks-keyservers.net >> >> iQEcBAEBAwAGBQJOu9LRAAoJEE1wgkIhr9j3mB4H/2s5CCF/x9ulhtZXQS6Oax3z >> BOyW2loUOQG0coGg7jfznVwHCjzWTetDU7+ml6xS8rEbRwwVeow/t5Mp5vA7IzZV >> Khb99bj0D5L8AqgisPfK6sy13+FXyVfETENcrVQWmSxtYhezFprSA3IjYpAj5oxB >> uAYQFGO4v53SyL6yJA4oNUsPIZH05ADJ4gdDDi1rj0SaHGzswgZ09b7tdSOZT5Ow >> rv3Aj/jW4dNrVhAGhO0OZ+UUCL+oRULoYkH6Tmep5w2tJFFczFHteVAuCMN6rehP >> J4Ybqq1lGnB3K+xd2ymWhegOvZQg6csnuPEBkIfcq/QjZ6uSURQ3wUSsD8gTPqA= >> =oeOo >> -----END PGP SIGNATURE----- > From maradns at gmail.com Thu Nov 10 14:08:25 2011 From: maradns at gmail.com (Sam Trenholme) Date: Thu, 10 Nov 2011 13:08:25 -0600 Subject: [MaraDNS list] Deadwood 3.0.05 released Message-ID: My funding drive for November 2011 has so far been very successful. Because of the generous donations from Bradley D. Thornton and AngelD, I will be able to release updates for Deadwood, MaraDNS 2.0, and MaraDNS 1.4 this month. In the 3.0.04 release of Deadwood, I rewrote the code to handle reject_aaaa (a parameter that disables IPv6 lookups; useful for IPv4-only networks). The new code did not have the RA bit set; unfortunately, Linux's rather anal DNS stub resolver rejects replies with RA set, causing reject_aaaa and the new reject_ptr parameter (which disables reverse DNS lookups) to break resolution in Linux. I have updated the code so that RA is now set when sending out an reject_aaaa or reject_ptr reply. In addition, I have fixed the Windows release to have the mkSecretTxt.exe program (needed the first time Deadwood is run) again. As an aside, if the Windows release complains there is a problem creating the Deadwood service, please ensure that the Deadwood service is stopped, and that the previous version of Deadwood is disabled with "Deadwood.exe --remove". It can be downloaded here: http://www.maradns.org/deadwood/stable/ Again, thank you for your generous sponsorship. If the sponsorship continues next month, I will begin to implement split horizon DNS for MaraDNS. As always, please only give if you can readily afford to. - Sam From maradns at gmail.com Fri Nov 11 20:44:26 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 11 Nov 2011 19:44:26 -0600 Subject: [MaraDNS list] MaraDNS 1.4.07 released Message-ID: Because of a very very generous donation from Nicholas Bamber, I was able to release MaraDNS 1.4.07 today. This is MaraDNS 1.4.06 with six different bug fixes backported from MaraDNS 2.0: A typo fix for fetchzone AXFR-over-UDP packets are now correctly marked "truncated" It is now possible to have the '/' in hostnames Fix for Debian bug #607739: Hostname shown when complaining about DDIP issues AngelD's issue with zone transfers when there are a lot of FQDN4 records fixed. Karim's issue with '/read' directive fixed Please note that this is a legacy version of MaraDNS and is only for users of MaraDNS 1.x who are not ready to update to MaraDNS 2.0 yet. It can be downloaded here: http://www.maradns.org/download/1.4/1.4.07/ Deadwood roadmap Because of Nicholas' generous donation, I also plan to make a Deadwood 3.1 branch which will fully utilize caching of dangling CNAME records. Fixing this issue with Deadwood will help Deadwood more quickly resolve names in "Akamai hell" -- names which require chasing a lot of CNAME records to resolve. - Sam From nicholas at periapt.co.uk Sat Nov 12 02:04:35 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Sat, 12 Nov 2011 07:04:35 +0000 Subject: [MaraDNS list] MaraDNS 1.4.07 released In-Reply-To: References: Message-ID: <4EBE1A83.9040005@periapt.co.uk> Sam, Thanks. It's a good thing I use git and can switch between the legacy and experimental branches easily. On 12/11/11 01:44, Sam Trenholme wrote: > ............. I was > able to release MaraDNS 1.4.07 today. > > - Sam -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Sat Nov 12 13:47:36 2011 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 12 Nov 2011 12:47:36 -0600 Subject: [MaraDNS list] MaraDNS 2.0.04 released Message-ID: In light of Nicholas Bamber's very kind donation, my work on MaraDNS continues. I have release MaraDNS 2.0.04 today -- this is a bugfix-only update of MaraDNS 2.0.03; details are in the changelog at http://maradns.org/changelog.html It can be downloaded here: http://www.maradns.org/download/2.0/2.0.04/ - Sam From maradns at gmail.com Sat Nov 12 13:52:35 2011 From: maradns at gmail.com (Sam Trenholme) Date: Sat, 12 Nov 2011 12:52:35 -0600 Subject: [MaraDNS list] MaraDNS 1.4.07 released In-Reply-To: <4EBE1A83.9040005@periapt.co.uk> References: <4EBE1A83.9040005@periapt.co.uk> Message-ID: There really isn't that much difference between the branches right now ... the 1.4 branch right now is simply 2.0 with the messy legacy recursive code still intact. That would change if I get a chance to implement split horizon (one issue with split horizon is that I can't really implement it without slowing down things a little for users who don't need split horizon. I'll probably make it a compile-time #ifdef) But first, let me see if I can fix one of Deadwood's bugs which slows down recursion for hosts in Akamai-style CNAME hell. - Sam On Sat, Nov 12, 2011 at 1:04 AM, Nicholas Bamber wrote: > Sam, > ? ? ? ?Thanks. It's a good thing I use git and can switch between the legacy > and experimental branches easily. > > On 12/11/11 01:44, Sam Trenholme wrote: >> ............. I was >> able to release MaraDNS 1.4.07 today. > >> - Sam > > > -- > Nicholas Bamber | http://www.periapt.co.uk/ > PGP key 3BFFE73C from pgp.mit.edu > From maradns at gmail.com Sun Nov 13 02:42:54 2011 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 13 Nov 2011 01:42:54 -0600 Subject: [MaraDNS list] Another Deadwood workaround to add: easydns.{com|org|net|info} tarpit Message-ID: [EasyDNS: I am a the implementor of Deadwood, which is MaraDNS 2.0's recursive DNS server. Because of how my server works, the way your DNS servers makes it difficult for Deadwood to resolve names your DNS servers serve.] easydns.{com|net|org|info} is a set of DNS servers that serves records in such a way that it can put Deadwood in a tar pit trying to resolve a domain name. Here's what happens. Let us suppose we want to resolve, say, plosone.org, which is served by easydns.too-many-tlds. We get a NS referral in this form: # Querying the server with the IP 199.19.57.1 # Question: Aplosone.org. # NS replies: plosone.org. +86400 ns ns1.easydns.com. plosone.org. +86400 ns ns2.easydns.com. plosone.org. +86400 ns remote1.easydns.com. plosone.org. +86400 ns remote2.easydns.com. plosone.org. +86400 ns ns1.plos.org. # AR replies: #ns1.plos.org. +86400 a 68.165.106.110 As it turns out ns1.plos.org is offline, so we need to chase a glueless DNS record. So, we start chasing, say ns1.easydns.com. We end up with something like this: # Querying the server with the IP 192.5.6.30 # Question: Ans1.easydns.com. # NS replies: #easydns.com. +172800 ns dns3.easydns.org. #easydns.com. +172800 ns dns1.easydns.com. #easydns.com. +172800 ns dns2.easydns.net. #easydns.com. +172800 ns dns4.easydns.info. # AR replies: #dns1.easydns.com. +172800 aaaa 2001:1838:f001:0:0:0:0:10 #dns1.easydns.com. +172800 a 64.68.192.10 #dns2.easydns.net. +172800 a 72.52.2.1 So, suppose we start chasing dns3.easydns.org. We end up with something like this from the .org servers: # Querying the server with the IP 199.19.53.1 # Question: Adns3.easydns.org. # NS replies: #easydns.org. +86400 ns dns3.easydns.org. #easydns.org. +86400 ns dns1.easydns.com. #easydns.org. +86400 ns dns2.easydns.net. #easydns.org. +86400 ns dns4.easydns.info. # AR replies: dns3.easydns.org. +86400 a 64.68.193.10 dns3.easydns.org. +86400 aaaa 2620:49:a:0:0:0:0:10 So now suppose Deadwood decides to start chasing dns1.easydns.info. We end up with something like this from the .info servers: # Querying the server with the IP 199.254.49.1 # Question: Adns4.easydns.info. # NS replies: #easydns.info. +86400 ns dns2.easydns.net. #easydns.info. +86400 ns dns1.easydns.com. #easydns.info. +86400 ns dns3.easydns.org. #easydns.info. +86400 ns dns4.easydns.info. # AR replies: dns4.easydns.info. +86400 a 194.0.2.19 dns4.easydns.info. +86400 aaaa 2001:678:5:0:0:0:0:13 So, now, it's possible that we chase dns1.easydns.com ... which puts us in a tarpit, since Deadwood doesn't cache dns1.easydns.com from its AR record -- if we did cache dns1.easydns.com before, it would make Deadwood more vulnerable to DNS spoofing attacks. (To protect Deadwood from some kinds of DOS attacks, Deadwood will only stay in a tarpit like this so long before giving up) There are some ways to avoid this kind of tarpit: * We can have heuristics that favor chasing glued records over glueless records, which reduces the chance of falling in to this kind of tarpit (as long as at least one name has glue) * We can have a list of glueless records we have already chased in trying to resolve a given name, and set up the resolution code to not allow us to chase a name we have already chased before when trying to resolve this query. - Sam From maradns at gmail.com Sun Nov 13 03:30:39 2011 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 13 Nov 2011 02:30:39 -0600 Subject: [MaraDNS list] Patch for easydns tarpit issue Message-ID: Here is a patch that makes Deadwood greatly favor using a glued NS referral for the first NS record when chasing a query. This should minimize the chance of falling in to something like an easydns tarpit without all of the complexity and overhead of keeping track of which DNS server we've been at already. If the patch gets scrubbed, it is also here: http://maradns.org/deadwood/patches/deadwood-3.0.05-easydns-tarpit.patch - Sam From jefsey at jefsey.com Wed Nov 16 07:19:12 2011 From: jefsey at jefsey.com (JFC Morfin) Date: Wed, 16 Nov 2011 13:19:12 +0100 Subject: [MaraDNS list] DNS under exploited attack? In-Reply-To: References: Message-ID: <7.0.1.0.2.20111116125105.0d4d6b88@jefsey.com> FYI - in case this would be a new form of DoS. ----- From: Barry Greene Subject: Update: BIND 9 recursive error being investigated To: undisclosed-recipients:; Interm Security Advisory: http://www.isc.org/software/bind/advisories/cve-2011-tbd (CVE will be updated) Organizations across the Internet are reporting crashes interrupting service on BIND 9 nameservers performing recursive queries. Affected servers crash after logging an error in query.c with the following message: "INSIST(! dns_rdataset_isassociated(sigrdataset))" Multiple versions are reported as being affected, including all currently supported release versions of ISC BIND 9. ISC is actively investigating the root cause and working to produce patches which avoid the crash. Further information will be made available soon (see the advisory http://www.isc.org/software/bind/advisories/cve-2011-tbd). It is unknown at this time if this is an exploited attack. This is under investigation. Questions, observations, and data is welcomed. Please send to security-officer at isc.org. ---- jfc From dsevilla00 at hotmail.com Wed Nov 16 08:56:23 2011 From: dsevilla00 at hotmail.com (david sevilla) Date: Wed, 16 Nov 2011 06:56:23 -0700 Subject: [MaraDNS list] DNS under exploited attack? In-Reply-To: <7.0.1.0.2.20111116125105.0d4d6b88@jefsey.com> References: , <7.0.1.0.2.20111116125105.0d4d6b88@jefsey.com> Message-ID: I wonder if Anon or/and lulzsec are involved :P > Date: Wed, 16 Nov 2011 13:19:12 +0100 > To: list at maradns.org > From: jefsey at jefsey.com > CC: support at easydns.com > Subject: [MaraDNS list] DNS under exploited attack? > > FYI - in case this would be a new form of DoS. > ----- > > From: Barry Greene > Subject: Update: BIND 9 recursive error being investigated > To: undisclosed-recipients:; > > Interm Security Advisory: > http://www.isc.org/software/bind/advisories/cve-2011-tbd (CVE will be updated) > > Organizations across the Internet are reporting crashes interrupting > service on BIND 9 nameservers performing recursive queries. Affected > servers crash after logging an error in query.c with the following > message: "INSIST(! dns_rdataset_isassociated(sigrdataset))" > > Multiple versions are reported as being affected, including all > currently supported release versions of ISC BIND 9. > > ISC is actively investigating the root cause and working to produce > patches which avoid the crash. Further information will be made > available soon (see the advisory > http://www.isc.org/software/bind/advisories/cve-2011-tbd). > > It is unknown at this time if this is an exploited attack. This is > under investigation. > > Questions, observations, and data is welcomed. Please send to > security-officer at isc.org. > > ---- > > jfc > From nicholas at periapt.co.uk Fri Nov 18 02:17:28 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Fri, 18 Nov 2011 07:17:28 +0000 Subject: [MaraDNS list] MaraDNS 1.4.07 released In-Reply-To: References: <4EBE1A83.9040005@periapt.co.uk> Message-ID: <4EC60688.1060302@periapt.co.uk> Sam, Could I make a really beaurocratic request? Could you post back on the mailing list the missing changelog entries from 1.4.06 onwards. Also please make sure subsequent releases keep this information uptodate. (Please don't make any sort of release for this. That would just create extra work for no gain, not even for beaurocrats.) On 12/11/11 18:52, Sam Trenholme wrote: > There really isn't that much difference between the branches right now > ... the 1.4 branch right now is simply 2.0 with the messy legacy > recursive code still intact. > > That would change if I get a chance to implement split horizon (one > issue with split horizon is that I can't really implement it without > slowing down things a little for users who don't need split horizon. > I'll probably make it a compile-time #ifdef) > > But first, let me see if I can fix one of Deadwood's bugs which slows > down recursion for hosts in Akamai-style CNAME hell. > > - Sam > > On Sat, Nov 12, 2011 at 1:04 AM, Nicholas Bamber wrote: >> Sam, >> Thanks. It's a good thing I use git and can switch between the legacy >> and experimental branches easily. >> >> On 12/11/11 01:44, Sam Trenholme wrote: >>> ............. I was >>> able to release MaraDNS 1.4.07 today. > >>> - Sam >> >> >> -- >> Nicholas Bamber | http://www.periapt.co.uk/ >> PGP key 3BFFE73C from pgp.mit.edu >> > -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From nicholas at periapt.co.uk Sun Nov 20 08:42:29 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Sun, 20 Nov 2011 13:42:29 +0000 Subject: [MaraDNS list] MaraDNS 1.4.07 released In-Reply-To: <4EC60688.1060302@periapt.co.uk> References: <4EBE1A83.9040005@periapt.co.uk> <4EC60688.1060302@periapt.co.uk> Message-ID: <4EC903C5.20009@periapt.co.uk> Sam, I have been through the old emails and put together a patch to get the changelog uptodate. I really would appreciate it if I didn;t have to do this. I need the upstream changelog partly so I can easily see what has changed and patly because Debian policy asks for it. On 18/11/11 07:17, Nicholas Bamber wrote: > Sam, > Could I make a really beaurocratic request? Could you post back on the > mailing list the missing changelog entries from 1.4.06 onwards. Also > please make sure subsequent releases keep this information uptodate. > (Please don't make any sort of release for this. That would just create > extra work for no gain, not even for beaurocrats.) > > > On 12/11/11 18:52, Sam Trenholme wrote: >> There really isn't that much difference between the branches right now >> ... the 1.4 branch right now is simply 2.0 with the messy legacy >> recursive code still intact. >> >> That would change if I get a chance to implement split horizon (one >> issue with split horizon is that I can't really implement it without >> slowing down things a little for users who don't need split horizon. >> I'll probably make it a compile-time #ifdef) >> >> But first, let me see if I can fix one of Deadwood's bugs which slows >> down recursion for hosts in Akamai-style CNAME hell. >> >> - Sam >> >> On Sat, Nov 12, 2011 at 1:04 AM, Nicholas Bamber wrote: >>> Sam, >>> Thanks. It's a good thing I use git and can switch between the legacy >>> and experimental branches easily. >>> >>> On 12/11/11 01:44, Sam Trenholme wrote: >>>> ............. I was >>>> able to release MaraDNS 1.4.07 today. > >>>> - Sam >>> >>> >>> -- >>> Nicholas Bamber | http://www.periapt.co.uk/ >>> PGP key 3BFFE73C from pgp.mit.edu >>> >> > > -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Sun Nov 20 12:22:40 2011 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 20 Nov 2011 09:22:40 -0800 Subject: [MaraDNS list] MaraDNS 1.4.07 released In-Reply-To: <4EC903C5.20009@periapt.co.uk> References: <4EBE1A83.9040005@periapt.co.uk> <4EC60688.1060302@periapt.co.uk> <4EC903C5.20009@periapt.co.uk> Message-ID: Nick, Here is the changelog (I updated it when I released 2.0.04): maradns-2.0.04: This is a stable release of MaraDNS. AngelD's issue with zone transfers when there are a lot of FQDN4 records fixed. Karim's issue with '/read' directive fixed (2011.11.12) maradns-1.4.07: This is a legacy release of MaraDNS. All patches are backports of MaraDNS 2.0 bug fixes. A typo fix for fetchzone AXFR-over-UDP packets are now correctly marked "truncated" It is now possible to have the '/' in hostnames Fix for Debian bug #607739: Hostname shown when complaining about DDIP issues AngelD's issue with zone transfers when there are a lot of FQDN4 records fixed. Karim's issue with '/read' directive fixed (2011.11.11) Source: http://maradns.org/changelog.html You can also look in the "update/" folder to see all of the patches that update a given version of MaraDNS and Deadwood. All MaraDNS and Deadwood updates are done by running a script that patches against the source code and makes any other changes to the code; this script is also included in the update directory. For example, MaraDNS 1.4.07 updates are in update/1.4.07/ in the 1.4.07 tarball. I am hoping we can get people to move up from MaraDNS 1 to MaraDNS 2 -- the MaraDNS 1 recursive resolver works, but by the time I shoehorned everything in to the resolver to get it to work, the code was so messy as to be nigh-to-unmaintainable. On Sun, Nov 20, 2011 at 5:42 AM, Nicholas Bamber wrote: > Sam, > ? ? ? ?I have been through the old emails and put together a patch to get the > changelog uptodate. I really would appreciate it if I didn;t have to do > this. I need the upstream changelog partly so I can easily see what has > changed and patly because Debian policy asks for it. > > On 18/11/11 07:17, Nicholas Bamber wrote: >> Sam, >> ? ? ? Could I make a really beaurocratic request? Could you post back on the >> mailing list the missing changelog entries from 1.4.06 onwards. Also >> please make sure subsequent releases keep this information uptodate. >> (Please don't make any sort of release for this. That would just create >> extra work for no gain, not even for beaurocrats.) >> >> >> On 12/11/11 18:52, Sam Trenholme wrote: >>> There really isn't that much difference between the branches right now >>> ... the 1.4 branch right now is simply 2.0 with the messy legacy >>> recursive code still intact. >>> >>> That would change if I get a chance to implement split horizon (one >>> issue with split horizon is that I can't really implement it without >>> slowing down things a little for users who don't need split horizon. >>> I'll probably make it a compile-time #ifdef) >>> >>> But first, let me see if I can fix one of Deadwood's bugs which slows >>> down recursion for hosts in Akamai-style CNAME hell. >>> >>> - Sam >>> >>> On Sat, Nov 12, 2011 at 1:04 AM, Nicholas Bamber wrote: >>>> Sam, >>>> ? ? ? ?Thanks. It's a good thing I use git and can switch between the legacy >>>> and experimental branches easily. >>>> >>>> On 12/11/11 01:44, Sam Trenholme wrote: >>>>> ............. I was >>>>> able to release MaraDNS 1.4.07 today. > >>>>> - Sam >>>> >>>> >>>> -- >>>> Nicholas Bamber | http://www.periapt.co.uk/ >>>> PGP key 3BFFE73C from pgp.mit.edu >>>> >>> >> >> > > > -- > Nicholas Bamber | http://www.periapt.co.uk/ > PGP key 3BFFE73C from pgp.mit.edu > From nicholas at periapt.co.uk Mon Nov 21 18:14:12 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Mon, 21 Nov 2011 23:14:12 +0000 Subject: [MaraDNS list] MaraDNS 1.4.07 released In-Reply-To: References: <4EBE1A83.9040005@periapt.co.uk> <4EC60688.1060302@periapt.co.uk> <4EC903C5.20009@periapt.co.uk> Message-ID: <4ECADB44.5030809@periapt.co.uk> Sam, Thanks for this. I have now uploaded 1.4.07-1 to Debian. I should say something about why deadwood in Debian is taking so long. As is normal for Debian, the package tries to install maradns in some sort of working state but also to respect any changes that the installer subsequently makes to the config files. This is a Debian feature requiring specific scripting for that package. Unfortunately the implementation for maradns is imperfect. I need to rewrite that bit from scratch to accommodate deadwood. So my plan is to distrbute the deadwood version to the rarely used experimental branch of Debian, but on the understanding that anyone using it has to manage their own config files - at the very least for deadwood. Then in 1.4.07-2 I will fix the configuration issue. Then finally I will merge deadwood into the main line. On 20/11/11 17:22, Sam Trenholme wrote: > Nick, > > Here is the changelog (I updated it when I released 2.0.04): > > maradns-2.0.04: > > This is a stable release of MaraDNS. > > AngelD's issue with zone transfers when there are a lot of > FQDN4 records fixed. > > Karim's issue with '/read' directive fixed > > (2011.11.12) > > maradns-1.4.07: > > This is a legacy release of MaraDNS. All patches are backports of > MaraDNS 2.0 bug fixes. > > A typo fix for fetchzone > > AXFR-over-UDP packets are now correctly marked "truncated" > > It is now possible to have the '/' in hostnames > > Fix for Debian bug #607739: Hostname shown when complaining about > DDIP issues > > AngelD's issue with zone transfers when there are a lot of > FQDN4 records fixed. > > Karim's issue with '/read' directive fixed > > (2011.11.11) > > Source: http://maradns.org/changelog.html > > You can also look in the "update/" folder to see all of the patches > that update a given version of MaraDNS and Deadwood. All MaraDNS and > Deadwood updates are done by running a script that patches against the > source code and makes any other changes to the code; this script is > also included in the update directory. > > For example, MaraDNS 1.4.07 updates are in update/1.4.07/ in the 1.4.07 tarball. > > I am hoping we can get people to move up from MaraDNS 1 to MaraDNS 2 > -- the MaraDNS 1 recursive resolver works, but by the time I > shoehorned everything in to the resolver to get it to work, the code > was so messy as to be nigh-to-unmaintainable. > > > > On Sun, Nov 20, 2011 at 5:42 AM, Nicholas Bamber wrote: >> Sam, >> I have been through the old emails and put together a patch to get the >> changelog uptodate. I really would appreciate it if I didn;t have to do >> this. I need the upstream changelog partly so I can easily see what has >> changed and patly because Debian policy asks for it. >> >> On 18/11/11 07:17, Nicholas Bamber wrote: >>> Sam, >>> Could I make a really beaurocratic request? Could you post back on the >>> mailing list the missing changelog entries from 1.4.06 onwards. Also >>> please make sure subsequent releases keep this information uptodate. >>> (Please don't make any sort of release for this. That would just create >>> extra work for no gain, not even for beaurocrats.) >>> >>> >>> On 12/11/11 18:52, Sam Trenholme wrote: >>>> There really isn't that much difference between the branches right now >>>> ... the 1.4 branch right now is simply 2.0 with the messy legacy >>>> recursive code still intact. >>>> >>>> That would change if I get a chance to implement split horizon (one >>>> issue with split horizon is that I can't really implement it without >>>> slowing down things a little for users who don't need split horizon. >>>> I'll probably make it a compile-time #ifdef) >>>> >>>> But first, let me see if I can fix one of Deadwood's bugs which slows >>>> down recursion for hosts in Akamai-style CNAME hell. >>>> >>>> - Sam >>>> >>>> On Sat, Nov 12, 2011 at 1:04 AM, Nicholas Bamber wrote: >>>>> Sam, >>>>> Thanks. It's a good thing I use git and can switch between the legacy >>>>> and experimental branches easily. >>>>> >>>>> On 12/11/11 01:44, Sam Trenholme wrote: >>>>>> ............. I was >>>>>> able to release MaraDNS 1.4.07 today. > >>>>>> - Sam >>>>> >>>>> >>>>> -- >>>>> Nicholas Bamber | http://www.periapt.co.uk/ >>>>> PGP key 3BFFE73C from pgp.mit.edu >>>>> >>>> >>> >>> >> >> >> -- >> Nicholas Bamber | http://www.periapt.co.uk/ >> PGP key 3BFFE73C from pgp.mit.edu >> -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Tue Nov 22 17:23:36 2011 From: maradns at gmail.com (Sam Trenholme) Date: Tue, 22 Nov 2011 14:23:36 -0800 Subject: [MaraDNS list] Deadwood usage guide Message-ID: Deadwood, MaraDNS 2.0's recursive resolver, has a number of useful features that resolves routine DNS headaches. One DNS headache is that a number of Linux applications request an IPv6 DNS record before falling back to an IPv4 record. There is no way to disable this in the system; each application that does this has to be patched. Or, one can use Deadwood to resolve IPs and have the following line in one's Deadwood configuration file: reject_aaaa = 1 Another *NIX annoyance are applications that perform a reverse DNS lookup, which can cause some applications to make you wait over a minute before there is a DNS timeout. These kinds of lookups can be stopped dead in their tracks with Deadwood: reject_ptr = 1 Another issue is malware. For example, a family member's computer has been infected with a virus that redirects Google results to spam-filled pages. The people responsible for this malware use a large number of different domains that all resolve to the same IP. Deadwood has support for having up to 1,000 different IPs in one's results black-listed; if we get a DNS reply with a black-listed IP, the reply is not sent to us. For example, the malware authors are currently using the IP 64.111.199.250 to host these unwanted redirects. To blacklist this, one can add this to one's dwood3rc file: ip_blacklist = "64.111.199.250" Once this is added, remove Deadwood's cache file (to do: Warn the user if the timestamp for the cache file is newer than the timestamp for the dwood3rc file), restart Deadwood, and malware domains listed by the IP will no longer work. These IPs are in a hash, so there is no slowdown having only one or having 900 such blacklisted IPs. Just some ways Deadwood, despite being a tiny 64k binary, can be useful. - Sam From phil.harlow at gmail.com Fri Nov 25 07:06:37 2011 From: phil.harlow at gmail.com (Phil Harlow) Date: Fri, 25 Nov 2011 04:06:37 -0800 Subject: [MaraDNS list] MaraDNS Recursive question Message-ID: Hello, \ First let me start by saying thank you for making maradns! And thanks for any help! It would be greatly appreciated! I would like to accomplish this: http://blog.mixu.net/2009/10/14/how-to-setup-a-lan-dns-server-using-maradns-under-windows-7/ I want to forward all dns requests to opendns, except for a certain url, which I'd like to relocate. I can get the single address relocation part to work I believe, using askmara, but I can't get the recursive part to work. All i get for askmara Agoogle.com. is REFUSED. In that old tutorial they say to use: upstream_servers = {} upstream_servers["."] = "8.8.8.8,8.8.4.4" To supply the default dns. But the last and recent comment says "Upstream_servers no longer supported". Is this true? Is there still a way I can accomplish this? I'm on win7 x64 ultimate. I've tried giving maradns.exe admin privileges, trying the "8.8.8.8,8.8.4.4" part with spaces, no commas, and I can't get it to work. Sometimes maradns just closes and I have no time to read any output if any. Here's my current marac file just to help: hide_disclaimer = "YES" ipv4_bind_addresses = "127.0.0.1" timestamp_type = 2 random_seed_file = "secret.txt" csv2 = {} csv2["apple.com."] = "db.lan.txt" upstream_servers = {} upstream_servers["."] = "8.8.8.8,8.8.4.4" Thanks for any and all help!! -Phil Harlow From maradns at gmail.com Fri Nov 25 15:00:12 2011 From: maradns at gmail.com (Sam Trenholme) Date: Fri, 25 Nov 2011 12:00:12 -0800 Subject: [MaraDNS list] MaraDNS Recursive question In-Reply-To: References: Message-ID: Make sure you are using Deadwood 3.0.05. This is available here: http://maradns.org/deadwood/stable The .zip file is the Windows binary. Deadwood 3.0.05 is also available with MaraDNS 2.0.04. Only use MaraDNS 1.4.07 (which also has Deadwood 3.0.05) or any other MaraDNS 1 release if you have a compelling reason to use an older release of MaraDNS. > I want to forward all dns requests to opendns, except for a certain > url, which I'd like to relocate. This is your dwood3rc file: bind_address="192.168.1.42" recursive_acl="192.168.1.0/24" chroot_dir="/etc/maradns" upstream_servers={} upstream_servers["."]="208.67.222.222,208.67.220.220" upstream_servers["google.com."]="8.8.8.8,8.8.4.4" Replace "192.168.1.42" with the IP of your computer and "192.168.1.0/24" with the network range which needs to have access to the Deadwood server. Replace "google.com" and "8.8.8.8,8.8.4.4" with the domain you want to go to another DNS server. If you only need to have Deadwood be accessible from a single computer with a dynamic IP, have the bind_address be "127.0.0.1" and the recursive_acl be "127.0.0.0/16". > To supply the default dns. But the last and recent comment says > "Upstream_servers no longer supported". Is this true? No, it is not. I once had a user who had issues with upstream_servers, but I ran some tests and confirmed the problem was not with my program. >Sometimes maradns just closes and I have no time to read any > output if any. Do not use maradns.exe, use deadwood.exe. deadwood.exe is a service. It has to be installed as a service. As admin, enter the directory Deadwood is in and run the following commands from a "cmd" prompt: mkSecretTxt.exe deadwood.exe --install net start deadwood deadwood.exe needs, for security reasons, a source of entropy (a random file). This is why we generate a random file called secret.txt by calling mkSecretTxt.exe before installing Deadwood. Deadwood will log all errors in the file dwlog.txt. Look at this file if Deadwood refuses to start; it will tell you what is wrong. > Thanks for any and all help!! MaraDNS development and support is funded for by user contributions; its business model is the "PBS" business model. If you can afford to, please make a modest contribution by making a paypal donation to abiword_bugs at yahoo.com, or by clicking on the donate button at http://maradns.org. Note that mail sent to this email address is not looked at. - Sam From phil.harlow at gmail.com Sat Nov 26 17:17:54 2011 From: phil.harlow at gmail.com (Phil Harlow) Date: Sat, 26 Nov 2011 14:17:54 -0800 Subject: [MaraDNS list] MaraDNS Recursive question In-Reply-To: References: Message-ID: Hello, I sent a reply to Sam but it may not have gotten to him. I'm sending this one to the mailing list. I will try to explain what I need as concisely as possible. I would like to set up maradns/deadwood (whichever is correct to use) so that all dns requests coming to it, are passed along to my real dns servers to be resolved, EXCEPT for one special address, which I would like to "resolve" and send back a local ip. Essentially, I would like to have a recursive dns server which just forwards all requests to to the big guys, except for a special URL (guzzoni.apple.com), in which case I'd like to it behave like an authoritative dns server and send back my own specially resolved URL. (192.168.0.199) Eg, I ask for google.com, mara/deadwood checks the real dns servers (opendns, googledns, my isp's dns) and returns their response. But if I ask for guzzoni.apple.com, I would like to "resolve" it to 192.168.0.199. I do not want to pass that dns request to ANOTHER dns server as the example below accomplishes (I believe) I would like it to send back a resolved address of my choosing (192.168.0.199), only if it matches guzzoni.apple.com, and otherwise just pass along normal dns results. Is this possible? Thanks so much guys! -Phil Harlow On Fri, Nov 25, 2011 at 12:00 PM, Sam Trenholme wrote: > Make sure you are using Deadwood 3.0.05. ?This is available here: > > http://maradns.org/deadwood/stable > > The .zip file is the Windows binary. > > Deadwood 3.0.05 is also available with MaraDNS 2.0.04. ?Only use > MaraDNS 1.4.07 (which also has Deadwood 3.0.05) or any other MaraDNS 1 > release if you have a compelling reason to use an older release of > MaraDNS. > >> I want to forward all dns requests to opendns, except for a certain >> url, which I'd like to relocate. > > This is your dwood3rc file: > > bind_address="192.168.1.42" > recursive_acl="192.168.1.0/24" > chroot_dir="/etc/maradns" > upstream_servers={} > upstream_servers["."]="208.67.222.222,208.67.220.220" > upstream_servers["google.com."]="8.8.8.8,8.8.4.4" > > Replace "192.168.1.42" with the IP of your computer and > "192.168.1.0/24" with the network range which needs to have access to > the Deadwood server. ?Replace "google.com" and "8.8.8.8,8.8.4.4" with > the domain you want to go to another DNS server. > > If you only need to have Deadwood be accessible from a single computer > with a dynamic IP, have the bind_address be "127.0.0.1" and the > recursive_acl be "127.0.0.0/16". > >> To supply the default dns. But the last and recent comment says >> "Upstream_servers no longer supported". Is this true? > > No, it is not. ?I once had a user who had issues with > upstream_servers, but I ran some tests and confirmed the problem was > not with my program. > >>Sometimes maradns just closes and I have no time to read any >> output if any. > > Do not use maradns.exe, use deadwood.exe. > > deadwood.exe is a service. ?It has to be installed as a service. ?As > admin, enter the directory Deadwood is in and run the following > commands from a "cmd" prompt: > > mkSecretTxt.exe > deadwood.exe --install > net start deadwood > > deadwood.exe needs, for security reasons, a source of entropy (a > random file). ?This is why we generate a random file called secret.txt > by calling mkSecretTxt.exe before installing Deadwood. > > Deadwood will log all errors in the file dwlog.txt. ?Look at this file > if Deadwood refuses to start; it will tell you what is wrong. > >> Thanks for any and all help!! > > MaraDNS development and support is funded for by user contributions; > its business model is the "PBS" business model. ?If you can afford to, > please make a modest contribution by making a paypal donation to > abiword_bugs at yahoo.com, or by clicking on the donate button at > http://maradns.org. ?Note that mail sent to this email address is not > looked at. > > - Sam > From phil.harlow at gmail.com Sat Nov 26 18:29:37 2011 From: phil.harlow at gmail.com (Phil Harlow) Date: Sat, 26 Nov 2011 15:29:37 -0800 Subject: [MaraDNS list] MaraDNS Recursive question In-Reply-To: References: Message-ID: Ok, I think I got it to work!! Probably not the best way, but it works for now! My solution is to run BOTH dns servers (yuck) I have deadwood setup with this dwood3rc.txt: upstream_port = 54 upstream_servers = {} upstream_servers["guzzoni.apple.com."]="127.0.0.1" # Servers we connect to root_servers = {} root_servers["."]="198.41.0.4, 192.228.79.201, 192.33.4.12, 128.8.10.90, " root_servers["."]+="192.203.230.10, 192.5.5.241, 192.112.36.4, 128.63.2.53, " root_servers["."]+="192.36.148.17, 192.58.128.30, 193.0.14.129, 199.7.83.42, " root_servers["."]+="202.12.27.33" bind_address="192.168.0.199" recursive_acl = "192.168.0.0/24" random_seed_file = "secret.txt" cache_file = "dw_cache_bin" filter_rfc1918 = 0 Then I have this for my marac file: hide_disclaimer = "YES" ipv4_bind_addresses = "127.0.0.1" dns_port = 54 timestamp_type = 2 random_seed_file = "secret.txt" csv2 = {} csv2["apple.com."] = "db.lan.txt" and in db.lan.txt is: guzzoni.% 192.168.0.199 ~ This seems to work so far. If you guys have any tips for how to improve this/get this accomplished with just ONE dns server, it would be GREATLY appreciated! I'm going to do a write up in the next day or two for other people, so I'd rather not send them down the wrong/inefficient path :) Thanks so much for maradns! Donation on it's way! -Phil Harlow On Sat, Nov 26, 2011 at 2:17 PM, Phil Harlow wrote: > Hello, > > I sent a reply to Sam but it may not have gotten to him. I'm sending > this one to the mailing list. I will try to explain what I need as > concisely as possible. > > I would like to set up maradns/deadwood (whichever is correct to use) > so that all dns requests coming to it, are passed along to my real dns > servers to be resolved, EXCEPT for one special address, which I would > like to "resolve" and send back a local ip. Essentially, I would like > to have a recursive dns server which just forwards all requests to to > the big guys, except for a special URL (guzzoni.apple.com), in which > case I'd like to it behave like an authoritative dns server and send > back my own specially resolved URL. (192.168.0.199) > > Eg, I ask for google.com, mara/deadwood checks the real dns servers > (opendns, googledns, my isp's dns) and returns their response. > But if I ask for guzzoni.apple.com, I would like to "resolve" it to > 192.168.0.199. > > I do not want to pass that dns request to ANOTHER dns server as the > example below accomplishes (I believe) > > I would like it to send back a resolved address of my choosing > (192.168.0.199), only if it matches guzzoni.apple.com, and otherwise > just pass along normal dns results. > > Is this possible? > > Thanks so much guys! > > > -Phil Harlow > > > > On Fri, Nov 25, 2011 at 12:00 PM, Sam Trenholme wrote: >> Make sure you are using Deadwood 3.0.05. ?This is available here: >> >> http://maradns.org/deadwood/stable >> >> The .zip file is the Windows binary. >> >> Deadwood 3.0.05 is also available with MaraDNS 2.0.04. ?Only use >> MaraDNS 1.4.07 (which also has Deadwood 3.0.05) or any other MaraDNS 1 >> release if you have a compelling reason to use an older release of >> MaraDNS. >> >>> I want to forward all dns requests to opendns, except for a certain >>> url, which I'd like to relocate. >> >> This is your dwood3rc file: >> >> bind_address="192.168.1.42" >> recursive_acl="192.168.1.0/24" >> chroot_dir="/etc/maradns" >> upstream_servers={} >> upstream_servers["."]="208.67.222.222,208.67.220.220" >> upstream_servers["google.com."]="8.8.8.8,8.8.4.4" >> >> Replace "192.168.1.42" with the IP of your computer and >> "192.168.1.0/24" with the network range which needs to have access to >> the Deadwood server. ?Replace "google.com" and "8.8.8.8,8.8.4.4" with >> the domain you want to go to another DNS server. >> >> If you only need to have Deadwood be accessible from a single computer >> with a dynamic IP, have the bind_address be "127.0.0.1" and the >> recursive_acl be "127.0.0.0/16". >> >>> To supply the default dns. But the last and recent comment says >>> "Upstream_servers no longer supported". Is this true? >> >> No, it is not. ?I once had a user who had issues with >> upstream_servers, but I ran some tests and confirmed the problem was >> not with my program. >> >>>Sometimes maradns just closes and I have no time to read any >>> output if any. >> >> Do not use maradns.exe, use deadwood.exe. >> >> deadwood.exe is a service. ?It has to be installed as a service. ?As >> admin, enter the directory Deadwood is in and run the following >> commands from a "cmd" prompt: >> >> mkSecretTxt.exe >> deadwood.exe --install >> net start deadwood >> >> deadwood.exe needs, for security reasons, a source of entropy (a >> random file). ?This is why we generate a random file called secret.txt >> by calling mkSecretTxt.exe before installing Deadwood. >> >> Deadwood will log all errors in the file dwlog.txt. ?Look at this file >> if Deadwood refuses to start; it will tell you what is wrong. >> >>> Thanks for any and all help!! >> >> MaraDNS development and support is funded for by user contributions; >> its business model is the "PBS" business model. ?If you can afford to, >> please make a modest contribution by making a paypal donation to >> abiword_bugs at yahoo.com, or by clicking on the donate button at >> http://maradns.org. ?Note that mail sent to this email address is not >> looked at. >> >> - Sam >> > From maradns at gmail.com Sun Nov 27 17:52:58 2011 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 27 Nov 2011 14:52:58 -0800 Subject: [MaraDNS list] Deadwood 3.1.01 released Message-ID: While everyone else in the USA has been celebrating Thanksgiving (OK, that's a slight exaggeration...I also have been celebrating Thanksgiving but made as much time as I could to work on Deadwood), I have been taking advantage of the days off from my day job to implement something in Deadwood that I didn't have a chance to implement before. I would like to thank Nicholas Bamber, again, for his sponsorship that makes this work possible. One issue Deadwood 3.0 has had is that it doesn't use cached incomplete CNAME referrals. Let me explain... When trying to resolve, say, news.yahoo.com, we end up getting a reply like this: "news.yahoo.com's name is actually some-horrible-really-long-name.yahoodns.net, and I am not going to tell you where to find some-horrible-really-long-name.yahoodns.net". So, Deadwood has to go to all of the effort to locate this really long horrible name. Now, 15 minutes later, once news.yahoo.com has expired from the cache, let us suppose someone else asks for news.yahoo.com. While Deadwood, in fact, notes that news.yahoo.com really uses some other name, Deadwood 3 does not actually use this information and has to start over to find news.yahoo.com. Deadwood 3.1.01 fixes all this. Deadwood will now use an incomplete CNAME record that is in its cache to speed up solving these kinds of difficult-to-resolve CNAME chains. Since Deadwood has always cached these records, this change to the code doesn't even change the binary format for Deadwood's cache file. Since this required re-factoring quite a bit of Deadwood's recursive resolver, it was rather difficult to implement. Also, due to the amount of code rewritten, this is a testing release. Please only use this release if you are willing to remain subscribed to the MaraDNS mailing list to report bugs. It can be downloaded here: http://www.maradns.org/deadwood/testing/ - Sam From maradns at gmail.com Sun Nov 27 22:17:42 2011 From: maradns at gmail.com (Sam Trenholme) Date: Sun, 27 Nov 2011 19:17:42 -0800 Subject: [MaraDNS list] Deadwood 3.0.02 released Message-ID: Last minute testing discovered a crash in Deadwood 3.1.01 (there were cases when a pointer would be uninitialized, causing Deadwood to segfault when dereferencing the pointer); I have released Deadwood 3.1.02 with this fixed. - Sam From maradns at gmail.com Tue Nov 29 15:14:02 2011 From: maradns at gmail.com (Sam Trenholme) Date: Tue, 29 Nov 2011 12:14:02 -0800 Subject: [MaraDNS list] MaraDNS Recursive question In-Reply-To: References: Message-ID: Phil made a donation so I answered his questions for him via private email; I have also written a blog entry detailing how to address Phil's issue: http://maradns.org/blog/20111128.html In addition, I have implemented sub-second finely-grained timestamps in Deadwood, both for using clock_gettime() in Linux and other POSIX-compliant OSes, and for Windows using GetSystemTimeAsFileTime(). Note that Mac OS X isn't POSIX compliant and doesn't have clock_gettime(); I have added a compile-time flag to get Deadwood to compile on *NIX-like systems without clock_gettime(): cd src/ ; export FLAGS='-O3 -DFALLBACK_TIME' ; make If people know of other *NIX variants without clock_gettime(), please report them to the list so I can tell people in which OSes people will need to use the FALLBACK_TIME to compile Deadwood. It can be downloaded here (both a source code and as a Windows binary): http://www.maradns.org/deadwood/snap/ - Sam (I could mutter darkly about the UNIX certification process, seeing that Mac OS X is UNIX certified yet does not have the POSIX clock_gettime() call, yet Linux, which isn't UNIX certified, does have this call) On Sat, Nov 26, 2011 at 2:17 PM, Phil Harlow wrote: > Hello, > > I sent a reply to Sam but it may not have gotten to him. I'm sending > this one to the mailing list. I will try to explain what I need as > concisely as possible. > > I would like to set up maradns/deadwood (whichever is correct to use) > so that all dns requests coming to it, are passed along to my real dns > servers to be resolved, EXCEPT for one special address, which I would > like to "resolve" and send back a local ip. Essentially, I would like > to have a recursive dns server which just forwards all requests to to > the big guys, except for a special URL (guzzoni.apple.com), in which > case I'd like to it behave like an authoritative dns server and send > back my own specially resolved URL. (192.168.0.199) > > Eg, I ask for google.com, mara/deadwood checks the real dns servers > (opendns, googledns, my isp's dns) and returns their response. > But if I ask for guzzoni.apple.com, I would like to "resolve" it to > 192.168.0.199. > > I do not want to pass that dns request to ANOTHER dns server as the > example below accomplishes (I believe) > > I would like it to send back a resolved address of my choosing > (192.168.0.199), only if it matches guzzoni.apple.com, and otherwise > just pass along normal dns results. > > Is this possible? > > Thanks so much guys! > > > -Phil Harlow > > > > On Fri, Nov 25, 2011 at 12:00 PM, Sam Trenholme wrote: >> Make sure you are using Deadwood 3.0.05. ?This is available here: >> >> http://maradns.org/deadwood/stable >> >> The .zip file is the Windows binary. >> >> Deadwood 3.0.05 is also available with MaraDNS 2.0.04. ?Only use >> MaraDNS 1.4.07 (which also has Deadwood 3.0.05) or any other MaraDNS 1 >> release if you have a compelling reason to use an older release of >> MaraDNS. >> >>> I want to forward all dns requests to opendns, except for a certain >>> url, which I'd like to relocate. >> >> This is your dwood3rc file: >> >> bind_address="192.168.1.42" >> recursive_acl="192.168.1.0/24" >> chroot_dir="/etc/maradns" >> upstream_servers={} >> upstream_servers["."]="208.67.222.222,208.67.220.220" >> upstream_servers["google.com."]="8.8.8.8,8.8.4.4" >> >> Replace "192.168.1.42" with the IP of your computer and >> "192.168.1.0/24" with the network range which needs to have access to >> the Deadwood server. ?Replace "google.com" and "8.8.8.8,8.8.4.4" with >> the domain you want to go to another DNS server. >> >> If you only need to have Deadwood be accessible from a single computer >> with a dynamic IP, have the bind_address be "127.0.0.1" and the >> recursive_acl be "127.0.0.0/16". >> >>> To supply the default dns. But the last and recent comment says >>> "Upstream_servers no longer supported". Is this true? >> >> No, it is not. ?I once had a user who had issues with >> upstream_servers, but I ran some tests and confirmed the problem was >> not with my program. >> >>>Sometimes maradns just closes and I have no time to read any >>> output if any. >> >> Do not use maradns.exe, use deadwood.exe. >> >> deadwood.exe is a service. ?It has to be installed as a service. ?As >> admin, enter the directory Deadwood is in and run the following >> commands from a "cmd" prompt: >> >> mkSecretTxt.exe >> deadwood.exe --install >> net start deadwood >> >> deadwood.exe needs, for security reasons, a source of entropy (a >> random file). ?This is why we generate a random file called secret.txt >> by calling mkSecretTxt.exe before installing Deadwood. >> >> Deadwood will log all errors in the file dwlog.txt. ?Look at this file >> if Deadwood refuses to start; it will tell you what is wrong. >> >>> Thanks for any and all help!! >> >> MaraDNS development and support is funded for by user contributions; >> its business model is the "PBS" business model. ?If you can afford to, >> please make a modest contribution by making a paypal donation to >> abiword_bugs at yahoo.com, or by clicking on the donate button at >> http://maradns.org. ?Note that mail sent to this email address is not >> looked at. >> >> - Sam >> From nicholas at periapt.co.uk Tue Nov 29 17:25:49 2011 From: nicholas at periapt.co.uk (Nicholas Bamber) Date: Tue, 29 Nov 2011 22:25:49 +0000 Subject: [MaraDNS list] TCP In-Reply-To: References: <4E1DA6D7.6090201@periapt.co.uk> <4E1F6DDC.6050301@periapt.co.uk> <4E1FE9D5.3000507@periapt.co.uk> <4E207A75.9050507@periapt.co.uk> <4E241458.2090809@periapt.co.uk> Message-ID: <4ED55BED.7030307@periapt.co.uk> Sam, I've got to the bottom of this (after dusting off gdb). The behaviour seems to have changed slightly since I raised the issue and now the only issue is this behaviour ? dig williams.periapt. @127.0.0.3 +tcp ;; communications error to 127.0.0.3#53: end of file I have found that this is because the zoneserver was not permissioned to pass on TCP requests. As soon as I set the "tcp_convert_server" and "tcp_convert_acl" parameters it worked normally. I have no issues with the documentation. The way Debian handles maradns config needs a complete reworking and as part of that, it will be reasonable for users on localhost to do these sort of queries. As such I will downgrade the bug report to a minor non-upstream bug. However there is still the question as to whether it would be possible for the zoneserver to pass an error message to the client before clsoing the connection so that the client can present a meaningful message such as "permission denied". On 18/07/11 16:25, Sam Trenholme wrote: >> >> 2.) The only way of forcing a TCP connection I can find is to use the >> +tcp option in dig. >> > > This is one of the reasons a lot of Deadwood's tests use Deadwood. The > other is IPv6. > > >> 3.) Asking for AXFR and IXFR records via dig seems to work but does not >> deliver useful information. >> >> > I thought I fixed this bug a while ago: > > http://woodlane.webconquest.com/pipermail/list/2011-July/000878.html > > Let me know if there are still problems > > 4.) Running 'dig hostname @server +tcp' works against a bind server but >> against the maradns zonserver seems to generate a seg fault. I will put >> the full output at the end. >> >> > This is not a good thing. Time to generate a stack trace. To do this: > > * Compile zoneserver with the '-g' flag set (change the appropriate flag in > zoneserver/Makefile ; with many programs "export FLAGS=-g ; make" does the > trick but I don't remember off the top of my head if that works with > MaraDNS) > > * To run "zoneserver foo bar baz" in "gdb", type in "gdb zoneserver", follow > by "set args foo bar baz", followed by "run" > > As I recall, I had to do a bunch of stuff to fix TCP recently in the 2.0 > branch of MaraDNS. Check it out: > > http://maradns.org/download/2.0/snap > > Dates are in YYYYMMDD format; 20110712 means "July 12, 2011", *not* > "November 7, 2011" > > 5.) Since askmara apparently does not have a +tcp option I am guessing >> that this is what you are expecting. However it was not what I was >> expecting given the documentation. >> > > There actually is an "askmara-tcp" that I use for some of the testing. > > Thanks a lot for looking at MaraDNS. I will next work on the code this > Friday; my first order of business is fixing a bug in Deadwood with > resolving answers.yahoo.com: > > http://agn2.vk.tj > > - Sam > -- Nicholas Bamber | http://www.periapt.co.uk/ PGP key 3BFFE73C from pgp.mit.edu From maradns at gmail.com Wed Nov 30 12:17:21 2011 From: maradns at gmail.com (Sam Trenholme) Date: Wed, 30 Nov 2011 09:17:21 -0800 Subject: [MaraDNS list] TCP In-Reply-To: <4ED55BED.7030307@periapt.co.uk> References: <4E1DA6D7.6090201@periapt.co.uk> <4E1F6DDC.6050301@periapt.co.uk> <4E1FE9D5.3000507@periapt.co.uk> <4E207A75.9050507@periapt.co.uk> <4E241458.2090809@periapt.co.uk> <4ED55BED.7030307@periapt.co.uk> Message-ID: > ? dig williams.periapt. @127.0.0.3 +tcp > ;; communications error to 127.0.0.3#53: end of file [...] > However there is still the question as to whether it would be possible > for the zoneserver to pass an error message to the client before clsoing > the connection so that the client can present a meaningful message such > as "permission denied". The reason for this unusual behavior is because this is how djbdns handles unauthorized DNS-over-TCP requests; back in 2001 I was emulating its behavior. I also used random source ports for upstream requests since the beginning, which got praised by ZDnet a few years later, so I think I did the right thing at the time. djbdns is really an excellent DNS server, and it was a good starting point for MaraDNS' design. - Sam