[ppml] Comments on ARIN's reverse DNS mapping policy
John Von Essen
john at quonix.net
Tue Sep 11 17:32:34 EDT 2007
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/cc993a5a/attachment.htm>
More information about the ARIN-PPML
mailing list