On 04/27/2011 04:40 AM, /dev/rob0 wrote:
With one KSK and one ZSK per zone, we're looking at *12* keys to go in the connected sites' trusted-keys. Errr, no, I guess I only need the KSKs, but still, that's 6. I'd prefer that it be fewer than that. One sounds simpler, in fact.
But the trusted-key statement still includes the key name. When you trust a key, it isn't trusted to sign anything; just the zone corresponding to it's name.
While writing this, a compromise came to me. :) I can run forward zones as children of a single TLD, and use 168.192.in-addr.arpa. as parent for all my reverse zones. :)
That's the way to do it.
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?
The idea is that you don't have any. The DNS root is signed, and many of the TLDs are now signed. The DLV and ITAR were always interim measures.
If you had to manage trusted keys, DNSSEC would never work, but you don't because DNS has built-in delegation and hierarchy.
_______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
