[ppml] Comments on ARIN's reverse DNS mapping policy
Ted Mittelstaedt
tedm at ipinc.net
Tue Sep 11 17:43:21 EDT 2007
Hi John,
No, I understood perfectly that is why I took pains to explain that while
we don't put in
PTR records we do have the in-addr.arpa stuff setup for our in-use numbers
in our block.
What I was trying to make as a point is that your assuming your ISP forgot
to put
them in. I'm saying they may be deliberately not putting them in precisely
to create those
annoying long timeouts.
Note this doesen't qualify as a DDoS attack because the delays don't happen
if the
recipeint TCP host doesen't do a PTR query. There's no requirement in the
standard
that requires a host like a mailserver or suchlike to do a reverse record
lookup.
I didn't say this was optimal.
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 2:33 PM
To: Public Policy Mailing List
Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy
Ted,
Your are making the same incorrect judgement over my original post.
Let me repeat, the issue is NOT about ISP's and forcing them to have PTRs.
I agree with you, the ISP doesn't need to have a PTR record for DSL IPs.
It even helps curb spam.
But that is not the issue.
The issue is the ISP is operating a given IP range, say 5.5.5.0/24, and
the DNS server that ARIN delegates reverse authority to does NOT have the
5.5.5.in-addr.arpa zone conigured at all, which means there is no SOA or NS
record for in-addr.arpa zone. This is all way before we get to PTR records.
The problem with this is when you try to reverse the 5.5.5.0/24 IP you get
a long timeout. (See dig +trace 191.161.76.in-addr.arpa.) If they map the
in-addr.arpa zone, and decide to NOT enter any PTR's (which is okay) a
reverse query would immediately return NXDOMAIN error, thereby not causing a
timeout.
So why is this an issue?
Creation of that timeout extends beyond the ISP's local customer base. It
effects 3rd party's that the ISP customer talks to. So the ISP is purposely
creating excessive dns query timeouts on 3rd party resolvers because they
failed to do a simple, and what I believe to be a required task - which
is... mapping all in-addr.arpa's with at least an SOA and NS record. Last
time I checked, causing excessive resource utilization on somebody else's
system is called a DoS attack.
It is my opinion that if large scale abuse like this were to continue and
grow, it could develop into a serious issue affecting global DNS resolver
health. I feel ARIN policy has a responsibility to curb this potentional
anomaly.
So please, no more posts about... "ISP's dont have to have PTR's". If you
are making that statement, you are completely missing the point of the
initial argument.
-John
On Sep 11, 2007, at 5:07 PM, Ted Mittelstaedt wrote:
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
Thanks,
John Von Essen
(800) 248-1736 ext 100
john at quonix.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070911/cffd25cc/attachment.htm>
More information about the ARIN-PPML
mailing list