[ppml] Policy Proposal: Modification to Reverse Mapping Policy

[Member Services]

ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.

The ARIN Advisory Council (AC) will review this proposal at their next
regularly scheduled meeting. The AC may decide to:

    1. Accept the proposal as a formal policy proposal as written. If the
AC accepts the proposal, it will be posted as a formal policy proposal
to PPML and it will be presented at a Public Policy Meeting.

    2. Postpone their decision regarding the proposal until the next
regularly scheduled AC meeting in order to work with the author. The AC
will work with the author to clarify, combine or divide the proposal. At
their following meeting the AC will accept or not accept the proposal.

    3. Not accept the proposal. If the AC does not accept the proposal,
the AC will explain their decision. If a proposal is not accepted, then
the author may elect to use the petition process to advance their
proposal. If the author elects not to petition or the  petition fails,
then the proposal will be closed.

The AC will assign shepherds in the near future. ARIN will provide the
names of the shepherds to the community via the PPML.

In the meantime, the AC invites everyone to comment on this proposal on
the PPML, particularly their support or non-support and the reasoning
behind their opinion. Such participation contributes to a thorough
vetting and provides important guidance to the AC in their deliberations.

The ARIN Internet Resource Policy Evaluation Process can be found at:
http://www.arin.net/policy/irpep.html

Mailing list subscription information can be found at:
http://www.arin.net/mailing_lists/

Regards,

Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Policy Proposal Name: Modification to Reverse Mapping Policy

Author: John Von Essen

Proposal Version: 1.0

Submission Date: September 11, 2007

Proposal type: modify

Policy term: permanent

Policy statement:

I am proposing a modification to section 7 of the IPv4 policy such that
a more precise definition and overview of lameness is described.
Below is how I think section 7 should be re-written.

START NEW Section

7. Reverse Mapping

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 which start or end with a CIDR prefix
longer than /16, ARIN can maintain IN-ADDRs through the use of the SWIP
(Reallocate and Reassign) templates or the Netmod template for /24 and
shorter prefixes.

7.2 Definitions

7.2.1 Lame Delegation

A delegation is defined as being lame if all of the in-addr.arpa zones
for a given name server of a specific network registration are lame. An
in- addr.arpa zone is defined as lame when ARIN requests the SOA record
from the name server registered in whois, but does not receive an answer.

7.2.2 Partially Lame Delegation

A delegation is defined as being partially lame if at least one in-
addr.arpa zone for a given name server of a specific network
registration is lame. An in- addr.arpa zone is defined as lame when ARIN
requests the SOA record from the name server registered in whois, but
does not receive an answer.

7.3. Handling of Lame and Partially Lame Delegations in IN-ADDR.ARPA

ARIN will actively identify lame and partially lame DNS name server
(s) for reverse address delegations associated with address blocks
allocated, assigned or administered by ARIN. Upon identification of a
lame or partially lame delegation, ARIN shall attempt to contact the POC
for that resource and resolve the issue. If, following due diligence,
ARIN is unable to resolve the lame or partially lame delegation, ARIN
will update the WHOIS database records resulting in the removal of lame
or partially lame DNS servers. ARIN's actions in resolving lame and
partially lame delegations is governed by the procedures set forth in
(Lame-Ref).

7.4 References

(Lame-Ref) "Lame Delegations In IN-ADDR.ARPA", http://www.arin.net/
reference/lame_delegations.html


STOP NEW Section


Rationale:

Current policy only considers an Org's delegation being deemed lame if
all of in-addr.arpa zones for a given name server of a specific network
registration are lame. Lame is defined when ARIN tests an in-addr.arpa
zone by requesting the SOA record from the name server registered in
whois, but does not receive an answer. If deemed lame, ARIN has an
appropriate procedure for contacting the Org and handling the issue as
per "http://www.arin.net/ reference/lame_delegations.html".

Unfortunately, the policy does not cover the situation of a so-called
partially lame delegation. That is, some of the in-addr.arpa zones
belonging to the network registration return a valid SOA upon testing,
and some do not. Even if only one /24 in-addr.arpa reverse tests comes
back as lame, it is my opinion that this still taints the reputation of
entire network registration. IPs belonging to that lame in-addr.arpa
zone will cause query timeouts to 3rd party dns resolvers, both public
and private. These excessive timeouts in my opinion can harm the overall
well-being of reverse dns functionality throughout the internet. The
only way to prevent such harm is for ARIN to not delegate reverse
authority to the so-called partially lame dns server as registered in
whois. That is the purpose of this policy proposal, to consider partial
lameness with the same prejudice as traditionally defined lameness.
Org's who are partially lame should be contacted by ARIN and lame
in-addr.arpa zones should be resolved as the procedures per
"http://www.arin.net/reference/ lame_delegations.html" dictate.

Timetable for implementation: June 1, 2008