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

Tue Sep 11 17:07:14 EDT 2007

John,

  Sorry for the top post but allow me to interject my $0.02 here.

  The purpose of this mailing list is to flesh out proposals.  There have
been enough postings on
this topic for you to get an idea of what would happen to such a proposal -
it would be voted
down as it's not in the RIR's scope of responsibilities.  I therefore think
your wasting your time
filing a proposal.

  Now I have read your ranting and some of the responses.  But there is one
response that I
didn't see and that you obviously didn't consider.  In my opinion, the
network manager at
your ISP is fully aware of the PTR issues and has chosen to DELIBERATELY not
entered
the in-addr.arpa zone for your numbers.

  "Why would those bozos do this" I hear you ask.  Very simple.  I am
assuming from the
background information you have posted that your DSL account is a simple
retail DSL account.
Well, the ISP that your buying it from may not want you running servers on
that account.
Nor may they not want you making direct SMTP connections to other people's
mailservers from
that IP address.  They have their own mailserver - maybe they think if you
want to relay outbound
mail then relay it through their server.

  Most of the gloom-and-doom scenarios you describe about the lack of PTR
records
simply do not apply.  We have NEVER had valid PTR's on our modem dialup IP
pools
for the simple reason that in any given time at least 20% of our modem
customers are
running systems that are infected with SMTP mailer viruses.  If one of our
infected
customers transmits spam to a destination mailserver, it is very simple for
that server
to reject the SMTP handshake on a failure to have either a forward or a
reverse record
in the DNS without having to spend lots of CPU time scanning the message for
spamliness.

And sure, we could block
outbound SMTP - which then is going to cause other complaints, plus there is
the
philosophical argument about blocking.  A dialup user could have a perfectly
legitimate need for
outbound SMTP so why block.  By contrast, chances a user would have a
legitimate
need for in-addr.arpa is far lower, and much easier to accomodate in any
case.

  As for our DSL customers, we do not by default add in PTR records
(although we do
have the in-addr.arpa zones properly setup and referred to the nameserver)
If you were our
customer and you called complaining I would have a very serious and long
discussion with
you to figure out exactly what you were doing and whether you were violating
any of our
AUPs.  Assuming you were in the category of "home user that wants to dink
around with
a personal mailserver" I'd set it up for you.  We have a number of those.
But, if your
trying to scam us, that would be a different story.

  We have had, for example, people in the past who have purchased
RESIDENTIAL
dsl accounts from us then attempted to setup a mailserver using fetchmail or
some
such at a business site.  Not all businesses use commercial buildings or
have business
telephone numbers and it's possible for some of them to slip in a
residential order without
the ISP knowing.  Those customers then find a month into it that a large
percentage of their
outbound mail is spam-blocked by other ISPs for failure to have proper DNS
setup - they
then call us complaining and that flushes them out of the woodwork.  To get
the desired
DNS mapping they have to pay more money for a business account, of course.
(and
usually most of them do, with a comment along the lines of "I guess ya
caught me")

Today with organizations like dydns.org who's sole purpose is to assist
businesses to cheat ISP's, there are not a lot of tools an ISP has at it's
disposal to
catch cheaters that don't have a lot of side effects.  Control of
in-addr.arpa records
is one of the few.  I am not saying it is a great way.  But dydns.org is a
far, far more horrible
hack.  I have seen cheaters setting up DNS records with SOA timers set at
under a minute,
causing virtually EVERY SINGLE dns query for their domain to cause a root
server query -
costing the Internet hundreds of dollars of extra network load a month just
so the cheater
can save $20 a month on a business DSL line.  If you want to start throwing
around
policy proposals to police the Internet well then how about a minimum DNS
expiration
requirement of 6 hours?  Don't start with the stone throwing if your sitting
in a
glass house.

As for your GoDaddy scenario, well the application controls UDP timeout.  If
GoDaddy
is finding - like we have found with our own mailservers - that a 5 minute
retry timeout is
to long for a missing PTR check, then it is trivial to change the sendmail
config to lower
the timeout.  So, people not loading in-addr.arpa isn't going to be a
problem for them any
more than it's a problem for us for other ISP's who also don't load
in-addr.arpa

As for Telnet and SSH yes well that is an annoyance if your setting a SSH or
Telnet server
up on your DSL line and you want to telnet into it.  But the vast majority
of users don't
do this.

Your story sounds like your just being given the usual brush-off by your
ISP, they are pretending they are stupid about this issue, because they
don't want
to engage you in a discussion to explain their reasons for not setting up
in-addr.arpa
I noticed your mail is coming from 76.161.192.192 so you obviously figured
out how
to get a static IP that doesen't have this problem.  I would submit that
your real beef
is that you want to pay residential rates on a dynamic IP not business rates
on a
static IP.  I would also ask you if you would like it if one of your
business customers on
quonix.net were to setup a bunch of mailboxes ostensibly for users in their
business,
when in reality they were doing a fetchmail solution for a bunch of other
companies
and using you merely as a spam filter, and reselling your service (and
making far more
money doing that then your making from them)

Take care!
Ted

-----Original Message-----
From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of John
Von Essen
Sent: Tuesday, September 11, 2007 11:31 AM
To: Public Policy Mailing List
Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy

Well, I for one would like to take on this project. How does one begin to
submit a policy proposal?

-John

On Sep 11, 2007, at 2:15 PM, cja at daydream.com wrote:

If the policy needs updating I really hope one of you will take on the
project and submit suggested changes in the form of a policy proposal. There
are a number of us on the AC who are more than willing to help and shepherd
it through the process. The great thing about the policy process is that if
you don't like a policy you can take action and fix/change it.

Thanks!
----Cathy

On 9/11/07, John Von Essen <john at quonix.net> wrote:
Identical issues to what I am experiencing. If people look deeply enough, I
am confident there are many Org's who operate AS's with no in-addr.arpa SOA
on there DNS servers.

If anything, can we agree on the fact the current policy is too vague. I had
to email ARIN's hostmaster 2 or 3 times to understand it - it can be read
many ways. And the explanation I got from hostmaster was if an AS properly
configures at least one in-addr.arpa zone, then Arin will bless the entire
delegation and not consider the dns server as lame. To be honest, I have no
idea how one draws that conclusion from the wording on the policy.

DNS is a standard protocol. The policy should specifically state the dns
servers must return a valid SOA for each in-addr.arpa in their IP prefix
that they advertise from their AS (i.e. they dont have to do it for IPs they
dont use). If any in-addr.arpa does not return an SOA, then that AS is in
violation, and their nameserver will be considered lame and suspect for
removal from reverse delegation.

I dont think it is a requirement that ARIN proactively seek and find AS's
that are in violation, but it should be in the policy.

Those 2 or 3 sentences are all that is needed.

On Sep 11, 2007, at 12:08 PM, Sam Weiler wrote:

dig +trace 79.114.208.in-addr.arpa.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net

_______________________________________________
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.

Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net