Re: [MaraDNS list] MaraDNS 2.0.05 released

>        To get the 2.x backwards compatible with 1.4.x cannot be done without
> asking the user about IP addresses. So the debconf system needs to be
> brought in. Even if I go for the really cheap option of usuing ucf I
> need to devote soem time to my other DEbian packages and other work.

Making 2.x backwards compatible with 1.4.x is non-trivial.  MaraDNS's
versioning scheme is, unlike a lot of software (As just one example,
Firefox *cough* *cough*) [1], the traditional scheme that increasing
the major version number means that old configurations will break.

I originally had the intention of having Deadwood support all of
MaraDNS' parameters, so that a mararc file would parse in Deadwood
without problem.  Alas, as I was getting engaged with my girlfriend I
realized that spending a lot of time working hard on software without
getting paid was no longer a reasonable life choice for me to make, so
I had to discard a lot of big plans I had for Deadwood.   :(

However, since the plan was at one point to be 100% compatible with a
MaraDNS 1.x mararc file, Deadwood's file configuration format is
remarkably similar.  I do not think making a Perl script or what not
to make a MaraDNS 1.x configuration file MaraDNS 2 compatible would be
too difficult.  Some points:

* The authoritative parts of the conversion file will stay in mararc.
The recursive bits would go to Deadwood.

* A mararc 1.x file will work with the authoritative half of MaraDNS 2
if the "recursive_acl" line is commented out (other recursion-based
parameters are just ignored in MaraDNS 2)

* Any leading white space will need to be removed when converting a
MaraDNS 1.x configuration file in to a Deadwood configuration file.

* MaraDNS and Deadwood use line-based formats, so simple line-based
processing (such as "perl -pe") can convert the configuration files.

* verbose_level should be multiplied by 20 in a maradns -> deadwood conversion

* retry_cycles should be multiplied by three and converted in to
num_retries (retry_cycles was the number of times we tried contacting
all name servers for a given answer; num_retries is the total number
of times we try contacting a name server)

* http://maradns.org/tutorial/update.html#2.0 claims that Deadwood
does not support "reject_ptr".  This is no longer true; Deadwood 3.2
has reject_ptr support.

Unfortunately, I am no longer in a position to implement a Perl or
whatever script to do this conversion, but I will gladly host the work
of anyone who wants to tackle this.  I will not add the script to the
MaraDNS/Deadwood tree because I can not take responsibility for any
bugs the script may have.

- Sam

[1] Deadwood uses a different numbering scheme: Each increase in the
major number means the addition of a significant new feature.  It
follows the plan I had back in October of 2007 [2]: Deadwood 1 is a
non-caching, non-recursive DNS forwarder, Deadwood 2 is a
non-recursive caching DNS forwarder, and Deadwood 3 is a fully
recursive DNS cache.  Deadwood 3.2 implements some things I meant to
get in to Deadwood 3.0 (better CNAME handling and finer time stamps),
but didn't have the time to.

[2] http://maradns.blogspot.com/2007/10/groundbreaking-of-deadwood-project.html