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

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: http://lists.arin.net/pipermail/ppml/attachments/20070911/cffd25cc/attachment.html