[ppml] Policy Proposal: Modification to Reverse Mapping Policy

Wed Sep 12 13:24:41 EDT 2007

Yes,

I have several examples of what I call partially lame dns servers.  
Let me put together a more in-depth list with prefixes from several  
different providers, and I'll email it to the list later today.

-John

On Sep 12, 2007, at 12:36 PM, Scott Leibrand wrote:

> John,
>
> Do you have any examples of Partially Lame Delegations (or, to use
> Brian's slightly more precise terminology, Lame Zone Delegations to a
> non-Lame Server)?  I'm not opposed to your policy rewrite, but I'm as
> yet unconvinced that we have a real life non-hypothetical problem that
> can't be fixed by application of current policies and procedures.
>
> Thanks,
> Scott
>
> Member Services wrote:
>> 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.
>>
> _______________________________________________
> 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.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070912/e5c01afd/attachment.htm>