Arrogant RBL list maintainers
schampeo at hesketh.com
Thu Dec 10 10:15:10 CST 2009
on Thu, Dec 10, 2009 at 07:43:36AM -0800, Dave CROCKER wrote:
> On 12/10/2009 7:29 AM, Sam Hayes Merritt, III wrote:
>> As previously noted in this thread, msullivan at 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".
> The time to pursue something like this in the IETF is when there is a
> substantial industry consensus that it is the right approach and that the
> folks supporting it will actually use it.
> Are those of you who have participated in this thread willing to conform to
> the model specified in this draft?
That draft has a few issues; perhaps foremost is the Anglocentric choice
of names. Why should a Pole care to name his poczta "mail"? Or a Brazilian
name his "correio" using an English term? But that's a minor point, and
there aren't *that* many variations on "mx" vs "mail" vs "smtp", etc in
non-English languages. If anything, I'd have liked to have seen a more
widespread use of the protocol as a canonical name for a box providing
service for that protocol, but www's ship sailed a long time ago...
M. Sullivan's proposals for the most part, however, conform to the best
of current practice as far as I can determine from having looked at
several hundred thousand hosts and tens of thousands of naming
conventions over the past few years.
There are probably ways the proposals could be expanded to cover other
edge cases or to conform to current practices (properly naming NATs, VPN
hosts, University resnets, "vps" instead of "shared", perhaps, dealing
with "cloud" computing, Web and other proxies). And there are certainly
plenty of other network situations that might be covered in a future
draft, certainly more than I could describe here.
The bottom line is that people *are* using rDNS/PTR naming as a means to
help them determine policy. It's not abstract, it's happening. I'd love
to see some way to define emission policies for a given netblock that
could be queried in real-time, by the receiving services, but I suspect
that's a long way off. Until then, clear and informative labeling is
the best way to go.
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/
More information about the NANOG