From strenholme.usenet at gmail.com Wed Jul 7 12:23:21 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 7 Jul 2010 09:23:21 -0700 Subject: Monthly posting: MaraDNS progress report; I'm still looking for work Message-ID: I am making a lot of progress with Deadwood. Deadwood?s recursive resolver is starting to be able to recursively resolve hostnames on the internet, but there is a lot of work to be done before I will be comfortable surfing the web with it and making a release for general testing. I would say about 99% of hostnames resolve with Deadwood right now; it?s the other 1% which I?m still working on. More importantly, I would like everyone to know that I have returned to the United States, and am looking for work. I require a job that allows me to remotely telecommute from Mexico about a week every month (yes, there is high-speed internet down there) so I can spend time with my wife until she has permission to come to the United States?a process that might take a year or longer. My resume is available here: http://samiam.org/resume/ People here know exactly how well I can code; I wrote MaraDNS after all. If anyone has any potential leads, please contact me via private email. This is a monthly posting; if I do not find a job in July, I will post an announcement in early August. - Sam From eminakbulut at gmail.com Fri Jul 16 09:50:55 2010 From: eminakbulut at gmail.com (Emin Akbulut) Date: Fri, 16 Jul 2010 16:50:55 +0300 Subject: NS answer instead of SOA Message-ID: Hi, MaraDNS returns NS records instead of SOA. Both NS and SOA types return in NS format. Config: izsmmmo.com. SOA ns1.izsmmmo.com. hostmaster at izsmmmo.com. 10 10800 3600 604800 1080 ~ izsmmmo.com. +600 a 88.255.136.43 ~ izsmmmo.com. +600 ns ns1.izsmmmo.com. ~ izsmmmo.com. +600 ns ns2.izsmmmo.com. ~ ... NsLookup: > set type=soa > izsmmmo.com Server: [212.174.121.150] Address: 212.174.121.150 izsmmmo.com nameserver = ns1.izsmmmo.com izsmmmo.com nameserver = ns2.izsmmmo.com > From eminakbulut at gmail.com Fri Jul 16 10:15:08 2010 From: eminakbulut at gmail.com (Emin Akbulut) Date: Fri, 16 Jul 2010 17:15:08 +0300 Subject: NS answer instead of SOA In-Reply-To: References: Message-ID: OK, I simply made the first line as SOA Question #2? I set all zones in single config file. How can I make second SOA record works? On Fri, Jul 16, 2010 at 4:50 PM, Emin Akbulut wrote: > Hi, MaraDNS returns NS records instead of SOA. > Both NS and SOA types return in NS format. > > Config: > izsmmmo.com. SOA ns1.izsmmmo.com. hostmaster at izsmmmo.com. 10 10800 3600 > 604800 1080 ~ > izsmmmo.com. +600 a 88.255.136.43 ~ > izsmmmo.com. +600 ns ns1.izsmmmo.com. ~ > izsmmmo.com. +600 ns ns2.izsmmmo.com. ~ > ... > > > NsLookup: > > > set type=soa > > izsmmmo.com > Server: [212.174.121.150] > Address: 212.174.121.150 > > izsmmmo.com nameserver = ns1.izsmmmo.com > izsmmmo.com nameserver = ns2.izsmmmo.com > > > > From strenholme.usenet at gmail.com Fri Jul 16 13:23:29 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 16 Jul 2010 10:23:29 -0700 Subject: NS answer instead of SOA In-Reply-To: References: Message-ID: > izsmmmo.com. SOA ns1.izsmmmo.com. hostmaster at izsmmmo.com. 10 10800 3600 > 604800 1080 ~ > izsmmmo.com. +600 a 88.255.136.43 ~ > izsmmmo.com. +600 ns ns1.izsmmmo.com. ~ > izsmmmo.com. +600 ns ns2.izsmmmo.com. ~ As a general rule, it is a good idea to check your logfile (syslog if you are using duende to start MaraDNS) for messages indicating potential problems. This zone file gives the following warning: Warning: Authoritative NSes must be immediately after SOA Or the first records in the zone Otherwise, the record is ignored Again, this is not a warning buried on page 132 of the manual. It is readily visible. It is fixed by changing your zone file to read thusly: izsmmmo.com. SOA ns1.izsmmmo.com. hostmaster at izsmmmo.com. 10 10800 3600 604800 1080 ~ izsmmmo.com. +600 ns ns1.izsmmmo.com. ~ izsmmmo.com. +600 ns ns2.izsmmmo.com. ~ izsmmmo.com. +600 a 88.255.136.43 ~ In other news, Deadwood is, as I type this, a fully recursive DNS server. It is what software developers call "feature complete": Deadwood now can do everything that it will do in the MaraDNS 2.0 release. However, there is a lot of testing that still needs to be done. Bugs need to be found and fixed. For example, I already know that Deadwood doesn't handle unresponsive nameservers very well, and will make changes to resolve that. My plan right now is to have it so, if a nameserver doesn't resolve, try the next nameserver, or better yet, try [(nameserver + 83) % number_of_nameservers]. If I decide to be really fancy about it, if a nameserver doesn't resolve while solving a glueless NS record, give up on the glueless sub-query and try another nameserver from the list. While testing Deadwood yesterday, I found a bug in authoritative MaraDNS: MaraDNS incorrectly handles delegation NS records when given an ANY query. So, yes, I already have bugs I need to fix. So, back to working on MaraDNS. There's a reason I don't do email support for MaraDNS, and reject blog comments asking for MaraDNS support. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Thu Jul 22 15:11:34 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 22 Jul 2010 12:11:34 -0700 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing Message-ID: I have just released Deadwood 2.9.01. This is the first release of Deadwood with full recursion; in other words, in addition to getting information from upstream_servers, Deadwood can now use root_servers (if neither upstream_servers nor root_servers are set, Deadwood defaults to the ICANN IPv4 root servers). The release is available here, both as source code and as Windows binaries: http://maradns.org/deadwood/testing/ This releases fixes a lot of issues people have reported here on the list and elsewhere: Deadwood has full IPv6 support. This release handles CNAMEs correctly and doesn?t have the issues MaraDNS 1.x has with AAAA records that point to CNAMEs. There is a good chance that a domain that doesn?t resolve with MaraDNS 1.x will resolve with Deadwood. More importantly, I?m willing to listen to bug reports about names not resolving again. If a given name doesn?t resolve in Deadwood 2.9, but resolves using another DNS server, I want to know about it. I now can give people something better than ?read http://maradns.org/faq.html#resolve and no I won?t fix it? when people report bugs with MaraDNS? recursive resolver. For example, when Ms. Maxine Ritter reported a bug with recursive ANY queries, I told her I wouldn?t fix that. Well, that?s changed and I have fixed her issue; Deadwood 2.9 correctly handles ANY queries. It has been a long road to get here. I have wanted to rewrite MaraDNS? recursive resolver since 2002; I started writing Deadwood in 2007 and it?s finally feature-complete. I encourage people to test Deadwood 2.9.01 and report any bugs they find. Please keep the following in mind: * Valgrind-reported memory leaks can always be reported. Valgrind-reported errors are only valid if Deadwood is compiled with -DVALGRIND_NOERRORS * The only officially supported OSes are Windows XP and CentOS 5. OS-specific issues such as startup, daemonizing, sysloggin, and /etc/resolv.conf setup are only supported on these two OSes. * Bugs need to be reported to the MaraDNS list, not to my email account nor as blog comments. I hope to have time to set up a web forum for MaraDNS/Deadwood support for people not comfortable with mailing lists, but no promises. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From jefsey at jefsey.com Thu Jul 22 16:34:34 2010 From: jefsey at jefsey.com (jefsey) Date: Thu, 22 Jul 2010 22:34:34 +0200 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: References: Message-ID: <7.0.1.0.2.20100722223249.05e64810@jefsey.com> Great! Thank you! I hope I can work on it all this coming month of august. Best. jfc At 21:11 22/07/2010, Sam Trenholme wrote: >I have just released Deadwood 2.9.01. This is the first release of >Deadwood with full recursion; in other words, in addition to getting >information from upstream_servers, Deadwood can now use root_servers >(if neither upstream_servers nor root_servers are set, Deadwood >defaults to the ICANN IPv4 root servers). > >The release is available here, both as source code and as Windows binaries: > >http://maradns.org/deadwood/testing/ > >This releases fixes a lot of issues people have reported here on the >list and elsewhere: Deadwood has full IPv6 support. This release >handles CNAMEs correctly and doesn't have the issues MaraDNS 1.x has >with AAAA records that point to CNAMEs. There is a good chance that a >domain that doesn't resolve with MaraDNS 1.x will resolve with >Deadwood. > >More importantly, I'm willing to listen to bug reports about names not >resolving again. If a given name doesn't resolve in Deadwood 2.9, but >resolves using another DNS server, I want to know about it. I now can >give people something better than "read >http://maradns.org/faq.html#resolve and no I won't fix it" when people >report bugs with MaraDNS' recursive resolver. For example, when Ms. >Maxine Ritter reported a bug with recursive ANY queries, I told her I >wouldn't fix that. Well, that's changed and I have fixed her issue; >Deadwood 2.9 correctly handles ANY queries. > >It has been a long road to get here. I have wanted to rewrite MaraDNS' >recursive resolver since 2002; I started writing Deadwood in 2007 and >it's finally feature-complete. > >I encourage people to test Deadwood 2.9.01 and report any bugs they >find. Please keep the following in mind: > > * Valgrind-reported memory leaks can always be reported. >Valgrind-reported errors are only valid if Deadwood is compiled with >-DVALGRIND_NOERRORS > > * The only officially supported OSes are Windows XP and CentOS 5. >OS-specific issues such as startup, daemonizing, sysloggin, and >/etc/resolv.conf setup are only supported on these two OSes. > > * Bugs need to be reported to the MaraDNS list, not to my email >account nor as blog comments. I hope to have time to set up a web >forum for MaraDNS/Deadwood support for people not comfortable with >mailing lists, but no promises. > >- Sam > >Note: I do not answer MaraDNS (including Deadwood) support requests >sent by private email without being compensated for my time. A MaraDNS >support request is any and all discussion you may wish to have about >MaraDNS in private email; if you want to email me to talk about >MaraDNS then, yes, that is a support request. I will discuss rates if >you want this kind of support. Thank you for your understanding. > >MaraDNS security vulnerability reports, however, will be dealt with >without charge and kept confidential. If you don't know what Bugtraq >is, then, no, your email is not a security report. It is not a >security report unless you've done due diligence to determine how the >security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Thu Jul 22 20:33:01 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 22 Jul 2010 17:33:01 -0700 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: <7.0.1.0.2.20100722223249.05e64810@jefsey.com> References: <7.0.1.0.2.20100722223249.05e64810@jefsey.com> Message-ID: Well, one thing really nice about Deadwood is that it?s a lot easier to set up things so it compiles in Windows than MaraDNS. It?s a simple as: * Download a program that can decode .7z archives, such as 7-zip (http://7-zip.org ; free software) or WinRAR. * Download deadwood-tcc-2.9.01.7z * Unpack deadwood-tcc-2.9.01.7z using 7-zip or whatever * Open up a command prompt (this has the name ?cmd?) in Windows with start?run??cmd? or the similar equivalent in Vista/Windows 7 * Enter the deadwood-tcc-2.9.01 directory * Type in ?tcc-compile.bat? * A couple of seconds later you will be in the ?src? directory with a freshly compiled Deadwood 2.9.01. OK, that takes a few steps, but it?s a lot less involved than hunting down for MinGW and MSYS (they?re at http://samiam.org/software/ for example, but I don?t broadcast this fact because I?m technically in violation of the GPL by distributing MinGW 3.1.0-1 without its source code) - Sam 2010/7/22 jefsey : > Great! Thank you! > I hope I can work on it all this coming month of august. > Best. > jfc > > At 21:11 22/07/2010, Sam Trenholme wrote: >> >> I have just released Deadwood 2.9.01. ?This is the first release of >> Deadwood with full recursion; in other words, in addition to getting >> information from upstream_servers, Deadwood can now use root_servers >> (if neither upstream_servers nor root_servers are set, Deadwood >> defaults to the ICANN IPv4 root servers). >> >> The release is available here, both as source code and as Windows >> binaries: >> >> http://maradns.org/deadwood/testing/ >> >> This releases fixes a lot of issues people have reported here on the >> list and elsewhere: Deadwood has full IPv6 support. ?This release >> handles CNAMEs correctly and doesn't have the issues MaraDNS 1.x has >> with AAAA records that point to CNAMEs. ?There is a good chance that a >> domain that doesn't resolve with MaraDNS 1.x will resolve with >> Deadwood. >> >> More importantly, I'm willing to listen to bug reports about names not >> resolving again. ?If a given name doesn't resolve in Deadwood 2.9, but >> resolves using another DNS server, I want to know about it. ?I now can >> give people something better than "read >> http://maradns.org/faq.html#resolve and no I won't fix it" when people >> report bugs with MaraDNS' recursive resolver. ?For example, when Ms. >> Maxine Ritter reported a bug with recursive ANY queries, I told her I >> wouldn't fix that. ?Well, that's changed and I have fixed her issue; >> Deadwood 2.9 correctly handles ANY queries. >> >> It has been a long road to get here. I have wanted to rewrite MaraDNS' >> recursive resolver since 2002; I started writing Deadwood in 2007 and >> it's finally feature-complete. >> >> I encourage people to test Deadwood 2.9.01 and report any bugs they >> find. ?Please keep the following in mind: >> >> ? ?* Valgrind-reported memory leaks can always be reported. >> Valgrind-reported errors are only valid if Deadwood is compiled with >> -DVALGRIND_NOERRORS >> >> ? ?* The only officially supported OSes are Windows XP and CentOS 5. >> OS-specific issues such as startup, daemonizing, sysloggin, and >> /etc/resolv.conf setup are only supported on these two OSes. >> >> ? ?* Bugs need to be reported to the MaraDNS list, not to my email >> account nor as blog comments. I hope to have time to set up a web >> forum for MaraDNS/Deadwood support for people not comfortable with >> mailing lists, but no promises. >> >> - Sam >> >> Note: I do not answer MaraDNS (including Deadwood) support requests >> sent by private email without being compensated for my time. A MaraDNS >> support request is any and all discussion you may wish to have about >> MaraDNS in private email; if you want to email me to talk about >> MaraDNS then, yes, that is a support request. I will discuss rates if >> you want this kind of support. Thank you for your understanding. >> >> MaraDNS security vulnerability reports, however, will be dealt with >> without charge and kept confidential. If you don't know what Bugtraq >> is, then, no, your email is not a security report. It is not a >> security report unless you've done due diligence to determine how the >> security bug you think you found can reasonably be exploited. > > From sysadmin at mrgnetwork.com.br Thu Jul 22 22:24:48 2010 From: sysadmin at mrgnetwork.com.br (Marlon) Date: Thu, 22 Jul 2010 23:24:48 -0300 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: (sfid-H20100722-155952-+033.21-1@spamfilter.osbf.lua) References: (sfid-H20100722-155952-+033.21-1@spamfilter.osbf.lua) Message-ID: <4C48FD70.4010009@mrgnetwork.com.br> Sounds good. this release has the feature "nothere = IP" for nxdomain redirection ? Regards, Marlon On 07/22/10 16:11, Sam Trenholme wrote: > I have just released Deadwood 2.9.01. This is the first release of > Deadwood with full recursion; in other words, in addition to getting > information from upstream_servers, Deadwood can now use root_servers > (if neither upstream_servers nor root_servers are set, Deadwood > defaults to the ICANN IPv4 root servers). > > The release is available here, both as source code and as Windows binaries: > > http://maradns.org/deadwood/testing/ > > This releases fixes a lot of issues people have reported here on the > list and elsewhere: Deadwood has full IPv6 support. This release > handles CNAMEs correctly and doesn?t have the issues MaraDNS 1.x has > with AAAA records that point to CNAMEs. There is a good chance that a > domain that doesn?t resolve with MaraDNS 1.x will resolve with > Deadwood. > > More importantly, I?m willing to listen to bug reports about names not > resolving again. If a given name doesn?t resolve in Deadwood 2.9, but > resolves using another DNS server, I want to know about it. I now can > give people something better than ?read > http://maradns.org/faq.html#resolve and no I won?t fix it? when people > report bugs with MaraDNS? recursive resolver. For example, when Ms. > Maxine Ritter reported a bug with recursive ANY queries, I told her I > wouldn?t fix that. Well, that?s changed and I have fixed her issue; > Deadwood 2.9 correctly handles ANY queries. > > It has been a long road to get here. I have wanted to rewrite MaraDNS? > recursive resolver since 2002; I started writing Deadwood in 2007 and > it?s finally feature-complete. > > I encourage people to test Deadwood 2.9.01 and report any bugs they > find. Please keep the following in mind: > > * Valgrind-reported memory leaks can always be reported. > Valgrind-reported errors are only valid if Deadwood is compiled with > -DVALGRIND_NOERRORS > > * The only officially supported OSes are Windows XP and CentOS 5. > OS-specific issues such as startup, daemonizing, sysloggin, and > /etc/resolv.conf setup are only supported on these two OSes. > > * Bugs need to be reported to the MaraDNS list, not to my email > account nor as blog comments. I hope to have time to set up a web > forum for MaraDNS/Deadwood support for people not comfortable with > mailing lists, but no promises. > > - Sam > > Note: I do not answer MaraDNS (including Deadwood) support requests > sent by private email without being compensated for my time. A MaraDNS > support request is any and all discussion you may wish to have about > MaraDNS in private email; if you want to email me to talk about > MaraDNS then, yes, that is a support request. I will discuss rates if > you want this kind of support. Thank you for your understanding. > > MaraDNS security vulnerability reports, however, will be dealt with > without charge and kept confidential. If you don't know what Bugtraq > is, then, no, your email is not a security report. It is not a > security report unless you've done due diligence to determine how the > security bug you think you found can reasonably be exploited. > > From strenholme.usenet at gmail.com Thu Jul 22 23:42:41 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 22 Jul 2010 20:42:41 -0700 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: <4C48FD70.4010009@mrgnetwork.com.br> References: <4C48FD70.4010009@mrgnetwork.com.br> Message-ID: > this release has the feature "nothere = IP" for nxdomain redirection ? Actually, Deadwood has the opposite of NXDOMAIN redirection: ip_blacklist, which will create a synthetic ?NXDOMAIN? if a blacklisted IP (such as a spammer or the IP given when a NXDOMAIN is redirected) is seen. I haven?t implemented notthere_ip for the simple reason that no one has offered to pay me to implement that (XeroBank paid me to implement it for MaraDNS 1.x). My opinion of NXDOMAIN redirection is that it?s a feature end users usually do not want; my target audience when developing Deadwood was an open-source enthusiast installing it on their embedded 32-bit router (perhaps with OpenWRT) or as a lightweight server on one?s 32-bit or 64-bit personal computer. I am, of course, perfectly willing to add notthere_ip support to Deadwood if an ISP is making advertising revenue from it, and lets me have a cut of said revenue. Open source ideals are nice, but I have a wife today and have to figure out a way to pay the bills for the two of us. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Fri Jul 23 00:27:39 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 22 Jul 2010 21:27:39 -0700 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: References: <7.0.1.0.2.20100722223249.05e64810@jefsey.com> Message-ID: > I?m technically in violation of the GPL by distributing MinGW 3.1.0-1 > without its source code. OK, I?ve fixed it. I couldn?t find the source code to MinGW 3.1.0 anywhere, so I updated to MinGW 3.4.2 which is available, along with source code, at ftp://ftp.trolltech.com/misc/ This is actually a little better for compiling Deadwood and MaraDNS, since it makes slightly smaller binaries: Deadwood 2.9.01 is 63,488 bytes in size when it was compiled with MinGW 3.1.0, but 62,976 bytes in size when compiled with MinGW 3.4.2. - Sam From strenholme.usenet at gmail.com Fri Jul 23 03:53:02 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 23 Jul 2010 00:53:02 -0700 Subject: NS answer instead of SOA Message-ID: >Question #2? I set all zones in single config file. >How can I make second SOA record works? http://maradns.org/tutorial/authoritative.html Each zone gets its own file. All the names that end in example.com are in a different file than all the names that end in example.org. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From eminakbulut at gmail.com Fri Jul 23 04:22:54 2010 From: eminakbulut at gmail.com (Emin Akbulut) Date: Fri, 23 Jul 2010 11:22:54 +0300 Subject: NS answer instead of SOA In-Reply-To: References: Message-ID: Yeah, I've used csv2["*"] = "_dns.config" until discovered that : ) It was very simple to manage... I prefer single file for all zones. On Fri, Jul 23, 2010 at 10:53 AM, Sam Trenholme wrote: > >Question #2? I set all zones in single config file. > >How can I make second SOA record works? > > http://maradns.org/tutorial/authoritative.html > > Each zone gets its own file. All the names that end in example.com > are in a different file than all the names that end in example.org. > > - Sam > > Note: I do not answer MaraDNS (including Deadwood) support requests > sent by private email without being compensated for my time. A MaraDNS > support request is any and all discussion you may wish to have about > MaraDNS in private email; if you want to email me to talk about > MaraDNS then, yes, that is a support request. I will discuss rates if > you want this kind of support. Thank you for your understanding. > > MaraDNS security vulnerability reports, however, will be dealt with > without charge and kept confidential. If you don't know what Bugtraq > is, then, no, your email is not a security report. It is not a > security report unless you've done due diligence to determine how the > security bug you think you found can reasonably be exploited. > From strenholme.usenet at gmail.com Fri Jul 23 04:34:21 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 23 Jul 2010 01:34:21 -0700 Subject: NS answer instead of SOA In-Reply-To: References: Message-ID: > csv2["*"] = "_dns.config" It?s amazing how people keep trying to put * in zone names. I explicitly added code to MaraDNS 1.4 to not permit it; for technical reasons I can?t blacklist a "*" by itself but, I assure you, having the zone have the name "*" doesn?t do what some people think it does. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From spamcatch-maradns.org at messageme.de Fri Jul 23 08:32:32 2010 From: spamcatch-maradns.org at messageme.de (=?UTF-8?B?U2ViYXN0aWFuIE3DvGxsZXI=?=) Date: Fri, 23 Jul 2010 14:32:32 +0200 Subject: Deadwood beta on debian lenny Message-ID: <4C498BE0.7010403@messageme.de> Hi, someone out there already tried to get deadwood running on debian? On my 64-bit lenny, it is listening, but not responding to any request. Sebastian From strenholme.usenet at gmail.com Fri Jul 23 14:06:39 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 23 Jul 2010 11:06:39 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: <4C498BE0.7010403@messageme.de> References: <4C498BE0.7010403@messageme.de> Message-ID: > someone out there already tried to get deadwood running on debian? > On my 64-bit lenny, it is listening, but not responding to any request. Well, I don?t use Debian (I use CentOS 5), but I did run a huge battery of regression tests, both in a 32-bit VMware virtual machine and in a native 64-bit CentOS 5 environment. The tests right now by and large only test upstream_servers, but there is one test for root_servers. Anyway, here is the setup that works for me. In one window: $ ? cat /etc/dwood3rc bind_address="127.0.0.1" recursive_acl="127.0.0.1/8" chroot_dir="/etc/deadwood" $ ? ls -a /etc/deadwood/ . .. $ ? ls -ld /etc/deadwood/ drwxr-xr-x 2 root root 4096 Jun 29 00:26 /etc/deadwood/ $ ? sudo ./Deadwood Deadwood version 2.9.01 Deadwood: A DNS UDP non-recursive cache (IPv4-only) We bound to 1 addresses Using default ICANN root servers: 198.41.0.4,192.228.79.201,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,199.7.83.42,202.12.27.33 reset_rem DwRecurse 1941 0 reset_rem DwRecurse 1941 2 reset_rem DwRecurse 1941 1 reset_rem DwRecurse 1941 3 reset_rem DwRecurse 1941 4 And in another window, let?s try resolving some names: >> A simple hostname to resolve; indeed the first hostname I got to recursively resolve a couple of months ago << $ ? askmara Awww.google.com. # Querying the server with the IP 127.0.0.1 # Question: Awww.google.com. www.google.com. +300 cname www.l.google.com. #www.l.google.com. +300 a 66.102.7.104 #www.l.google.com. +300 a 66.102.7.99 # NS replies: # AR replies: >> A slightly more complicated hostname to resolve that requires glueless NS support to resolve << $ ? askmara Asamiam.org. # Querying the server with the IP 127.0.0.1 # Question: Asamiam.org. samiam.org. +86400 a 209.172.32.214 # NS replies: # AR replies: >> This one is very tough to resolve. Not only are there a number of complicated CNAME paths to follow, not to mention glueless NS chains to chase down and solve, but two of the three kintera.org nameservers are down << $ ? askmara Awww.gbod.org. # Querying the server with the IP 127.0.0.1 # Remote server said: SERVER FAILURE # Question: Awww.gbod.org. # NS replies: # AR replies: >> OK, we didn't succeed the first time. However, we finally get this domain to resolve the second time we try. This particular domain name didn't resolve with Deadwood until yesterday << $ ? askmara Awww.gbod.org. # Querying the server with the IP 127.0.0.1 # Question: Awww.gbod.org. www.gbod.org. +3600 cname unitedmethodist.kintera.org. #unitedmethodist.kintera.org. +3600 cname kinteracust.kintera.org. #kinteracust.kintera.org. +3600 cname www.kintera.org.edgekey.net. #www.kintera.org.edgekey.net. +3600 cname e1291.b.akamaiedge.net. #e1291.b.akamaiedge.net. +3600 a 96.17.213.103 # NS replies: # AR replies: So, that in mind: * Use the above /etc/dwood3rc * Make sure there is an empty directory called /etc/deadwood/ owned by root * Don?t try daemonizing Deadwood; just run it from the command line (I?m in the deadwood-2.9.01/src directory above and ran a ?make -f Makefile.centos5? to compile Deadwood before the ?sudo ./Deadwood?) * See if things work by using dig or askmara to resolve various common domains, or by having an /etc/resolv.conf with the line ?nameserver 192.168.189.2? in it Keep in mind this is a beta-test release. Please post any bug reports of domains not resolving at all, domains resolving differently than they do in BIND/dnscache/PowerDNS recursor/Unbound/whatever, Valgrind memory leak reports, crashes (with stack traces or repeatable recipes to reproduce please), or what not here on the mailing list. The program is feature-complete, so I am not interested in feature requests, only in bug reports. Feature requests will be responded to by requests for money and/or patches. For an explanation for why I work like this, read this blog from former Samba developer Gerry Carter: http://www.plainjoe.org/blog/?p=11 ?There is a time in the development cycle to fix bugs, and there is a time to focus on pushing features forward [...] as a general rule the bug fix phase and the feature work phase should be partitioned into separate cycles.? - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Fri Jul 23 14:08:07 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 23 Jul 2010 11:08:07 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: References: <4C498BE0.7010403@messageme.de> Message-ID: > * See if things work by using dig or askmara to resolve various common > domains, or by having an /etc/resolv.conf with the line ?nameserver > 192.168.189.2? in it I meant having the following /etc/resolv.conf: nameserver 127.0.0.1 - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From spamcatch-maradns.org at messageme.de Fri Jul 23 20:23:24 2010 From: spamcatch-maradns.org at messageme.de (=?UTF-8?B?U2ViYXN0aWFuIE3DvGxsZXI=?=) Date: Sat, 24 Jul 2010 02:23:24 +0200 Subject: Deadwood beta on debian lenny In-Reply-To: References: <4C498BE0.7010403@messageme.de> Message-ID: <4C4A327C.3080402@messageme.de> Am 23.07.2010 20:06, schrieb Sam Trenholme: >> ... I found the failure. Using recursive_acl = "127.0.0.1/8" everything is working. When I change recursive_acl and re-use this part of mararc, ipv4_alias["localhost"] = "127.0.0.0/8" ipv4_alias["kabelbw-RIPE"] = "78.42.0.0/15,82.212.0.0/18,85.216.0.0/17,91.89.0.0/16,95.208.0.0/16,109.192.0.0/15,217.8.48.0/20" recursive_acl = "localhost,kabelbw-RIPE" # dig @127.0.0.1 google.com ; <<>> DiG 9.6-ESV-R1 <<>> @127.0.0.1 google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached From strenholme.usenet at gmail.com Fri Jul 23 22:18:50 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Fri, 23 Jul 2010 19:18:50 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: <4C4A327C.3080402@messageme.de> References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> Message-ID: > Using recursive_acl = "127.0.0.1/8" everything is working. > When I change recursive_acl and re-use this part of mararc, > > ipv4_alias["localhost"] = "127.0.0.0/8" > ipv4_alias["kabelbw-RIPE"] = > "78.42.0.0/15,82.212.0.0/18,85.216.0.0/17,91.89.0.0/16,95.208.0.0/16,109.192.0.0/15,217.8.48.0/20" > recursive_acl = "localhost,kabelbw-RIPE" [it stops working] Unfortunately, Deadwood does not support the ipv4_alias mararc variable. When I did the rewrite, this particular variable did not become a part of the Deadwood parser. Thank you very much for the report. One of the things that does need updating is the documentation; the Deadwood *code* is feature complete. The Deadwood *documentation*, however, needs to be updated. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From sysadmin at mrgnetwork.com.br Fri Jul 23 22:34:02 2010 From: sysadmin at mrgnetwork.com.br (Marlon) Date: Fri, 23 Jul 2010 23:34:02 -0300 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: (sfid-H20100723-003057-+037.42-1@spamfilter.osbf.lua) References: <4C48FD70.4010009@mrgnetwork.com.br> (sfid-H20100723-003057-+037.42-1@spamfilter.osbf.lua) Message-ID: <4C4A511A.6050409@mrgnetwork.com.br> Hi, On INSTALL.TXT file of Deadwood 2.9.01 tarball on the system start-up scripts example, the line: killall DwMain should be: killall duende Please, see attached the files: Makefile.icc # build duende with ICC compiler Makefile.funtoo.icc # build deadwood with ICC compiler Regards, Marlon -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Makefile.funtoo_icc URL: From strenholme.usenet at gmail.com Sat Jul 24 03:51:16 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 24 Jul 2010 00:51:16 -0700 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: <4C4A511A.6050409@mrgnetwork.com.br> References: <4C48FD70.4010009@mrgnetwork.com.br> <4C4A511A.6050409@mrgnetwork.com.br> Message-ID: > On INSTALL.TXT file of Deadwood 2.9.01 tarball on the ?system start-up > scripts example, the line: > > ? ? ? ?killall DwMain > > should be: > > ? ? ? ?killall duende > Fixed: http://www.maradns.org/deadwood/snap/deadwood-H-20100723-1.tar.bz2 Or, for just the patch: http://www.maradns.org/deadwood/patches/deadwood-2.9.01-DwMain.patch > Please, see attached the files: > > Makefile.icc ? ? ? ? ? ? ? ? ? ?# build duende with ICC compiler > Makefile.funtoo.icc ? ? ? ?# build deadwood with ICC compiler I only got the Makefile.funtoo_icc file; I see it is very similar to the Makefile.centos5 file included with Deadwood. I presume these are Makefiles for Intel's C compiler (ICC). Any information about the Makefile and what it can be used for is good. I also assume the changes to the Makefile are licensed under Deadwood's license. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From sysadmin at mrgnetwork.com.br Sat Jul 24 09:21:55 2010 From: sysadmin at mrgnetwork.com.br (Marlon) Date: Sat, 24 Jul 2010 10:21:55 -0300 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: (sfid-H20100724-043914-+047.31-1@spamfilter.osbf.lua) References: <4C48FD70.4010009@mrgnetwork.com.br> <4C4A511A.6050409@mrgnetwork.com.br> (sfid-H20100724-043914-+047.31-1@spamfilter.osbf.lua) Message-ID: <4C4AE8F3.5060108@mrgnetwork.com.br> > I only got the Makefile.funtoo_icc file; I see it is very similar to > the Makefile.centos5 file included with Deadwood. I presume these are > Makefiles for Intel's C compiler (ICC). Any information about the > Makefile and what it can be used for is good. The only diference from Makefile.centos5 are the lines: export CC="icc" export FLAGS=${ICCCFLAGS} so, who has the Intel's C compiler (ICC) installed, can compile Deadwood running: makef -f Makefile.funtoo_icc > I also assume the > changes to the Makefile are licensed under Deadwood's license. > Sure. No problem. Regards, Marlon From spamcatch-maradns.org at messageme.de Sat Jul 24 17:11:12 2010 From: spamcatch-maradns.org at messageme.de (=?UTF-8?B?U2ViYXN0aWFuIE3DvGxsZXI=?=) Date: Sat, 24 Jul 2010 23:11:12 +0200 Subject: Deadwood beta on debian lenny In-Reply-To: References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> Message-ID: <4C4B56F0.2010800@messageme.de> Am 24.07.2010 04:18, schrieb Sam Trenholme: >> ... Another question, is verbose_level no longer working? First, I wrote verbose_level = 9 in the config. # /usr/local/bin/Deadwood Deadwood version 2.9.01 Deadwood: A DNS UDP non-recursive cache (IPv4-only) Verbose_level set to 9 We bound to 2 addresses Using default ICANN root servers: 198.41.0.4,192.228.79.201,192.33.4.12,128.8.10.90,192.203.230.10,192.5.5.241,192.112.36.4,128.63.2.53,192.36.148.17,192.58.128.30,193.0.14.129,199.7.83.42,202.12.27.33 then I went to different websites The only output done by deadwood is: reset_rem DwRecurse 1941 0 reset_rem DwRecurse 1941 1 reset_rem DwRecurse 1941 1 reset_rem DwRecurse 1941 2 reset_rem DwRecurse 1941 3 reset_rem DwRecurse 1941 2 reset_rem DwRecurse 1941 5 reset_rem DwRecurse 1941 4 reset_rem DwRecurse 1941 3 reset_rem DwRecurse 1941 0 reset_rem DwRecurse 1941 1 reset_rem DwRecurse 1941 0 reset_rem DwRecurse 1941 1 reset_rem DwRecurse 1941 2 reset_rem DwRecurse 1941 1 reset_rem DwRecurse 1941 7 reset_rem DwRecurse 1941 1 reset_rem DwRecurse 1941 6 I wonder that queries are no longer displayed using a high verbose_level. Another thing. When /etc/deadwood/ is owned by root (as you suggested), deadwood is not able to access dw_cache until you create it by hand and chown to the deadwood user manually. Wouldn't it be better to create a dw_cache(and chown/chgrp) by deadwood if none exists, before droping root? Cheers, Sebastian From strenholme.usenet at gmail.com Sun Jul 25 05:34:20 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sun, 25 Jul 2010 02:34:20 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: <4C4B56F0.2010800@messageme.de> References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> Message-ID: > Another question, is verbose_level no longer working? It works but the messages various verbose levels show is completely different from what MaraDNS does with verbose_level. To see all DNS queries, one needs a query level of 100. > reset_rem DwRecurse 1941 0 This is a debug message when tracking down a problem which I neglected to remove from the beta-test release of Deadwood. The next release will not have this spurious message. > Another thing. > When /etc/deadwood/ is owned by root (as you suggested), deadwood is not > able to access dw_cache until you create it by hand and chown to the > deadwood user manually. I need to document this. Like I said, the code is done; there are a lot of holes in the documentation. > Wouldn't it be better to create a dw_cache(and > chown/chgrp) by deadwood if none exists, before droping root? I like to do as little as possible before dropping root; anything done as root gives an attack complete control of the system should there ever be a security problem in the code. Anything done as "nobody" only gives an attacker very limited access to the system (being an unprivileged user trapped in a chroot jail). As an aside, I really ought to put Deadwood in a sandbox on Windows. The reason I haven?t is plain simply because I?ve been programming for Linux more than I?ve programmed for Windows, and haven?t taken the time to learn how to sandbox things in Windows. As another example of this, users currently have to make their own entropy source in Windows, since I didn?t learn, until very recently, about Windows version of /dev/random: CryptGenRandom(). Thanks a lot for your questions and feedback! - Sam From spamcatch-maradns.org at messageme.de Sun Jul 25 13:41:42 2010 From: spamcatch-maradns.org at messageme.de (=?UTF-8?B?U2ViYXN0aWFuIE3DvGxsZXI=?=) Date: Sun, 25 Jul 2010 19:41:42 +0200 Subject: Deadwood beta on debian lenny In-Reply-To: References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> Message-ID: <4C4C7756.80403@messageme.de> Am 25.07.2010 11:34, schrieb Sam Trenholme: >> Another question, is verbose_level no longer working? > > It works but the messages various verbose levels show is completely > different from what MaraDNS does with verbose_level. > > To see all DNS queries, one needs a query level of 100. Thanks for the hint. It's working now. It seems like recursive_acl is limited to 6 nets and got some kind of overflow (/bad looping?!). First of all, my current dwood3rc: > bind_address="127.0.0.1,85.93.18.63" > tcp_listen = 1 > chroot_dir = "/etc/deadwood" > recursive_acl = "127.0.0.1/8,78.42.0.0/15,82.212.0.0/18,85.216.0.0/17,91.89.0.0/16,95.208.0.0/16,109.192.0.0/15,217.8.48.0/20" > verbose_level = 100 > maxprocs = 8 > handle_overload = 1 > maradns_uid = 110 > maradns_gid = 114 > maximum_cache_elements = 60000 > cache_file = "dw_cache" > resurrections = 1 As you can see, I am currently using 8 nets. I am unable to do full testing since my girlfriend wants a working LAN. on the local machine: > # dig @127.0.0.1 google.de > ; <<>> DiG 9.6-ESV-R1 <<>> @127.0.0.1 google.de > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached using a pc on net 109.192.0.0/15: > $ dig @85.93.18.63 google.de > ; <<>> DiG 9.7.0-P1 <<>> @85.93.18.63 google.de > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35547 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;google.de. IN A > > ;; ANSWER SECTION: > google.de. 289 IN A 74.125.43.103 > google.de. 289 IN A 74.125.43.147 > google.de. 289 IN A 74.125.43.106 > google.de. 289 IN A 74.125.43.105 > google.de. 289 IN A 74.125.43.104 > google.de. 289 IN A 74.125.43.99 > > ;; Query time: 12 msec > ;; SERVER: 85.93.18.63#53(85.93.18.63) > ;; WHEN: Sun Jul 25 19:17:28 2010 > ;; MSG SIZE rcvd: 123 When I change recursive_acl to fit 6 nets: > recursive_acl = "127.0.0.1/8,82.212.0.0/18,85.216.0.0/17,91.89.0.0/16,95.208.0.0/16,109.192.0.0/15" and restart deadwood, dig resolves on localhost. . > # dig @127.0.0.1 google.de > ; <<>> DiG 9.6-ESV-R1 <<>> @127.0.0.1 google.de > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18299 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;google.de. IN A > ;; ANSWER SECTION: > google.de. 293 IN A 74.125.43.103 > google.de. 293 IN A 74.125.43.99 > google.de. 293 IN A 74.125.43.106 > google.de. 293 IN A 74.125.43.147 > google.de. 293 IN A 74.125.43.105 > google.de. 293 IN A 74.125.43.104 > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sun Jul 25 19:28:35 2010 > ;; MSG SIZE rcvd: 123 From strenholme.usenet at gmail.com Sun Jul 25 16:06:22 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sun, 25 Jul 2010 13:06:22 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: <4C4C7756.80403@messageme.de> References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> <4C4C7756.80403@messageme.de> Message-ID: > It seems like recursive_acl is limited to 6 nets and got some kind of > overflow (/bad looping?!). > As you can see, I am currently using 8 nets. > I am unable to do full testing since my girlfriend wants a working LAN. > When I change recursive_acl to fit 6 nets [it works] Thank you very much for the detailed bug report. The issue is that Deadwood only supports seven nets. This, however, can easily be changed; the number in question is ?DW_MAXIPS? and it?s on line 88 of the file ?DwSocket.h?. I will make this limit 128 for the next snapshot of Deadwood. - Sam From spamcatch-maradns.org at messageme.de Sun Jul 25 17:33:05 2010 From: spamcatch-maradns.org at messageme.de (=?UTF-8?B?U2ViYXN0aWFuIE3DvGxsZXI=?=) Date: Sun, 25 Jul 2010 23:33:05 +0200 Subject: Deadwood beta on debian lenny In-Reply-To: References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> <4C4C7756.80403@messageme.de> Message-ID: <4C4CAD91.8020204@messageme.de> Am 25.07.2010 22:06, schrieb Sam Trenholme: >> It seems like recursive_acl is limited to 6 nets and got some kind of >> overflow (/bad looping?!). > >> As you can see, I am currently using 8 nets. >> I am unable to do full testing since my girlfriend wants a working LAN. > >> When I change recursive_acl to fit 6 nets [it works] > > The issue is that Deadwood only supports seven nets. Yeah, thats what's written in DwSocket.h line 88. #define DW_MAXIPS 7 and DwSocket.c in line 42 I found ip_mask_T recursive_acl[DW_MAXIPS + 1]; nevertheless with, recursive_acl = "127.0.0.1/8,82.212.0.0/18,85.216.0.0/17,91.89.0.0/16,95.208.0.0/16,109.192.0.0/15,217.8.48.0/20" (7 nets) it is not working to resolve domains for 127.0.0.1/8. Only with six nets, it is. > I will make this limit 128 for the next snapshot of Deadwood. Thats a handy value. From strenholme.usenet at gmail.com Mon Jul 26 01:21:36 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sun, 25 Jul 2010 22:21:36 -0700 Subject: Deadwood 2.9.01 released: Recursion is ready for beta testing In-Reply-To: <4C4AE8F3.5060108@mrgnetwork.com.br> References: <4C48FD70.4010009@mrgnetwork.com.br> <4C4A511A.6050409@mrgnetwork.com.br> <4C4AE8F3.5060108@mrgnetwork.com.br> Message-ID: > makef -f Makefile.funtoo_icc Is there any reason why I can't just call it "Makefile.icc"? >> ? I also assume the >> changes to the Makefile are licensed under Deadwood's license. >> > > Sure. No problem. Thanks for the permission. - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Mon Jul 26 02:07:27 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sun, 25 Jul 2010 23:07:27 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: <4C4CAD91.8020204@messageme.de> References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> <4C4C7756.80403@messageme.de> <4C4CAD91.8020204@messageme.de> Message-ID: >> I will make this limit 128 for the next snapshot of Deadwood. > Thats a handy value. OK, done. DW_MAXIPS is now 128. I?ve also updated the documentation to more fully describe root_servers in the Deadwood man page and to explain some of the information I have shared in this thread in the Deadwood FAQ, as well as removing the spurious debug message that pops up in logs. It can be downloaded here: http://maradns.org/deadwood/snap/deadwood-H-20100725-1.tar.bz2 Patches (against Deadwood 2.9.01) can be seen here: http://maradns.org/deadwood/patches/ - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From spamcatch-maradns.org at messageme.de Mon Jul 26 07:58:49 2010 From: spamcatch-maradns.org at messageme.de (=?UTF-8?B?U2ViYXN0aWFuIE3DvGxsZXI=?=) Date: Mon, 26 Jul 2010 13:58:49 +0200 Subject: Deadwood beta on debian lenny In-Reply-To: References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> <4C4C7756.80403@messageme.de> <4C4CAD91.8020204@messageme.de> Message-ID: <4C4D7879.5030907@messageme.de> Am 26.07.2010 08:07, schrieb Sam Trenholme: Using: > http://maradns.org/deadwood/snap/deadwood-H-20100725-1.tar.bz2 Hi Sam, it's me again. ;) I tested how dnsmasq(resolver) and deadwood are playing together. I experience some timeouts. They happen only for the first(/uncached) request using deadwood and are not happening when using maradns. I used dig on Linux, nslookup on Linux and nslookup on Windows to generate these messages: From strenholme.usenet at gmail.com Mon Jul 26 13:40:44 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Mon, 26 Jul 2010 10:40:44 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: <4C4D7879.5030907@messageme.de> References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> <4C4C7756.80403@messageme.de> <4C4CAD91.8020204@messageme.de> <4C4D7879.5030907@messageme.de> Message-ID: >> Got DNS query for \013volltreffer\002de\000\000\001 >> Got DNS query for \007clubber\002de\000\000\001 >> Got DNS query for \007mueller\002de\000\000\001 Looks to be an issue with getting an AAAA record for volltreffer.de, clubber.de, and mueller.de In all three cases, I can get an A record, but Deadwood gives me a "server fail" when I try to get the AAAA record (which doesn't exist for any of these names, but Deadwood should still cache and forward the "that doesn't exist" DNS reply). One workaround for names like this (A OK, AAAA having problems) is to add the following line to /etc/dwood3rc: reject_aaaa = 1 This will automatically return a synthetic "this host does not exist" reply to any and all AAAA queries. Of course, this isn't a good idea for anyone actually using IPv6, but it's a reasonable workaround until I can fix the Deadwood code. >> C:\>nslookup mueller.de nslookup is really an outdated tool. I prefer "dig" myself, or my own (very simple) Askmara tool. Dig in use: dig mueller.de or dig @127.0.0.1 mueller.de or dig mueller.de AAAA - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From rick at linuxmafia.com Mon Jul 26 15:43:22 2010 From: rick at linuxmafia.com (Rick Moen) Date: Mon, 26 Jul 2010 12:43:22 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: References: <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> <4C4C7756.80403@messageme.de> <4C4CAD91.8020204@messageme.de> <4C4D7879.5030907@messageme.de> Message-ID: <20100726194322.GT22299@linuxmafia.com> Quoting Sam Trenholme (strenholme.usenet at gmail.com): > nslookup is really an outdated tool. And buggy. http://homepages.tesco.net/J.deBoynePollard/FGA/nslookup-flaws.html Apparently its widespread use, still, among MS-Windows users owed primarily to the fact that nslookup.exe is included in the OS. Quoting a private wiki page I maintain on the subject: Please download, install, and use Dig for Windows (http://members.shaw.ca/nicholas.fong/dig/), instead. (The package also comes with "whois.exe", a useful tool for querying who is responsible for and owns an Internet domain; and "host.exe", another utility for performing DNS lookups similar to "dig.exe", except simpler.) Unpack all files including *.dll to the desired directory, e.g., C:\Dig. Alternatively, to get the very latest package of dig.exe, host.exe, and whois.exe, directly from the publisher Internet Software Consortium: (1) Visit http://www.isc.org/software/bind, and note the current production release of BIND9. (2) Visit ftp://ftp.isc.org/isc/bind9 and pick that release's subdirectory. The .Zip archive in that subdirectory, about 5 MB, will include dig, host, whois, and the support *.dll files, along with things you probably won't want such as the MS-Windows version of the BIND9 DNS daemon, which you can discard. From strenholme.usenet at gmail.com Wed Jul 28 15:43:58 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 28 Jul 2010 12:43:58 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: <4C4D7879.5030907@messageme.de> References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> <4C4C7756.80403@messageme.de> <4C4CAD91.8020204@messageme.de> <4C4D7879.5030907@messageme.de> Message-ID: > I experience some timeouts. They happen only for the first(/uncached) > request using deadwood and are not happening when using maradns. Fixed. The issue was that I was performing bailiwick checks on the SOA record in the NS section of a "not there" reply; I only should be doing a bailiwick check for NS referrals, not SOA "not there" replies. The following patch fixes this issue by making it so SOA records are always considered to be "in bailiwick": http://maradns.org/deadwood/patches/deadwood-2.9.01-show_not_there.patch However, I?m thinking it may be better to verify that we always store ?not there? replies in the same location as the original query (I?m pretty sure Deadwood already does this, but I have to look at the code again to make sure) and to not perform a bailiwick check for ?not there? replies at all. However, life calls. It looks like I will finally get to meet in person Kai Hendry today, who has maintained the Debian package for MaraDNS for many years. In the meantime, people can download a Deadwood tarball with the above patch here: http://maradns.org/deadwood/snap/deadwood-H-20100728-1.tar.bz2 Which is GPG signed with MaraDNS? signing key: http://maradns.org/deadwood/snap/deadwood-H-20100728-1.tar.bz2.asc - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you?ve done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Wed Jul 28 19:07:14 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 28 Jul 2010 16:07:14 -0700 Subject: Deadwood beta on debian lenny In-Reply-To: References: <4C498BE0.7010403@messageme.de> <4C4A327C.3080402@messageme.de> <4C4B56F0.2010800@messageme.de> <4C4C7756.80403@messageme.de> <4C4CAD91.8020204@messageme.de> <4C4D7879.5030907@messageme.de> Message-ID: > However, I?m thinking it may be better to verify that we always store > ?not there? replies in the same location as the original query (I?m > pretty sure Deadwood already does this, but I have to look at the code > again to make sure) and to not perform a bailiwick check for ?not > there? replies at all. OK, I?ve done this. I have verified that ?not there? replies are always stored in the cache with the same name as the original DNS query. Here is the relevant code around line 2051 of DwRecurse.c: if(type == TYPE_ANSWER || type == TYPE_NXDOMAIN || type == TYPE_NOT_THERE) { dw_log_dwstr("Caching direct answer at ",query,100); dwh_add(cache,query,action,ttl,1); ret = 1; goto catch_dwx_cache_reply; } The ?type? is the type of answer we get; a NXDOMAIN is different from a ?NOT THERE? because a NXDOMAIN tells us there is no record of any type for the query we ask; a ?NOT THERE? tells us there are other records with the same name. TYPE_ANSWER is a direct answer to our question (such as the IP for ?maria-jose.kabah.foo?) The ?dwh_add()? call adds the answer to the cache; ?cache? is the DNS cache; ?query? is the original DNS question; ?action? is the data we put in the cache; ?ttl? is the TTL for the record (shortest TTL when we see a CNAME chain); and ?1? is used to indicate that this record will be removed from the cache when the cache is full and we need to flush records not recently accessed. This code only will cache a query in the location the original query was made; it completely stops AR-injection cache poisoning attacks. I have also updated the caching code to not perform bailiwick checks for answers which are not NS referrals (since NS referrals are the only records where we have to be real careful with bailiwick; the location to cache a NS referral depends on how much of the DNS tree the NS referral covers, and we have to make sure a given referral doesn?t control more of the DNS tree than it should be able to control); this will slightly speed up processing of non-NS referrals and resolves the issues Sebastian reported a couple of days ago. The updated patch: http://maradns.org/deadwood/patches/deadwood-2.9.01-show_not_there_2.patch And the updated tarball: http://maradns.org/deadwood/snap/deadwood-H-20100728-2.tar.bz2 With GPG sig: http://maradns.org/deadwood/snap/deadwood-H-20100728-2.tar.bz2.asc - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From andersonaa at gmail.com Wed Jul 28 21:00:06 2010 From: andersonaa at gmail.com (Anderson Alves de Albuquerque) Date: Wed, 28 Jul 2010 22:00:06 -0300 Subject: New user with MaraDNS In-Reply-To: References: Message-ID: I always use Bind. This month I am starting with maradns but I have problem. In this e-mail, I describe one problem. The 10.0.0.0/8 and 172.16.16.0/24 are my internal network. I use maradns to mydomains (prefeitura.mydomain.br and intranet.pu.mydomain.br) I want maradns to recursive dns and authorithative dns. My problem is that I have cname www.prefeitura.mydomain.br to another doamin (b200.nce.otherdomain.br). When my squid transparent search www.prefeitura.mydomain.br in maradns, the browser of the clients receive error of the dns. www.prefeitura.mydomain.br. +86400 cname b200.otherdomain.br. ~ # cat /etc/maradns/mararc ipv4_bind_addresses = "10.0.0.3,127.0.0.1,172.16.16.3" chroot_dir = "/etc/maradns" csv2 = {} csv2["prefeitura.mydomain.br."] = "prefeitura.mydomain.br.db" csv2["pu.mydomain.br."] = "pu.mydomain.br.db" csv2["intranet.pu.mydomain.br."] = "intranet.pu.mydomain.br.db" recursive_acl = "127.0.0.1, 10.0.0.0/8,172.16.16.0/24" no_fingerprint = 0 verbose_level = 3 timeout_seconds = 8 bind_star_handling = 1 # cat /etc/maradns/prefeitura.mydomain.br.db prefeitura.mydomain.br. +86400 soa ns.prefeitura.mydomain.br. noc at pu.mydomain.br. 2010032008 3600 900 604800 86400 ~ prefeitura.mydomain.br. +86400 ns ns.nce.mydomain.br. ~ prefeitura.mydomain.br. +86400 ns ns.mydomain.br. ~ prefeitura.mydomain.br. +86400 ns ns.prefeitura.mydomain.br. ~ prefeitura.mydomain.br. +86400 ns guanabara.rederio.br. ~ prefeitura.mydomain.br. +86400 a 192.164.25.6 ~ fpu.prefeitura.mydomain.br. +86400 a 192.164.25.6 ~ mail.prefeitura.mydomain.br. +86400 cname webmail.prefeitura.mydomain.br. ~ ns.prefeitura.mydomain.br. +86400 cname webmail.prefeitura.mydomain.br. ~ webmail.prefeitura.mydomain.br. +86400 a 192.164.25.4 ~ www.prefeitura.mydomain.br. +86400 cname b200.otherdomain.br. ~ # Second SOA received, exiting If I use nslookup command, I have this: # nslookup www.prefeitura.mydomain.br localhost Server: localhost Address: 127.0.0.1#53 www.prefeitura.mydomain.br canonical name = b200.otherdomain.br. What should I change in files of the configuration? -- [], Anderson Alves de Albuquerque. --------------------------------------------------------------- E-mails: andersonalvesdealbuquerque#hotmail.com (replace # by @) andersonaa#gmail.com (replace # by @) ICQ: 73222660 --------------------------------------------------------------- -- [], Anderson Alves de Albuquerque. --------------------------------------------------------------- E-mails: andersonalvesdealbuquerque#hotmail.com (replace # by @) andersonaa#gmail.com (replace # by @) ICQ: 73222660 --------------------------------------------------------------- From strenholme.usenet at gmail.com Thu Jul 29 01:39:19 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 28 Jul 2010 22:39:19 -0700 Subject: New user with MaraDNS In-Reply-To: References: Message-ID: > ?My problem is that I have cname www.prefeitura.mydomain.br to another > doamin (b200.nce.otherdomain.br). When my squid transparent > search www.prefeitura.mydomain.br in maradns, the browser of the clients > receive error of the dns. > ?What should I change in files of the configuration? You have a dangling CNAME record. This is discussed, along with solutions, here: http://www.maradns.org/tutorial/dangling.html - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Thu Jul 29 15:05:33 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 29 Jul 2010 12:05:33 -0700 Subject: Deadwood 2.9.02 released Message-ID: I had the pleasure, last night, of finally meeting Kai Hendry, who has been in change of MaraDNS for Debian for many years. While we were talking, I was mentioning that Deadwood is feature complete but not fully tested, and asked if he would be up to packaging it up for Debian so we can get some more testing done for it. He told me he would; I told him Deadwood 2.9.02 would be out soon fixing all known Deadwood bugs which he could package up for Debian. But he said it would be best if I could get Deadwood 2.9.02 out the door soon. So, that in mind, Deadwood 2.9.02 has been released today. I got it ready quickly, but this is no rush job. All known bugs are fixed. As far as I know, Deadwood 2.9.02 has no bugs. Zero. Zilch. So it?s up to you all to prove me wrong and find some bugs in Deadwood. Is the documentation not explaining something as well as it should? File it as a bug. Does Deadwood crash in a way that can be reproduced? File it as a bug. If you can?t reproduce the crash nor have a stack trace, I will just assume you?re pulling my chain by pretending Deadwood crashes when it really doesn?t, and mark the bug as ?unreproducible?. Did you find a memory leak using Valgrind or what not? File it as a bug. Note that Valgrind will report errors unless compiled with -DVALGRIND_NOERRORS. To answer your next question, that is because Deadwood uses, as one of its entropy sources, an uninitialized string. How to file a bug: Deadwood is a small enough project that there is no bug tracking system (not having bugs does minimize the need for a bug tracking system :). Bug reports can be reported one, and only one way: By posting to this mailing list. Emails with bug reports will get you the ?give me money or take it to the list? form reply. Blog comments with bug reports will not be approved (I moderate blog comments). So, guys, please download and use Deadwood 2.9.02, to show me that my rather arrogant claim of having no bugs in Deadwood is wrong. It can be downloaded for both CentOS 5 (OK, it should compile in other *NIX systems, but I?m not dealing with your FreeBSD issues or whatever without money coming my way) and Windows XP (as well as Vista and Windows 7) here: http://maradns.org/deadwood/testing/ - Sam Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding. MaraDNS security vulnerability reports, however, will be dealt with without charge and kept confidential. If you don't know what Bugtraq is, then, no, your email is not a security report. It is not a security report unless you've done due diligence to determine how the security bug you think you found can reasonably be exploited. From strenholme.usenet at gmail.com Thu Jul 29 18:40:09 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 29 Jul 2010 15:40:09 -0700 Subject: New Deadwood snapshot: Working around broken CentOS behavior Message-ID: CentOS 5.5 broke select()?s timeout behavior. This caused one of my SQA tests, dwood2rc_n_timeout_seconds, to fail in CentOS 5.5. The workaround was to disable this test after making sure this test ran fine in CentOS 5.4. Since this was caused by CentOS and not by Deadwood, I reported this as a bug: http://bugs.centos.org/view.php?id=4465 I quickly got a reply telling me they won?t fix this issue. That in mind, I have revised this SQA regression test to work, both with older versions of CentOS with a correct timeout for select(), as well as with CentOS 5.5 and its broken select(). The Deadwood snapshot with this revision is here: http://maradns.org/deadwood/snap/deadwood-H-20100729-2.tar.bz2 (also GPG signed, as usual) - Sam From andersonaa at gmail.com Thu Jul 29 19:28:31 2010 From: andersonaa at gmail.com (Anderson Alves de Albuquerque) Date: Thu, 29 Jul 2010 20:28:31 -0300 Subject: New user with MaraDNS In-Reply-To: References: Message-ID: But otherdomain.br is not my domain. The otherdomain.br is in DNS at another person in other company. Normally, in Bind p.ex., I need to have register "cname" to b200.nce. otherdomain.br and I don?t need have register "A" to b200.nce. otherdomain.br . If I put register "A" to b200.nce. otherdomain.br and other administrator change IP, I need manually change too. don?t I have to put register "cname" like Bind? 2010/7/29 Sam Trenholme > > My problem is that I have cname www.prefeitura.mydomain.br to another > > doamin (b200.nce.otherdomain.br). When my squid transparent > > search www.prefeitura.mydomain.br in maradns, the browser of the clients > > receive error of the dns. > > > What should I change in files of the configuration? > > You have a dangling CNAME record. This is discussed, along with > solutions, here: > > http://www.maradns.org/tutorial/dangling.html > > - Sam > > Note: I do not answer MaraDNS (including Deadwood) support requests > sent by private email without being compensated for my time. A MaraDNS > support request is any and all discussion you may wish to have about > MaraDNS in private email; if you want to email me to talk about > MaraDNS then, yes, that is a support request. I will discuss rates if > you want this kind of support. Thank you for your understanding. > > MaraDNS security vulnerability reports, however, will be dealt with > without charge and kept confidential. If you don't know what Bugtraq > is, then, no, your email is not a security report. It is not a > security report unless you've done due diligence to determine how the > security bug you think you found can reasonably be exploited. > -- [], Anderson Alves de Albuquerque. --------------------------------------------------------------- E-mails: andersonalvesdealbuquerque#hotmail.com (replace # by @) andersonaa#gmail.com (replace # by @) ICQ: 73222660 --------------------------------------------------------------- From strenholme.usenet at gmail.com Fri Jul 30 01:45:19 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 29 Jul 2010 22:45:19 -0700 Subject: New user with MaraDNS In-Reply-To: References: Message-ID: > But otherdomain.br is not my domain. The > otherdomain.br is in DNS at another person > in other company. Yes, I am aware of what you are trying to do. Did you read the ?dangling CNAME? document I pointed you to? http://www.maradns.org/tutorial/dangling.html Yes, yes, I understand. It?s in English. Maybe not your first language. Well, thankfully, it?s also in Brazilian Portuguese (I?m not sure how good the translation it is, but read this): Existem dois casos que podem fazer a mensagem "dangling CNAME" aparecer: * Quando um CNAME aponta para um nome de host externo. * Quando um CNAME possui erros de escrita ou o host que o CNAME aponta est? com erro de escrita. CNAMEs apontando para nomes de host externos As vezes, as pessoas podem desejar ter nomes locais apontando para entradas externas com registros CNAME. Por exemplo, pode ser desej?vel ter o atalho "google" para "www.google.com." Um modo que a pessoa possa desejar fazer isto ?: google.example.com. +86400 CNAME www.google.com. A configura??o padr?o do MaraDNS n?o completar? o registro. Em outras palavras, algumas pessoas podem esperar que o Mara produza o seguinte para "google.example.com": google.example.com. +86400 CNAME www.google.com. www.google.com. +900 A 66.102.7.104 Ao inv?s, Mara simplesmente reproduz: google.example.com. +86400 CNAME www.google.com. Eu chamo isto de um registro "dangling CNAME", j? que o registro CNAME n?o ? resolv?vel por alguns servidores toscos. Para solucionar o dangling CNAME, MaraDNS pode ser configurado desta maneira: * Executarmos dois servidores MaraDNS em dois IPs diferentes. * Por causa deste exemplo, supormos que a pessoa do servidor envie requisi??es para solucionar nomes de hosts que tem o IP 192.168.1.1. Vamos supor mais adiante que h? um servidor que tem o dangling CNAME com o IP 192.168.1.2 * Configure 192.168.1.1 para usar 192.168.1.2 como um servidor upstream usando a vari?vel upstream_servers do mararc. * Configure 192.168.1.2 para ser tanto um servidor autoritativo e recursivo de DNS, e tenha registros de dangling CNAME dentro da metade do autoritativo. Isto resolver? completamente o problema de dangling CNAME; aqui ? o que os dois servidores MaraDNS fazem para solucionar tal registro: 1. Um determinador servidor tosco pergunta para 192.168.1.1 o endere?o de IP para, digamos "google.example.com" 2. 192.168.1.1 pede para 192.168.1.2 o endere?o de IP "google.example.com" 3. 192.168.1.2 diz que 192.168.1.1 "google.example.com ? um CNAME para www.google.com, e eu n?o tenho um IP para isto" 4. 192.168.1.1, vendo que tem um CNAME sem um IP, pede para 192.168.1.2 o IP "www.google.com" 5. 192.168.1.2 recursivamente soluciona o IP para www.google.com, e d? este IP para 192.168.1.1 6. Agora que 192.168.1.1 t?m um registro completo, enviar? este registro ao tosco. Em outras palavras, 192.168.1.1 contar? ao tosco que google.example.com ? um CNAME para www.google.com, e ent?o distribuir? o IP para www.google.com. Aqui ? um exemplo do arquivo mararc para 192.168.1.1: ipv4_bind_addresses = "192.168.1.1" chroot_dir = "/ etc/maradns" recursive_acl = "192.168.1.0/24" upstream_servers = "192.168.1.2" Aqui ? um exemplo do arquivo mararc para 192.168.1.2: ipv4_bind_addresses = "192.168.1.2" chroot_dir = "/ etc/maradns" recursive_acl = "192.168.1.1" csv2 = {} csv2 ["example.com".] = "db.example.com" Se dangling CNAME n?o ? problema para uma determinada configura??o, ou se foi resolivido atrav?s dos exemplos anteriores, as advert?ncias sobre dangling CNAME podem ser desabilitadas adicionando o seguinte num arquivo mararc: no_cname_warnings = 1 Um erro de digita??o pode causar um registro dangling CNAME Um erro de digita??o tamb?m pode causar um registro de dangling CNAME. Por exemplo: www.example.com. CNAME hoost1.example.com. host1.example.com. A 10.1.2.3 Aqui, n?s cometemos um erro no registro CNAME; pretend?amos digitar "host1.example.com" mas digitamos "hoost1.example.com." . N?s tamb?m podemos adquirir um CNAME oscilando deste modo: www.example.com. CNAME host1.example.com. hoost1.example.com. A 10.1.2.3 Ou por um erro no arquivo arquivo mararc: csv2 ["exammple.com".] = "db.example.com" (N?s digitamos exammple.com quando n?s dever?amos ter digitado "example.com") Seguido por um arquivo de zona que se parece: www.example.com. CNAME host1.example.com. host1.% A 10.1.2.3 Desde que o % se expandir? a "exammple.com" em vez de "example.com." Em todos estes casos, os avisos de dangling CNAME desapareceram quando o erro for encontrado e corrigido. From strenholme.usenet at gmail.com Sat Jul 31 04:23:20 2010 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Sat, 31 Jul 2010 01:23:20 -0700 Subject: MaraDNS 1.4.04 released Message-ID: Now that Deadwood is feature-complete, I have released MaraDNS 1.4.04. This is the most current stable release of MaraDNS; if using an older MaraDNS, please update to this release (yes, I ran a bunch of SQA tests so anything that worked before should work in 1.4.04). While the old recursive code is still in place to allow people to slowly make the transition to using Deadwood as their recursive DNS server, Deadwood 2.9.02 is included. The Windows version of MaraDNS has had its documentation updated to encourage people to use Deadwood instead of MaraDNS; I will also start nudging *NIX users along. I have also made a tool for getting entropy from the OS and putting it in a file. This is currently a very simple tool; it makes a random 64-byte file called secret.txt which MaraDNS and Deadwood can use. It acts like a UNIX command: There is no user interface; when it is run, it just silently creates the 64-byte random secret.txt file, overwriting any already existing secret.txt, and only outputting something if something goes wrong. It?s a lot better than the old ?just type in some random text to make secret.txt? directions I have given. I plan on making it a little more friendly (failing if secret.txt already exists, and stating the secret.txt file has been created, and always pausing and having the user hit a key so they know what the program is doing if called from the GUI.) In addition, I fixed the bug with delegation NS records and ANY queries, as well as incorporating a NAPTR bugfix I made a few months ago in to the code. There is a full changelog at maradns.org. It can be looked at here: http://maradns.org/download.html Or here: http://sourceforge.net/projects/maradns