[ppml] Policy Proposal: Modification to Reverse Mapping Policy

[Linda]

Policy Proposal: Modification to Reverse Mapping Policy


I oppose this proposal, this is an operational issue.

Regards,
Linda Werner
Satellite Communication Systems, Inc.

> ----- Original Message ----- 
> From: "Member Services" <info at arin.net>
> To: <ppml at arin.net>
> Sent: Wednesday, September 12, 2007 11:06 AM
> Subject: [ppml] Policy Proposal: Modification to Reverse Mapping Policy
>
>
>> 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
>>
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the ARIN 
>> Public Policy
>> Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN 
>> Member Services
>> Help Desk at info at arin.net if you experience any issues.
>>
>>
>