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

[Mark Andrews]

In message <A50D0A1F-6AA5-400A-94BB-789CF9058053 at icann.org>, Joe Abley writes:
> 
> 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 exi
> sted 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

Which shouldn't have been a problem if arin was being fed by icann
which is how it should have been done to safely move to a new primary
master.  You always make the old master a slave for the new master.
Doing so prevents these sort of issues.  Unfortunately many people
forget this step or don't think it is necessary.

> 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 20110
> 21902.
> 
> Zone serial 2011021804 (the one sourced from ARIN) contained identical delega
> tions and glue to zone serial 2011021902, so there was no impact on the opera
> tion 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-conf
> igured trust anchors may have seen validation failures.
> 
> ICANN will publish an incident report next week which includes more (and auth
> oritative) 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 obser
> ved, a DS Record for the IN-ADDR.ARPA zone will be inserted in ARPA.
> 
> Regards,
> 
> 
> Joe
> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org