1 Lis
2013
1 Lis
'13
11:28
[ Quoting <johani(a)johani.org> in "Re: [knot-dns-users] Knot DNS 1.3.3..."
]
Are you
suggesting that 'delete KSK' would be part of the API? If so, I
do not see the need. IHMO the API needs to be as small as possible and
just provide good defaults. If we want more, there is always OpenDNSSEC.
I don't have a strong position on that. From my POV we want most things to be
automatic, because if manual then some users will screw up (if no one else,
I will). But whether you delete old retired keys via a "delete" operation in
the API or if the key-manager is sufficiently clueful on its own to understand
when to delete keys I don't really care. One concern with making the key-manager smarter is
that I think you want
to avoid ending up with the key-manager running as a server process that
you connect to. Much better to keep it as "invoked on demand", but then you
must avoid making it responsible for anything that should happen on a clock.
Deleting old keys may be deferred until whenever it is called next, so that is
probably ok, though.
A stand alone cmd tool would be preferred, yes. But not running it as a daemon
will mean you have to call it often enough, not to miss any important key
rollover timings. Although thinking about it, making the PublishSafety large
would mean you don't have to query every second, but only 0.5 * PublishSafety
(to make up an equation).
Interesting, I was assuming a daemon, but cmd-line tool which just talks to an
HSM is the next level of awesomeness (sorry JP).
grtz,
--
Miek Gieben
PGP 3880D0F6