[Pdns-users] PowerDNSSEC Progress: ready for a first look

Leen Besselink leen at consolejunkie.net
Fri Jan 7 10:24:12 UTC 2011

On 01/06/2011 08:00 PM, bert hubert wrote:
> On Thu, Jan 06, 2011 at 11:55:24AM -0500, Mathew Hennessy wrote:
>> Excellent!  BTW, can PowerDNSSEC operate in the following way as one would expect:
>> PowerDNS supermaster which has DNSSEC RRs but doesn't do DNSSEC (aka
>> traditional PowerDNS) providing data to PowerDNS slaves.  If you use the
>> new code with a compatible backend on the slaves (such as gsqlite3), and
>> your whois servers only point to those slaves, will it work?
> Almost! If you did that up till just now, you would have had to run 'pdnssec
> rectify-zone' on your slaves after each AXFR.
> However, thank you for raising this idea, this sounds like a very valid use
> case.
> It has just been implemented in changeset
> http://wiki.powerdns.com/trac/changeset/1819
> I tested it against an ancient server, and now I have a fully
> operational DNSSEC zone!
> It works fully automatic on retrieving a zone for which we have local keying
> material.
> In this way, PowerDNSSEC can now be used to 'dnssec-ify' existing data, a
> bit like 'phreebird'. http://freshmeat.net/projects/phreebird
> 	Bert

Hi Bert,

Thank you for all your work so far, it is probably a lot of work.

I was thinking what about the opposite ?

A (possibly hidden) supermaster which does all the DNSSEC signing and
the superslaves which only do
zone-trasfers and no online DNSSEC-signing but do understand enough of
the protocol to be able to serve it.

I guess during the zone-transfer it would update any parts of the zone
that are not yet
(correctly) DNSSEC-signed ?

Would that also work ? Technically/DNSSEC-wise I would expect it to work
but maybe you don't have the right
configuration options yet. Also judging from the current documentation
it currently is not a mode of operations.

I ask this because I have a feeling not everyone wants their private key
material in several physical locations or
do not yet want to be hindered by the the DNSSEC-performance of the
current release for their public authoritive

Most of these requirements are already handled by the SQL-replication
mode of operation. I have a hunch not
atleast someone out there currently runs a supermaster/superslave
operation and would like to only add
DNSSEC to the supermaster and only upgrade (if needed) the slaves.


I really like how PowerDNSSEC and Phreebird are trying to lower the
administrative/operational burden.

But their is one part I'm missing a way to hook up an EPP-client for
sending the DS-record to the parent-zone.

Because when you setup the DS-record(s) at the parent-zone, you'll
eventually need to update it and the point
it is time when it needs to be updated is kind of dictated by the

So far the only effort I've seen is a some experimental/beta code
created by the OpenDNSSEC-people.

Any thoughts on that yet ? Or is it just to early at this point ?

Are their to many TLD's that do not have the needed EPP-extensions at
this time ? Or are their to many different
authentication scheme's ? Probably worse, I guess for some people they
have registrars in between. And some
currently have EPP, but probably not many have DNSSEC yet.

Anyway, when is the new DS known to PowerDNSSEC (and in the database) so
communication with all parties that
are involved can be initiated and how can it be recognised.

Would it be enough to run some script every day for example ?

I hope this is going to be a good year for everyone,
    Leen Besselink.

>> Thanks,
>> = Matt
>> On Jan 6, 2011, at 10:13, bert hubert wrote:
>>> Dear PowerDNS Community,
>>> With the help of many of you, we've now brought 'PowerDNSSEC' to the point
>>> where it might make sense for you to trial it on test domains.  We expect to
>>> make move some of our own important domains over to PowerDNSSEC early next
>>> week. PowerDNS.COM underlies the commercial DNS hosting service 'Express',
>>> and may have to wait a bit longer.
>>> To test, head over to http://www.powerdnssec.org (which of course is powered
>>> by PowerDNSSEC). More information is on
>>> http://wiki.powerdns.com/trac/wiki/PDNSSEC - including how to get started,
>>> and how to get help.
>>> In brief, PowerDNSSEC will allow you to continue operating as normal in many
>>> cases, with only slight changes to your installation. There is no need to
>>> run signing tools, nor is there a need to rotate keys or run scripts.
>>> Particularly, if you run with Generic MySQL, Generic PostgreSQL or Generic
>>> SQLite3, you should have an easy time. A small schema update is required,
>>> plus an invocation of 'pdnssec secure-zone domain-name && pdnssec
>>> rectify-zone domain-name' per domain you want to secure. And that should be
>>> it.
>>> Supported are:
>>> 	* NSEC
>>> 	* NSEC3 in ordered mode (pre-hashed records)
>>> 	* NSEC3 in narrow mode (unmodified records)
>>> 	* Zone transfers (for NSEC)
>>> 	* Import of 'standard' private keys from BIND/NSD
>>> 	* Export of 'standard' private keys
>>> 	* RSASHA1
>>> 	* "Pure" PostgreSQL, SQLite3 & MySQL operations
>>> 	* Hybrid BIND/PostgreSQL/SQLite3/MySQL operation
>>> To join the fun, download the tarball which can be found on the sites above,
>>> and let us know how it works for you!
>>> To clarify, we do not recommend taking the current code snapshot into
>>> production, but we are getting close.
>>> Kind regards,
>>> Bert
>>> _______________________________________________
>>> Pdns-users mailing list
>>> Pdns-users at mailman.powerdns.com
>>> http://mailman.powerdns.com/mailman/listinfo/pdns-users
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users

More information about the Pdns-users mailing list