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

[Ted Mittelstaedt]

>-----Original Message-----
>From: Brian Dickson [mailto:briand at ca.afilias.info]
>Sent: Tuesday, September 11, 2007 2:33 PM
>To: Ted Mittelstaedt
>Cc: John Von Essen; Public Policy Mailing List
>Subject: Re: [ppml] Comments on ARIN's reverse DNS mapping policy
>
>
>Ted Mittelstaedt wrote:
>> There have
>> been enough postings on
>> this topic for you to get an idea of what would happen to such a
>proposal -
>>
>There have been enough people commenting on their misinterpretation of
>John's observation (complaint),
>and the underlying technical issue, that the proposal would need to be
>very clearly written to avoid this.
>
>That said, the *actual* issue, if addressed, most certainly would be
>in-scope for RIR policies, and as such
>would be suitable for normal discussion, and likely would get support,
>enough to be adopted as policy.

Go for it, man.  I still don't think it will pass.  I have seen many
reasonable proposals get shot down already.  Such as ones requiring
legacy holders to return unused IPv4 addressing.

>>   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.
>>
>If that is what you think the issue is, then I think you misread the
>original message and several of the follow-ups.
>
>The issue isn't the *content* (present or absent) of the in-addr zone
>that has been delegated, it is that the server to which
>the delegation has been made, fails to answer queries for the *specific*
>in-addr zone. It is lame *for that zone*.
>

I understand that, no that wasn't the issue I was bringing up.   What I
was pointing out is John's original assumption insofar that he was taking
the ISPs excuses at face value.

>[discussion relevant only to non-lame zones with no PTRs in them,
>omitted for brevity.]
>> As for your GoDaddy scenario, well the application controls UDP timeout.
>The problem is fundamentally tied to resolvers. Unless the application
>is doing a roll-your-own implementation
>of name resolution, it is likely sharing a common fate with all clients
>of resolution service on whatever box is acting as a recursive resolver.
>
>Tweaking timeouts on nameserver lookups is something, to paraphrase
>Randy Bush, I encourage anyone foolish enough to want to, to do so.

I disagree the problem is tied to resolvers.  The original Godaddy scenario
is that if godaddy does a PTR query that fails that it ties up resources.
This is true - but the resources it ties up are -not- resolver or
network resources.  They are server resources.  If "everyone on the Internet
did this" then assuming Godaddy's mailservers started a process for each
incoming SMTP and waited around for 5 minutes for a response, you have 5
minutes that a very significant large memory consumptive SMTP process is
sitting in core ram waiting.  You get hundreds of these doing that and
for sure your going to seriously impact your SMTP receiver.  That is why
I said to fix that they can adjust their application timeout timers
for the SMTP application accepting the incoming mail.  Not to adjust
timeouts
in the resolver.

>From the resolvers POV it's going to get a PTR query for every incoming
mail anyway no matter if a in-addr.arpa exists or not.

Or perhaps there is some other aspect of the example I'm missing?

>> Take care!
>> Ted
>>
>If you were to "take care" yourself and read and understand what the
>original poster said, IMHO reasonably clearly and with all due emphasis,
>you would have been able to avoid making your misunderstanding so
>visible on a public mailing list. No offense intended.
>

None taken since I don't think you got the point of my response.  Since you
like things simple I'll summarize:

1) His proposal won't pass.
2) His ISP knows what they are not doing, and is being a lying jerk to him.
3) Even if his proposal does pass unless it has teeth it won't have
any value to compel a jerk ISP to stop being a jerk ISP.
4) If it has teeth it definitely won't pass since people don't support
proposals that have teeth.
5) The problem the proposal purports to solve can be worked around so
people will use that as yet another excuse to not support it.

It would be nice to be proved wrong and see the policy process actually
produce a policy that had some teeth and solved a problem.  God knows
it's failed miserably with the IPv4 pending runout problem.

Ted