[dns-operations] DNSSEC problem with 174.in-addr.arpa

[Matt Rowley]

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