Hi Antti,
I agree with you. When we started with OpenDNSSEC we decided it was a
good design to split the key management functionality and the signer
functionality in two daemons, as it are two very separate tasks. And it
has its benefits (code simplicity, flexibility (only use enforcer or
signer, ...)
However, now that the project exists some longer time, we also
identified some quirks, your example being one of them, and the split is
not as strict as we once thought. We could solve this in multiple ways:
1. More communication between enforcer and signer, signer could signal
events that have happened. We would lose flexibility, as we tie signer
and enforcer together.
2. One daemon to rule them all. Might be more simpler than adding all
kinds of communications, operational wise too.
3. Scripts that check an event has happened, instead of relying on time
only. This has the advantage signer and daemon can still be ran
separately and you can mix enforcer with a different signer for example.
Just some ideas of how we can fix it in the future. For a short term
work around, I assume monitoring is your friend.
Best regards,
Matthijs
On 05-03-14 11:37, Antti Ristimäki wrote:
Hi,
We've been lately starting worrying about the possible decoupling
between enforcerd and signerd. Given that enforcerd is responsible for
rolling the keys and managing related timers, I think it should receive
at least some level of feedback from the signerd in order to do all the
timings properly. Let's consider for example the following simple and
quite realistic scenario:
1) Enforcerd runs and decides that it's time to introduce a new key into
the zone.
2) The zone next signing should take place but for some reason the zone
is NOT signed, for example due to an outage in the zone provisioning
system. All the subsequent signings are also missed, so the zone won't
get signed until phase 3)
3) Enforcerd runs again and decides that the new key has now been
published for long enough and marks it as active.
4) The zone signing process chain works again and the zone gets signed.
As the new key is now active, the zone gets populated with signatures
created with the new key.
5) A random resolver queries for an RRset not present in cache and
receives it along with the signature created with the new key. The
resolver still has the old DNSKEY RRset in cache and thus validation
fails until cached DNSKEY RRset expires.
The scenario described above is only a single example, but the issue
would also occur if the zone is signed between enforcerd periodic runs
but the updated zone is not propagated to public DNS servers. An
ultimate feature would be if the enforcerd could somehow track whether
the key state changes have been actually propagated to public DNS. Maybe
this could be accomplished by some optional hook to some user defined
script?
The probability of this issue is not so big when the signerd runs
periodically e.g. every half an hour, but in environments where the zone
signing is triggered only when the zone is received from a provisioning
system, the probability might be much bigger.
It is also worth mentioning, that the default PublishSafety interval is
only 3600s IIRC.
Any thoughts about this? Is there already some mechanism in OpenDNSSEC
to prevent this issue that I'm not aware of?
Antti
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
