SORBS on autopilot?

Steven Champeon schampeo at hesketh.com
Tue Jan 12 17:42:58 UTC 2010


on Tue, Jan 12, 2010 at 11:51:47AM -0500, Jed Smith wrote:
> The vibe I got from a number of administrators I talked to about it
> was "why would a standards document assume an IPv4/IPv6 unicast
> address is a residential customer with a modem, forcing those with
> allocations to prove that they are not residentially allocated rather
> than the other way around?"

Well, of course. Any idiot can tell just by looking at any PTR that the
IP to which it corresponds is obviously an IPv4 unicast address! I think
they teach that in elementary school now. I know I got high marks on how
to identify mail sources hidden behind NATs, ISP-outsourced university
residential network blocks, and snowshoe spammers using burner domains
with hostnames "borrowed" from real hosts in other domains. But there
was this one kid in my class who simply couldn't see when a host with a
IP-derived, hexadecimal generic name was obviously a broadcast address.
Poor guy. Even when it emitted spam he had trouble seeing that it wasn't
actually possible, because clearly the PTR is always correct.

OTOH, those of us who were out sick when they dealt out the magic PTR
meaning decoder rings need a little more help. If I had my way, all PTRs
would be clear, unambiguous strings of tokens that indicated their use,
their assignment type, the technology or technologies in use, and so on.

In reality, we have names like these to contend with (naturally, this
example's IP whois simply indicates it's part of a /16):

183.87.5.131.static-dynamic.nivyah.com [183.87.5.131]

And if you're trying to classify such naming conventions, as I do with
my Enemieslist project, or if you're trying to build and/or maintain a
DUL, as Michelle does, well, that sucks.

It's far better when the naming is clear, eg

u1524.spam-source.sprintnet.ru [81.22.1.89] 
n081022008237.avoid-mail-from-theese-hosts.sprintnet.ru [81.22.8.237]

or, more informatively:

host-79-141-236-93.dynamic.pptp.planeta.starnet.ru [79.141.236.93]
host-94-102-86-87.static.pppoe.planeta.starnet.ru [94.102.86.87]

or, because there's always a joker (both names have since been updated):

alameda.net.has.not.owned.this.ip.for.more.then.four.years [209.0.51.16]
this.ptr.is.named.in.honor.of.arin.nac.net [66.246.175.3]

(heh)

just to pick a few. At the very least, customer-assigned blocks ought to
have a SWIP and a comment showing whether they're dynamic or static,
residential or business class, and so forth. A surprising example, given
the paucity of such examples in the .pl TLD, is dialog.net.pl, which does
exactly that:

inetnum:        87.105.24.0 - 87.105.24.255
netname:        DIALOGNET
descr:          Static Broadband Services
descr:          Telefonia Dialog S.A. - Dialog Telecom
country:        PL

inetnum:        62.87.215.0 - 62.87.215.255
netname:        DIALOGNET
descr:          Dynamic Broadband Services
descr:          Telefonia Dialog S.A. - Dialog Telecom
country:        PL

So, if the Poles (well, some Poles) can do it, why can't we simply end
the endless back and forth over why SORBS is evil, and start adopting
sane and clear naming conventions for PTRs? Given how easy it is to
modify a $GENERATE statement, I should think you've spent far more
energy on arguing about why you're being wronged than it would have
taken to fix your problem.

-- 
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 mailing list