IN-ADDR.ARPA Transition

This is the fifth of a number of updates regarding the transition of the IN-ADDR.ARPA zone.

As of 11.15am 16th February UTC-8, today, the action items listed in the Process and timeline for IN-ADDR.ARPA transition were successfully completed.

This transition at this stage results in:

• ICANN as the technical manager of IN-ADDR.ARPA.
• IN-ADDR.ARPA being served by the 6 nameservers described in RFC 5855 and operated by the five RIRs and ICANN.
• IN-ADDR.ARPA DNSSEC-signed by the same systems that signs many ICANN-operated zones including IP6.ARPA, IP6-SERVERS.ARPA, IN-ADDR-SERVERS.ARPA, IANA.ORG, and ICANN.ORG.
• A conservative plan in place to remove IN-ADDR.ARPA from the 12 root servers that currently serve it.

On 14 March 2011 a request will be sent to the IANA to add DS records to the IN-ADDR.ARPA delegation. It is expected that this change will take several days to complete due to the required authorisations.

The delay between transition and adding DS records to the root zone facilitates a simple rollback procedure in the (unlikely) event that harmful effects of DNSSEC in the IN-ADDR.ARPA zone are observed.

Final updates regarding the root servers and DS submission will be posted here as necessary.

This is the forth of a number of updates regarding the transition of the IN-ADDR.ARPA zone.

ARIN and ICANN have agreed to the following process details for the transition of the IN-ADDR.ARPA DNS zone.

On 16th February at 9am UTC-8:

• ICANN takes last agreed update from ARIN and publishes the zone via the in-addr-servers.arpa namservers. The agreed update from ARIN will be the generated zone data for the time stamp “201102160445”.
• ICANN will disable any further imports from ARIN.
• Both ARIN and ICANN will confirm zone contents (delegated NS) match between in-addr-servers.arpa servers and the root servers and signoff by 9.30am UTC-8
• ICANN to advise VerSign (root server hidden master operator) to pull IN-ADDR.ARPA from ICANN at 10.00am UTC-8
• ICANN will advise IANA to continue processing of the IN-ADDR.ARPA delegation change
• ICANN will update http://in-addr-transition.icann.org
• ICANN and ARIN to publish a statement of transition
• ICANN to publish/update appropriate whois records for *.in-addr.arpa delegations on whois.iana.org
• ICANN to provide public AXFR to  IN-ADDR.ARPA on xfr.dns.icann.org
• ICANN to publish IN-ADDR.ARPA zone on the ftp.internic.net site

During this transition a 48 hour update embargo will be placed on the IN-ADDR.ARPA zone. This will run from0000hrs 16th February UTC-8 to 2400hrs 17th February UTC-8.

This is the third of a number of updates regarding the transition of the IN-ADDR.ARPA zone.

As of today the 12th of January 2011, ICANN is now republishing the zone content provided by ARIN. This version of the IN-ADDR.ARPA zone is available for public query on the following servers.

• A.IN-ADDR-SERVERS.ARPA
• B.IN-ADDR-SERVERS.ARPA
• C.IN-ADDR-SERVERS.ARPA
• D.IN-ADDR-SERVERS.ARPA
• E.IN-ADDR-SERVERS.ARPA
• F.IN-ADDR-SERVERS.ARPA

See RFC5855 for additional details.

The servers under these names are operated by ICANN and the 5 RIRs and will ultimately be made the authoritative nameservers for IN-ADDR.ARPA (in the same way that [A-F].IP6-SERVERS.ARPA is authoritative for IP6.ARPA).

It is worthwhile to note that the zone SOA and zone apex published on [A-F].IN-ADDR-SERVERS.ARPA are different to the current active IN-ADDR.ARPA zone given the new name server set (described by RFC5855). Futher, by virtue of being published through the ICANN DNS systems operated by ICANN DNS Operations, the zone in its republished state is also DNSSEC signed.

Over the next several weeks the ARIN produced zone content will be imported, republished, and audited. During this period any required adjustments will be made before announcing the final transition date.

This is second of a number of updates regarding the transition of the IN-ADDR.ARPA zone.

As of today, the 23rd of December 2010, ARIN commenced a process of transferring the zone data  and zone configuration data to ICANN via a secure channel. This upload occurs daily and paves the way for the next steps in the transition process.

In the coming weeks, this data will be validated, and imported into ICANN systems, republished on a non-authoritative nameserver, and tested for consistency. Details of the available nameserver will be published soon.