Update on Deadwood (MaraDNS rewrite)

Sam Trenholme strenholme.usenet at gmail.com
Wed Apr 8 01:07:10 EDT 2009


> 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


More information about the list mailing list