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
