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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
