After the 1.0 release, start up a thread discussing the features
which MaraDNS should have.  I will copy the "BUGS" and
"UNIMPLEMENTED FEATURES" section of the man page here, which
is a list of possible features to implement:

       The maximum allowed number of threads is 200; this is a
       hard limit because there may be problems with some
       pthreads implementations causing MaraDNS to hang if this
       number is higher.

       The system startup script included with MaraDNS assumes
       that the only MaraDNS processes running are started by the
       script; it stops all MaraDNS processes running on the
       server when asked to stop MaraDNS.

       When a resolver asks for an A record, and the A record is
       a CNAME which points to a list of IPs, MaraDNS´ recursive
       resolver only returns the first IP listed along with the
       CNAME.

       When a resolver asks for an A record, and the A record is
       a CNAME that points to another CNAME (and possibly a
       longer CNAME chain), while MaraDNS returns the correct IP
       (as long as the glueless level is not exceeded), MaraDNS
       will incorrectly state that the first CNAME in the chain
       directly points to the IP.

       If a NS record points to a list of IPs, and the NS record
       in quesiton is a "glueless" record (MaraDNS had to go back
       to the root servers to find out the IP of the machine in
       question), MaraDNS´ recursive resolver only uses the first
       listed IP as a name server.

       When MaraDNS´ recursive resolver recives a "host not
       there" reply, instead of using the SOA minimum of the
       "host not there" reply as the TTL (Look at RFC1034
       §4.3.4), MaraDNS uses the TTL of the SOA reply.

       MaraDNS keeps referral NS records in the cache for one day
       instead of the TTL specified by the remote server.

       MaraDNS has very limited support for DNS data over TCP. In
       particular, MaraDNS only uses DNS‐over‐TCP for zone
       transfers, which is handled by the companion program
       zoneserver (see zoneserver(8) for usage information), and
       only allows authorized IPs to make zone transfer requests.

       MaraDNS handles the "any record" (255) request by only
       returning A and MX records (optionally: NS and SOA
       records), instead of sending all of the records
       assosciated with a given host name. The only places where
       I have seen the "any record" query used is by MTAs, and by
       the .au and .de registrars. In recursive mode, a request
       for "any record" is translated in to separate A and MX
       requests, which MaraDNS subsequently concatenates
       together.

       MaraDNS never returns a NXDOMAIN (nothing in the answer
       section, SOA in the authority section, result code of
       "name error" [3]). If a given domain node label does not
       exist for any RR, MaraDNS will still return a "no host"
       (nothing in the answer section, SOA in the authority
       section, 0 result code), implying that the host name
       exists for at least one RR type.

       MaraDNS does not use the zone file ("master file") format
       specified in chapter 5 of RFC1035.

       If a wildcard MX record exists in the form
       "*.example.com", and there is an A record for
       "www.example.com", but no MX record for "www.example.com",
       the correct behavior (based on RFC1034 §4.3.3) is to
       return "no host" (nothing in the answer section, SOA in
       the authority section, 0 result code) for a MX request to
       "www.example.com".  Instead, MaraDNS returns the MX record
       attached to "*.example.com".

       Star records (what RFC1034 calls "wildcards") can not be
       attached to NS records.

       MaraDNS´ recursive resolver does not perform TTL aging;
       while MaraDNS will expire a record TTL seconds after
       adding a record to her cache, the TTL that MaraDNS´
       recursive resolver displays is always the TTL the
       authoritative server gave MaraDNS. This means that records
       will stay in the cache longer than the original domain
       name owner may desire if one is using upstream or
       downstream dns servers.

       MaraDNS recursive resolver treats any TTL shorter than 300
       seconds (five minutes) as if the TTL in question was 300
       seconds long when determining when to expire a record from
       MaraDNS´ cache.

       MaraDNS´ recursive resolver´s method of deleting not
       recently accessed records from the cache when the cache
       starts to fill up can deleted records from the cache
       before they expire. Some people consider this undesirable
       behavior; I feel it is necessary behavior if one wishes to
       place a limit on the memory resources a DNS server may
       use.

       MaraDNS´ recursive resolver stops resolving when it finds
       an answer in the AR section. This is a problem in the case
       where a given host name and IP is registered with the root
       name servers, and the registered IP is out of date. When
       this happens, a server "closer" to the root server will
       give an out‐of‐date IP, even though the authoritative DNS
       servers for the host in question have the correct IP. Note
       that resolving this will result in increased DNS traffic.

       MaraDNS, like every other known DNS implementation, only
       supports a QDCOUNT of 0 or 1.

       MaraDNS does not send more than one DNS packet to a given
       DNS server when processing a DNS request; this is not a
       serious problem because most client implenetations send
       multiple DNS packets to a recurisve DNS server when
       processing a DNS request.

       MaraDNS spwawns a new thread for every single recursive
       DNS request when the data in question is not in MaraDNS´
       cache; this makes MaraDNS an excellent stress tester for
       pthread implementations.  Many pthread implementations can
       not handle this kind of load; symptoms include high memory
       usage and termination of the MaraDNS process.

UNIMPLEMENTED FEATURES
       These are features which will not be implemented in the
       1.0 release of MaraDNS:

       MaraDNS does not become a daemon. One can use a shell with
       job control functionality to make MaraDNS a daemon
       process, e.g:

           nohup maradns > /dev/null &

       MaraDNS does not use syslog or any other logging facility
       to log messages that MaraDNS generates.  Instead, the
       messages are logged to standard output. One can use a
       shell´s output redirection to log messages to a file, e.g:

           touch /var/log/maradns
           nohup maradns >> /var/log/maradns &

       MaraDNS does not have a "fully qualified host name"
       record, which would automagically create a PTR record from
       an A record.  MaraDNS does not have support for a
       "default" zone, which would allow one to add zones without
       needing to change MaraDNS configuration files.

       MaraDNS, like every other known free DNS server
       implementation, does not have SQL support.

       MaraDNS does not have a disk‐based caching scheme for
       authoritative zones.

       MaraDNS´ UDP server only loads zone files while MaraDNS is
       first started.  UDP Zone information can only be updated
       by stopping MaraDNS, and restarting MaraDNS again. Note
       that TCP zone files are loaded from the filesystem at the
       time the client requests a zone.

       MaraDNS does not have support for allowing given host
       names to only resolve for a limited range of IPs querying
       the DNS server, or for host names to resolve differently,
       depending on the IP querying the host name.

       MaraDNS does not support IPv6.

       MaraDNS has no signal handlers. Sending a HUP signal to
       MaraDNS terminates the MaraDNS process instead of telling
       MaraDNS to reload the configuration files.

       With the exception of the ability to decompress some RR
       types not present in RFC1035, MaraDNS does not support any
       DNS features which are not present in RFC1034 and RFC1035.

       MaraDNS, in accordance with RFC1034 §4.3.3, only allows
       wildcards at the beginning of a host name. E.g. names with
       wildcards like "foo.*.example.com" or "www.*" will not
       work.

       MaraDNS does not have support for MRTG or any other SNMP‐
       based logging mechanism. In fact, MaraDNS does not even
       use syslog().

