+rpcuser=
+rpcpassword=
+rpchost=localhost
+rpcport=8336
+```
+
+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 "trused" into the configuration of
+your resolvers.
+
+## Status
+
+Alpha. It is largely untested, and there are loose ends in the
+functionality. For example, `delegate` does not work yet, 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.