[ppml] Policy Proposal: Modification to Reverse Mapping Policy

Thu Sep 13 18:19:14 EDT 2007

John Von Essen wrote:
> Below are three Org's that are examples of partially lame. Several 
> in-addr.arpa's in their range correctly return an SOA request, but the 
> /24 prefixes listed below do not. These three were actually quickly 
> gathered by just trial and error. Cavalier is the ISP I have been 
> having trouble with, Cogent was a pure guess (I had a feeling they'd 
> be doing something wrong somewhere, so I just tested some random 
> ranges, and in a few minutes found a few culprits), and Interland is a 
> large hosting provider. Took about 10 minutes to find these. If I had 
> all day, I could probably find many more.
>
>
>
> Cavalier Telephone
> Ord ID: CTLL
> NetRange:   76.160.0.0 - 76.161.255.255
> NameServer: DNS01.CAVTEL.NET
> NameServer: DNS02.CAVTEL.NET
> Lame in-addr.arpa zones for Org CTLL:
> 76.161.193.0/24 - Is advertised by AS16810 
> 76.161.194.0/24 - Is advertised by AS16810
> 76.161.195.0/24 - Is advertised by AS16810
> and there are more

As far as I can tell this is not an example of a partially lame 
registration.  It appears to me that both /16 delegations are fully 
lame, so this should be covered under existing policies and procedures.
>
>
> Cogent Communications
> Ord ID: COGC
> NetRange:   66.250.0.0 - 66.250.255.255
> NameServer: AUTH1.DNS.COGENTCO.COM
> NameServer: AUTH2.DNS.COGENTCO.COM
> Lame in-addr.arpa zones for Org COGC:
> 66.250.60.0/24 - Is advertised by AS174
> 66.250.61.0/24 - Is advertised by AS174
> and there are more

This one is a case of lame subdelegations.  The /16 delegation from ARIN 
to Cogent is fine.  It's (some of) Cogent's /24 subdelegations to their 
customers that are lame.  In my opinion that's not directly ARIN's problem.
>
>
> Interland, Inc.
> Org ID: INTD
> NetRange:   209.237.128.0 - 209.237.191.255
> NameServer: A.NS.MYREGISTEREDSITE.COM
> NameServer: B.NS.MYREGISTEREDSITE.COM
> Lame in-addr.arpa zones for Org INTD:
> 209.237.139.0/24 - Is advertised by AS36476
> 209.237.140.0/24 - Is advertised by AS36476
> and there are more

This one is the only one of these that truly appears to be partially 
lame.  129.237.209.in-addr.arpa. returns SOA, but others do not.

It appears to me that this would indeed be newly covered under your 
revised policy.  However, I'm still undecided whether such procedural 
changes require policy changes as well, or whether we could get 
http://www.arin.net/reference/lame_delegations.html updated via the 
suggestion/consultation process (ASCP), and accomplish the same thing 
without having to redefine policy (thereby leaving more operational 
discretion to ARIN staff).  I suppose the ARIN AC will decide at their 
next meeting whether they think this policy proposal would best be 
addressed through the public policy process or the suggestion and 
consultation process.

-Scott
>
>
>
> -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 <mailto: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 <mailto: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 <mailto: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 <mailto:info at arin.net> if you experience 
>> any issues.
>
> Thanks, 
> John Von Essen
> (800) 248-1736 ext 100
> john at quonix.net <mailto:john at quonix.net>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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.
>   