[Opendnssec-develop] Enforcer engine design v2 work breakdown

[Matthijs Mekking]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/30/2011 09:46 AM, Yuri Schaeffer wrote:
> 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)

Yes. When key rollovers talk about 'waiting approximately one TTL', it
is assumed the Maximum Zone/DNSKEY TTL (depending on ZSK or KSK
rollover) of the RRset of the previous version of the zone.

If you are going to introduce keys at a faster rate than TTL, the TTL
can even span multiple versions of previous zones.

- - Matthijs

> 
>>> 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
> 
> _______________________________________________ Opendnssec-develop
> mailing list Opendnssec-develop at lists.opendnssec.org 
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJODDNSAAoJEA8yVCPsQCW5bIEH/3PKi/cG/6l2V9gdNVIJxp2j
nukkhx8OArpYVcU7N7OnUvWd2ZXyfWIQN6MOAy+G1j9zXk6+v7rMX52BzvBE80gZ
aq2uRQAz8f0nFnNJ7DHuFu3TpWoiAo1lweH+5iKsmAxCk+ki9WLOfGD6lpL0Rtls
AM5KdsAcHlhSa7DxASmBLDnFDCdA8b3yO7yLl2lV2T0j7/nXEDytOGg6ffSWm8L/
iy2c+7g7b9UrXKcUQaxSHf3io9ax/Xetdwu8h+4DmR36uVe8N0VlKPz7WRFAnBJ6
w0XnKxjqMrHmFHGnAAeJKSH8o7EABnUq4lMYPGIjSFdVzi72gWOrUMBlqHtZQ5Q=
=4ls9
-----END PGP SIGNATURE-----