[arin-ppml] Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text

[ARIN]

Recommended Draft Policy ARIN-2014-6
Remove Operational Reverse DNS Text

On 19 March 2015 the ARIN Advisory Council (AC) recommended
ARIN-2014-6 for adoption, making it a Recommended 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 Draft Policy 2014-6 on the PPML prior to
the upcoming ARIN Public Policy Consultation at ARIN 35 in San Francisco 
in April 2015. Both the discussion on the list and at the meeting will 
be used by the ARIN Advisory Council to determine the community 
consensus for adopting this as policy.

The ARIN Policy Development Process 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)


## * ##


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

Date: 21 January 2014

AC's assessment of conformance with the Principles of Internet Number 
Resource Policy:

2014-6 enables fair and impartial number resource administration by 
removing technical statements that are not related to number policy from 
the NRPM. It is technically sound to remove operational practice from 
the NRPM; indeed this act serves as a forcing function for a best 
practices document that is both more detailed and more approachable than 
the policy statement that was removed. Discussion of the previous 
revision of 2014-6 centered around "why are you fixing this for IPv4 and 
not IPv6", and the most recent changes reflect that community feedback. 
There has not been notable opposition to the notion of removing 
operational language from the NRPM.

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.

#####

ARIN STAFF & LEGAL ASSESSMENT

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

Date of Assessment: March 17, 2015

1. Summary (Staff Understanding)
This proposal would remove 6.5.6 and 7.1, thus removing reverse DNS 
language from the NRPM.

2. Comments
A. ARIN Staff Comments
This change to NRPM will not change the DNS service that ARIN performs. 
This proposal can be implemented as written.

ARIN registration services staff occasionally receives a telephone or 
email inquiry asking how reverse DNS services can be set up for a 
company. In the cases the company is a downstream customer of an ISP who 
has received a direct allocation from ARIN, staff explains this service 
can be set up for them by their service provider. On rare occasion, the 
company presses for a reference that states this is done by their ISP, 
and not ARIN. In those cases staff will refer them to the language 
currently in the NRPM.

In the case the language is removed from NRPM, ARIN staff will create a 
resource for the ARIN public website that describes how ARIN's Reverse 
DNS services are provided; including who is able to establish Reverse 
DNS service for different types of registration records.

B. ARIN General Counsel – Legal Assessment
The policy does not create legal concerns.

3. Resource Impact
This policy would have minimal impact from an implementation standpoint. 
It is estimated implementation would occur within 3 months after 
ratification by the ARIN Board of Trustees. The following tasks will be 
completed for implementation:
Versioned change to NRPM
Updated guidelines on ARIN website describing reverse DNS services (to 
act as general information resource and serve as new reference point for 
situation described in staff comments).
Staff training

4. Proposal / Draft Policy Text Assessed

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

Date: 21 January 2015

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.