[ppml] Comments on ARIN's reverse DNS mapping policy

[Azinger, Marla]

Well, as Randy pointed out ...maybe I am leaping a bit.  But I have had circular conversations where that wasnt viewed as such a leap.  Be it strictly routing or dns success/failures, they both have fallen into the  "it shouldnt be dictated by ARIN" conversations.  And I guess pointing out in an obviouse way that they shouldnt be in the same conversation is needed.  So...thanks Randy for getting me thinking straight again.
 
So to your point John, I would say its worth writing up and submitting it.  Clearly you have good rational and a need.  I would be interested to see how many people would support it and what type of Con's would be pointed out.  
 
Cheers!
Marla

[Azinger, Marla]  -----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of John Von Essen
Sent: Monday, September 10, 2007 9:38 PM
To: Public Policy Mailing List
Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy



Randy - Thanks, you are the first person to not write this off as a "find another ISP" comment. 

Maria, I understand your comments, but consider this... The current policy on reverse dns mapping "almost" does the job - it just needs to go a tiny bit further. 

Current policy dictates that you have to map an in-addr.arpa zone for your prefix in order for your nameservers to not be considered lame.

Problem is, an AS only has to properly map a single in-addr.arpa to satisfy that requirement. What I am saying is just go a bit further, and have policy dictate that the AS must properly map ALL in-addr.arpa's for advertised prefixes in order for their nameservers to not be considered lame. Seems simple enough.

The problem goes beyond the ISP-to-customer scenario. Take Verizon DSL, what if they didn't map the in-addr.arpa's for all their DSL IP's - thats probably 10 or so /16's easily. That would cause tons of problems for various 3rd party organizations all throughout the internet; people like vonage (sip traffic), gmail, postini, or any large smtp environment or protocol dependent on reverse DNS.

But the current policy would not consider Verizon's reverse DNS servers as being lame. Because even though there are 1000's of in-addr.arpa zones not mapped (thereby causing excessive timeout on resolvers throughout the world), they do have one mapped to meet the minimum ARIN requirement for non-lameness. That simply doesn't make sense.

The threat of one's reverse DNS server being declared lame is the only way to ensure proper reverse DNS mapping. I dont see why 100% enforcement across all advertised prefixes for a given AS is a problem.

Lets not forget that reverse DNS plays an important role in the proper operation of many protocols throughout the internet, and one of ARINs most important jobs is delegation of reverse dns authority.  ARIN has a responsibility to make sure that the DNS server they are delegating reverse authority too is maintained to at least a minimum level of efficiency.

-John


On Sep 11, 2007, at 12:05 AM, Randy Bush wrote:


I understand your desire to make this an ARIN policy.  However, it
has long been a position of the ARIN Community (for the most part)
that ARIN policy is not to dictate or guarantee routing.


perhaps re-reading the OP's post would reveal that nothing about routing
is mentioned.

my guess is that you are making an inference from routing to reverse
dns.  but such a leap may not be completely defensible, as reverse dns
is something about which arin does have policy, just not the policy
which i think the OP wants.

many fora have looked at reverse mapping policy and not made much
progress.  this is mostly due to a large and loud contingent of "who
cares?  it does not matter.  those who check are <bleep>s.  etc."

the problem is that it is the user (that silly person who pays all our
salaries) who gets screwed, as you can see from the whining of this
particular screwee.  most do not know why they get long hangs when doing
simple things, they think crap is normal.  perhaps it should not be.

randy



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/20070911/b15ef28c/attachment.htm>