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

[Azinger, Marla]

Hi John-
 
Thank you for posting for the first time.  
 
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.  Thus, the majority of the responses you will get here will have people telling you to go find a new ISP that has a clue.  I hate to say it, but that is what I would suggest too.  Hopefully you are in a location that provides you the opportunity to shop around for a clueful ISP.
 
If you really think policy of some kind may help, your best bet is collecting up RFC and BCP's written within the IETF that address cluefull mapping of in-addr.  
 
Cheers!
Marla Azinger
Frontier Communications

-----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 7:14 PM
To: Public Policy Mailing List
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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070910/38a4425b/attachment.htm>