Recommended Draft Policy ARIN-2014-6: Remove Operational Reverse DNS Text [Archived]
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.
Status: Implemented 29 July 2015
Tracking Information
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
AC recommended Board adopt - 26 May 2015
ARIN Public Policy Meeting:
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
-
Summary (Staff Understanding)
This proposal would remove 6.5.6 and 7.1, thus removing reverse DNS language from the NRPM. -
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.
-
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 -
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.
OUT OF DATE?
Here in the Vault, information is published in its final form and then not changed or updated. As a result, some content, specifically links to other pages and other references, may be out-of-date or no longer available.