[ppml] Policy Proposal: Modification to Reverse Mapping Policy

Ted Mittelstaedt tedm at ipinc.net
Wed Sep 12 15:00:37 EDT 2007


Don't forget to include the examples of how attempting to resolve these
through
normal operational procedures have failed.

Ted
  -----Original Message-----
  From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of
John Von Essen
  Sent: Wednesday, September 12, 2007 10:25 AM
  To: Public Policy Mailing List
  Subject: Re: [ppml] Policy Proposal: Modification to Reverse Mapping
Policy


  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/2bb6b2ba/attachment.html>


More information about the ARIN-PPML mailing list