shared KSK for static zone and dynamic subzone?

[Torinthiel]

On 04/27/11 05:40, /dev/rob0 wrote:
> On Tue, Apr 26, 2011 at 10:15:18AM +0100, Phil Mayers wrote:
>> On 04/26/2011 02:13 AM, /dev/rob0 wrote:
>>> Is there any
>>> reason why I can't use the parent zone's KSK for the dynamic
>>> zone? Better yet, is there a reason why I shouldn't?
>>
>> Better yet, why *would* you? Keys aren't exactly expensive to 
>> generate.
> 
> Again, the $SUBJECT problem is resolved, but I have come upon a 
> possible reason to reuse a key.
> 
> I'm setting up a private namespace (RFC 1918 networks and imaginary 
> domain names) named+dhcpd system with three static zones, a dynamic 
> forward zone, and two dynamic reverse zones. Six total.
> 
> I want all these zones to be signed. Why? No good reason, just a
> learning exercise, actually. "Because I can."

That's a very good reason.


> [...]
>
> So that's what I'm going to do. Two more zones, four more keys, but 
> only two in trusted-keys. Tolerable.

You have some other options as well. First, as you've noticed, only the
top zone in the chain needs to have keys configured, all zones below can
benefit from DS records.
Second, if your zones are public, you can add your key to dlv.isc.org,
and only have to configure one key (which is build in into bind BTW).

Third, you can create your own DLV, and still use one key even with
private zones. Downside is that BIND cannot use two DLV repositories, so
you won't benefit from a lot of DLV configured zones. And I don't know
of a sensible way to duplicate ISC DLV and add some more keys.

You could download zones from http://secspider.cs.ucla.edu/ add your own
keys and sign by your own key. But keep in mind, that while ISC DLV asks
admins to configure their zones and verifies that they have keys and
abilities to modify zone, secspider simply walks everything (but from
several points around the world), so it's probably less secure.


> 
>> Anyway, the answer is "not really". The keys that bind generates
>> include the zone name, and you can't easily use a key whose name
>> != zone, and certainly not whose name is in a different zone.
>>
>> You're just complicating your life to no benefit. Use a different 
>> key for the child.
> 
> I'm a bit late to the DNSSEC party, what with the signed root being 
> in place already, but ISTM that these trusted-keys could be a major 
> management problem. Am I wrong? Is it still a problem?

Yes, but there are several possibilities to solve it.
First note that root is already signed, but not all (not even most) TLDs
are signed/accept DS records for delegations. So eg in .pl you are no
better than if root was not signed.

Ways to circumvent this include:
1) have your key distributed widely. Worst IMHO option, as it requires a
good distribution chain both at start, and when you change your KSK.

2) DLV - from DNS point of view it's a simple zone with a bit different
record types. If you have dlv.net, and want to check if example.com is
correclty signed, than your resolver asks for example.com.dlv.net, of
type DLV and if it receives correct answer (this implies that first you
trust DLV's key) it behaves just as if it got example.com's DS record
from .com. You still have to maintain key, but only one.

3) RFC 5011 specifies how keys can authenticate themselves, thus
simplifying KSK rollover.

Torinthiel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20110427/d422250f/attachment.bin>