[Pdns-dev] Seperating KSK and ZSK for PowwerDNS ?

[Leen Besselink]

On Wed, May 30, 2012 at 01:44:27PM +0200, Peter van Dijk wrote:
> Hello Leen,
> 
> On May 29, 2012, at 13:34 , Leen Besselink wrote:
> 
> > It is just an idea, I would like to know what people think.
> 
> 
> In short: this is an excellent idea. Would you file an enhancement ticket at http://wiki.powerdns.com/ for it so the idea does not get lost? We will not get to it soon. Of course, patches are always welcome :)
> 

Hi,

This weekend I was listening to the presentation by Bert at the ICANN44 in Pragua and he mentioned this enhancement which I had made a ticket for ( http://wiki.powerdns.com/trac/ticket/481 ).

As I had time to look at the source, that is just what I did. I also needed to brush up on my knowledge of the DNSSEC.

However I did not create any code because there are a lot of things unclear about what it should look like.

For example, for us, with our current setup (a hidden-master database) and replication method, we could just store the KSKs in a seperate database table and not replicate that one table.

Which would be a small change to the PowerDNS code in comparison.

But I doubt that setup would fit the environment of most people. If only because I believe a lot of replication systems don't even support per-table replication.

So do we want a seperate database for KSKs ? Or even a seperate backend-definition (even if it is of the same database-type) ?

Or maybe just a simple file-based storage for the KSKs ?

I think the best place to start would be to look at what the configuration options for this would be.

But before we go there, I needed to figure out if creating this new "hybrid mode" is actually useful:

0. Does current PowerDNS online signing still work if you move the private part of the KSK out of the database and restart PowerDNS ? Or does it need to calculate and cache something at the first time it gets queried about a domain (or when that something expires).
 -> I think it does, it needs to generate a RRSIG of the DNSKEY-records. So we need to store the result of that calculation in the database as well AND update it when ANY ZSK changes. PowerDNS with online signing currently creates such a DNSKEY RRSIG for every 2 weeks.
    That is like a key rollover, you'd need to regularly update it.

1. Does the hybrid-mode even make much sense:

 You have a few situations I can think of of the top of my head:
 1. someone gets read-only access to the database or finds an other way to steal the ZSK.
 2. someone gets read-only access to the database or finds an other way and steals the ZSK and RRSIG for the DNSKEY
 3. someone gets read/write or write-only access to the database and can modify the content

 3. isn't solved/covered by this, only 1 and 2. Because in case of 3. the attacker can change the database, the attacker can change it to point to anywhere the attacker likes. So if you are afraid that the hosting provider gets access to your secundairy nameservers. You probably don't want online signing.

 1. and 2. are practically the same thing, because if the ZSK is still valid, the attacker can just query an existing authoritive DNS-server for the domain to get a new RRSIG.

 So as long as the ZSK isn't regularly changed, an attacker can use the ZSK for as long as the attacker isn't discovered.

 If the ZSK does change, the attacker can use the old ZSK/DNSKEY RRSIG for up to 2 weeks if the KSK isn't also changed.

Looking at all this, this might not add as much benefit as first thought ? Unless you very regularly change the ZSK.

Bert already hinted at that too at ICANN44 it seems, but at least now (I think) I understand why. :-)

> Kind regards,
> -- 
> Peter van Dijk
> Netherlabs Computer Consulting BV - http://www.netherlabs.nl/
> 

Have a nice day,
	Leen.
> _______________________________________________
> Pdns-dev mailing list
> Pdns-dev at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-dev