[ppml] Policy Proposal: Modification to Reverse Mapping Policy

Scott Leibrand sleibrand at internap.com
Thu Sep 13 13:20:17 EDT 2007


ARIN's current lame delegation procedure allows a customer to exclude 
their zone from lameness testing on the grounds that the reverse DNS 
services for the zone are not reachable by ARIN.  I presume such policy 
would allow your customer to tell ARIN "yes, it's supposed to be that 
way", and then ARIN would leave them alone.  I don't think anyone is 
trying to change that, nor should we.


michael.dillon at bt.com wrote:
>> Why should ARIN give out referalls to servers that 
>> *intentionally* timeout?
> Because ARIN's customer asks them to do this.
>> Why should ARIN be a party in wasting other people's time and 
>> resources?
> Because the people whose resources are being wasted are customers of the
> organization which intentionally has their servers timeout.
> About a year ago, I was called in to help sort out a major incident for
> a customer of ours. Our customer was providing a service over the
> network to hundreds of their customers. This service was delivered by an
> application which their customers ran. One day last year, hundreds of
> these customers were unable to login to the service at the beginning of
> the day.
> The cause? Verisign, in their wisdom, had cleaned up a bunch of lame
> delegations in the .com zone by replacing the registered nameservers
> with two nameservers in lame-delegation.org. The application that our
> customer provides their customers, depends on a certain domain being
> lame, and when it did not get the correct error, it was unable to
> connect to it's servers. 
> That's right, I said CORRECT ERROR. I didn't design the application, but
> that is how it works. The solution was to put back the lame delegation
> in the .com zone, and then to transfer the registration to another
> registrar who will ensure that the lame delegation is left untouched in
> the future. 
> I have no problem with ARIN auditing the behavior of nameservers
> registered for in-addr.arpa, and I have no problems with ARIN contacting
> the right people (not the wrong people) at the organizations to discuss
> the results of said audits. But I do have a problem with ARIN removing
> records when a nameserver is "intentionally" lame.
> ARIN is not the Internet police. ARIN allocations are used for many
> other networks other than the Internet. ARIN currently does not maintain
> the right contact info (DNS administrators) for organizations.
> And most of all, punitive policy sets a bad precedent for ARIN when we
> can expect increasing scrutiny of our activities due to IPv4 exhaustion
> looming.
> --Michael Dillon
> _______________________________________________
> 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.

More information about the ARIN-PPML mailing list