-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I am questioning if the duration of 30 days with respect to adding a KSK
is the absolute correct value. The 30 days is a validator parameter that
says a trust anchor must stay in the AddPend state for that amount of time
before it may actually be used as trust anchor. The new KSK must
be pre-published two times the Active Refresh, as defined in RFC 5011.
Roughly, this is indeed 30 days at most.
However, one does not know whether the validator failed to do an
Active Refresh. If you take into account the retryTime (which is at most
an hour), the Active Refresh can go up more than 15 days. Suppose a query
fails just once, the maximum value of the Active Refresh is 15d 1h.
A more accurate value for the add hold-down time at the server side would
be 2 times Active Refresh:
Active Refresh = (queryInterval + x * retryTime)
where x is the the number of queries failed. Perhaps adding a Dta, the
delay between the query and the trust anchor set is actually updated, for
additional safety.
Also, the remove hold-down time is a validator parameter that can't be
taken exactly as a value for the server side. Actually, the validator only
has to see the revoked key once in order to remove it from the set of
trust anchors. So the remove hold-down time at the server side would be
only one time the Active Refresh.
By the way, why RFC 5011 says the server needs to keep the revoked key for
remove hold-down time in the zone, I don't know.
Best regards,
Matthijs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJOMZ06AAoJEA8yVCPsQCW544oH/RnCjsrVQHDbAD5X6cYPeNHF
xWdYDu+5d/28NnY9qt8UxVZ05125ZkKYgZ/3JZQlwpHH6+l4txnnT/3sbkFhRG/X
8NS8XdUf70yYd3aZp3jRAC6zseUyZJ1P232SOLjlUDu1Z/mgtZ1M2m/pAVrcgyBR
n0IBOrb2Ay4z2PJ2EixxcM0ehdsglDkdV7lCrIWKNb1MCfU4u5RdCbehiuouvtiv
a26C9y66xC9bGvh4vmp/+KbKToUvPoDWp1mhBWG3Kn8CKka7cO8Eb5cyea5ktck0
wXvPZUrxyWmO6DoE6ZDYuVa1YjKKJUWpt2IpWevNQKMZ9aYDFZz8X1AHloyCH/Y=
=ge57
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
