[MaraDNS list] MaraDNS 2.0.05 released
Sam Trenholme
maradns at gmail.com
Sun Feb 12 11:39:05 EST 2012
> 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
More information about the list
mailing list