Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text (was: Remove 7.1) - revised

[ARIN]

ARIN-2014-6 has been revised. This draft policy is open for discussion
on this mailing list and will be on the agenda at the upcoming ARIN
Public Policy Consultation at NANOG 63 in San Antonio.

ARIN-2014-6 is below and can be found at:
https://www.arin.net/policy/proposals/2014_6.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2014-6
Remove Operational Reverse DNS Text (was: Remove 7.1)

Date: 21 January 2014

Problem Statement:

7.1 attempts to assert rules on rDNS management at ARIN. It fails to do 
so because it only addresses in-addr.arpa (missing equally important 
rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary 
decision made by ARIN technical staff. We should remove this text from 
policy, as it represents operational practice rather than ARIN number 
policy.

In feedback received at public policy meetings and on the PPML mailing 
list, the Community expressed a desire for IPv4 and IPv6 policy on 
reverse DNS to be congruent (that is to say, it makes no sense to remove 
7.1 without addressing 6.5.6 which is similarly operationally 
prescriptive) and bring this proposal forward again.

Policy statement:

Remove 7.1

Remove 6.5.6

Comments:

a.Timetable for implementation: Immediate

b.Anything else:

7.1. Maintaining IN-ADDRs

All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses 
from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain 
records for their respective customers. For blocks smaller than /16, and 
for the segment of larger blocks smaller than /16, ARIN can maintain 
IN-ADDRs.

6.5.6. Reverse lookup

When an RIR delegates IPv6 address space to an organization, it also 
delegates the responsibility to manage the reverse lookup zone that 
corresponds to the allocated IPv6 address space. Each organization 
should properly manage its reverse lookup zone. When making an address 
assignment, the organization must delegate to an assignee organization, 
upon request, the responsibility to manage the reverse lookup zone that 
corresponds to the assigned address.


On 1/29/14 10:27 AM, ARIN wrote:
> On 24 January 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-198 Remove 7.1" as a Draft Policy.
>
> Draft Policy ARIN-2014-6 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_6.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-6 on the Public Policy Mailing List.
>
> The AC will evaluate the discussion in order to assess the conformance
> of this draft policy with ARIN's Principles of Internet Number Resource
> Policy as stated in the PDP. Specifically, these principles are:
>
>   * Enabling Fair and Impartial Number Resource Administration
>   * Technically Sound
>   * Supported by the Community
>
> The ARIN Policy Development Process (PDP) can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2014-6
> Remove 7.1
>
> Date: 29 January 2014
>
> Problem Statement:
>
> 7.1 attempts to assert rules on rDNS management at ARIN. It fails to do
> so because it only addresses in-addr.arpa (missing equally important
> rules in ip6.arpa). It's also not based on any RFC; it's an arbitrary
> decision made by ARIN technical staff. We should remove this text from
> policy, as it represents operational practice rather than ARIN number
> policy.
>
> Policy statement:
>
> Remove 7.1
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
>
> 7.1. Maintaining IN-ADDRs
>
> All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses
> from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain
> records for their respective customers. For blocks smaller than /16, and
> for the segment of larger blocks  smaller than /16, ARIN can maintain
> IN-ADDRs.
>