Hi Chris,
Chris Thompson wrote: > It's the "wait for the new DS record(s) to appear in the parent > zone" step (rather than "perform the action that will (should) cause > them to appear and then assume that will happen in a timely fashion") > that seems to be the critical point. Maybe I am misinterpreting Matt > Rowley's messages, but it sounded as if this was how the problem > with 174.in-addr.arpa happened. While this is a valid concern, it is not really what happened in the case of 174.in-addr.arpa this weekend. Put simply, we had not intended for 174.in-addr.arpa to be resigned with new keys. This was the accidental result of a quirk in our zone signing system which was designed before we had inter-RIR transfers. Last week, a block within 174/8 was transferred to APNIC, and this reclassified 174 and created a 'new' zone, which was then given new keys. We tried to fix it quickly by updating the new DS set in in-addr.arpa, but our changes weren't applied as expected. ICANN is investigating this. Luckily, we had the old keys backed up and we were able to revert to them to correct the chain of trust for 174.in-addr.arpa. We have noted this for future transfers of this nature. We plan on updating our zone signing system to account for this case. Hopefully this has provided a little clarity to what happened. Please let me know if you have any questions or concerns. cheers, Matt Rowley ARIN _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
