[ppml] Policy Proposal: Modification to Reverse Mapping Policy
John Von Essen
john at quonix.net
Thu Sep 13 01:00:53 EDT 2007
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
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
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
-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/20070913/35f4f0f2/attachment.htm>
More information about the ARIN-PPML
mailing list