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

Chris Thompson cet1 at cam.ac.uk
Mon Nov 18 12:44:19 UTC 2013


On Nov 18 2013, Anand Buddhdev wrote:

>On 17/11/2013 18:57, Chris Thompson wrote:
>
>Hi Chris,
>
>> As a matter of interest to many of us, what are ARIN's operational
>> procedures for interlocking KSK rollovers in NNN.in-addr.arpa zones
>> with the change of DS records in in-addr.arpa?
>> 
>> (Of course we could ask the same question of the other RIRs as well...)
>
>I haven't understood your question fully, but let me try answering.

I think you have addressed exactly the point I had in mind.

>The RIPE NCC's procedure involves removing the old DS records, and
>inserting the new ones, in a single transaction, when we do KSK
>roll-overs. This saves us from having to do double the work.
>
>Last week, we began KSK roll-overs for all the RIPE NCC's zones. We
>began a slow start by updating the DS records for just 2.in-addr.arpa.
>However, our update did not appear in the in-addr.arpa zone. Our DNSSEC
>signer will not withdraw the old KSK until it has seen the new DS
>record, so it patiently kept waiting and logging this fact. We informed
>ICANN, and they fixed the operational issue in their provisioning system
>that was blocking the update. We expect to update the DS records of all
>zones this week.

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.

One can still argue as to whether one should ratchet up one's degree
of paranoia further, though. Published at *all* authoritative nameservers
for the parent zone, or just one? (And "all" may be difficult to check
when anycast configurations are in use.) Should one allow for the
possibility that the parent zone might revert to an earlier version,
and if so for how long? And so on ... :-(

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: cet1 at ucs.cam.ac.uk    Roger Needham Building, 7 JJ Thomson Avenue,
Phone: +44 1223 334715       Cambridge CB3 0RB, United Kingdom.



More information about the dns-operations mailing list