On 01/12/11 16:07, Mark Elkins wrote: > --------------------------- > > So now I want to resign the zone. Its already signed. How can I do that > without having to have the Private KSK still around. I'd have thought > that I'd just perhaps need the Private ZSK around to re-sign new zone > data. > > (here I removed the KSK Private file - 9983) > I think this works - but I get the message: > dnssec-signzone: warning: dns_dnssec_keylistfromrdataset: error reading > private key file example.com/NSEC3RSASHA1/9983: file not found > > So why is dnssec-signzone worried about the private part of a KSK that > it (I believe) should not need? Bug?
Because it tries to resign whole zone, with new validity period. That's why it needs KSK. You could try passing it the previously-signed message, and add -i parameter. However, see below why this is not necessary a good idea. > > ------------------------ > > My zone changes quite a bit - so what I was thinking to do is Sign a > very basic copy of the zone (SOA, NS records - not much else) - then > move the Private KSK's off the disk completely - then add in my > "dynamic" data and re-sign as often as I need (whenever my "dynamic" > data changes) with just my Private ZSK available. KSK is only used to sign DNSKEY records. SOA, NS and everything else are signed by ZSK. > After about 6 month (whatever) - I can then create a new KSK - bring > back my original 'off-disk' Private KSK - sign a new basic copy of my > zone - take the two Private KSK's offline and go through the whole KSK > roll-over process. ie - I only have the private part of the KSK on the > disk for a very short time - usually its off-site. I should be able to > generate my very basic zone on a completely different server - perhaps > not connected to the Internet at all - and just (via USB stick) copy > over the basic signed zone every six months? You definitely can generate signatures offline. That's what's done for the root zone. But watch for one thing. You don't need to change KSK every time you re-sign your zone. Changing the KSK requires some good timing, changing the DS records in parent zone (if you publish them, and good odds that you don't control the parent zone, only have some web/email/phone interface to change your record) and informing all DLV repositories you might be in and everyone that has configured your key as a trust anchor. That's not something you want to do often. What you also don't want, is long signature periods. Why? Because for as long as a signature is valid, an attacker can pretend to anyone in the Internet that your zone hasn't changed. E.g. you move your web server from 1.2.3.4 to 4.3.2.1, update zone files, test that it works. But an attacker has your older A and RRSIG records, and can present them to someone in place of your correct answers. The receiver sees this response, verifies RRSIG (it validates, after all you've created it) and believes you still have 1.2.3.4 address. Now, thin about what happens if the DNSKEY record gets attacked this way, and you've changed it because your ZSK got stolen. As long as signature is valid you're vulnerable. Better, generate a range of signatures for DNSKEY with your KSK, say one for each month' and keep those RRSIGs secret for now. Guard them the same way you guard ZSK, but in different place, and release them into the zone file only when needed. That way if ZSK gets compromised you just scrap those signatures, generate new ZSK and new signatures. Just don't put those signatures with ZSK. It it gets compromised so do the signatures, and you're screwed. Torinthiel _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
