<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 6.00.2900.3157" name=GENERATOR></HEAD>
<BODY 
style="WORD-WRAP: break-word; khtml-nbsp-mode: space; khtml-line-break: after-white-space">
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff size=2>Hi 
John-</FONT></SPAN></DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff size=2>Thank 
you for posting for the first time.  </FONT></SPAN></DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff size=2>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.</FONT></SPAN></DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff size=2>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.  </FONT></SPAN></DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff 
size=2>Cheers!</FONT></SPAN></DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff size=2>Marla 
Azinger</FONT></SPAN></DIV>
<DIV><SPAN class=978083603-11092007><FONT face=Arial color=#0000ff 
size=2>Frontier Communications</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> ppml-bounces@arin.net 
  [mailto:ppml-bounces@arin.net]<B>On Behalf Of </B>John Von 
  Essen<BR><B>Sent:</B> Monday, September 10, 2007 7:14 PM<BR><B>To:</B> Public 
  Policy Mailing List<BR><B>Subject:</B> [ppml] Comments on ARIN's reverse DNS 
  mapping policy<BR><BR></FONT></DIV>Disclaimer: This is my first post, so be 
  kind!
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV>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.</DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV>First, let me describe the scenario that spawned all of this.</DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV>1. I signup for DSL and receive an account with an IP address that does 
  not resolve.</DIV>
  <DIV>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.</DIV>
  <DIV>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.</DIV>
  <DIV>4. Contact ISP to resolve, no luck.</DIV>
  <DIV>5. Contacted ISPs ARIN Tech/Abuse/NOC POCs, still no luck.</DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV>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.</DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV>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.</DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV>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.</DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV>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? </DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV>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.</DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV><BR class=khtml-block-placeholder></DIV>
  <DIV><BR>
  <DIV><SPAN class=Apple-style-span 
  style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; khtml-text-decorations-in-effect: none; apple-text-size-adjust: auto; orphans: 2; widows: 2"><SPAN 
  class=Apple-style-span 
  style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; khtml-text-decorations-in-effect: none; apple-text-size-adjust: auto; orphans: 2; widows: 2"><SPAN 
  class=Apple-style-span 
  style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; khtml-text-decorations-in-effect: none; apple-text-size-adjust: auto; orphans: 2; widows: 2"><SPAN 
  class=Apple-style-span 
  style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px 0px; khtml-text-decorations-in-effect: none; apple-text-size-adjust: auto; orphans: 2; widows: 2">
  <DIV>Thanks, </DIV>
  <DIV>John Von Essen</DIV>
  <DIV>(800) 248-1736 ext 100</DIV>
  <DIV>President, Quonix Networks, Inc.</DIV>
  <DIV><A href="mailto:john@quonix.net">john@quonix.net</A></DIV><BR 
  class=Apple-interchange-newline></SPAN></SPAN></SPAN></SPAN></DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>