[120140] in North American Network Operators' Group
Re: best practices for PTR naming and whois (was, sadly, Re:
daemon@ATHENA.MIT.EDU (Steven Champeon)
Thu Dec 10 13:02:38 2009
X-Received-From: schampeo@tabasco.hesketh.com
X-Delivered-To: <nanog@nanog.org>
Date: Thu, 10 Dec 2009 13:01:29 -0500
From: Steven Champeon <schampeo@hesketh.com>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <4B212F90.90201@mtcc.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
on Thu, Dec 10, 2009 at 09:27:44AM -0800, Michael Thomas wrote:
> On 12/10/2009 09:06 AM, Joe Abley wrote:
>> I think Mark means "the question of whether a particular address is
>> statically-assigned or dynamically-assigned", but...
>
> Which assumes that that's the question that actually needs to be answered.
Well, it seems to be a question that folks at MAAWG are currently trying
to answer; I know of at least one effort to coordinate standard means of
publishing your "dynamics" between various MAAWG members, so it seems to
be a question that does need to be answered. I'd agree that it's not the
only question - see my post on why we consider generic statics suspect.
I think in the end, we'll see anyone without a custom, clear, legible,
name indicating that a host should be sending mail simply having their
mail refused.
>> ... I agree that there's no clear limit to the kind of questions we could
>> come up with that we could answer in such a way. Maybe we don't need to
>> boil the ocean, though.
>
> Sure, but positing the deployment of any infrastructure comes at a
> huge cost.
Yeah, for example, it took Road Runner something on the order of 18
months to move all of their residential account PTRs under 'res.rr.com',
and their business class under 'biz.rr.com'. They're a bit of a special
case, as they're more of a franchise than a single entity, but still.
They came to realize that doing so was useful and good, so they did it.
And kudos to them for doing so.
> Making certain that you're solving the right problem should be the first
> concern, since it's so expensive.
All I'm saying, and feel free to do with this what you will, is that
there is a demand for means for assigning reputation to IPs based partly
on their PTR records; antispam appliance vendors, reputation service
providers, carrier class cable and telco companies and ISPs, are all
exploring or actively using PTR naming classification as one of those
means. You can either recognize this and make your networks more
transparent to such enquries, or not. Whois is not the only answer;
without a way to quickly associate a PTR with a whois record that
happens to say "dynamic residential" or "static business" (to use the
most broad of available classifications) in real time by DNS lookup or
other means, your detailed whois records are useless in direct,
practical terms, to postmasters and spam filtering software and others.
Spamhaus PBL is one answer, mapping IPs based on ISP-provided
information or Spamhaus researcher-discovered information, into zones to
be used for rejecting mail. SORBS DUL works in similar way, and makes
assumptions on the basis of rDNS scans at the /24 level (among other
mechanisms). Enemieslist uses whatever information we can to classify
PTR naming; whois, Web sites, price lists and a la carte menus ("do they
charge extra for static IPs?", "do they even provide static IPs?", etc.)
and then bases that classification on the name of the remote host at
connect time - so we don't have the same "falls in a suspicious /24"
problem seen so often with SORBS and now MAPS DUL, but just because a
customer /can/ ask for and pay for and receive a custom PTR for their
mail server doesn't mean they always do - just that over time, they will
have to or face poor deliverability, hassles, and the like.
But the bottom line is that failure to provide transparency via PTRs is
a problem, particularly for deliverability, whether directly (your mail
server is named "rrcs-12-34-56-78.se.biz.rr.com", which is static but
generic, so would be scored suspicious via Enemieslist) or indirectly
(your mail server is in a block of generic PTRs that may be static or
dynamically assigned based on vague rDNS, so it ended up in a SORBS DUL
listing) or (your mail server is in a block with no custom rDNS that the
whois record doesn't indicate is static, so ended up in a PBL listing
due to lack of cooperation from the ISP), and so on and so on.
Of course it makes it easier for me, and Spamhaus, and SORBS, and Trend,
if the networking community helps us make these determinations and pass
along the proper and appropriate classifications, so that our users and
licensees can use our data to make fine-grained policy decisions. Also
true is that doing this stuff right can be difficult, or expensive, but
I think the point to take away here is that it's already being done,
and you can either help, or be an obstacle to progress.
Asking whether this is "the right question" isn't terribly helpful
/now/, given that debates have raged here and on mailop and in other
forums for years. I prefer to look at the available data (spamtraps,
filters, mail flow analyses, etc.) and do something /now/ that is
helpful to people wishing to ameliorate abuse /now/. And for the moment,
as for the past six years, associating classifications with PTRs based
on their naming is a very effective strategy, and one which we're going
to continue to use.
Steve
--
hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/
antispam news and intelligence to help you stop spam: http://enemieslist.com/
