[120131] in North American Network Operators' Group
Re: best practices for PTR naming and whois (was, sadly,
daemon@ATHENA.MIT.EDU (Mark Andrews)
Thu Dec 10 11:38:44 2009
To: Michael Thomas <mike@mtcc.com>
From: Mark Andrews <marka@isc.org>
In-reply-to: Your message of "Thu, 10 Dec 2009 08:11:18 -0800."
<4B211DA6.9000203@mtcc.com>
Date: Fri, 11 Dec 2009 03:38:00 +1100
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
In message <4B211DA6.9000203@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: marka@isc.org
