Hi Klaus, > Generally the expected DS propagation delay depends on the parent > domain operator. If, like in your case, it is a TLD operator, I would > suspect that these people try to have all there name servers in sync > and can resolve issues quite fast. On the other hand, it does not harm > to have an old KSK in zone for some days more than the expected DS > propagation delay.
parent domain operators are always TLDs in my use cases. As far as I know transfering large zonefiles to the other end of the world might take some time and perhaps this might cause something to get out of sync and not real-time updated. > Thus, during "normal" KSK rollovers I use 5 days (to cover > out-of-sync issues over a long weekend / holidays) before I remove the > old KSK. In case of emergency rollovers (key was leaked) you have to > decide per case if it is better to have short delays and risk failing > validation vs. someone can spoof valid answers. I'm using the DelegationSignerCommand to get notified, if OpenDNSSEC wants me to do an update on a domain. This currently triggers a domain update (by a simple script) with my domain registrar. The command gets exactly one DNSKEY (the new one). From this point of view, the workflow does not allow the old DS to persist in the parent zone, because I'm not told there should be two DNSKEY entries and there will be no second call to the DelegationSignerCommand command either to tell me to finally remove the old DS. BTW: it's a pity that there is no call when setting the initial DNSKEY, too. Regards, Volker _______________________________________________ Opendnssec-user mailing list Opendnssec-user@lists.opendnssec.org https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
