Your IP address could not be determined at this time.

Draft Policies and Proposals

Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text
Status:

Under discussion

 
Discussion Tracking
Mailing List:
Formal introduction on PPML on 29 January 2014

Origin - ARIN-prop-198

Draft Policy - 29 January 2014

Revised - 21 January 2015

 

 

Public Policy Mailing List
ARIN Public Policy Meeting:

ARIN PPC At NANOG 60

ARIN 33

ARIN PPC at NANOG 61

ARIN PPC at NANOG 62

ARIN 34
ARIN PPC at NANOG 63

ARIN Advisory Council:

AC Shepherds:
Robert Seastrom, Kevin Blumberg

 

ARIN Board of Trustees:
Revisions Implementation

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.

 

#####

Older version

Draft Policy ARIN-2014-6
Remove 7.1 [Maintaining IN-ADDRs]

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.

 

ARIN Staff and Legal Assessment

ARIN-prop-2014-6 – “Remove 7.1”

Date of Assessment: 04 Mar 2014

1. Summary (Staff Understanding)

This proposal would remove NRPM section 7.1 on the grounds that it is missing rules on ip6.arpa and that it is not based on any RFC, but rather on operational practice.

2. Comments

A. ARIN Staff Comments

· Staff believes that the removal of section 7.1 would have no operational impact.

· This proposal could be implemented as written.

B. ARIN General Counsel - Legal Assessment

The policy does not create legal concerns.

3. Resource Impact

This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees.

4. Proposal Text

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:

 

 

Advanced Search

Relevant Links