+They are the parameters needed to contact the `namecoind` server over
+its JsonRPC interface. With default installation on `localhost`, you
+will only need to specify `rpcpassword`.
+
+Configure your resolvers to use the PowerDns instance for queries in
+the `.bit` zone. This is left as an exercise to the reader.
+
+## Security Considerations
+
+Namecoin per se has excellent non-repudiation characteristics. But
+once you've converted the data into (non-DNSSEC-protected) DNS
+format, all bets are off. If you intend to query your powerdns
+instance over public Internet, remember that nothing prevents evil
+hackers or ruthless governments from tampering with your queries
+and powerdns responses. There are two possible approaches to
+mitigation of this problem:
+
+* Run namecoind and powerdns as close to the consumer as
+possible: on the same host, or at least on the same network, and
+keep it guarded.
+* I did not try it, but it should be possible to use PowerDNS
+[Front-signing](http://doc.powerdns.com/html/dnssec-modes.html#dnssec-frontserver),
+so the communication will happen over DNSSEC protocol without the
+need to keep the signatures in the zone data itself. You probably
+would need to create signing key for the PowerDNS instance, and add
+the corresponding public key as "trusted" into the configuration of
+your resolvers.
+
+## Status
+
+Alpha. It is insufficiently tested, and there are loose ends in the
+functionality. For example, version in the `SOA` record is bogus.
+Some of the the problems are due to incomplete and/or imprecise
+[definition of the domain data format](https://wiki.namecoin.info/index.php?title=Domain_Name_Specification)
+on the wiki. That said, I am using it to access some of the `.bit` websites
+and did not notice anomalies so far.
+
+Try at your risk.
+
+## Unsolved problems
+
+The biggest problem by far is generating meaningful `SOA` records. 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.
+
+## 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).