[dns-operations] Planned IN-ADDR.ARPA Nameserver Change

[Joe Abley]

On 2011-02-18, at 08:49, Joe Abley wrote:

> On 2011-02-18, at 08:40, Chris Thompson wrote:
> 
>> But today we seem to have reverted to the [12-out-of-13].ROOT-SERVERS.NET
>> nameservers and an unsigned version of the zone :-(
> 
> We are aware, and are investigating.

The previous setup for IN-ADDR.ARPA was as follows:

  VeriSign -> *.ROOT-SERVERS.NET
     ^
     |
   ARIN

The transitional setup for IN-ADDR.ARPA is as follows. This configuration was brought live on Wednesday this week:

  ICANN -> *.IN-ADDR-SERVERS.ARPA
    |
    v
 VeriSign -> *.ROOT-SERVERS.NET

The zone served by *.IN-ADDR-SERVERS.ARPA was correct at all times. However, it appears that due to an operational hiccup, the following configuration existed for a window long enough for a new zone to be received from ARIN and be published to the root servers:

  ICANN -> *.IN-ADDR-SERVERS.ARPA
    |
    v
 VeriSign -> *.ROOT-SERVERS.NET
    ^
    |
   ARIN

The data path from ARIN has now been closed at VeriSign, and all nameservers (including *.ROOT-SERVERS.NET) are now serving the correct zone, serial 2011021902.

Zone serial 2011021804 (the one sourced from ARIN) contained identical delegations and glue to zone serial 2011021902, so there was no impact on the operation of the v4 reverse DNS. The ARIN-sourced zone was not signed, however, as was observed by Chris on this list, and so early-adopters with manually-configured trust anchors may have seen validation failures.

ICANN will publish an incident report next week which includes more (and authoritative) detail.

In a couple of weeks (per the published timeline) the root servers will drop the IN-ADDR.ARPA zone altogether, leaving the data path like this:

  ICANN -> *.IN-ADDR-SERVERS.ARPA

Once we reach that configuration, assuming no harmful effects have been observed, a DS Record for the IN-ADDR.ARPA zone will be inserted in ARPA.

Regards,


Joe