In message <4db7b21d.8010...@data.pl>, Torinthiel writes: > 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=20 > >> generate. > >=20 > > Again, the $SUBJECT problem is resolved, but I have come upon a=20 > > possible reason to reuse a key. > >=20 > > I'm setting up a private namespace (RFC 1918 networks and imaginary=20 > > domain names) named+dhcpd system with three static zones, a dynamic=20 > > forward zone, and two dynamic reverse zones. Six total. > >=20 > > 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=20 > > 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. > > > >=20 > >> 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 > >> !=3D zone, and certainly not whose name is in a different zone. > >> > >> You're just complicating your life to no benefit. Use a different=20 > >> key for the child. > >=20 > > I'm a bit late to the DNSSEC party, what with the signed root being=20 > > in place already, but ISTM that these trusted-keys could be a major=20 > > 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
There is zero point in trying to share keying material between zones unless you have a HSM and it has limits on the number of keys it supports. The RRSIGs differ. The DS differ. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
