[Pdns-users] New PowerDNS Authoritative Server snapshot with DNSSEC + Release Notes

Leen Besselink leen at consolejunkie.net
Fri Jan 28 10:14:43 UTC 2011

On 01/27/2011 11:37 PM, bert hubert wrote:
> Hi everybody,
> (the short version, there is a snapshot worth looking at, packages on
> http://powerdnssec.org/downloads - documentation on http://powerdnssec.org )
> Since our previous 'PowerDNSSEC' announcement, a lot has happened. 
> PowerDNSSEC now offers support for almost all DNSSEC algorithms standardised
> (RSASHA1, RSASHA256, RSASHA512, GOST), and even for some that aren't yet
> (ECDSA).
> In addition, we've added support for pre-signed zones, so you can now slave
> signed zones from non-PowerDNS installations, and serve them. The other way
> around works too, you can slave unsigned zones and serve them with DNSSEC
> added to it, as a front-proxy.
> Finally, there is now a lot of documentation, a good place to start reading
> is still http://powerdnssec.org.
> Today, we've released snapshot 20110127.1921 which is in reasonably wide
> production. It powers every single access to the PowerDNS Wiki and the
> PowerDNS Subversion repository. 
> Packages for 32 bit and 64 bit Linux distributions, plus source, can be
> found on http://powerdnssec.org/downloads
> We urge everybody with an interest in DNSSEC to give this snapshot and its
> associated documentation a go, if only to find out if it would 'work for
> you'.
Hi Bert and others,

So I wanted to atleast do a quick test last night. So I downloaded the
static 64-bit .deb and installed it on my 64-bit Ubuntu 10.10 desktop.
But it did not work. Eventually I found some of the problems, but a
CNAME problem remained. I have some suggestions as well.

I didn't want to setup a mysql or postgresql database, but first try to
setup the bind backend.

I've not created a bind zone file in ages, so I did a quick dig AXFR of
an existing zone in production and removed and replaced a lot of stuff,
this was the result:

test.net.               14400   IN      SOA     ns1.test.net.
hostmaster.test.net. 2011012731 10800 3600 604800 38400
test.net.               14400   IN      NS      ns2.test.net.
test.net.               14400   IN      NS      ns1.test.net.
test.net.               14400   IN      NS      ns3.test.net.
ns1.test.net.           3600    IN      A
ns2.test.net.           3600    IN      A
ns3.test.net.           3600    IN      A
web.test.net.   3600    IN      A
www.test.net.           3600    IN      CNAME   web.test.net.
test.net.               14400   IN      MX      100 mx1.test.net.
test.net.               14400   IN      MX      100 mx2.test.net.
test.net.               14400   IN      MX      400 mx3.test.net.
test.net.               14400   IN      MX      400 mx4.test.net.
mx1.test.net.           3600    IN      A
mx2.test.net.           3600    IN      A
mx3.test.net.           3600    IN      A
mx4.test.net.           3600    IN      A

I created a named.conf:

zone "test.net" {
        type master;
        file "/etc/powerdns/zones/test.net";

and added these settings to pdns.conf:



Everything seemed to work fine. I tested this by sending:

dig +norec @ www.test.net. A

I got the CNAME and the A-record of web.test.net as result as expect.

So just running the bind-backend seemed to work just fine.

If I don't want to setup a whole database server, for DNSSEC I would
need sqlite or sqlite3.

First problem: what do I need to specify at the launch parameter ?:
sqlite or sqlite3 ?

I checked pdns_server --list-modules

gsqlite or gsqlite3

I guess if I use the 'sqlite3' command to create the database I'll use

So I added that to the launch setting:


created a database:

http://doc.powerdns.com/gsqlite.html#id621028 (gsqlite / Setting up the

And added the dnssec changes:


Added to the config:



Everything still worked.

As I understand it, it is possible to use bind-zones and sqlite3 to
store the keys.

So I ran the commands:

$pdnssec secure-zone test.net
This should not happen, still no key!

So I ran check-zone:
$pdnssec check-zone test.net
no nsec3 for test.net
Jan 28 10:39:17 [bindbackend] Done parsing domains, 0 rejected, 1 new, 0
Checked 17 records, 0 errors

Still the same error when I ran pdnssec secure-zone test.net

So I try:

$ pdnssec rectify-zone test.net
no nsec3 for test.net
Jan 28 10:41:46 [bindbackend] Done parsing domains, 0 rejected, 1 new, 0
Adding NSEC ordering information
Done listing

so I run:

$ echo .dump | sqlite3 /etc/powerdns/sql/powerdns.sqlite3 2>&1 | less -I

Nothing was added to the database.

So I run pdnssec secure-zone test.net

Still the same: This should not happen, still no key!

Now I think, well, maybe I should just move everything over to the
sqlite3-database instead.

As I've never created a sqlite3-database for powerdns before yesterday I
create one without dnssec first.

So I run zone2sql without the DNSSEC.

I disabled/change the settings:


Look at the a .dump, it looks fine.

Run a dig and spot an other problem:

www.test.net.           3600    IN      CNAME   web.test.net.

Just the CNAME, no A-record.

This seems wrong, I think it is an ordering problem. So I add the
dnssec-schema and enable:


Again and run:

pdnssec rectify-zone test.net

Now it worked:
www.test.net.           3600    IN      CNAME   web.test.net.
web.test.net.           3600    IN      A

But still signing does not work:

$ pdnssec secure-zone test.net
This should not happen, still no key!

And I go to bed because it is late. :-/

This morning I tried running the bind and sqlite3 again but changed:


That did not help.

Then I figured out the problem, I forgot to add to the domains-table.

So I have 2 suggestions:

1. add the insert into domain line to zone2sql
2. the documentation should be changed from:

$ echo 'insert into domains (name, type) values ('powerdnssec.org', 'NATIVE') | sqlite3 ./powerdns.sqlite3


$ echo "insert into domains (name, type) values ('powerdnssec.org', 'NATIVE')" | sqlite3 ./powerdns.sqlite3

So I retested, but the problem with the CNAME and sqlite3 remained when
running without a DNSSEC-schema and gsqlite3-dnssec-setting.

After ordering and singing and ordering the DNSSEC the CNAME problems
all went away and when I run dig with +trusted-key= and everything worked.

It also worked with or without the bind backend.

Have a nice day,
    Leen Besselink.

More information about the Pdns-users mailing list