MaraDNS and NAPTR support

[Sam Trenholme]

> We (e164.org) are evaluating MaraDNS as a suitable authoritative only
> name server options.

Isn't e164 a site devoted to E.164, which is what NAPTR is about.

Anyway, I knew I should have added this record during the pre-1.3.07
process.  I knew there was a RR type one person wanted added to
MaraDNS, and I had every intention of adding it, but never got around
to it.  Then I decided to stabilize with 1.3.07.01, and since that
branch is on a strict "no new features" stage of development, I can't
add it to that release of MaraDNS.  And, oh, if you want NAPTR in 1.2
(or even 1.0, heaven forbid); forget it.  Both of those branches are
currently in "critical bugfixes only" mode.

The good news is that I have already opened up a 1.2.08 branch for new
features since Jean-Jacques Sarto is doing so much to improve the IPV6
support in MaraDNS.  The first formal 1.2.08 release will be this
Friday, and I should be able to get NAPTR in there by then.

Let's see: NAPTR.  RR code 35; two 16-bit unsigned numbers; three
"character-strings" (thingys where you have a single byte indicating
the length of the string, followed by the actural string.  No worries;
MaraDNS has code to do all of this); and finally a <domain-name>.  The
<domain-name> is a little tricky, since the compression/decompression
library will have to deal with them, but this should not be too hard
(I haven't added a new RR to the compression core since 2002 or so).

The RFC mandates that this RR not be compressed, but I can write the
code to decompress it just in case it does get compressed.

OK, looks simple enough.  Look for it in 1.3.08 this Friday.

And, oh, if NAPTR requires the DNS server to do any of the regular
expression stuff and what not, forget it.  I'm not about to deal with
that kind of code.  CNAME was enough of a nightmare; thankfully DJB
(and myself) were able to kill A6 and DNAME before they caught on.

- Sam