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
> [email protected]
> http://mailman.powerdns.com/mailman/listinfo/pdns-dev
_______________________________________________
Pdns-dev mailing list
[email protected]
http://mailman.powerdns.com/mailman/listinfo/pdns-dev

Reply via email to