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/