Your IP address could not be determined at this time.

Draft Policies and Proposals

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

Last Call - 27 April through 11 May 2015

 
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

Recommended Draft Policy - 24 March 2015

Last Call - 27 April through 11 May 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 35

ARIN Advisory Council:

AC Shepherds:
Robert Seastrom, Kevin Blumberg

 

ARIN Board of Trustees:
Revisions Implementation

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.

 

#####

Earlier 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.

Advanced Search

Relevant Links