In message <[email protected]>, Michael Peddemors <[email protected]> wrote:
>Of course, we are supposed to 'report it to hostmaster', but after many >such reports, and seeing no effect, it makes it hard to bother with >reporting it.. Yes. Statistically speaking, it has appeared to me that approximately 98 times out of a hundred, any report regarding either an utterly non- functioning rwhois server and/or big swaths of spammer-infested IPv4 space where the IP blocks are clearly and provably "live" (and spewing spam) and where the relevant rwhois server simply returns -no- information, such reports are greeted with abject silence and no change to anything whatsoever, even when allowed to percolate for a week or more. And indeed, the problem is getting worse. The latest, biggest, and most disappointing such failure is for the entirity of 38.0.0.0/8 aka rwhois://rwhois.cogentco.com:4321 which appears to have been recently emptied of -all- information, with the exception of a single common one-line greeting banner. But that is just one example. If pressed, I'm quite sure that I could cite innumerable others in short order. I come across these broken (or deliberately disabled) rwhois servers every day now, and often multiple times each day. (Sometimes, I can't help but think to myself that the relevant providers might just as well hang big signs around their necks saying "Yes, we know that we are harboring snowshoe spammers, but they are paying us not to let on to anyone who they are.") >We see daily bad SWIP entries, entries pointing to bad or non >functioning 'rwhois' servers, and without the 'stick', that is unlikely >to change. Quite so. >Maybe an independent movement to 'blackhole' IP space with bad SWIP >practices?? (not entirely kidding) It isn't always done with malice, and is, in my opinion, just as often done out of carelessness, laziness, or a simple failure, on the part of the lowest-level operational worker bees to understand or even be aware of the ARIN requirements. Over time, at a lot of these places, management changes, ownership changes, and worker bees come and go or are swapped out for newer ones, and the internal company memo about the ARIN requirements gets lost in the shuffle and ends up in the dumpster out back. There are never any downside consequences, and thus, the overworked and underpaid worker bees focus their daily efforts on keeping the network running and all of the customer machines up, just as we all would, if placed in similar positions. I might be tempted to suggest that perhaps John C. and his team might possibly be able to render some useful service with respect to this large and growing problem, via something that would fall well short of any kind of formal "enforcement" action... e.g. just sending a polite/ friendly email to the relevant provider in each case, asking them to please consider turning their rwhois servers back on... but I'm afraid that there would likely be resistance, both in the community and from ARIN itself, to having ARIN do even that sort of minimalist thing, because ARIN has not been explicitly tasked to do it, formally or otherwise, by the community. On the other hand, if ARIN -were- ever so tasked, they wouldn't need to go out searching for providers with broken or non-functioning rwhois servers, as I could, and would, gladly, email them a daily stream of reports of exactly such providers. (Remarkable as it may seem to some, real-world experience indicates that there is a dramaticaally high degree of intersection/overlap between the set of providers that, on any given day, can be shown to be hosting snowshoe spammers, and the set of providers that, on that same day, are demonstratably failing to run a functioning or useful rwhois server or to use WHOIS/SWIPs to properly document their sub-allocations. I know what you're thinking... "Gee! Who woulda thunk it?"... Right? :-) Regards, rfg _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
