[ppml] Policy Proposal: Modification to Reverse Mapping Policy

[Scott Leibrand]

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.
>