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

Couple of quick points.

I have spent three weeks with the ISP, and they are either  
incompetent or unwilling to resolve, or both.

And it is definitely not a case of them rolling out a new /24 and  
simply forgetting to add it to their DNS server. I have done some  
digging around, and they have massive amounts of IPs ranges that have  
no in-addr.arpa mappings.

I understand some people think that this is an ISP-and-customer  
issue, but when an ISP who has a /16 or larger assignment and they  
engage in activity that literally slows down external resolvers  
throughout the internet by causing tons of excessive reverse DNS  
timeouts, I do feel it is ARIN's responsibility to have a policy that  
will official denounce this practice

-John


On Sep 10, 2007, at 10:26 PM, Hyunseog Ryu wrote:

>
> I don't think this should be considered as policy discussion.
> It's their way to manage reverse zone data.
> it seems to me that they have inverse dns setup for allocated ip  
> block, but they don't maintain the data as up-to-dated.
> It should be dealt between you and your ISP, and there is not much  
> ARIN can do.
> If your ISP doesn't update reverse DNS data for your IP, it's their  
> customer case handling problem.
> You can escalate the case with your ISP, or find somebody else.
> This is my humble opinion.
>
> Hyun
> Sent from blackberry on the road
>
>  ----- Original Message -----
>   From: John Von Essen [john at quonix.net]
>   Sent: 09/10/2007 10:14 PM AST
>   To: Public Policy Mailing List <ppml at arin.net>
>   Subject: [ppml] Comments on ARIN's reverse DNS mapping policy
>
>
> Disclaimer: This is my first post, so be kind!
>
> A run-in with a local ISP in my area was a cause for concern. That  
> lead me to a closer understanding of ARINs reverse DNS policy, then  
> an email to ARINs hostmaster, and now an email to this list.
>
> First, let me describe the scenario that spawned all of this.
>
> 1. I signup for DSL and receive an account with an IP address that  
> does not resolve.
> 2. Upon review, its more then a missing PTR, the IP I was given  
> belongs to an in-addr.arpa zone which is not mapped at all in the  
> ISP's DNS servers - the servers indicated in their IP assignments  
> from ARIN. It is not site-wide however, some in-addr.arpa's they  
> map, others they do not.
> 3. Several functions on my PC incur long reverse DNS timeouts (up  
> to 30 seconds) as a result. i.e. sending mail through smtp, telnet  
> and ssh connections, and any other protocol which natively has  
> built in reverse DNS checks.
> 4. Contact ISP to resolve, no luck.
> 5. Contacted ISPs ARIN Tech/Abuse/NOC POCs, still no luck.
>
> After contacting the ARIN hostmaster, it is my understanding that  
> under the current policy the ISP in question is not violating  
> anything. Since at least one in-addr.arpa prefix in their range is  
> properly mapped, their reverse DNS servers are not considered Lame.
>
> I do not agree with this. I feel that every prefix advertised from  
> an AS should have all of its in-addr.arpa zones mapped, that is  
> 100% compliancy for reverse DNS.
>
> I feel that the scenario of these dns timeouts is significant and  
> should be avoided. Theoretically, it is causing an environment that  
> wastes UDP connections. Consider GoDaddy's public SMTP server for  
> email customers. Every user that hits that smtp server causes a  
> reverse dns check - so a UDP connection is needed, but quickly  
> recycled because it finishes within a few milliseconds. But users  
> who come from ISPs who do not map their in-addr.arpa cause  
> GoDaddy's resolvers to open a UDP connection and wait for a  
> timeout, then retry, wait, then try secondary, server, etc.,.  
> Thereby wasting resources on GoDaddy's internal resolving DNS servers.
>
> What are other peoples thoughts on this? Could the policy be  
> updated requiring full mapping of ALL in-addr.arpa zones that an AS  
> advertises?
>
> ARIN wont have to police behavior of ISPs, just have the policy in  
> place so the community can say to a rogue ISP, "Hey, you violate  
> policy". Down the road automated systems would be nice to  
> automatically find AS's who violate.
>
>
>
> Thanks,
> John Von Essen
> (800) 248-1736 ext 100
> President, Quonix Networks, Inc.
> john at quonix.net
>
>
> _______________________________________________
> 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: http://lists.arin.net/pipermail/ppml/attachments/20070910/698a0c97/attachment.html