+Beta. It is mostly feature-complete, but insufficiently tested.
+It implements the data format specification (SPEC.md in the source
+distribution) that slightly deviates from the
+[official specification](https://wiki.namecoin.info/index.php?title=Domain_Name_Specification).
+I am using it to access some of the `.bit` websites and it works
+for me.
+
+Try at your risk.
+
+## Unsolved problems
+
+The biggest problem by far is generating meaningful `SOA` records.
+
+### SOA Version a.k.a. Generation Count
+
+DNS infrastructure (including PowerDNS implementation) relies on the
+"generation" field of the `SOA` RR when it makes decision to invalidate
+the cache. So, if there is zone data in the DNS cache, and a DNS server
+needs to respond to a request about an object from that zone, it first
+checks if the TTL has expired. If it has not, the server takes the data
+from the cache. If it has expired, the server asks the "authoritative
+source" (which is in our case the dnamecoin daemon) for the SOA record
+and compares the generation count in the received response with the
+number kept in the cache. If the "authoritative" SOA does not have a
+greater generation count than the cached SOA, DNS server **does not**
+refresh its cache, presuming that the data there is still valid.
+
+So, it is important that the generation count in the SOA record is
+incremented every time when the domain object, or any of the object that
+it "include"-s or to which it "delegate"-s is changed.
+
+At present, there is no machanism for that. In most cases, simply
+summing the number of entries in `name_history`-s of all domain object
+involved in resolution would work, but this approach would produce
+wrong result when an "import" entry is removed from a domain, because
+in such case the sum would decrease. It would also not notice the
+changes in an object "include"-ed in a subdomain, unless complete
+recursive resolution of the subdomain tree is enforced for when
+SOA record is requested. That would invalidate the reason to have
+caching in the first place.
+
+One possible workaround, currently implemented in `pdns-pipe-nmc`, is to
+use a derivative of absolute time, in our case the number of 10-munute
+intervals elapsed since Namecoin was concieved, as the SOA generation
+count.
+
+### Nameserver field
+
+There is no "reasonable" value that could be placed there. Except
+possibly the name of the host on which the PoweDNS instance is running,
+in the `.bit` zone. Currently, `pdns-pipe-nmc` just puts a dot "."
+there, and no problems where noticed so far.
+
+## Getting the Software
+
+Check the [project homepage](http://www.average.org/pdns-pipe-nmc/).
+
+### Source
+
+Git [clone](git://git.average.org/git/pdns-pipe-nmc.git) or
+[browse](http://www.average.org/gitweb/?p=pdns-pipe-nmc.git;a=summary),
+or use [github mirror](https://github.com/crosser/pdns-pipe-nmc).
+
+### Binary Executable
+
+There is a binary built for x86_64 Linux with glibc6:
+
+| Executable file | PGP |
+|----------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------|
+| [**pdns-pipe-nmc.linux-glibc6.x86_64.2014-04-22.git-108b6c2**](http://www.average.org/pdns-pipe-nmc/pdns-pipe-nmc.linux-glibc6.x86_64.2014-04-22.git-108b6c2) | [sig](http://www.average.org/pdns-pipe-nmc/pdns-pipe-nmc.linux-glibc6.x86_64.2014-04-22.git-108b6c2.sig) |
+| [pdns-pipe-nmc.linux-glibc6.x86_64.2014-04-20.git-e9bd43f](http://www.average.org/pdns-pipe-nmc/pdns-pipe-nmc.linux-glibc6.x86_64.2014-04-20.git-e9bd43f) | [sig](http://www.average.org/pdns-pipe-nmc/pdns-pipe-nmc.linux-glibc6.x86_64.2014-04-20.git-e9bd43f.sig) |
+
+## Author
+
+Eugene Crosser \<crosser at average dot org\>
+<http://www.average.org/~crosser/>