From strenholme.usenet at gmail.com Tue Apr 7 14:56:45 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Tue, 7 Apr 2009 13:56:45 -0500 Subject: Update on Deadwood (MaraDNS rewrite) Message-ID: <7bd685720904071156k52cfd19flbe47385e8f1e8701@mail.gmail.com> Hello, everyone, This is just a quick update to let people know I've been steadily at work on Deadwood, the rewrite of MaraDNS. The UDP part of the code is now a fully functional Windows service when compiled in Windows, and is a very useful little (under 32k little) DNS cache both in CentOS 5 and as a native Windows XP (read: No Cygwin needed) binary. The code has some features MaraDNS doesn't have (resurrections, the ability to write the cache to disk, full Windows service support, non-threaded code) but doesn't have feature parity with MaraDNS yet (TTL again, RR rotation, and recursive DNS resolution). The code base is far cleaner and maintainable than MaraDNS, and much more pleasant to work with. The code seems rock stable to me, but getting more testing would be nice. It can be looked at here: http://www.maradns.org/deadwood I post updates about Deadwood here: http://maradns.blogspot.com/search/label/Deadwood And MaraDNS updates: http://maradns.blogspot.com/search/label/MaraDNS I am slowly but surely making Deadwood a fully functional DNS cache with a lot of features MaraDNS doesn't have. As always, since I am giving this program away under an open-source license, updates are done at my discretion and on my schedule. If you wish to direct MaraDNS/Deadwood development, sponsorship offers are currently being accepted at competitive rates, and patches will be considered. - Sam [You are getting this email because you are subscribed to the MaraDNS mailing list. If you don't want to get further mails like this, unsubscribe from this list.] From alex at digriz.org.uk Tue Apr 7 15:19:18 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Tue, 7 Apr 2009 20:19:18 +0100 Subject: Update on Deadwood (MaraDNS rewrite) References: <7bd685720904071156k52cfd19flbe47385e8f1e8701@mail.gmail.com> Message-ID: Sam Trenholme wrote: > > [snipped] > > The code has some features MaraDNS doesn't have (resurrections, the > ability to write the cache to disk, full Windows service support, > non-threaded code) but doesn't have feature parity with MaraDNS yet > (TTL again, RR rotation, and recursive DNS resolution). > Regarding the 'cache to disk' bit, is it worth it? I would image the latency to use the disk as a cache is roughly in the same order of just making the query to the authoritive DNS server? Now, if you are instead talking about "write the cache to disk on shutdown for sweet and lovely restart", that's a whole different kettle of fish :) Good work never-the-less. Cheers [1] so you don't in effect flush the cache -- Alexander Clouter .sigmonster says: Life is like a simile. From strenholme.usenet at gmail.com Wed Apr 8 01:07:10 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 8 Apr 2009 00:07:10 -0500 Subject: Update on Deadwood (MaraDNS rewrite) In-Reply-To: References: <7bd685720904071156k52cfd19flbe47385e8f1e8701@mail.gmail.com> Message-ID: <7bd685720904072207i44616ed1o58dd9ec00606219@mail.gmail.com> > Regarding the 'cache to disk' bit, is it worth it? ?I would image the > latency to use the disk as a cache is roughly in the same order of just > making the query to the authoritive DNS server? Actually, Deadwood doesn't do that because it doesn't really make sense to do that with a recursive cache (it's a different story with an authoritative database of records). > Now, if you are instead talking about "write the cache to disk on > shutdown for sweet and lovely restart", that's a whole different kettle > of fish :) Exactly. Deadwood has two features that make it easier to get DNS records when DNS servers on the internet are acting up: * Resurrections. If it's not possible to get a RR from the upstream DNS server, and we have an expired record in the cache, we will temporarily un-expire the record so that the user gets a record that probably still points to the site they want to reach. * Writing the cache to disk when shutting down Deadwood; reading the cache from disk when starting Deadwood. This allows the cache to stay around between computer reboots; this way, should a web site we went to three days ago no longer have working DNS servers, we can get the record from our cache file. The cache has a finite size and starts discarding records not recently accessed when it is filling up. Did you know that Bind 8 couldn't limit cache size and would just use more and more and more memory as more records were cached? My tentative plans are to add recursion to Deadwood, release a MaraDNS 2.0 which will be MaraDNS without recursion and Deadwood (this means it won't be possible to have the authoritative MaraDNS and Deadwood share the same IP). This will probably be released sometime in 2010. Since some people will still want the MaraDNS 1 behavior (same IP authoritative and recursive), I will continue to maintain a branch of MaraDNS 1. After MaraDNS 2.0, I currently plan to merge the Deadwood and MaraDNS authoritative code and have something that will have all the features of MaraDNS 1. At that point, I will decide on an end-of-life EOL timeline for MaraDNS 1. For distributors, there currently is no EOL for the 1.3.07 branch. The 1.2.12 branch of MaraDNS will be maintained until December 21, 2010; the only fixes for this branch are security and critical bugfixes. The 1.0 branch of MaraDNS is still maintained, but the only changes at this point are critical security fixes. 1.0 will be no longer available for download on the site after December 21, 2010. The extent of support I offer for MaraDNS 1 is pretty limited, and described here: http://maradns.blogspot.com/2009/01/maradns-update-last-one-for-while.html http://maradns.blogspot.com/2009/01/maradns-support-boundaries-linux-rocks.html Basically, I'm concentrating all of my MaraDNS development energy rewriting the recursive half of MaraDNS 2, and you need to show me the money if you want more support or features added to the MaraDNS 1 code. - Sam From alex at digriz.org.uk Wed Apr 8 06:12:22 2009 From: alex at digriz.org.uk (Alexander Clouter) Date: Wed, 8 Apr 2009 11:12:22 +0100 Subject: Update on Deadwood (MaraDNS rewrite) References: <7bd685720904071156k52cfd19flbe47385e8f1e8701@mail.gmail.com> <7bd685720904072207i44616ed1o58dd9ec00606219@mail.gmail.com> Message-ID: <6t9ua6-l5g.ln1@woodchuck.wormnet.eu> Sam Trenholme wrote: > > [snipped] > > My tentative plans are to add recursion to Deadwood, release a MaraDNS > 2.0 which will be MaraDNS without recursion and Deadwood (this means > it won't be possible to have the authoritative MaraDNS and Deadwood > share the same IP). This will probably be released sometime in 2010. > Since some people will still want the MaraDNS 1 behavior (same IP > authoritative and recursive), I will continue to maintain a branch of > MaraDNS 1. > Does not really matter if the authoritative lives on 127.0.0.1 and you have similar functionality as you do in 1.3.x that effectively relays particular domains to particular IP's....it would need to be a 'pass through' non-caching option though. I would imagine that this would help keep the codebases very separate and the 'pass-though no cache' hack would be rather non-invasive. Anyway, cheers for the update [1] we need DNS views -- Alexander Clouter .sigmonster says: I smell a wumpus. From strenholme.usenet at gmail.com Wed Apr 8 13:30:16 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 8 Apr 2009 12:30:16 -0500 Subject: Update on Deadwood (MaraDNS rewrite) In-Reply-To: <6t9ua6-l5g.ln1@woodchuck.wormnet.eu> References: <7bd685720904071156k52cfd19flbe47385e8f1e8701@mail.gmail.com> <7bd685720904072207i44616ed1o58dd9ec00606219@mail.gmail.com> <6t9ua6-l5g.ln1@woodchuck.wormnet.eu> Message-ID: <7bd685720904081030h36a7dbf3kcfeb50e034d04a2a@mail.gmail.com> > Does not really matter if the authoritative lives on 127.0.0.1 and you > have similar functionality as you do in 1.3.x that effectively relays > particular domains to particular IP's....it would need to be a 'pass > through' non-caching option though. It matters if people have to materially change their MaraDNS configuration to update to a new version. My rule for software updates is that I don't like forcing users to make substantial changes to their configuration when upgrading. This is why MaraDNS 1 will still be (minimally) supported after 2.0 comes out so as to ease transition. My rule is three years of support for an older version once a new version compatible with the older version is released. > I would imagine that this would help keep the codebases very separate > and the 'pass-though no cache' hack would be rather non-invasive. I have some tentative plans on keeping the authoritative codebase separate and have it so I have to do the minimum amount of modifications to update things for MaraDNS 2.2. The mararc underlying parser has already been rewritten for Deadwood, so code that interacts with the parser (main() in MaraDNS) will be redone for MaraDNS 2.2. [1] > [1] we need DNS views It is going to take a few years for me to implement that, since that's a change to the authoritative code. [2] There's a lot of stuff the authoritative code needs: DNS views; the ability to reload zones without restarting MaraDNS (one of my sponsors asked me for this); full Notify, IXFR, and AXFR support. All of this matters, but it's more important right now to rewrite the recursive cache, since the recursive code was always "something that works until I can rewrite it", and got quite messy by the time it was able to reasonably well resolve names on the internet [3]. Just to let people know, I will not have access to email starting today until Sunday night or Monday, so will not be able to send replies. - Sam [1] MaraDNS 2.0 will be Deadwood with full recursion + MaraDNS with recursion disabled. [2] If someone is willing to sponsor me to do this, it would be quite expensive; you basically will have to hire me and it will then take three to six months of me working on the code eight hours a day, five days a week. [3] This is why I don't like making changes to the recursive code; the code needs to be rewritten; band-aid solutions to hosts that don't resolve are just that: Band aid solutions. It's akin to Windows ME at this point; the best thing we can do to move forward is to no longer use this code and rewrite the code from scratch. Which is what I've been doing on and off since 2007. From strenholme.usenet at gmail.com Wed Apr 22 13:26:21 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Wed, 22 Apr 2009 12:26:21 -0500 Subject: Deadwood 2.3.01 released: Windows service; nocache Message-ID: <7bd685720904221026k7a7bb909o3c840e7cd2d240ba@mail.gmail.com> Deadwood is the code base that will (hopefully) eventually become the next MaraDNS recursive resolver. Right now, it's a tiny (under 32k) combined binary with both caching (but not recursive) DNS-over-UDP support, and basic non-caching DNS-over-TCP support. The big changes from the 2.1 release of Deadwood is that both the DNS-over-UDP and DNS-over-TCP client are now one combined binary that looks at argv[0] to determine what mode to run in. In addition, there is full support for this program being a Windows XP service. Since I don't have regular access to Vista, there are no manifests for Vista's UAC. On the other hand, there is a document called Vista.txt that describes one way to install this program as a service in Vista. Since I'm no longer maintaining Deadwood-1, I have added a compile time flag, NOCACHE (as in -DNOCACHE) that disables all caching code, giving people a DNS forwarder akin to Deadwood-1. People who are interested in looking at this code are invited to go to Deadwood's web page: http://maradns.org/deadwood - Sam From wsummers at deerfield.edu Thu Apr 23 16:58:57 2009 From: wsummers at deerfield.edu (Summers, William) Date: Thu, 23 Apr 2009 16:58:57 -0400 Subject: Question about delegating NS to another zone In-Reply-To: References: Message-ID: <2E5D0601FD7C9942992BCF406FF10E380444FA81@mail2k3.da.edu> Sam, I was looking for clarification on how Mara handles a delegation from a subdomain to a nameserver in another zone using the authonly binary. For example: xxxx.example.com {SOA} xxxx.example.com. ns ns1.dnsprovider.com. xxxx.example.com. ns ns2.dnsprovider.com. In my initial tests Mara returns ns records, but, even with glue records I have not been able to get A records from the offsite ns. I also set +norecurse to see if the issue listed in the faq as "I have a NS delegation, and MaraDNS is doing strange things." I have experimented with dangling CNAME between ns1.xxxx.example.com and ns1.dnsprovider.com. So far no luck returning dns records from the provider. Do I need to run the full binary? I am not certain these are Mara issues, but was hoping for some insight since the FAQ pages refer to delegations only within the same zone. Thanks for such a great, secure system. From strenholme.usenet at gmail.com Thu Apr 23 17:16:19 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 23 Apr 2009 16:16:19 -0500 Subject: Question about delegating NS to another zone In-Reply-To: <2E5D0601FD7C9942992BCF406FF10E380444FA81@mail2k3.da.edu> References: <2E5D0601FD7C9942992BCF406FF10E380444FA81@mail2k3.da.edu> Message-ID: <7bd685720904231416w5be45a87y111f3fdb95e7fa1d@mail.gmail.com> > I was looking for clarification on how Mara handles a delegation from a > subdomain to a nameserver in another zone using the authonly binary. Mara doesn't handle these things. If MaraDNS is authonly, MaraDNS doesn't return any records which aren't in MaraDNS' memory. In other words, if you have a NS sub-delegation by name, MaraDNS will only return the names, and not the IP addresses for these NS sub-delegations unless one adds local records in MaraDNS' memory. BIND has this way of looking on the internet for DNS records if it can't make a complete reply; for security reasons, MaraDNS doesn't do this and it's up to the user to make all of their replies are complete (no dangling CNAMEs, etc.) If you want to have MaraDNS as an authonly client return A records for NS records, the records need to be local. This is what the relevant lines in a CSV2 zone file would look like: sub.example.com. NS ns.example.org. sub.example.com. NS ns2.example.org. ns.example.org. A 10.1.2.3 ns2.example.org. A 10.1.2.4 - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From strenholme.usenet at gmail.com Thu Apr 30 11:23:33 2009 From: strenholme.usenet at gmail.com (Sam Trenholme) Date: Thu, 30 Apr 2009 10:23:33 -0500 Subject: I'm looking for work in California Message-ID: <7bd685720904300823x7bda539l2ef2eacea323a318@mail.gmail.com> Hello, MaraDNS users, It makes me very happy that people freely download and use MaraDNS, and even get free MaraDNS support from me and others here on this list. I'm letting people know that I'm ready to move back in California and am looking for work there. For people that may be able to hire me, or know someone who can hire me, my resume is here: http://samiam.org/resume/ There are other ways to help me. If you use MaraDNS in your enterprise or as an internet provider, I would like to know about it. If you use MaraDNS in an router or other device that is shipping, I want to know about it. If people are using MaraDNS professionally, this will make my resume look better. In addition, for people with embedded routers that can't handle threads, I have recently released Deadwood 2.3. This is a fully functional forwarding DNS server with low memory requirements that is under 32k in size when compiled in x86 [1] (25% of the size of dnsmasq). It also has full Windows support, running as a Windows service. Again, if people are using this code professionally, please let me know about it. Thank you everyone, for taking the time to read this email, and any assistance finding employment in California is greatly appreciated. I am continuing work on Deadwood and hope to have MaraDNS 2.0, with a completely rewritten caching and recursive code, out by the end of the year. - Sam [1] -Os; stripped From bogus@does.not.exist.com Tue Apr 7 14:56:51 2009 From: bogus@does.not.exist.com () Date: Tue, 07 Apr 2009 18:56:51 -0000 Subject: No subject Message-ID: >All messages created by the child process are sent to syslog() with a priority of LOG_INFO and a "facility" of LOG_DAEMON; should duende itself encounter an error, it will send messages to syslog() with a priority of LOG_ALERT.< It's up to syslog() or what not to rotate these log messages. Syslog is a daemon which handles log messages; "man syslog.conf" and "man syslog" might help you out, as might a friendly Google search. - Sam *Note:* I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding. From bogus@does.not.exist.com Tue Apr 7 14:56:51 2009 From: bogus@does.not.exist.com () Date: Tue, 07 Apr 2009 18:56:51 -0000 Subject: No subject Message-ID: >All messages created by the child process are sent to syslog() with a priority of LOG_INFO and a "facility" of LOG_DAEMON; should duende itself encounter an error, it will send messages to syslog() with a priority of LOG_ALERT.< It's up to syslog() or what not to rotate these log messages. Syslog is a daemon which handles log messages; "man syslog.conf" and "man syslog" might help you out, as might a friendly Google search. - Sam Note: I do not answer MaraDNS support requests sent by private email without being compensated for my time. I will discuss rates if you want this kind of support. Thank you for your understanding.