[governance] Reverse DNS changes (was: meanwhile in actual IG news.....)

[John Curran]

On Dec 16, 2010, at 1:41 AM, McTim wrote:

> http://blog.icann.org/2010/12/planned-changes-to-ipv4-reverse-dns-infrastructure/

These are predominantly implementation issues, but as there could IG implications, I'll elaborate the key points for this community's consideration:

> The IPv4 Reverse DNS uses the special domain IN-ADDR.ARPA. For many years the IN-ADDR.ARPA zone has been served by twelve of the thirteen DNS root servers. The changes we are planning will see the IN-ADDR.ARPA zone move to new, dedicated nameservers, five operated by the Regional Internet Registries (RIRs) and one operated by ICANN. The deployment of dedicated DNS infrastructure for IN-ADDR.ARPA provides additional protection for clients and for root servers from high IPv4 reverse DNS traffic loads, and is consistent with the direction identified by the Internet Architecture Board (IAB) in RFC 3172. 

- The DNS root servers have also been serving as the IN-ADDR.ARPA servers, and this is not good from a load or security perspective.
- These concerns were documented in an IETF "Best Current Practice" RFC 3172 more than 10 years ago.
- The RIRs, IAB, and ICANN jointly came to agreement that this should finally be addressed.
- As the IN-ADDR.ARPA zone contains information about the Internet number space, the new set of servers for the IN-ADDR.ARPA zone is distributed among the Internet number registries (i.e. the RIR's, and the IANA which serves as a Internet number registry for portions of the address space)

> ARIN has carried out the DNS zone maintenance function for IN-ADDR.ARPA since 1997. This function will transition to ICANN and will be managed concurrently with the central assignment of IPv4 address space to RIRs.

- While ARIN's always had the IN-ADDR.ARPA zone it reflect the full number assignment hierarchy, ARIN should not have a unique role in determination of the "content" of IN-ADDR.ARPA zone.
- The RIRs, IAB, and ICANN jointly came to agreement that this should finally be addressed along with the servers by having the ICANN perform the zone maintenance task under the existing understanding for technical tasks between the IAB and ICANN (RFC 2860).

As these changes were made by joint determination of the affected technical & operational parties, no single entity may unilaterally alter the outcome. These changes are based on public consensus documents stating the principles of good operational policy, extensive discussion for more than a decade, and actual collaboration (enhanced or otherwise ;-) between the parties.  It is my personal opinion that this compares quite favorably to the decisional processes for other Internet infrastructure functions, but if anyone has suggestions for improvements, as always I would welcome such...

Your humble infrastructure servant,
/John

John Curran
President and CEO
ARIN



____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t