<!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>