--On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman <[EMAIL PROTECTED]>
wrote:
Once you implement DNSSEC you *must* generate keys every 30 days. So,
I think, if you're going to enable it by default, there needs to be a
script in periodic that will do all the magic to change keys every 30
days. Maybe put vars in /etc/rc.conf to override the default key
lengths and other portions of the commands that could change per
installation.
No, you don't HAVE to generate keys every 30 days, but you should if you
want real security.
For me that means must. :-)
Someone needs to write a really good tutorial on dnssec. The bits and pieces
are scattered about the web, but explanations of now to publish your keys, to
whom they need to be published and what is involved in the ongoing maintenance
are lacking. Especially a clear explanation of what is required to run both
keyed and "legacy" dns at the same time.
Still, for a while, until the infrastructure is
complete enough to make DNSSEC really of value to the end user, just
getting signed domains with keys published in an easily accessed place
is at least getting things started and getting the infrastructure
moving.
Where do you publish the keys?
Rolling keys is a rather tricky operation where mistakes, once DNSSEC
makes it to the end user, would be disastrous, so it would require a
couple of scripts, one to set a new key and another to remove the old
one. You need both key present for a period of time.
I'd not read that. Can you explain? I thought you simply overwrote the
existing keys with the new ones (in the zone file.) In fact I was thinking
that an $INCLUDE would make a great deal more sense. I didn't realize you had
to retain the old keys for a while. That complicates matters significantly.
BTW, I think without those scripts (or at least examples) you'll find adoption
will be a great deal slower. Many people that need to run dns are far from
experts and often intimidated by its complexity - especially the complexity of
dnssec.
--
Paul Schmehl
As if it wasn't already obvious,
my opinions are my own and not
those of my employer.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
