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

Hyunseog Ryu HRyu at norlight.com
Mon Sep 10 22:26:05 EDT 2007


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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070910/fbbd1a57/attachment.html>
-------------- next part --------------
_______________________________________________
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.


More information about the ARIN-PPML mailing list