Re: Arrogant RBL list maintainers

[Steven Champeon <schampeo () hesketh com>]

on Wed, Dec 16, 2009 at 06:01:51PM +0100, Michelle Sullivan wrote:
> ...and if people used "static" and "dynamic" keywords in DNS as I
> suggested in my previously mentioned draft, there would be *NO NEED*
> for DUL/DUHL/PBL lists at all because people could create a very
> simple set of patterns to match and therefore the RBLs would be
> unneccessary.. (and it would save me about 10 hours a day, every day
> of the week, every week of the year!) Currently I have a few 100
> patterns and I know another on this list has more like the region of
> 10k patterns to do what in reality one should be able to do in 2 (10
> at the most!). At 10k patterns it becomes a lot cheaper to use
> DUL/DUHL/DYNABLOCK to block dynamics, does anyone wonder why people
> do?

10K? Ha! Try 47086, as of the most recent release. Of course, those are
all fully-qualified, and we deal with a much broader spectrum of
classifications than just 'dynamic/static', because that a host is
static doesn't mean much these days.

As for the idea that you could make do with 2 patterns, as I've said
elsewhere this is incredibly wishful thinking and Anglocentric, to boot,
but the principle behind proper labeling is sound in a general sense. It
just doesn't happen to be that way in the real world, which is full of
non-English speaking netadmins and varieties of assignment beyond a
simplistic "dynamic/static" split.

For instance, resnets, which are usually statically assigned to a room,
but not a given computer from one semester to another. Or my "dynamic"
cable modem IP, which I've had for years, through four changes in our
"static" office numbering/naming (three moves, four providers). Or NATs,
which are static but allow dynamic users behind them to emit and receive
traffic. Or Web hosts, which have the shared reputation of dynamics (on
shared hosting, anyway). Or cloud computing, which is a dog's breakfast
of mixed static ("elastic") and dynamically instantiated entities
(though some simple efforts to clarify which are which in the PTRs would
help that somewhat).

Steve

-- 
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/