[Opendnssec-user] Enforcerd and signerd decoupling

[Matthijs Mekking]

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
> Opendnssec-user at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-user