Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
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)
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 12/10/2009 09:06 AM, Joe Abley wrote: On 2009-12-10, at 16:42, Michael Thomas wrote: On 12/10/2009 08:38 AM, Mark Andrews wrote: The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records. Sigh. What is the "this" to which you refer? 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. The problem space here is what's important. And I think it's worth considering that port 25 isn't the only abuse vector anymore. ... 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. Making certain that you're solving the right problem should be the first concern, since it's so expensive. $ORIGIN 90.212.90.in-addr.arpa. @ SOA ... @ NS ... ; 13 PTR calamari.hopcount.ca. 13 HINFO Apple-Mac-Mini "Mac OS X Server" 13 RP jabley.hopcount.ca. . 13 TXT "dynamic" See, that makes the assumption that that is the right question. Is it really though? Dynamic vs static is a placeholder for "authorized for this role or not", right? And not a very good one when you start to consider the larger world of protocols. I don't think it's "boiling the ocean" to ask the question of what the producers and consumers of that information are actually looking for. Mike ; * RP jabley.hopcount.ca. . * HINFO Nothing "Unallocated" * TXT "unallocated, should source no traffic" Joe
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 2009-12-10, at 16:42, Michael Thomas wrote: > On 12/10/2009 08:38 AM, Mark Andrews wrote: > >> The way to do this is to put other data in the ip6.arpa/in-addr.arpa and >> stop trying to infer things from the PTR records. > > Sigh. What is the "this" to which you refer? I think Mark means "the question of whether a particular address is statically-assigned or dynamically-assigned", but... > The problem space here is what's important. And I think it's worth considering > that port 25 isn't the only abuse vector anymore. ... 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. $ORIGIN 90.212.90.in-addr.arpa. @ SOA ... @ NS ... ; 13 PTR calamari.hopcount.ca. 13 HINFO Apple-Mac-Mini "Mac OS X Server" 13 RP jabley.hopcount.ca. . 13 TXT "dynamic" ; * RP jabley.hopcount.ca. . * HINFO Nothing "Unallocated" * TXT "unallocated, should source no traffic" Joe
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 12/10/2009 08:38 AM, Mark Andrews wrote: In message<4b211da6.9000...@mtcc.com>, Michael Thomas writes: To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high? Mike The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records. Sigh. What is the "this" to which you refer? The problem space here is what's important. And I think it's worth considering that port 25 isn't the only abuse vector anymore. Mike
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
In message <4b211da6.9000...@mtcc.com>, Michael Thomas writes: > On 12/10/2009 07:54 AM, Steven Champeon wrote: > > In a nutshell, if you're not clearly indicating mail sources as mail > > sources, don't expect great deliverability. If you're running a Web > > hosting shop and don't have rate-limited outbound smarthosts, expect all > > your clients' mail to be suspected of being phishing scams. If you run a > > corporate network that allows unsecured outbound port 25 via NAT, you > > lose. If you run a university network (or part of one) without clearly > > distinguishing between server infrastructure and student-use end nodes, > > you really might want to rethink that. And if you're a consumer ISP that > > allows both static and dynamic assignments or serves both residential > > and commercial under the same useless generic naming convention, you are > > Making It Harder for the rest of us, which is an automatic upgrade path > > to reflexive blocking of all traffic. Oh, and if it's out of your control > > or what you consider your responsibility, SWIP it and label it clearly > > so we can figure out what it is and decide whether we want it as part > > of our view of the Internet. Keep your whois up to date and indicate > > if nothing else whether a given block is static or dynamically assigned, > > residential or corporate. > > I'd say that Mikael Abrahamsson's sentiment (or at least the way I read > it) would be a better start: take a step back and ask what the problem is. > Naming conventions blah, blah, blah all started from the _lack_ of a > standard and trying to educe knowledge from chaos. In other words, a > bunch of hacks. Which doesn't work especially well, especially when > every RBL has its own hack. > > If IETF can do something here, which seems plausible, it would be to actually > define the problem and _then_ write a protocol to fit the needs of the > problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming > conventions > (ick), probably it does not. But if it were standardized, it would at least > be predictable which the current situation manifestly is not. > > To Crocker's point though: if IETF came up with a way to publish your > network's > dynamic space (assuming that's The Problem!), would operators do that? Or is > this another case where the energy barrier is too high? > > Mike The way to do this is to put other data in the ip6.arpa/in-addr.arpa and stop trying to infer things from the PTR records. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
on Thu, Dec 10, 2009 at 08:11:18AM -0800, Michael Thomas wrote: > I'd say that Mikael Abrahamsson's sentiment (or at least the way I read > it) would be a better start: take a step back and ask what the problem is. Well, as I see it, the problem is a widespread and systemic failure to prevent massive abuses from being perpetrated by unauthorized software in the control of entities other than the administrators of those networks and servers in question, resulting in a near-total breakdown of trust in any given unknown host's reputation, resulting in desparate attempts to gain insight into which hosts might be trusted and which not, using what means may be available (naming, whois, DNSBLs, etc.) > Naming conventions blah, blah, blah all started from the _lack_ of a > standard and trying to educe knowledge from chaos. In other words, a > bunch of hacks. Which doesn't work especially well, especially when > every RBL has its own hack. Well, I'd like to think my approach (name-based, rather than IP-based) works fairly well, going as it does in the names you give your IPs and whatever other public information may be available, but I understand your frustration with the various approaches used by IP-based DULs; I can also understand the lack of patience on the side of the DUL operators. The situation is a mess. > If IETF can do something here, which seems plausible, it would be to > actually define the problem and _then_ write a protocol to fit the > needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it > uses naming conventions (ick), probably it does not. But if it were > standardized, it would at least be predictable which the current > situation manifestly is not. Like it or not, naming conventions are useful and powerful and widespread. Would you rather have to deal with inbound mail from 134.25.177.41-get-allinone-adsl-and-free-webhosting-for-only-r189.saol.com or 196-200-118.isnigeria or one-of-hosts-our-net.dn.cv.ua [194.146.136.24] or dressless-debate.volia.net [77.123.181.13] or dont-blame-admin-its-a-dsl-pool-251-41.wobline.de or cable-66-103-40-69.clarenville.dyn.personainc.net [66.103.40.69] or 200.72.157.254: pcdibujante2.eiser.local ? > To Crocker's point though: if IETF came up with a way to publish your > network's dynamic space (assuming that's The Problem!), would > operators do that? Or is this another case where the energy barrier is > too high? It's not just dynamics, either. Static generic IPs also emit spam and abuse. Finding all the dynamics on the Net would only stop from half to maybe two thirds of the traffic we see, for example. http://enemieslist.com/news/archives/2009/07/why_we_suspect.html 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/
Re: best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
On 12/10/2009 07:54 AM, Steven Champeon wrote: In a nutshell, if you're not clearly indicating mail sources as mail sources, don't expect great deliverability. If you're running a Web hosting shop and don't have rate-limited outbound smarthosts, expect all your clients' mail to be suspected of being phishing scams. If you run a corporate network that allows unsecured outbound port 25 via NAT, you lose. If you run a university network (or part of one) without clearly distinguishing between server infrastructure and student-use end nodes, you really might want to rethink that. And if you're a consumer ISP that allows both static and dynamic assignments or serves both residential and commercial under the same useless generic naming convention, you are Making It Harder for the rest of us, which is an automatic upgrade path to reflexive blocking of all traffic. Oh, and if it's out of your control or what you consider your responsibility, SWIP it and label it clearly so we can figure out what it is and decide whether we want it as part of our view of the Internet. Keep your whois up to date and indicate if nothing else whether a given block is static or dynamically assigned, residential or corporate. I'd say that Mikael Abrahamsson's sentiment (or at least the way I read it) would be a better start: take a step back and ask what the problem is. Naming conventions blah, blah, blah all started from the _lack_ of a standard and trying to educe knowledge from chaos. In other words, a bunch of hacks. Which doesn't work especially well, especially when every RBL has its own hack. If IETF can do something here, which seems plausible, it would be to actually define the problem and _then_ write a protocol to fit the needs of the problem. Maybe it's using DNS, maybe it's not. Maybe it uses naming conventions (ick), probably it does not. But if it were standardized, it would at least be predictable which the current situation manifestly is not. To Crocker's point though: if IETF came up with a way to publish your network's dynamic space (assuming that's The Problem!), would operators do that? Or is this another case where the energy barrier is too high? Mike
best practices for PTR naming and whois (was, sadly, Re: Arrogant RBL list maintainers)
on Thu, Dec 10, 2009 at 09:29:15AM -0600, Sam Hayes Merritt, III wrote: > >> Creating a standard on what to put in WHOIS/DNS for >> dynamic/static/infrastructure would make a lot of sense, seems nobody is >> doing it though. > > As previously noted in this thread, msulli...@sorbs did a fairly good job > of documenting this in an RFC draft. I'd say its still the primary goto to > point people at for how to do things the "right way". > > http://tools.ietf.org/html/draft-msullivan-dnsop-generic-naming-schemes-00 There's also Dan Senie and Andrew Sullivan's draft: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06 ...which basically boils down to "if you're not using rDNS to project a clear picture of the intended uses of a given IP, you're screwed". Or maybe that's just my read. I've written up my thoughts on naming and why it matters in a series of posts on my Web site; this is the cumulative wisdom acquired after six years or more of collecting and attempting to classify naming conventions worldwide. We're at close to 47K patterns for over 18K domains worldwide, so I think it's safe to say I've seen my share of this stuff and can draw general observations. In a nutshell, if you're not clearly indicating mail sources as mail sources, don't expect great deliverability. If you're running a Web hosting shop and don't have rate-limited outbound smarthosts, expect all your clients' mail to be suspected of being phishing scams. If you run a corporate network that allows unsecured outbound port 25 via NAT, you lose. If you run a university network (or part of one) without clearly distinguishing between server infrastructure and student-use end nodes, you really might want to rethink that. And if you're a consumer ISP that allows both static and dynamic assignments or serves both residential and commercial under the same useless generic naming convention, you are Making It Harder for the rest of us, which is an automatic upgrade path to reflexive blocking of all traffic. Oh, and if it's out of your control or what you consider your responsibility, SWIP it and label it clearly so we can figure out what it is and decide whether we want it as part of our view of the Internet. Keep your whois up to date and indicate if nothing else whether a given block is static or dynamically assigned, residential or corporate. Full archive here: http://enemieslist.com/news/archives/gripes/ Of particular interest, perhaps: http://enemieslist.com/news/archives/2009/06/principles.html http://enemieslist.com/news/archives/2009/06/basic_principle.html http://enemieslist.com/news/archives/2009/06/basic_principle_1.html http://enemieslist.com/news/archives/2009/06/basic_principle_2.html http://enemieslist.com/news/archives/2009/06/a_few_thoughts_1.html http://enemieslist.com/news/archives/2009/07/why_we_suspect.html http://enemieslist.com/news/archives/2009/07/a_passionate_cr.html but the whole archive is full of examples of DNS stupidity, for your enjoyment, and as an expression of years of pent up frustration. ;) Cheers, 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/
