[Opendnssec-develop] Enforcer engine design v2 work breakdown

[Yuri Schaeffer]

Roland,

> > The main problem is that policy information is not tied to a key (in my
> > initial design it was but this was somehow dropped by Rene and me in the
> > actual implementation as redundant). When a policy changes all existing
> > keys should still propagate according to the old policy. This is fixable
> > after Rene's vacation. (I will not block on this)

> Do I understand correctly that this will only affect keys that are already in use?

I think new keys are affected as well. When for example the new DNSKEY
TTL is shorter than the old DNSKEY TTL, the old and the new set both
roll too quick. (zone may become invalid)

When the new TTL is longer. The roll is unnecessary slow. (but will stay
valid)

> > I did (and introduced an ordening) and dropped it again. This is now a
> > policy decision, not reflected in the rules.

> Can you explain why that is and what changes you made? I recall we had quite a bit of discussion about this during the last call.

So the problem is that you may always introduce the RRSIG DNSKEY without
affecting validity. The situation was that in some cases the DNSKEY
could not introduce yet, but its signature did.

I tried to capture this in a rule having state(DNSKEY) >= state(RRSIG
DNSKEY). This worked without a problem. Later I realized introducing the
signatures first is not wrong, just undesirable. Hence I removed it from
the rules and added the case to the policy of the enforcer. (note: I'm
not referring to the user defined policy, the kasp.xml).
Now the RRSIG DNSKEY may only introduce when the DNSKEY is not hidden.
In almost all cases this will cause the DNSKEY and RRSIG DNSKEY to
propagate at the same time and pace.

Let me finally remark that having no restrictions on the RRSIG DNSKEY
will not make the zone invalid, nor will it affect the speed of a
rollover. It could however give the signer more work.

//yuri