
<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">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="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><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></BODY></HTML>